Fog Implementation

December 6th, 2013 No comments













I wanted to go into some detail how the fog component in the RTS project worked, which was one of the more specialised features you don’t find in other genres. I decided to use a three-stage implementation.

  • Undiscovered
  • Discovered
  • Revealed

The fog would begin as being completely undiscovered. As units explore, areas become revealed. Then, if a unit leaves a discovered area, instead of covering the area back up completely, the area would become only partially shrouded – only the landscape is visible and no potential hostile entities are.

The fog itself is essentially a low-resolution texture, 64 x 64 that is orthogonally projected over the entire terrain, as well as being rendered on top of the minimap texture, which means I’ve separated static (terrain) and dynamic (icons, units, other icons) draw calls

To reveal areas of the map, each unit and building sends a raycast upwards which is masked to only hit the fog’s physical layer which covers the entire map. The hit point is then converted into a texture coordinate by dividing the world position by the terrain size. Because it’s orthogonally projected, this results in a perfect representation of a pixel using the correct coordinates. This pixel and its neighbour’s colours are then set to black with no alpha, to allow it to fade in from the surrounding shroud.


The downside to this is that this is performed on the CPU entirely with the obvious exception of the projection being drawn. To somewhat solve the problem of a lot of units causing a lot of stress on the CPU from raycasts, raycasts are performed for 10% of all units per frame, which still results in a fast fog reaction. Because the fog resolution is relatively small, only 64 x 64, areas are revealed in a grid-like pattern which in this case is fine. A smooth and gradual reveal would most likely be impractical using my implementation due to the sheer number of raycasts and texture resolution of the fog layer.

One problem this has caused is that the way Unity handles projections is rather odd. As can be seen from the second image, projections are performed on a per-material basis which is causing artifacts on textures themselves. For example, the bridge has bright spots which match the area of the fog layer that is revealed. A fix for this would most likely also combat the aforementioned downside, by utilizing a pixel shader on the GPU that handles my own implementation without the use of texture projection. This however would not allow the raycasting implementation and I would most likely have to use  unit positions in static buffers to feed directly into GPU memory.

Web Stuff and RTS Project Status

November 30th, 2013 No comments

Well, it’s been a week and I’m still working on a website, 1 to 2 hours a day with another few spent on researching the DirectX 11 API in depth as most of my rendering experience is behind with DirectX 9. Having read through large text resources, it’s given me some great insight on future systems I intend to write, which means I can start posting more work samples rather than theory and more importantly, content that is of more interest to the public.

In regards to the RTS project I have currently put it on hold due to the fact I’m working on the website, and my main interest has been focused on writing a complete game engine which will take a considerable amount of time as well the constant reminder to seek employment which is becoming tiresome. On top of all that I’ve had various issues with the pathfinding due to unexplained behaviour with Unity’s inbuilt navmesh agent after it is interrupted with my local A* solution for collision avoidance which isn’t something I can fix unless I opt to purchase an expensive third party navmesh plugin or spend a long time writing my own which is out of the scope of the project.

The main purpose of the RTS design was to see if I could replicate core functions from the genre – fog of war, an interactive interface, unit control, pathfinding, building placement and construction, individual AI (such as the harvester automatically collecting resources)  and some other tidbits. What I might do in the future is see if I can expand on it and polish it up, after all the last missing component is the actual combat.

With that said, I have not yet discussed my implementation of the Fog of War system, so this will be an update I will release in a short time that details how it works, with some screenshots to keep things interesting. The next image posted thereafter are most likely UML diagrams as I plan the architecture of my realtime rendering engine. However, expect interesting image results too as I’ll be experimenting with the latest shader model languages!

Categories: Me Tags: , , ,

Web Development

November 21st, 2013 No comments

It’s been a little while since the last update, mainly for two separate reasons. The first being I have had second degree burns on my shoulder for a week which wasn’t helping motivation to code let alone use a computer or do anything else, and while I didn’t do nothing I chose to take a bit of time off from any side hobbies until I could get to a point they’d be fun to code again.

The second part goes for a website I’ve been creating for someone that’s essentially going to be used for a small community group, and since this is a bit more than a hobby project I’ve been prioritizing it’s completion has a somewhat larger meaning. The thing is I’ve never actually dealt much with web development. I have a blog which I occasionally tinker with, and I have had some work done with SQL databases for non-web based applications. The nice thing the deadline is very relaxed; essentially ‘get it done before the end of the year or something’ so it’s given me ample time to explore some features. I’ve been using jQuery, the Facebook API, the Google Maps v3 API, more PHP and a fair bit of CSS.

I’m quite content with the progress I’m making, having developed a user system that synchronizes loosely with the Facebook API (only for notifications, which work nicely) as well as varying levels of access, and of course, secure, salted and encrypted passwords. There’s a bit more to go – I’d estimate I’m just over the halfway point now with a fair bit of that second-half simply being polishing things up, and I might post a link up once I’ve finished it. I’ll post a bit more later on how I’m dividing up my workload so if anyone follows the posts then you’d have a better understanding of when to expect things.

Categories: Me, Programming Tags: , , , ,


November 6th, 2013 No comments

The next topic is path finding. It’s a tricky subject with an RTS as I’ve found, as ultimately it’s the most complex system each individual unit must perform, therefore it is directly affecting how many RTS units the game can have at a time. The faster the algorithm, the higher the theoretical unit count on the same system. I’m pretty lenient here with my unit count since I’m not asking for a huge Planetary Annihilation /  Supreme Commander style RTS, neither am I asking for the precision systems of the Men of War series. I’m going to go with a target count of 100, so I’ should have plenty of CPU utilization room for pathfinding, assuming of course I don’t create a horrible algorithm.

Technical talk aside, I’ve recorded two videos that demonstrate two different versions of pathfinding. Both use Unity’s inbuilt nav-mesh to an extent, which from what I’ve read is a very fast pathfinding system. It didn’t take me long to figure out why, considering there is absolutely no collision avoidance built in which makes it a little less useful. The actual pathfinding itself however is good, and the agent system isn’t bad. The videos will be from a week old built, but it was a good time to record them as I was phasing out the old temporary system.

The only thing I didn’t like about the nav agents is the fact they rotate and move on the spot, giving a very weird sliding behaviour if your agent is meant to be a vehicle, so I’ve designed vehicle units to stop and rotate to a 15 degree zone of their target direction giving it a more natural approach.

Of course, the more important aspect was collision avoidance. RTS buildings can be placed at any time, in addition there’s lots of potential units all moving in different directions. My initial approach was to create a simply temporary system that paths around objects using cross products. This worked alright for pathing around single objects, but with multiple objects, the generated pathing started to become undesirable. I would simply set a temporary destination 90 degrees off a cross product from the unit position and the obstacle position.

The second method, a little less temporary was to implement an A* grid, and use this on top of the nav mesh. The avoidance path is currently not pathed all the way to the destination, meaning that after one obstacle a unit may have to figure a way past another in the distance. It makes sense to a degree as the pathing a long distance may be very processor intensive and may be wasteful considering obstacles can appear, disappear as well as move around.

At the moment the pathfinding works quite well with the avoidance system actually being more complete than the rest. The immediate change I can think of is sending a group move order without the units trying to pass around each other at the destination – setting a group destination pattern based on the relative position of other group units. At the moment, ordering a dozer to construct a building will set the destination to one of the four sides of the building – whichever is closest, after which construction begins.

There’s been quite a few nice additions since the videos, a big one being fog of war which will be fun to talk about, as well as a refinery/harvester/gold combination, of course relying heavily on the pathfinding. Another one being buildings now require a bulldozer to built them!

Categories: Me, Programming Tags: , , , , ,

Data Driven System

October 30th, 2013 No comments

Time for another update!

In this post I’ll be talking a little bit about the back-end of the game itself, so any pictures that are in the post won’t actually be showing the game this time. I’ve still included some to keep things interesting.

While planning for the project was minimal, I did think over the essentials around the time I started, and one of these decisions was to make the game somewhat data driven. This has multiple benefits, both for me and potential end users.

  • Game data is easy to add and remove as items are handled modularly
  • If something goes wrong it’s easy to track it down from the fail-safe importing methods
  • RTS units and buildings are much more dynamic – I’ll come back to that in a moment
  • Custom content (think mods!) is really easy to add
  • Code is much cleaner and structured

So let’s talk about a few of those points. I’ve decided that game content is handled from three different sources.

  1. Core game content (.NET Assemblies, code, core assets, etc.)
  2. Game Data (Units, levels, buildings that I created, etc.)
  3. Mod Data (Custom user created content)

A visual demonstration of the importation process is shown in the picture on the right. Core game files are loaded as per usual, then the data folder is unencrypted and uncompressed. Compression and encryption are here just to keep my own assets in check, and should I be outsourcing any 3D assets then you’d need to go through a bit of effort to actually obtain them.

The mod folder is actually loaded first, and therefore is able to override original content. Original content data is available in help files, so as an example, a player is able to replace the construction yard to use custom models or use the original buildings for tech references. The data and mod folder are actually the exact same format, it’s just that the former is simply packaged with the game in a less accessible way.

buildingFiles that provide the game with information are standard XML format which then point to any additional resources that the entity is made of. Currently there are only two formats, one for buildings and one for units. A level format might be added in the future, but it seems more appropriate to leave that as a binary file.

As part of the data structure, I have designed units and buildings to be somewhat in reverse order. Typically, a building may have a list of units it can create, or a building may have a list of new buildings that can be built after it. Instead, units refer to the string ID which they spawn from, as well as any tech requirements before they become available. Buildings are similar, in that they also have tech requirements.

As an example I have attached an image of the current barracks building. Note that the XML structure is very likely to change as there are some essential gameplay items that need to be provided, such as view distance, fire rate, damage, and what not. It wouldn’t be much of a fun RTS without combat would it? You can see that the building ID is listed at the top of the file, with basic properties below, tech properties then data files. Of course the order doesn’t actually matter, but that’s how I’ve structured it. You’ll also notice that the tech requirement of the BARRACKS building is the CONSTRUCTION_YARD, which means that it can only be built after the construction yard has been built. What isn’t visible is the upgrade XML nodes, but as these haven’t actually been implemented in-game they wouldn’t be much use yet anyway.

Upgrades can of course also serve as tech requirements for a building as they have their own string ID. It is currently planned to allow upgrades to replace the mesh of the unit or building, or even add to it if it’s a building, depending on if performance isn’t a concern (seeing as shadows would greatly increment the vertex count with all kinds of upgrades on screen). At this point the default texture formats of PNG/JPG are supported and OBJ models, but seeing as the asset loading is written in a modular way I’ll probably add a few more formats in the future such as TGA and 3DS.


Categories: Me, Programming Tags: , , ,