I guess it's pretty soon after my last journal entry, but I've been quick at progress with my game code the past couple of days. First of all I finally got the Entity-Component System code working in the project.

In more detail:

• PlayerSystem sets movement and commands for all players
  
  
  • For AI, PlayerAction chooses a target out of a list of possible targets
    
  • For human controlled players, it reads and updates PlayerInput
    
  • Velocity is then updated based on one of the components mentioned above.
    

PhysicsSystem applies Velocity to Transformation matrix of objects

PowerUpSystem tracks all available power-ups and other pickup items and checks for player interaction

RenderingSystem is used with Transform and Sprite to draw the graphics on screen

The results are not exactly the same but I was mostly focused on translating most of the program logic and making the code compile again. Last week I completed the move to ECS, but more exciting is that I also moved to MonoGame 3.2 and building it as a MonoGame application. I decided that it's a lot easier sooner than later, especially since my code base is still not so big and I am still prototyping in 2D.

One of the big hurdles in moving from XNA to MonoGame is re-doing your content pipeline. XNA had it all set up for you, for processing different types of images, models and sounds, and making it possible to write your own content processors. It worked like an awesome magic black box that takes care of all the conversion for you outside of the actual game and the you just do a few function calls in your game to load them blazingly fast. MonoGame didn't have that for a long time. Just now they recently added a custom Content Builder but I have no use for it yet.

Processing image files is now a part of MonoGame, and I also found a way to add in SpriteFont support to the build process as well. Keeping with my XNA projects, I even got it to work with the Nuclex SpriteFont Processor so now all my text can be rendered very nice and smooth-looking. The next big step with the content is re-adding the code for my 3D engine piece by piece and hopefully bringing in support for normal and spec-mapped models and all my custom shaders again.

Experiments With Pathfinding

But for now, I am focusing on an important part of the game AI- pathfinding. As mentioned before my goal is to make a 3D top-down shooter, and a lot of the inspiration comes from a similar indie shooter simply called Kong. This started development around 2007, and then ported to XNA on Xbox 360 a few years later. It's a simple game but one that looks potentially very fun with multiple players (online scene is dead at the moment). This is the basis on what I want to make my game like.

I do not know exactly how the bots in the game work, but I am thinking back to the days of Unreal Tournament 2004 when bots used waypoints and pickup items as guides to get around the map. Waypoints, though straightforward to implement, are now considered obsolete and show artifacts in unconvincing AI movement. It is preferred to use a navigation mesh, or a grid or some combination of both that lets AI players have freedom of movement over areas, instead of sticking to a fixed network of paths.

I decided to go with grid-based movement. Two reasons for this: there exist several algorithms that make it easily to apply grid-based movement, even when the movement in the game is not restricted to squares, and also because the maps in my game will be built using a 3D cube grid. No, it will not look like Minecraft, but having 3D objects snap to a grid makes it easier for me to build a map editor, as well as be more intuitive for people to use.

Yesterday I was able to get a simple A* pathfinding demo working on my browser, using plain old Javascript and no external libraries. Most of the help did come from Brian Grinstead's A* algorithm code but I still had to make a couple tweaks to get it working on my demo. I used the simpler, but less efficient version, and have it support 45-degree diagonal movement. Here is a screenshot of the demo:



The drop down box lets you add/remove walls, a start point and end point, and then calculate the path. It's a little buggy in cell selection, but this is just a web page prototype so I just cared about making the algorithm work. In its final version I want it to support Euclidean distances so it can follow any kind of diagonal direction, but it's more likely that will happen long after I integrate the pathfinding code into the game.

One oversight on diagonal movement is that this code allows movement through diagonal walls. It's part of the original code when it checks neighboring cells. For instance, if there are obstacles to your north and east, but not northeast, you can still move northeast. In a game, this will make a character look as if he is "tunneling" through the wall. It is made even worse if there are tiles that have diagonal walls, making it much more obvious that you shouldn't pass through there.



Needless to say the pathfinding is not yet in a usable state. It's an easy fix, though. There are only four pairs of directions that, if there are walls present, it's safe to assume that the direction between them is also impassable. Thus, a wall should also be added there to the list of neighbor cells to check.

Once I have made that fix, I will port the code to C# and run it in a separate simulation so I can find out its real-time performance. I want to have several AI players make their way to a goal from random points in a maze first, and then have that goal movable so that their paths update in real time. Keep in mind I still have to add collision detection to the walls, especially when it comes to the human controlled player. However, this will already be a huge step forward in development. Not only for this game, but also in my understanding of game mechanics I have not previously explored in detail.