Introduction
You guessed it; I'm a geek and got excited to participate in the star trek challenge! So after reading the guidelines, I emailed my co-author, since email is the fastest way to get hold of a geek, and he and I made the decision to bring you the world of StarTrek, text style.
Mr. Michael Birken states “[StarTrek] is the kind of game that deserves to be reinvented every time it trades hands.”(startrek_1971_text.aspx) And I could not agree more! In fact, an interesting follow-up article would be a summary of the competition entries, showing a feature matrix for all of the entries.
I have been talking about writing a game for years, and I just have not quite achieved that goal. A text based adventure should eliminate the graphic headaches and allow me to focus on the core design of the game. Moreover, this is a prototype for another game adventure that I have wanted to produce for some time now. Let’s see how that goes.
The system is developed with three major sub-systems: ship structures, the world structures, and the UI. Therefore, we will be investigating the most interesting parts of the application (and it is certainly not the UI).
Table Of Contents
The Object Oriented Ship Design – The Good, Bad and the Ugly
The ship design that I want in my future game would closer resemble the discussion found here by creating interfaces for each category of object the ship could better interact with additional plug-in components. In my world, I have only one interesting part to a ship, the weapons. Note this definition of weapons is a little unconventional, as both offensive and defensive weapons count. Red alert, for example, is also a weapon.
The model provides a reasonable separation of duties – A specific offensive weapon only knows how to calculate damage, while the specific targeted ship understands how to apply that damage. For example, imagine the Defiant is in a battle against a Bird of Prey. When the Defiant gets damaged, because it is so small it would most likely have a higher frequency of failing systems, while the enterprise with more surface area systems should have a lower failure rate because the systems are less densely packed into the ship. The key to this design is the firing weapon does not care how the damage is distributed, and the ship does not care how the damage is calculated.
How does the technology behind the phaser system work? Well I am glad that you asked. The phaser calculates damage based on three primary factors, distance, energy, and efficiency. If the phaser is registered at 80% for 3 units, then for each unit of energy used, it will perform 80% of the energy when the target is 3 units away. The theory behind phasers is that they are sound waves and subject to dispersion; therefore, if the target is beyond the range of the weapon, it will do less damage. Similarly, if the target is closer then it should do more than the expected damage.
PhaserDamagePesudoCode(Eff, RecommedRange, AppliedEnergy)
{
Let d = EculadianDistance(SourceSector, TargetSector)
Eff += ((d – RecommedRange) * Penalty)
Return AppliedEnergy * Eff
}
Where Penalty is the cost of inefficiency for one unit over the recommended distance, 10% is used in the local implementation.
In contrast, the Photon system is much simpler; it requires a number of missiles and a recommended range. If the player targets a vessel beyond the range of the photon, it is assume the missile cannot be as successful at targeting the vessel so it does a random amount of damage to the target from 0 to the max damage of the weapon.
PhotonDamagePesudoCode(RemainingMissiles, MaxDamage)
{
If RemainingMissiles <= 0, Return 0
RemainingMissiles = RemainingMissiles - 1
Let d = EculadianDistance(SourceSector, TargetSector)
Let Damage = MaxDamage
If d > MaxDistance
Damage = randomNumberBetween(0, MaxDamage)
Return Damage
}
Lastly, the ship is able to apply damage to itself. While there is only one implementation in this version, it is possible to have some other way of applying damage to a vessel:
- First the shields are damaged, since they are the first line of defence.
- If there is remaining damage, it could damage certain weapon systems; I imaged having secondary explosions and other failures when the shields exposed parts of the vessel to the opponent.
- Finally, damage is applied to the hull of the ship, since there is no other defence.
The World Representation
As mentioned before, the world structure is one of the three major sub-systems. The world is represented by a Singleton pattern, which upon the first use will load the galaxy from a configuration XML file, which contains all of the relevant information about what the world looks like, the shape, the contents and, of course, the Kligons.
I would like to say, I would have preferred to use serialization and deserialization methodology to construct my world; however, multidimensional arrays cannot be serialized using XML and I was not interested in binary serialization, as that cannot be easily edited by the player or developer. Security of the game internals was not a design consideration. I was looking for flexibility and consistency.
After performing some quick analysis of the world representation, using JetBrains dotTrace, my memory usage is very inefficient. Over 200 Meg is being occupied with 6,265 unique SpaceUnit instances, which represent empty space. That’s a whole lot of nothing! Note the following lines:
private static Galaxy LoadWorldXML(FileInfo target)
{
for (int i = 0; i < size.X; i++)
{
for (int j = 0; j < size.Y; j++)
{
for (int k = 0; k < size.Z; k++)
{
if (rVal.cGalaxy[i, j, k] == null)
rVal.AddItem(i, j, k, Quadrant.FromString(new string('0', 64)));
}
}
}
return rVal;
}
So why do I need 6000 of these? Because, in this design, the definition of traveling is simply altering the contents of the iSpaceItem.PresentShip variable. If the system was more Cartesian based, these mostly unused objects could be factored out.
In contrast, this design is simple – we have a tree-like structure, rooted with a galaxy, branched with Quadrants, and leaved with iSpaceItems. If you want to add black-holes to this implementation, that should take approximately 10 minutes to implement the interface and 3-5 to add it to the configuration file, and one minute to add it to the builder function BuildSpaceUnit.
Future Insights
- Although the ship design is "directionally correct", it must improve on its robustness so it can better simulate a real complex ship design.
- Adding a visitor pattern to the ship model for rendering and damage calculations would be a step in the right direction
- Also implementing a notification system so the ship can communicate with other interested objects.
- The world configuration is nice; however, the poor memory usage is something that needs to be addressed in future versions.
- Some Terrain should have some intelligence, a planet should be able to orbit a star or other terrain object (a black hole maybe).
- The Space Station should be a vessel rather than an element of terrain. The Klingons cannot go to war with a piece of terrain, and that’s no fun. Moreover warping into the sector where the Klingons were battling a federation space station would be a spectacular sight.
History
- Aug-25, 2008: Initial upload
Berkeley Grad (B.A. Computer Science) With MBA
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.
Submit an article or tip
