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.

 

Content, content, content

I’ve been preparing for the release of public playable demo of Xenos. There’s still a lot stuff to do before I consider it ready: I guesstimated it last week and came with 4-5 weeks in total. A lot of this time is going to be spent on adding content to the game – I mean, as opposed to writing code, adding new features etc.

Even a relatively small game location requires many objects – static models, effects, items etc. I’m working now with a town sized at 256×256 tiles (that’s the size of a “block” of map that is stored in a single file on disk). It has around 20 different buildings that use some 20 kinds of wall objects and 50 kinds of tile objects – things like furniture, stuff lying around etc. And I think it needs even more, perhaps twice that number. It turns out, a town has tons of different stuff – who would’ve thought, right?

As I’m spending most of my time making models and putting them on the map (the town map is not procedurally generated – I want to have an example made by hand before I tackle generation), today’s post is gonna be mostly pictures.
content_houses

Here we have some residential houses. This (and most of the following) picture is shot in editor mode, which allows me to put camera higher than in-game, to fit more on a single picture.
content_cafeHere’s a little cafe. Currently it mostly reuses the same models as residential houses: it’s just a really big kitchen and many tables. And chairs.

content_store A general store with a parking lot. With a small house in background.

content_warehouse

A warehouse with crates. No game can be considered complete if it doesn’t feature crates (although, these are just cardboard boxes actually. I guess they’ll have to do..)

content_workshopSome sort of workshop. I think workshops and generally industrial  buildings are in the most dire need of more models. I had to resort to sprinkling “generic rubble” around here.

content_gas

A gas station. Looks sorta empty, but it would be of huge importance when I add refuelling mechanic to the game.

content_invThis picture shows a different kind of content: items. To make a more-or-less believable abandoned town, I have to put lots of items in the houses. Since Xenos is set immediately, or maybe soon after, the apocalypse, I can’t just explain empty containers with “everything has been looted”, like zombie games do: there are no looters yet – in fact, you play one of the first. I made dozens of items, event though lots of them still use the generic “gray box” icon, and don’t do anything useful in-game. Some don’t even have any descriptions: try writing interesting 5-15 word descriptions for 20 items in a row and you’d understand why.

I think town content is mostly ready for the demo; but I need at least some alien objects to add: their metal robotic structures, traps, and maybe a couple of alien “species”.

Also, if you can think of any useful object or item to add, don’t hesitate to suggest it in comments. I don’t promise I’d add it immediately, but it would probably find its way into the game sooner or later.

 

On vision and violence

Xenos development has stalled a bit lately, because I’ve been sick. I had a mother of all fevers last week, but fortunately I got better, and am now back to the game. This means that I don’t have many exciting new features to describe; but I still don’t want to leave this blog silent for a long time… So, let’s talk about Xenos vision: what would the game actually be about?

I have to say that my ideas about Xenos change all the time, sometimes radically. When I just started first prototype, back in 2011, I envisioned some sort of cross between Crimsonland and Terraria: a top-down game of frantic shooting combined with resources gathering and building. Today, there’s no building (although some is planned) and no shooting (ditto), and the accent is mostly on gathering and exploration. Ideas for Xenos that I have today might also change in the future – though maybe not so radically, since the game is already under development.

And my current ideas about what Xenos should be were born from my musings on violence in games. I’m not going to argue that videogame violence is inherently bad, or good for that matter – that’s better left to psychologists. But what I clearly see is that it’s prevalentIt’s not just that games are violent: it’s that violence is basically the only tool game protagonists have. If we take more “traditional” games (i.e., exclude puzzles and casual games etc, that don’t feature any violence at all), most of them are structured like this: “There’s something wrong with the world. Go kill those people, then everything’s gonna be OK.” Some games – a precious few – embellish this formula somewhat, making it “There’s something wrong with the world. Go figure out who to kill so that everything would be OK” or “There’s something wrong with the world. Go kill those people… oh, that’s making it worse!” And we praise these games for being “serious”, for offering “moral choices” etc. Having hundreds  and thousands of games repeat this same formula seems kinda sad.

I don’t want to do that. I’ve decided that for Xenos, violence would not be the only, or even the main, tool of the protagonist. And that actually meshes quite good with the theme of alien invasion… I mean, I could make the game about blasting aliens to pieces. But realistically speaking, a single guy could never blast the whole invasion out of existence, no matter how badass he is. The only way to do that is postulate some sort of “hive mind” or “mothership”, that, once destroyed, takes the entire alien race with it. In my book, that’s a cheap and cheesy trick, but even Duke Nukem basically uses it with Cycloid Emperor. And Duke is probably the most badass hero in the universe.

But, if you can’t defeat the aliens though sheer firepower – what would you do with them? Making a game without any victory condition seems way sadder than using violence in the same way everybody does. Another cheesy trick that I frankly don’t like is finding some way to “speak” with aliens and then basically telling them off. Some games use this, like Space Rangers or UFO: Aftermath for example: you speak with aliens, explain that humans are a sentient race, and invaders immediately see the error of their ways and stop. I think it’s really cheap, but what choice do I have? I can’t kill them, I can’t tell them off…

Ligthning-flinging robots and alien poison gas.

Ligthning-flinging robots and alien poison gas.

Let’s talk about the difference between aliens and zombies. I know, that seems like a sudden diversion, but bear with me – it’s actually relevant. You see, Xenos is really looking like Project Zomboid, only with aliens instead of zombies. What’s the difference? Well, first, zombies are stupid, easily destroyed, but numerous. You kill them by the dozen, but more always come, and in the end there are too many. Xenos’ aliens, on the other hand, are relatively rare, but really tough. You just don’t dismantle an armored alien robot with a monkey wrench – or a shotgun, for that matter.  Also, zombies pursue the living relentlessly, longing for their brains; but aliens basically don’t care about humans. They just do their stuff, and if you get in the way, you die. And we humans have no idea what that “stuff” is. I think these aliens are actually a lot like a natural force. Take thunderstorms for instance: we can’t do much about a thunderstorm, and we don’t know why or when a thunderstorm appears (OK, we do, but didn’t for most of human history). Mostly, we just try to stay out of the way, just like with aliens in Xenos.

And what do we, as a species, do with natural forces? We study them; we subvert them; we use them to our advantage. That’s  what Xenos should be about: you should study and subvert aliens to win. The victory condition would be humanity that learned to live with the alien “menace” and ever transformed the “menace” to “boon”. I like this idea, because it’s not something that’s been done to death (like the “destroy the hivemind” trick), and it’s not something that’s achieved through violence. Also, being a technocrat and a transhumanist, I really like the “triumph of science” vibe. Of course, this ending raises a question of whether subverting and using a supposedly sentient race is any better than genocide, but that is actually an interesting question to raise (If aliens in Xenos are in fact sentient. They might not be.)

I don’t plan to make Xenos an entirely non-violent game. It’s a sandbox, after all, and a sandbox should offer maximum freedom, including, in this case, freedom to blast some aliens, and/or humans, with a shotgun. But violence would not be the path to victory, and that’s enough for me.

Playing around with cameras

I’m busily adding new stuff to the game; but all this stuff seems kinda disjoint. I’ve added lots of different models, items, and a couple of new mechanics (like hunger and eating), but they don’t yet form a coherent whole, and as such I don’t really intend to write about them.

In the meantime, I have something to show and discuss. While Xenos is a 2D game mechanically, it is rendered using 3D models. This means, among other things, that I can change camera behaviour willy-nilly, without affecting the rest of the game. I’ve played around with different camera angles lately, and here’s the results:

High camera

High camera

High camera

This is the “default” setup that was used in all screenshots to-date. The camera is pretty high, with a small field-of-view. It’s supposed to add a “toy-like” feel to the game, but I’m not sure it’s working. Character controls use a “top-down” style: WASD moves in cardinal directions, and mouse is used to target things.

Low camera

Low camera

Low camera

This is a variant of previous setup where camera is moved closer to the ground, but its field-of-view is increased. This gives a sort of fish-eye effect, exaggerating the 3D feel. Controls are the same as with high camera.

Isometric camera.

Isometric camera

Isometric camera

An opposite to low, this is “infinitely high” camera. Perspective is disabled at all, and the game looks 2D. Every model is always seen from the same angle, which is both nice (because I only need to worry about this angle when creating models) and bad (because it may be hard to see in this angle). Isometric look is sorta “real old-school”.

Top-down camera

Topdown camera

Topdown camera

This camera uses the same height and field-of-view as “high” one, but it’s looking directly down, and in a cardinal grid direction. This view reminds me of original Grand Theft Auto, which is probably a good thing. It’s also old-school, and my shitty 3D-models look least shitty in this view – mainly because it’s hard to make out anything (-8. Now, for something really different…

FPS camera

FPS camera

FPS camera

Yes, I can easily switch to full first-person view! Control scheme has to change – now, WASD controls forward/backward and strafe movements, and mouse rotates character around. I suppose that any on-screen menus would have to be modal with this camera (that is, you’re either moving around or using inventory or whatever, never both at the same time). First-person view make the world around seem way bigger and more mysterious than bird’s eye views. However, voxel models don’t look so good, and repetition becomes more apparent. Also, I need to add roofs for this view.

MMO camera

MMO camera

MMO camera

As a compromise between FPS and bird’s eye, I tried this view. I call it “MMO” because the characted is controlled in the same way as in WoW and the likes: WASD moves forward/backward and turns character, and mouse is used to interact with the world and on-screen GUI. I must say that the character model looks especially ugly this close.

 Poll

I actually like all of these views, and have a hard time choosing. So here’s a little poll where anyone can vote for whatever camera mode you like.

Seamless

Let’s talk about procedural map generation for a bit. I’ve always considered procedurally generated maps one of the most important features for Xenos; but it wasn’t working out all that good.

The problem with procedural generation is that it’s hard to create interesting places. Scattering trees around, placing roads and random buildings is pretty easy, but the resulting levels are pretty bland. On the other hand, my system is flexible enough to create, say, a village house with a yard and a garden and outbuildings etc – but it requires a lot of effort. Enough effort to create several such houses by hand, actually; and while this system can then generate any number of houses, they would all feel the same. And many houses that feel the same is, again, bland.

Now, this is hardly a problem unique to Xenos. Generating lots of really different stuff (whatever “stuff” means – levels, textures, tunes, stories) is, first, really hard, and second, requires great artistic taste. I believe  can manage hard, but the “artistic taste” part always gets me in the end. So, procedural content being bland is probably a given for Xenos… how can I still make it useful?

To get this beauty in Minecraft, you have to specifically select your generation seed.

To get this beauty in Minecraft, you have to specifically select your generation seed.

Most games that use procedurally generated maps out there actually manage to do just that. For example, Minecraft terrain is mostly bland and same-y, but every so often some fluke of the generator produces a beautiful cliff, waterfall or something. However, this works because Minecraft is 3D and first-person: we humans are engineered to find beauty in this perspective. Take strategy game like Civilization, for example: while they look nice, no one expects to find any special beautiful place on a Civilization map. Since Xenos is, like Civilization, mostly 2D, with top-down perspective, I don’t think I can rely on random generator producing something nice and pleasant to look at.

How does Civilization use procedural generation to its advantage then? In Civilization, (and Minecraft too!) random maps are not interesting by themselves, but they become interesting as a result of player actions. One stretch of grasslands, hills and jungle is not that different from any other. However, when cities are founded on it and military forces fight for supremacy, every hill becomes meaningful. This is basically what I was shooting at with Xenos; but it seems like it’s not really working out. Xenos’ maps are huge, and there’s just one player-controlled unit; you can build sort of a “base” (theoretically: there’s no building functionality in-game yet), but you wouldn’t spend much time in it. I suppose I could turn Xenos into a strategy game, but that’s not a direction I like.

This hill is only important when it gets in the way of attacking knights.

This hill is only important when it gets in the way of attacking knights.

What else can I do? What if take advice from Terraria and focus more on exploration and finding special, interesting places? This might work: I can create a number of interesting places by hand, using the level editor (and spice them up with some random generation, so that they’re not identical every time you play). Then, I’d use more generic “bland” random generation to fill up the map, scattering these interesting places around.

This idea immediately seems bad, though: why would I want to have bland content in between interesting? Give me all interesting, all the time! Of course, games don’t actually work that way: the player needs some “downtime” to appreciate the interesting content. On the other hand, I certainly don’t want to bore players into leaving the game before they even reach this “interesting place”.

To improve this balance, I had an idea that is sort of out-of-place for a survival rogue-like game, but seemed really interesting. Add cars. Seriously, driving a car is interesting in and of itself, especially if there are obstacles and/or time is of the essence. Driving works pretty good in a top-down or any birds-eye perspective (remember GTA? The original, from 1997?). And to top it off, cars come with a large set of potentially interesting mechanics: finding fuel, breaking/repairs, tuning and modifications… and, if I add cars, I can probably add a tank to drive right in the middle of alien base, destroying everything in your path – how awesome is that?

However, with cars came one “slight” technical problem. Up until now, Xenos map were organized into distinct locations, with loading-screen transitions between them. It works OK for walking, but driving straight into a loading screen is definitely a bad idea. So, before adding cars, I’d have to change all the game code to work with continuous background loading, and make the whole map seamless.

I’m proud to say that, even though this was really painful, last week I did just that. Xenos game world is now a single seamless level 2084 tiles on a side (which is to say, it’s LARGE!). And there’s a car that you can drive around this map, too!

Car

Car driving in Xenos