Tag Archives: software engineering
It’s Sinking! Hurray!
Well, hurray for submerging and staying submerged anyway.
A small portion of the crew responsible for the 2012 RoboSub entry.
I recently competed in the 2012 RoboSub Competition held in the temperate Sand Diego, California as the lead programmer for the MSU team. You can read an excellent summary of the team experience from the MSU News Service. We were able to overcome some rather severe difficulties to make it into semi-finals this year. What follows is an overview of some of the issues the competition foists upon the participants.
I Have Two Conditions
No really, I do!
While working with the data structures in Epigon, I realized that I have two completely different things which are both called “condition”.
The first “condition” is how much damage a physical object has taken. This is to represent wear and tear on anything that’s not a creature. A table with light scratches might be at 98% condition, while missing a leg would put it at maybe 5% Once this number is reduced to zero, the object decomposes into its component parts, as dictated by the data file on it.
The second “condition” is an ongoing effect. Being poisoned is a condition, as is eating a good meal and having more energy for a while. This second condition can have complex interactions with other conditions and abilities as well. For example, you can’t eat if you’re already full.
These two very different uses of the same word have been constant throughout the design process. Because they have no overlap in what they represent, it took me until yesterday to even notice that I had used “condition” twice.
Since the context of their use is so clear, I’m tempted to leave things the way they are, but the player of the game will have access to the information contained within the two uses. It would be unfair to the player to knowingly include such potential confusion, so one of them must change! The only question is which one, and to what?
Epigon Control Flow
Provided for perusal, the main control flow chart for Epigon.
This is the way things work inside Epigon.
In the beginning, there are two possible sources of input, the Player and the Dungeon Master (also known as the DM). For those that don’t know, the Dungeon Master is the person at a traditional pen and paper role playing game table that controls all the monsters and other things in the world that the players don’t control. These two sources operate on a different information set and have a slightly different set of ways to attempt actions. The differences lie largely in cases such as the Dungeon Master can create a new mountain, while the player can’t directly do so. There is a third source of an action request, which is the result of another action, but more on that after the jump. (more…)
Object Design in Epigon
Physical Objects’ structures are about 80% designed!
While that’s the exciting news, first some information about the data classes themselves.
The base idea for the data classes in Epigon is Inheritance and Interface. Like an object oriented language, all data elements subclass another data element. This includes Physical Objects, Biomes, Terrain, AI Strategies, etc. While this adds complexity to the data structures themselves, it allows for some nice effects.
Some examples of the power of subclassing data:
- Sword of Orc Slaying can be tagged to do bonus damage against the Physical Object “Orc” and without having to specify anything further, it will get that same bonus against everything that subclasses Orc, such as Orc Shamans, Pink Orcs, and Giant Orcs.
- Resistance to the Element “Fire” will include resistance to the element “Magma”
This kind of carry forward of effects works on the declared class and anything that subclasses it, but not on the ancestors of the declared class.
The biggest downside to this kind of subclassing is that it promotes an overly large hierarchy in which many elements exist simply to be umbrella classes, such as “Animal” or “Tree” without any specific instance of that class wanting to be created. I think this comes down to a choice on the data designer’s part about how generic they want things to be. A basic set of umbrella classes is not a bad thing, and they can be tagged so that they don’t have instances of them actually created.
There is no multiple inheritance allowed in the data sets. This keeps things more organized, but it does make some things a bit more interesting. If you wanted to create a half-dragon half-orc creature, the “Half Dragon Half Orc” creature, and dragon and orc were not in a direct line, you would make a decision as to which one it directly inherited from and then tag it as “also counts as” the other. This way the designer has the flexibility to have things count as multiple things, but since it can only directly inherit from on parent, a tree is maintained rather than a complex connected graph.
So there’s some of the highlights of the data structures in general 
The current news is that the Physical Object class definition is complete enough to start working with in a programmatic sense. That means combat, recipe, and object creation testing!
Next up: planning out the starting data classes that will provide good examples for others who may wish to modify what goes into the world of Epigon!