Survivore - Computer Edition

[Deathworks]

Hi!

This here will become the development thread for the computer edition of Jurodan's "Survivore: The Card Game".

I think the suggestions section is the right place for this thread, since it will be open for any ideas and suggestions people may have.

Related threads are:

New Vore Card Game : The thread where Jurodan originally his (? sorry, I am not sure about that) concept for the card game.

Looking for collaboration (game) : The thread where I was looking for someone who needed a programmer for a vore game.

I will add more information to this thread after I linked updated the information on my 'search for collaboration' thread.

Deathworks

[Deathworks]

Hi!

Okay, the links and information are out, so let's start filling this thread here with information.

First of all, the engine I will be using is Kirikiri (吉里吉里2, to be precise). It is a Japanese multimedia programming engine using a script language extremely similar to C++. For further information on it and downloading it (not necessary if you simply want to play the game or make suggestions), see its homepage(Japanese!). The current stable version of the engine is 2.26 rev.2.

Secondly, this thread here will be used for just about all information exchanges about the game. Please do not pm me if you have any suggestion or anything else for the game project itself. Unlike a digital novel or an RPG, a card game has no secrets (with the possible exception of computer enemy styles). Therefore, it should be no problem to have any ideas and suggestions posted here in the thread.

Once I have first testable routines, I will upload them to this thread to get alpha testing. Kirikiri has two ways for handling finished programs. You can have all the data and the runtime converted to a single exe file, or you can have data as a special packaged file while the exe will only contain the runtime. In order to save download capacity, I will choose the second method. After initially uploading both files, I will only upload the new data package for updates. I consider this the best solution since one of the few disadvantages of Kirikiri is that its runtime package is comparatively big.

In addition, I am also planning on releasing the source code as well. I believe that this has several advantages:

1. People can help me debug.
2. If someone wants to port the game to some other language/engine, like C++, the original source code might come in handy.
3. Fledgling programmers can learn from my mistakes or my ideas. In addition, they can see Kirikiri source code, perchance helping them get a grasp of it.

BTW, the system requirements for Kirikiri are listed in the readme.txt as at least a Pentium processor, Windows 98/98SE/ME or Windows 2000/XP and at least 65536 colors.

In the same way, I would like to see all material contributed to the project uploaded to this thread. This does include graphics or sounds provided by Jurodan. Again, this is in order to encourage suggestions.

About suggestions, please understand that there are basically two limitations for suggestions: Jurodan and me. This is Jurodan's game, so if something doesn't fit into Jurodan's vision for the game, I won't implement it. You are free, of course, to try to convince Jurodan. In order to save time and effort, I think this will by and large be a veto kind of thing. When a suggestion is made, I will say that I like it and will probably implement it as soon as possible. If Jurodan does not object, I assume that it is okay. Note, however, that as soon as Jurodan objects to a given feature, it will be scheduled for removal in the next implementation of the game. The second limitation is me, because if I don't know how to program it or can't test it, I can't implement a feature. So, networking features are a no-go because I can't test them.

Basically, any support is welcome. It can be suggestions for features, for cards, it can be graphics, musics or sound effects (the latter two depending on how the game(read: Jurodan) will stand towards that kind of stuff.), it can also be in the form of programming advice.

However, the project will follow a rough route, so at given times, certain suggestions will not be implemented immediately. For instance, deck management and card shop are features I want to deal with later in the development since they are not as essential as the card battle proper. So, regardless of their quality, no contributions concerning the card shop will be implemented in the first test versions, simply because the shop doesn't exist.

I am not a professional programmer, and I am still lacking in experience. I think I can successfully program this game. Most things shouldn't be a problem. The only feature I have absolutely no experience with and am not yet sure about how to do it is the enemy artificial intelligence (how the computer decides when to play which card). Therefore, I am sorry, but I can't guarantee the quality of the enemy AI. I will try my best, but that is the one aspect where there might be a weakness. Thus, once I get to designing the AI, any advice on it will be more than welcome. All the other aspects of the game should be alright, judging from my first impression of it.

Finally, Christmas is around the corner. During the period between Christmas and New Year, I will probably suffer from limitations on my internet access. Thus, I won't be able to respond immediately to developments here on the thread. In addition, at least during Christmas (probably 23rd to 26th) I am expected to stay at my parents' place, so I won't be able to do any programming or debugging during that time (sorry, my personal machine is not a laptop). Thank you for your understanding.


Okay, now that the basics are somewhat settled, let's set the course. The first thing I want to work on is the card game proper, that is playing the card game itself.

The thing I need to develop first is a format for the card data, so sample cards of the four categories would be high on my wish list. Mind you, I am not foremost talking about the graphics, but rather the cards' statistics and what they do.

Speaking of graphics, there are also some basics we need to settle there. Personally, I am a great fan of Full Screen, so I strongly recommend using a full screen format like 640x480, 800x600, and the like. Whether the game runs in full screen mode or not can be made toggable by the user, so people not too fond of full screen can also be satisfied. Therefore, I suggest to go with either 640x480 or 800x600. I believe that should be big enough to allow for detailed graphics yet small enough to run in a normal window for those who don't like full screen.

Besides the card structure, the other thing that needs to be developed first is the game play structure, that is, how the game advances. Given the phase structure Jurodan provided in the original thread concerning the card game, I guess we would be on the safe side by following that structure.

Then, there is the issue of the screen layout and input layout. Since I am under no obligation to draw the graphics, from my point of view, anything is possible for the graphics :) :). But seriously, personally, I think a graphic frame works wonders for a game, so my suggestion would go in that direction. As for the input layout, I strongly recommend allowing both keyboard and mouse input. Alternatively keyboard only would also be an interesting idea. I think mouse only is a bad idea since keyboard controls are simply the most reliable in my opinion for this kind of game. Kirikiri also supports game pad input, but given the limitations of game pads, I suggest not to include it in the original planning. Once the game works and we find that we need only a very limited number of action buttons, game pad support might be added.

Well, I guess these are my first thoughts on the project for the moment. I hope this is enough to encourage people to state their thoughts and opinions.

Deathworks

[Deathworks]

Hi!

One thing I forgot: Unless Jurodan objects, anyone contributing to the game, be it complete cards, graphics, or even just ideas will be mentioned somewhere in the helpfile as well as in the game's credits, once proper release versions of the game are created. Details of this mentioning will be determined once it is being done.

Thank you for your understanding that the incomplete test releases will not include that honorary mentioning.

If you don't want to be mentioned, you are of course free to request remaining anonymous.

Deathworks

[Geno]

Well I for one really like the card game idea. It is very straightforward and would easily be lots of fun. I would love to help out with art or card ideas, but I'm unsure if I should be posting card game ideas here, or if I should direct those to Jurodan's original thread. But just so we're clear, I approve of this game and want to help!

[Deathworks]

Hi!

Geno: First of all thank you for your support. As for where to upload such ideas, I think I will leave that to Jurodan to decide. If you upload information that could be useful for the game development here to the other thread, just make sure to write a short message in this thread here as well, so that I know I should look for goodies in the other thread.

As for graphics, it may very well be that we need slightly different sizes/formats between the two versions. Half of the physical card is taken up by the text and flavor text, while the computer version lends itself to the possibility of card size images (but that is not decided yet).

Now, for more general information.

One rule I forgot to mention is the copyright infringement rule: if any of the contributions here to this thread contains graphics or other artwork that is being redistributed without the artist's permission, I will put all work on this project on hold until it is removed. Since this is Jurodan's project, this rule extends for Jurodan. Should I find Jurodan knowingly contributing stolen art, I will abandon the project for good. I am doing this because I want to do something good for the communities. If you don't care about the fellow members of the communities, I can't see how your actions could be honestly beneficial for the communities. If someone wishes to discuss this issue with me, please do so in another thread or via PM.

My previous posts may have been a bit misleading. In order to do proper programming, there has to be a good planning stage first. If we don't know what the program is supposed to do, we can't program it, right? So, it may be a while before I upload the first test routines.

As for the things I need now, concerning card data, sample data as well as general guidelines, like for instance "Pursue has a minimum value of 0." is what I am mainly interested in at the moment, so I can get the data structure straight.

Concerning the structure layout, I will give a bit of an example, using some of the easier phases of the game:

Reinvigoration Phase (Player Side)

Displays cards that do not reinvigorate in the left half of the screen, one at a time. If the failure to reinvigorate is caused by another card, that card is displayed in the right half of the screen. If more than one card is involved, only one is displayed at a time.

The player can get detailed information about the cards displayed, page through the cards if more than one card is on the right hand side, or choose continue to have the next card displayed.

This phase can be tuned via the game options:
* Display All (Default)
* Don't display digestion (Do not list cards that don't reinvigorate because they are digesting)
* Skip (Do not display any cards, in effect don't have any messages during this phase)


Survival Phase (Player Side)

In this phase, each character card the player has in play is displayed in the left half of the screen, one at a time. In addition, a text informs about how many Survival Points are gained.

If the number of Survival Points is altered by one or more cards affecting the character, these cards are shown on the right hand side of the screen, one at a time.

The player can get detailed information on the cards currently displayed, page through the cards on the right hand side, if there are more than one, or choose continue to see the next card on the left hand side.

This phase can be tuned via the game options:
* Display All (Default)
* Don't display 1 SP (Do not list characters who produce just the default 1 SP)
* Skip (Do not display any cards, in effect don't have any messages during this phase)


You don't need to be as detailed, but having this much information would be helpful. These examples are still just rough suggestions, so there is a lot that can be said about these and the other phases.

Note that you can also use sketches and fake screenshots to better explain what you envision.

I made a very quick and dirty sketch for the Reinvigoration phase, just to illustrate this possibility. Hopefully, the graphics we will be using in the game will be of much better quality.

For those curious about what the first coding will be about, I can say as much that the first routines I will eventually do will probably be loading card data and deck data and then displaying card data information for cards currently not in play. But before I can do that, I need to know what information the cards contain and how things should be presented in the game. So, planning first, coding later :) :) :)

Deathworks

[Geno]

Okay, I do like the idea of showing off one card at a time to help clearly explain everything, especially since space is too limited to just try to show everything at once... But this kinda makes me wonder how we're going to show the player's hand when they want to play cards... Perhaps show one card with an arrow on the side to cycle through? And what about locations? From the get-go there are 10 locations out, and their placement is important, so it can't exactly be "cycled through" like the player hand could. Any ideas?

[Jurodan]

Ok! I'll be looking this over when I get back later tonight, but it LOOKS about right.

[Deathworks]

Hi!

Geno: Basically, that is why I say the first step is a brain storming phase where we collect all suggestions we can get.

As for the player's hand, when actually choosing a card, I suggest going through the hand one card at a time. You are right, my sketch would have needed arrow buttons on the right hand side to simulate the multiple cards situation.

While viewing something else, I could imagine using small icons to give an overview over the hand effectively like the upper left corner in Cartovore 2.

Basically, I suggest to cut up complex actions into successive stages. For instance, let's say you are in your main phase. The default would be the map view where you see some of the locations in play. From there you can choose to get more information about a certain location or access your hand. To play a new card, you access your hand then go through it until you have reached the desired card (if there is an overview, that might be used for a short cut). The you choose to play the card. This brings you into the next stage, namely target selection. During that phase, you are able to choose the target card for the new card. Once you confirm your choice there, the card is played.

Please note that I can use several screen layouts, so each stage can have its own individual screen design to match its specific needs. Theoretically, I could even change screen resolution during game play, but would prefer not to do so. So, feel free to suggest what you consider the best layout for each task individually.

As for the map screen, using size-reduced versions of the location cards to show one section of the map at a time seems the best approach to me. The size of the section would depend on what sizes we choose for the screen and the miniature cards. My suggestion would be to center the display on the currently selected location card. This would make for relatively straightforward controls for both mouse and keyboard. If there are characters at a given location, there will be markers on it. The minimum would be to have markers that inform about the presence of enemy characters and player's characters. If that information is not available, I think the game becomes unnecessarily confusing. In addition, it may be considered to somehow give information about the number of creatures for each side present. While this information would be neat, I don't think it is essential. The main issue I have with it is finding a way to display it without looking boring, confusing, or taking up too much of the screen.

Jurodan: Take your time. The design for the reinvigoration phase was merely a crude example of mine. I hope that we get some people helping with the brain storming, so that we have many concepts from which we can then choose the one that is best to convey the feel of the game. There are still tons of details and designs to create, so you better take it easy.

Deathworks