Category Archives: Xenos

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

Interfaces

You know what’s really hard in game development? User interfaces. That doesn’t seem obvious: there are certainly lots of areas that require hard stuff: maths, physics, etc. Graphics, physics, advanced AI, procedural generation – these all require pretty advanced concepts; and user interface generally does not. But the fact is, I’ve seen good existing libraries for all of these things; I’ve never seen a good GUI library. And none of my fellow developers had, either. Every game GUI system out there is weird, quirky, slow, hard to use and/or badly coded. Sometimes all of the above. Here’s what GUI systems are commonly used with Unity3D engine.

UnityGUI

Unity3D has a built-in system called UnityGUI. It’s pretty weird: all interface is created by code, and controls are function calls. Here’s what I mean: usually, GUI systems have a notion of “control”: a button, a line of text, a checkbox, etc. These controls are created either in some kind of editor or directly by code, like this:

var button = new Button();
button.Width = 100;
button.Height = 30;
button.Caption = "Click me";
button.Click = DoStuff;

Then this “button” is placed somewhere, like in a window, and the GUI system takes care of drawing it in the right place, checking for clicks, etc. You can still change the button after it’s created, i.e. resize it or change color or whatever.

In UnityGUI, though, there is no explicit button. Instead, the code calls a function that draws a button on screen immediately, and also checks for clicks. This makes the code dead simple:

if(Button(100,30,"Click Me"))
{
    DoStuff();
}
unityGUI

This is how UnityGUI looks like.

But while this is simple and easy to code, there are many problems with this approach. First, since there is no button, there’s no easy way to change its size, or text, or whatever, dynamically. Second, it requires that the code that draws the button, and the code that runs on button click, are specified in one place. This is called “tight coupling” in programmers’ parlance, and is a big no-no: it causes code to become tangled, intertwined, and ultimately unusable. And third, since all GUI elements are drawn immediately with this approach, it tends to be quite slow.

UnityGUI is essentially so bad, even Unity Technologies employees don’t advise using it. It does have its use, though: when you need to draw lots of mostly independent controls, and don’t care much about visual prettiness or performance, UnityGUI really shines. This is not the case with games, but this is exactly what’s needed for game tools. My editors for procedural generation, game objects and settings, and lots of other stuff all use UnityGUI and I love it; but it can’t be used for the actual game.

NGUI

This is how NGUI looks like

Another GUI system commonly used with Unity is NGUI. It’s a relatively nice system, based on the common approach of creating various controls in the editor (it basically reuses Unity level editor). However, it does not cut it for my needs. NGUI is based on the premise that all controls are basically created and laid out in advance, and the game might show or hide them, with animations maybe, but not create new ones. Not that dynamic creation is impossible in NGUI – it’s just not really thought out. In the same vein, NGUI does not offer any ways for laying out (positioning) controls on screen, except the most basic. This is enough for many interfaces, but Xenos is going to need more. I plan lots of different windows: inventory, character and NPC information, dialogs, crafting tables, etc; simple layouts of NGUI are not enough. Also, NGUI costs $95 – it’s not much, but still an investment.

Other systems

There are some other GUI systems usable with Unity out there, but they’re less widely used and are probably less functional. There are also two really advanced alternatives: Flash and HTML/Javascript GUI (basically, integrating a whole another renderer into Unity). These are nice, but they require advanced capabilities of Unity3D Pro license, which I don’t have (and it costs $1500 and I’m not willing to spend this much just yet).

This leaves me with no other choice but create my own GUI system. Now, I can’t really hope to best literally everyone out there. Most probably, my GUI system would turn out to be bad too. However, what I do hope to achieve, is make a system that is good enough in the areas that really matter for this game, and maybe is shitty in some less important ones. Also, having GUI system written by myself means that I’d probably understand it really well and would be able to fix things relatively easy. That’s not guaranteed, though.

XGUI

XGUI is the name of system that I ended up with. It’s not fully finished yet, but all the big stuff is in. I can create windows and controls using a visual editor. I can automatically generate “glue” code that makes using these windows easy, and de-couples control creation and use. I can create and change anything dynamically. I have a small, but effective library of simple controls that can be combined to create complex interfaces. And I have advanced automated layouting system, that adapts to target resolution.

Basically, what’s missing is drag-and-drop support (it’s pretty easy to add) and a system for editing and playing animations in GUI.
And, of course, missing is any kind of nice artwork to actually show off the interface. For now, all my GUI consists of differently colored boxes. But I hope to enlist an actual artist’s help for this, so stay tuned. Meanwhile, here’s how the GUI looks now.

xgui-editor xgui-ingame

Places to go, people to see

Activities

Last time, I was talking about pathfinding algorithm in Xenos. But where would the NPCs  go? For now, there’s not many places for them to visit; just enough to demonstrate that they can do something and the code actually works.

Here’s how it works. When the game generates a house, it marks some areas of it as activity zones. Right now, there are 3 types of such zones: farm plots outside are marked as farming zones, beds inside are marked as resting zones, and the whole house is marked as idle zone. Then, when an NPC spawns, it checks all zones around and prepares a list of all activities it can do.

Npc activity

An NPC selected farming zone and is “tending to crops”.

The idea is that during the game, NPCs would somehow select the most “preferable” activity, go to its corresponding zone, and play required animations there. For example, at night resting in a bed is preferable, and during the day, farming or some such. Right now, though, they just select a random activity every few seconds… which is already surprisingly effective. Even three really simple activities make the village seem alive; adding more would probably be even better.

Locations

When I had a whole village of NPCs doing stuff (OK, pretending to do stuff), I wanted to add some other places. The village is far from done, of course, but I think the most interesting gameplay would happen outside, and I had no outside at this point.

For Xenos, I want to build a game world consisting of many discrete locations. There would be a short loading screen when moving between them: not because of some technical difficulties, but to make generation simpler, so that different locations don’t have to line up exactly. Also, having a clear line between “loaded” and “unloaded” locations simplifies game mechanics: I don’t have to worry about some place being unloaded suddenly – only as a part of leaving the whole location behind.

Adding another location brought an unexpected difficulty: the whole procedural generation system is quite unwieldy when I add new content. For example, at first I created an asphalt tile and a concrete wall tile. Adding them to the game took maybe a couple of minutes, but to actually see them, I had to create a new map generation feature that creates something out of asphalt and concrete, and then use it in some bigger feature that would create a “town” location… that was unacceptably slow.

Location editor

Creating a small town map

So, in addition to procedural generation, I had to create an old-fashioned map editor, so that I could create locations and test new stuff quickly. This took quite a long time, but would hopefully be faster in the long run.

Of course, I’m not dropping the procedural generation from the game. Instead, I hope it would work well together with hand-made maps: the systems are connected, and I can both use procedural system to generate something in the editor, and feed parts of hand-made maps into generation (i.e. a generation system creates a town layout, and fills it with buildings that are made by hand).

With the editor in place, I quickly added a few tiles and objects that can be encountered in a town, and built a little sample location. Next, I wanted to start adding actual gameplay, but there still were one system to build: user interface…