Change of Plans

Well, I am glad I was playing with those other programs before I tried to make something as complicated as my tank shooting game. While I really like python and think it has great potential, I have found some of the drawbacks. Before I go into those, I would like to mention some of the highlights of the language since it is quite convenient in many respects. Probably the nicest aspect compared to Java and C is that python has duck-typing. The file i/o is a breeze compared with all the buffers some other languages use; and the networking with need to use sockets and other complexities was also nice. Now for my complaints: problems with class instancing and initializing data. While writing the GEDcom converter, I allowed for a person to have multiple later in life families by setting that type of family to be stored as an array. While running the program, I found that while I meant the array to be per individual, I was creating a global array where each person was adding to the array. Another aspect I could not work out is why most of my parsing code worked fine while one check did not return the right data, but I am going to say that was on my end and not blame python for that. So that was my big complaint, the array not working as I had wanted it too, and I know it has something to do with the odd way python works with classes, but that is for another time, hopefully in a future version this is remedied. My other complaint is that python insists that when defining members of a class they be initialized, which is fine since I understand the need to know how much space to allocate. But python does not support multiple constructors, which makes it hard to have a blank class place holder in the definition and then create a class with some variable. I know this is nitpicking but I really found this to be a hassle (I have been using Java for years which is why I am used to multiple constructors).

So where does that leave me? With a big choice, what language to try to do this project in next? My main choices were C and Java. Java has its advantages in a built in method of creating a graphical interface, but I have never really liked the way it looked. So I looked for graphics engines, and found one I think I like. It is called Ogre, and I believe it runs code written in C++. Not quite one of my two choices, but it will work well enough if this engine does what I am hoping it will. This is going to involve a lot of work before I even start on the main project, since Ogre comes with a ton of predefined classes. So far I have made it through the first two basic tutorials, slightly cheating on the second since I did not find a black ninja in the dark a very fun thing to look at (as it turned out, I needed to move the mesh file to render the ninja which I would not find out looking at a black screen). Currently I am using a Pentium 4 computer running Ubuntu 10.10 to do all of the programming work, but if it becomes too much for that computer - the ninja with three lights casting a shadow, though it was the most complex shadow, had it between 8 and 18 frames per second - I may need to move over to my main computer, which is Windows which I was avoiding since I do not really like the setup of Visual Basic, as odd as it sounds I like the basic text editor.

And now a bit about the game:
I was going over what I have posted so far in my head earlier today and realized I missed a very big part of the game play experience. Every tank is electrically powered and has a certain bettery life (it can be slightly expanded but I will get into that more when I expound on the different modules). While near the base and friendly reconnaissance points the battery charges until it is full. Outside of those areas, the battery begins to drain, with a Warning state (75% movement speed) at 25% and a Critical State (50% movement speed) at 10%. These two altered states keep the battery alive slightly longer, and I may include an option on the tank customization page to override these states which would drain the battery at a constant rate, but once the tank looses all battery power it stops. The tank does not loose weaponry, but cannot move the turret, so as long as the opponent moves out of the line of fire, the stationary tank is sunk.

Disconnects and logging off each leave the tank on the field for 10 seconds. During this time the tank is vulnerable to enemy attacks, so watch where you are when you log out, best done inside the base.

One final bit is the recharge rate of the base and reconnaissance points. These are not unlimited, but rather start with 100 slots. For each module refilled (mostly mines, missiles and other one-use modules) the point looses 1 slot. For bases slots will regenerate every 15 to 30 seconds depending on how testing works out - players entering and respawning will each eat some of the slots, so this will need to be a fairly quick regeneration. Reconnaissance point will like be on the order of a minute of so depending again on testing feedback.