Here is the next set of modules. Actually missiles only have a single item which uses modules: the Missile Chambers. The Missile Chambers requires two modules to install. Once installed, the user can select how to arm each bay. For each bay, a drop down list is given, from which the user may select the desired missile. There is no limit to the number of Missile Chambers available. The following are the different types of missiles.
* Force Missile: This missile fires at whatever the tank's turret is pointed. This missile does massive damage on a successful hit, but is one of the harder missiles to hit with. This missile travels at average speed.
* Guided Missile: This missile has an interesting movement where the player's camera switches from their turret to just behind the launched missile. The player looses the ability to control the tank while the missile is airborne, but gains the ability to control the missile itself. It does slightly less damage and travels at a slower speed than the force missile.
* Homing Missile: This missile will fly as straight as possible from the tank's turret, but may change course slightly to follow an enemy tank. Much like the guided missile, these do slightly less damage and travel slightly slower than the force missile.
* Jamming Missile: This missile travels in a straight path aimed along the tank's turret. Unlike most of the other missiles, this missile damages the opposing tank's shields temporarily, all;owing the attacking tank an opening with either other missiles or lasers. This missile travels slightly faster than the force missile.
* Kore Missile: This missile also follows a straight path aimed along the tank's turret. The goal of this missile is to create a disruption in the enemy lines by launching a massive electromagnetic pulse over the enemy. Once launched, the player's camera switches to a view from behind the ,missile, much like th4e guided missile. During that time, again like the guided missile, the player's tank is left vulnerable and is not controlled by the player. The difference is the player does not control the missile, just when the missile detonates. From the center of the explosion, an EM pulse deals splash damage any opposing tank's battery life inside the radius. This missile does nothing if it hits an object unlike most other missiles. This missile travels faster than the force missile, only slower than the lightning missile.
* Lightning Missile: This missile is in many ways similar to the force missile. It goes in a straight line from wherever the tank's turret is pointed. It does slightly less damage than the force missile, but is harder to avoid since it moves quicker.
All missiles, unlike lasers, are objects, whether or not they are controlled by the player. The force missile is pretty much the average missile and is therefore used as the comparison in the previous list. Guiding and Homing Missiles, since the can change direction, are slightly slower to benefit the person who fired them, whereas the Kore and Lightning Missiles are faster. Any collision, either terrain, a tank, a satellite or another missile, will cause the missile to trigger is firing sequence, except the Kore Missile which needs to be detonated or it becomes inactive. As far as final numbers on speed and damage, these will need extensive play testing before decided.
If I forgot to mention this last post, user input for lasers will most likely be space bar and left mouse click. Missiles are much more difficult. Since multiple types missiles are allowed on any given tank, unlike lasers which is limited to one type even if the tank has two laser mounts, each missile type is given a key binding. To launch each missile in the list above, the first letter of the missile name is the letter of the key. On a qwerty keyboard the missiles would be the second row, except a, s, d, ; and ' keys. Kore missile is detonated with a second press of the 'k' key. Tank and turret binds when on the normal screen will be split between w/a/s/d and up/left/down/right. When the guided missile is launched, both sets of bindings have the same effect: up/down (w/s) raises or lowers missile's tip (ability to invert this should be in early), and left/right (a/d) moves the missile in the desired direction (again, inversion should be an option fairly early on).
The inversion options are in case a player wants to control the back of the guided missile, which is what the player is watching while the missile is airborne. In this case, raising the tail would lower the front or moving the tail right would move the front left. These options will be disabled by default but should be available fairly early in testing.
Next time I hope to have an update on my progress using the Ogre Engine, though most likely it will just be a page describing the different types of mines.
~gunnah
30 July 2011
22 July 2011
Modules 1: Projectiles
While progress has been slow learning Ogre, my fault for not having enough to to just fool around, I decided I should get to posting something. Since I already went over the basic user interface and the layout I am using for the different tanks, next on the list would be items to customize the tanks. The goal is to make a large group of modules so that the game is very customizable. Since my plan is to include a truly large amount, I decided to break the modules into several different groups. This post will cover lasers and different items to add onto the laser for improved performance.
Lasers:
All tanks have a laser as a primary weapon. The standard laser is the normal, though some tanks, especially in the matches with the tanks already equipped, come already upgraded. Lasers are infinite as long as the tank has battery power remaining. Lasers do cause heat, usually proportional to damage, and a gauge on the user interface shows a warning when near overheating or when the tank has overheated. Other uses of this gauge specific to individual laser types are discussed with the laser type. One and only one of the following must be equipped at all times on the tank.
* Standard Laser: This is the normal weapon pre-equipped on almost all tanks. It is light damage but very quick and fairly cool. This takes up one module, usually already equipped on the tank.
* Improved laser: This weapon is a little better than the standard laser in terms of damage, but has a slightly slower firing rate and overheats a little faster. This takes up two modules on the tank.
* High-power Laser: This weapon deals much more damage than the standard laser, but fires slower and overheats faster than the improved laser. This takes up two modules on the tank.
* Shield Disrupting Laser: Since shields are created by energy fields, this laser fires a beam with an wave pattern that interferes with the shield-energy's wave function. Because of this high specificity to shields, it temporarily knocks shields off-line until the shield can be recharged, but does less damage to enemy tanks then the standard laser. This laser has a similar firing speed and heat generated as the standard laser. This takes up two modules on the tank.
* Pulse Laser: This weapon emits a beam with such high power that the beam actually scatters, causing damage to nearby enemy tanks as well. Not only does this deal damage, but the power of this beam causes a small electromagnetic pulse to follow the laser splash damage. This pulse causes damage to the electrical functionality of enemy tanks, particular in their ability to store energy in batteries. Because of the volume of energy needed for a pulse this size, this laser charges up, visible to the user by the filling of the display that usually shows the laser's temperature. Once full this laser can be fired, the charging time negates the importance heat build-up, but makes this laser very slow firing. Unlike all other lasers, this laser will not stop until it hits something or comes to the edge of the map. This takes up two modules on the tank.
Laser Add-ons:
In addition to the aforementioned lasers, there are several different additions available to make the laser, a weapon usually of secondary importance, very viable. Please note that distance and power modifiers may stacks. All items may be add only once unless otherwise specified. All or none may be equipped at any one time.
* Thermal Imaging Detector: This devices helps lock onto enemy tanks. It takes up one module.
* Sniper Barrel and Scope: This adds the functionality of a scope to the user, enabling a zoom of up to 16 times. Additionally this doubles the range of most lasers. This takes up one module.
* Second Laser Mount: Decreases time between firing by two since it adds a second laser for most lasers. The Pulse laser adds a divider in the indicator, enabling the firing of two pulses near simultaneous. The Pulse laser, unlike other lasers, has no reduction in firing time. This needs as many modules as the original laser (one for standard, two for any other).
* Increased Power Transformer: This increases the power of the laser as well as the maximum firing distance. Heat build up is increased when this is equipped. This slightly reduces the charging time on the Pulse laser. This takes up one modules.
* Liquid nitrogen Laser Cooling System: To prevent the initial buildup of heat, a generator pumps liquid nitrogen at the same time the laser is being fired. A gauge is shown on the user interface over the laser heat gauge. This item may be doubled to double the cooling capacity. If equipped with a Second Laser Mount, two are installed each time for up to four total. This does nothing if the pulse laser is equipped. This takes one module per system, for up to four if two are installed with a second laser mount.
Hope this gives some insight into laser functionality and module consumption. Next time will probably be missiles, with items like mines and shields in future posts. Also I am hoping to have a test run in ogre with a model I made, though that may be a little further off than missiles.
~gunnah
Lasers:
All tanks have a laser as a primary weapon. The standard laser is the normal, though some tanks, especially in the matches with the tanks already equipped, come already upgraded. Lasers are infinite as long as the tank has battery power remaining. Lasers do cause heat, usually proportional to damage, and a gauge on the user interface shows a warning when near overheating or when the tank has overheated. Other uses of this gauge specific to individual laser types are discussed with the laser type. One and only one of the following must be equipped at all times on the tank.
* Standard Laser: This is the normal weapon pre-equipped on almost all tanks. It is light damage but very quick and fairly cool. This takes up one module, usually already equipped on the tank.
* Improved laser: This weapon is a little better than the standard laser in terms of damage, but has a slightly slower firing rate and overheats a little faster. This takes up two modules on the tank.
* High-power Laser: This weapon deals much more damage than the standard laser, but fires slower and overheats faster than the improved laser. This takes up two modules on the tank.
* Shield Disrupting Laser: Since shields are created by energy fields, this laser fires a beam with an wave pattern that interferes with the shield-energy's wave function. Because of this high specificity to shields, it temporarily knocks shields off-line until the shield can be recharged, but does less damage to enemy tanks then the standard laser. This laser has a similar firing speed and heat generated as the standard laser. This takes up two modules on the tank.
* Pulse Laser: This weapon emits a beam with such high power that the beam actually scatters, causing damage to nearby enemy tanks as well. Not only does this deal damage, but the power of this beam causes a small electromagnetic pulse to follow the laser splash damage. This pulse causes damage to the electrical functionality of enemy tanks, particular in their ability to store energy in batteries. Because of the volume of energy needed for a pulse this size, this laser charges up, visible to the user by the filling of the display that usually shows the laser's temperature. Once full this laser can be fired, the charging time negates the importance heat build-up, but makes this laser very slow firing. Unlike all other lasers, this laser will not stop until it hits something or comes to the edge of the map. This takes up two modules on the tank.
Laser Add-ons:
In addition to the aforementioned lasers, there are several different additions available to make the laser, a weapon usually of secondary importance, very viable. Please note that distance and power modifiers may stacks. All items may be add only once unless otherwise specified. All or none may be equipped at any one time.
* Thermal Imaging Detector: This devices helps lock onto enemy tanks. It takes up one module.
* Sniper Barrel and Scope: This adds the functionality of a scope to the user, enabling a zoom of up to 16 times. Additionally this doubles the range of most lasers. This takes up one module.
* Second Laser Mount: Decreases time between firing by two since it adds a second laser for most lasers. The Pulse laser adds a divider in the indicator, enabling the firing of two pulses near simultaneous. The Pulse laser, unlike other lasers, has no reduction in firing time. This needs as many modules as the original laser (one for standard, two for any other).
* Increased Power Transformer: This increases the power of the laser as well as the maximum firing distance. Heat build up is increased when this is equipped. This slightly reduces the charging time on the Pulse laser. This takes up one modules.
* Liquid nitrogen Laser Cooling System: To prevent the initial buildup of heat, a generator pumps liquid nitrogen at the same time the laser is being fired. A gauge is shown on the user interface over the laser heat gauge. This item may be doubled to double the cooling capacity. If equipped with a Second Laser Mount, two are installed each time for up to four total. This does nothing if the pulse laser is equipped. This takes one module per system, for up to four if two are installed with a second laser mount.
Hope this gives some insight into laser functionality and module consumption. Next time will probably be missiles, with items like mines and shields in future posts. Also I am hoping to have a test run in ogre with a model I made, though that may be a little further off than missiles.
~gunnah
12 July 2011
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.
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.
07 July 2011
Vacation Over
I will start this post off with why it has been about two weeks since I last posted. I ended up going to Canada for a few days which means factoring in packing and unpacking takes a week out of that time. Besides this trip, I have also been designing another program. Before I do my tank shooting game, I am looking to make two programs, which I will discuss now:
* A Family History Website Maker. This program takes a GEDCOM and converts it into a series of HTML files. For those of you out there who do not know, GEDCOM is a file format (usually using the extension .ged) which was developed by the Church of Latter Day Saints and which has become a standard for storage of genealogical information from programs. This obviously does not look run or sound like an online tank shooting game. My goal with this program is to review syntax for my chosen language, work with varying amounts of file input and output and eventually build a basic graphical user interface. With the experience from this I will have most of the concepts for the program on the server side, as well as the client side.
* The second program is a small instant messenger. The goal is to have it handle a small group of basic tasks such as the instant messenger process itself and file transfer, as well as problems like disconnections and time outs. Again the hope is this program will have a slightly more complicated graphical user interface. This will familiarize myself with how to get the server program talking with the client program.
Once these two programs are complete, I will begin work on programming the tank shooting program. The hope is that by then, everything is already laid out and the preparations will make the actual programming go much smoother. The language I have chosen for all three programs is python, because of how friendly the language is, especially in the areas of file i/o, GUIs and internet protocols.
Basic Tank Stats
Each tank will be given a rating in each of three categories: armor, modules and speed. All tanks will have a total of thirty points to spread between the stats, described a little later in this post. A score in any stat of a 10 is about average with zero being near useless and thirty being overkill in an particular stat. I am thinking of releasing ten tanks at beta launch and cutting out the three absurd tanks once I feel the game is balanced. The most balanced tank has a ten in each stat. Tanks which slightly favor one stat will have a points spread of about 14/8/8 while those tank which strongly favor one stat will be 20/5/5. The final three which will likely be removed will have a spread of 28/1/1. A score of zero does not mean the tank does not have anything in that stat, for example a tank will always have armor, it is just a scale of how much. For this reason, On top of each stat, there should be six global variables, two for each stat. The first is the scaling factor - how many points of armor do you get for each point the tank has in the stat for example. The second is the base case - if my tank has no points in armor, how much damage can it take? These will be decided during the beta testing once this program is more of a finished product. The following is a brief description of each stat:
* Speed: dictates both top speed and acceleration. Top speed is linear while acceleration increases greater than linear.
* Armor: how much damage can the tank take and how fast does the health recover. The amount of health increases greater than linear while health recover increases less than linear.
* Modules: many many compartments does the tank have for equipment. Modules also dictates how large the tank is, since to have more compartments the tank needs to be larger. The overall size increases less than linear while the number of modules is linear.
In the above, I am not sure how clear it is described, so here is what I meant by linear, greater/less than linear. Linear is basically the same here as in math with the generic formula x = base + (stat * scaler). A stat which has an attribute increasing greater than linear means the attribute grows faster than a linear plot or when plotted the second derivative would be positive in a more mathematical sense. Increasing lesser than linear is the opposite of greater than.
I hope this explanation is not too confusing, next time I will probably go into what modules will be available.
~gunnah
* A Family History Website Maker. This program takes a GEDCOM and converts it into a series of HTML files. For those of you out there who do not know, GEDCOM is a file format (usually using the extension .ged) which was developed by the Church of Latter Day Saints and which has become a standard for storage of genealogical information from programs. This obviously does not look run or sound like an online tank shooting game. My goal with this program is to review syntax for my chosen language, work with varying amounts of file input and output and eventually build a basic graphical user interface. With the experience from this I will have most of the concepts for the program on the server side, as well as the client side.
* The second program is a small instant messenger. The goal is to have it handle a small group of basic tasks such as the instant messenger process itself and file transfer, as well as problems like disconnections and time outs. Again the hope is this program will have a slightly more complicated graphical user interface. This will familiarize myself with how to get the server program talking with the client program.
Once these two programs are complete, I will begin work on programming the tank shooting program. The hope is that by then, everything is already laid out and the preparations will make the actual programming go much smoother. The language I have chosen for all three programs is python, because of how friendly the language is, especially in the areas of file i/o, GUIs and internet protocols.
Basic Tank Stats
Each tank will be given a rating in each of three categories: armor, modules and speed. All tanks will have a total of thirty points to spread between the stats, described a little later in this post. A score in any stat of a 10 is about average with zero being near useless and thirty being overkill in an particular stat. I am thinking of releasing ten tanks at beta launch and cutting out the three absurd tanks once I feel the game is balanced. The most balanced tank has a ten in each stat. Tanks which slightly favor one stat will have a points spread of about 14/8/8 while those tank which strongly favor one stat will be 20/5/5. The final three which will likely be removed will have a spread of 28/1/1. A score of zero does not mean the tank does not have anything in that stat, for example a tank will always have armor, it is just a scale of how much. For this reason, On top of each stat, there should be six global variables, two for each stat. The first is the scaling factor - how many points of armor do you get for each point the tank has in the stat for example. The second is the base case - if my tank has no points in armor, how much damage can it take? These will be decided during the beta testing once this program is more of a finished product. The following is a brief description of each stat:
* Speed: dictates both top speed and acceleration. Top speed is linear while acceleration increases greater than linear.
* Armor: how much damage can the tank take and how fast does the health recover. The amount of health increases greater than linear while health recover increases less than linear.
* Modules: many many compartments does the tank have for equipment. Modules also dictates how large the tank is, since to have more compartments the tank needs to be larger. The overall size increases less than linear while the number of modules is linear.
In the above, I am not sure how clear it is described, so here is what I meant by linear, greater/less than linear. Linear is basically the same here as in math with the generic formula x = base + (stat * scaler). A stat which has an attribute increasing greater than linear means the attribute grows faster than a linear plot or when plotted the second derivative would be positive in a more mathematical sense. Increasing lesser than linear is the opposite of greater than.
I hope this explanation is not too confusing, next time I will probably go into what modules will be available.
~gunnah
Subscribe to:
Posts (Atom)
