Building a city

Let’s talk a bit about map generation in Xenos. I’ve started development of the game with making a procedural map generation system, and I’ve talked about it in the very first post. However, then we decided to change everything, and the old system had been summarily ripped out; replaced with a new, kinda-similar-but-not-quite one. So, how does Xenos create maps now?

I still have not solved it in general – current algorithm is heavily geared toward creating town maps. On the other hand, it’s simple and it works. As you may remember, maps in new Xenos are made of chunks, that are approximately 10×10 old tiles in size. A single chunk can contain a building or a length of road – i.e. open street. And a single “location” is 20×20 chunks – for now, this is the whole of Xenos, but in the future I’ll add more locations that connect seamlessly.

buildtown

Creating road grid

The generation of a location starts with a road grid. I used a very simple algorithm: imagine an empty 20×20 grid. Then, mark some rows of it as “road” – making horizontal and vertical lines 1-3 squares apart. You end up with a grid of streets and city blocks, but it looks much too regular. To break up regularity a bit, let’s simply remove some roads. First, going horizontally along every row, we randomly remove some roads between neighbouring blocks, in effect merging them. Then repeat the same, only going vertically along every column. As a result, you get a nice irregular pattern of streets.

There are a couple of gotchas to watch out for: first, we shouldn’t merge too many blocks in a row – we want to have enough roads for driving. This is easily accomplished by tweaking the probability of merge (larger block means smaller probability) Second, and more important, is to check for disjoint roads. Sometimes, when we remove a piece of road, the whole grid would be split into two unconnected parts, and we really don’t want that. Fortunately, that is pretty straightforward to check.

Once we have the road pattern, next step is to place actual streets. Again, a pretty straightforward algorithm goes over every chunk and select a matching piece of street – a straight road, a corner or an intersection.

Next we have a “special chunks” step. The idea behind it is, what if we want our map to have, e.g. one or two fuel stations, no more, no less? We might have a list of these “special” objects with respective counts. After streets are placed, the next step is going through this list and finding random places to fit objects. Some of these may take up more than one chunk – for example, our fuel station is 2×2, with 2 of those overlapping the street. Every special object has some code attached, that basically answers one question: “given the map generated so far, can this object be placed in point X?” In the above example – fuel station, that piece of code checks for a length of straight road to “attach” the station to.

Finally, when we have placed all special objects, the rest is filled with the most dumb algorithm imaginable – every chunk that is still empty is simply assigned a random object (well, not totally random, but random from the “applicable for town map” list).

And this is basically it – we have a town location that is random, more-or-less irregular (the grid of chunks is still apparent, of course, but it’s not bad in practice), and contains the stuff we want it to – but in unpredictable places. I think it’s pretty good for a game map.

Development video

Recently, while working on Xenos, we had an idea. What if we made a video of the development process? A lot of our work is not really exciting to watch: me typing code in Visual Studio is probably boring as hell. But some processes might be actually interesting.

So, today we present the Xenos dev video – first of many, I hope. This time it’s the process of making a single “chunk” of game map, containing a simple house. The house is not completely finished – it has no floor for example, and it could use more details – but the basic process is there.

The video also showcases some procedural capabilities: see how the house is built with a set of props, and then re-generated automatically with props changing and wallpapers having different color. In the end, the location generation process is shown, where the new house is automatically integrated into our town map. (The map is generated very slowly – that’s a property of Unity editor. In-game it works faster, although far from lightning-fast)

Watch and enjoy

Resurfacing

Hello everybody! Did you miss us?

This blog went without updates for an unusually  long time. You might’ve been thinking that Chaos Cult Games went belly-up and development stopped; however, nothing would be further from the truth. I’ve been busy with rewriting lots of foundational code basically from scratch, while my friends and partners were drawing, modeling texturing etc, preparing new content. All that to make Xenos look way nicer than before.

When I started working on Xenos, (that was almost a year ago. My god, it IS taking longer than planned!) the game world was made up of small tiles. And these tiles had little objects, modeled with all the art skill of an experienced programmer. It looked ugly, but it was workable. Today, when art is created by actual artists, this approach is both ugly and counterproductive; so I had to change everything.

example of a chunk

A single chunk in Unity editor

The new Xenos game world is made of chunks, that are around 100 times bigger that a tile was (i.e. a chunk is approximately 10×10 tiles area). Each chunk can have any number of objects inside, that can be arranged however we like – no grid of tiles is required. And, of course, the objects are not made with voxels anymore, but modeled traditionally with polygons and lots of detail (at least, more detail. We still have to deal with performance limitations). This new approach allows for much more interesting and varied environment, but it also brought lots of technical difficulties. The procedural map generation that worked on tile map, naturally, stopped working. I had to make some new algorithms and I’m still nowhere near the complexity and flexibility I had with tiles. Pathfinding on a tile map is really easy compared to tile-less environment. Again, I reworked it, but it’s no longer as robust as before. Algorithm  for loading part of map on-the-fly – to create seamless environment – works with new system, but is unacceptably slow (went from 200ms to several seconds.) I’ve yet to fix this, and for now Xenos is limited to a single location.

In addition to that, content development is much slower now. Where before I could just decide: “I need a new table for this house”, model said table in 10 minutes with voxels and add it to the game, now I have to ask an artist to create that table. Which takes maybe an hour of actual work, and the work does not start immediately. Of all people working on Xenos, I’m the only one without a full-time job, after all.

On the plus side, with more generic art requirements, we’ve been able to make use of ready-made assets in Asset Store. These help considerably.

Current status of Xenos development is this:

  • We have working chunk-based system, that supports most of game mechanics from current demo.
  • We have a number of assets to create a town location, kind of like the one in demo (but not enough)
  • We’re building different buildings and parts of environment for this location, but we don’t have nearly enough yet.
  • We have concept art for player character and alien robots, and it’s being turned into actual models right now.

So, I think we can wrap these things up and create a new demo version somewhere around october. While you’re waiting, be sure to check new screenshots and concept art on IndieDB!