Technically, prototypes

While I’m busily adding more and more stuff to Xenos, let’s talk how this stuff is actually organized. I think it may be interesting.

The game world in Xenos is made of tiles – that much is evident just by looking at it. And each tile can have one (and only one) object inside: stuff like trees, furniture, alien artefacts etc. Some objects, like beds, take up more than one tile. There are also walls that are placed between tiles (technically, each tile has a “top” and “left” wall). Walls and objects are static: they never move, but they can be destroyed or placed anew. Objects that can move are called dynamics: currently, that would be the car and poison gas cloud. Finally, there are NPCs and the player: they can move, but they’re not dynamics (Why? I don’t know, it just happened somehow. I probably should change that in the future.)

There are also some things that don’t exist directly in the game world, but are important nonetheless: most notably, items in inventory.

To add a new thing to the game, it has to be described somehow. In Xenos, things’ descriptions are called prototypes. Technically, a prototype is a piece of XML that specifies everything the game needs: what model the object has, how high the wall is, what the item is named, etc. Here’s how a very simple prototype looks:

   <PrototypeBase xsi:type="FloorPrototype">
     <Name>grass/1</Name>
     <Id>1</Id>
     <TagsArray />
     <AtlasIndex>1</AtlasIndex>
   </PrototypeBase>
protos_editor

The editor I made to work with prototypes.

For more complex objects, though, a simple list of data is not enough: I have to define behaviors somehow. Most, probably all, objects and items in Xenos are going to be interactive, probably in more ways than one. Consider a simple cabinet: it can be opened and items stored inside, it can be chopped up using an axe, maybe it can be disassembled into boards for building, or moved to block passage… that’s a lot of behaviors!

To handle this, I use something called a component system. Every prototype has a list of components, where a component is itself a little piece of data with a corresponding piece of code. When prototypes are loaded in game, every component data is coupled with code (technical term: it becomes an instance of corresponding class). Components have several nice features:

  1. Components contain their own data. If some objects are destructible and have a hitpoint value, but others don’t, I can store this value in a component and only add this component to relevant objects.

  2. Components are reusable. If a cabinet and a chest can both store items, I can only write one “container” component and use it with both.

  3. Components can be mixed and matched independently. A knife and an axe are both melee weapons, so I add a “melee weapon” component to both. If I want the axe to also have an ability to chop trees, I need only add another component: the weapon code is not affected at all.

  4. Components can be queried. For example, when an item is selected, I can select from the list of this item’s components those that define a “use item” behavior (technical term: they implement the “UsableItem” interface.)

This approach: a list of prototypes, each with a list of components, all stored in XML – makes Xenos pretty modding-friendly. Properties can be easily changed, behaviours added or removed, etc. Unfortunately, adding or changing assets – that is, models, icons etc – is not that easy. It’s actually next to impossibly due to how Unity3D insists on using its own compressed format for everything. I might be able to solve this problem at least partially, but for now it’s pretty low priority.

And to counterbalance all the technicalities above, here are some (relatively) pretty pictures. In the last couple of days I’ve been adding various hazardous alien artefacts…

hazards_arcs

These are alien arc machines. The ones on top produce a rotating ray, and the ones on bottom have a static lightning between two machines. Needless to say, touching the lightnings hurts.

hazards_fire_and_gasThe green clouds are poison gas generated by those strange green contraptions on the ground. And orange clouds are jets of fire (yeah, they don’t look the part. I’m not that good with particle effects either) that spring up in random tiles. There are also a couple of alien robots here.

 

Leave a Reply

Your email address will not be published. Required fields are marked *