First Implementation Considerations

Deathworks on 2007/09/01 08:46 of Deathworks

Hi!

This entry is just my rant about what considerations I have made about the game to be created. In accordance to the rules, I haven't done any coding, but I have considered some general aspects about the code.

I am now determined to make a small RPG. It does seem like the simplest thing for me to do.

So, I have been brainstorming abstractly what I may need.

Initially, I considered hard-coded events, but the more I think about it, it seems like a really stupid idea. I would only create a completely obscure monstrous source code that even I won't understand the next morning (^_^;;

Implementing a really proper and nice-looking event system is clearly not possible in such a short time (My calculations are - because I have internet only until Thursday afternoon - that Python programming must be finished by Tuesday morning at the latest, so I have one day to do content expansion). Besides obviously implementing only the minimum functions, I guess that using separate files to store text (like in message boxes) would be the best way to handle things since I don't need to work with dynamic length arguments in the file loader for the event proper.

After having determined that, I also figured that handling saves may be easiest using a similar method, splitting the data that needs to be saved into several files put into a common directory. So, I have to check what functions (preferably in the default library or wxPython (^_^;; ) can be used to handle directories (I remember seeing a function that can check whether a directory exists or not, and I think the FAQ over at python.org mentioned something about how to delete files).

It will be interesting to work with dictionaries and arrays (ah, I just checked the documentation, you call them lists here (^_^;; ) simultaneously. The way I see it, dictionaries are most efficient when dealing with index data provided as a string, which would be the default for anything read from a file, whilst arrays work best if I had numeric index data. So, during implementation, I am going to examine which kind of index data is more likely for each candidate and try to choose the type accordingly.

Originally, I considered allowing only exactly screen-sized maps, but I reconsidered, figuring that the benefit in terms of game fun of having things you find only by going to the edge of the map clearly outweight the potential trouble the few lines of extra-code that would require (I would need variable sized maps and would need to handle centering and being close to the map border; all of these should be easily implemented, but since they increase the amount of code, I consider them basically a liability).

I also spent a little thought on speed vs. memory concerning events, figuring that memory is more important.

The thing is, event files need to crunch the event data quite tightly, while interpretation is likely to benefit from cutting it into smaller pieces for easy handling and reference. The question I asked myself was whether I would want to have that cutting up into smaller pieces take place for all events when they are loaded (in effect when a new map is entered), or only for one event when it is accessed.

Converting all events upon entering a map would be time-efficient since conversion happens only once, but it would probably waste a lot of memory because each event would be cut into dozens if not hundreds of tiny strings (which are bound to have a bit of ID and processing stuff added by the system).

Converting only the current event clearly saves memory since only one converted event is kept in memory, but it means that conversion has to be done again and again, every time the event is triggered.

I figured that conversion is probably not so slow a task as to hinder gameplay, so I figured that preserving memory should have a higher priority.

Concerning the completely unintuitive handling of globals and locals in Python (yes, I do believe that giving spontaneous overriding priority over access is not an intuitive system), I guess the safest way is to access globals always using the __main__. terminology, even if they are on the right hand side. I find it simply odd that, when working within a given code block, I can address a global by (name) if it is on the right hand side, but need to write __main__.(name) if it is on the left hand side. Two different notations for the same variable seem to be unnecessarily confusing. Thus, I will always use the ugliest, but unfortunately only universal terming.

During the brain storming, I figured that I may want to do an HTML manual. This should be relatively portable (although I will not do any IE/Netscape/Whatever compatibility code or any Javascript at all (^_^;; ) and allow for giving detailed instructions in an easy-to-read fashion. If you are now raising concerns about the time, that is already considered: The last phase of the development (Wednesday to Thursday afternoon) is playtesting/debugging. This means that I am basically on standby, only modifying the program or its data in response to bug reports. More likely than not, that means that I have some periods of interactivity where I can't do anything. That time would be ideal for working on the instructions since they would have no impact on the bugs in the game and it needs to be written last anyway, since it should describe the features the program has, and not those I wanted it to have at the start of the programming.

Finally, I think it is a good idea to add a lots of comments. I figure that during programming and debugging, time is a luxury. And with the amount of programming/coding I will have to do on the first day, it is quite likely that I will forget many of the details I came up with during the process. So, by Tuesday, large parts of the code may be completely obscure even to myself if I don't comment them properly.

Besides, this competition is meant to help build a code base for Python. While I don't think that my code will be briliant or something, I do believe that people will be able to learn from it - but only if they understand what I am doing or trying to do.

In addition, library/engine images are a pet peeve of mine. It is frustrating me to no end that Kirikiri, which is basically C++ without the portability (to be implemented in the next release) and without the 300+ error messages if you don't tell the compiler your computer sucks at chess and you like the color green beforehand, is generally considered a dedicated digital novel engine. Kirikiri's standard functions offer all you need for many types of game and other applications, but its distribution includes KAG (Kirikiri Adventure Game system) which is a dedicated digital novel engine written in Kirikiri.

Similarly, I see people talking about PyGame all the time for game programming, but I think that wxPython may actually be easier for certain game genres to use (RPG being top because of the default joystick/pad availability, but also strategy (not RTS, though) and simulations). And as I mentioned elsewhere, wxPython also comes with really good and helpful installation instructions (not to mention a seemingly comprehensive and helpful demo, which needs to be downloaded separately, but which is really worth it.).

Mind you, I am not saying that PyGame is no good. It is simply that I believe that it is more suited for action and RTS types of games while things like wxPython may have advantages when trying to do other genres (actually, I find it really odd that Ren'py is based on PyGame (^_^;; ).

I think I will implement a few simple spells, so that levelling the character results in new options (and so that combat becomes less monotonous). But I will quite obviously not implement event spells (spells triggering special event code), instead sticking to simple healing and damaging spells and their kin.

At the moment, I think animation is most probably not to be implemented since it would increase the amount of artwork required too much. I realize that this is a painful decision because animated characters are something players expect of an RPG, but with these time constraints, it is just illusory (^_^;;.

I may use sound effects (not sure about that), but no music since I would be limited to WAV if I wanted things to be fully portable (wxPython has a command for playing general media, but that is not supported yet by Linux, I think). Besides, musics is not really my field, I am more with graphics :) :) :).

Well, these are all the considerations I have made thus far.

def myfunction():
   __main__.someotherfunction()
   instance = __main__.SomeClass()

foo = "Something"

def myfunction():
   global foo
   foo = "else"

class A(object):
    pass

B = A

class x(object):
   pass

def foo():
   x = f(x)

square = lambda x: x ** 2

B = type('B', (), {'foo', 'bar'})