About

I am starting a second career as a game programmer. For the past twenty years I have worked in the field of military modelling and simulation. My role have been varied ranging from writing some software as needed, to project management and acquisition, education and analysis.

My key areas of interest is in behavioral modeling or in my new context, game AI, and simulated persistent worlds. So things like behavior trees, GOAP, Utility systems and so on is right up my ally. I also like as systems for game-play features like trading, economics, large scale combat e.t.c.

I do and enjoy other kinds of programming too, but a guy has to have some favorites, right?

I am currently attending The Game Assembly’s higher vocational education as a game programmer. During two years we learn a lot of useful patterns, bits and pieces useful for games, finally in writing our own game engine in C++.

We also have time to work with graphics and level design students to create eight different games, the last four using our own engine.

cv

Level of Detail for game AI

In this experiment I have investigated a technique for giving AI behaviors a Level of Detail capability.

The idea is simple, when no one is looking we can use a more lightweight model to get the effect of the AIs activities in the world. And when someone we care about comes within range we switch to a more detailed model.

In the demo two identical beehives have workers gathering pollen to make honey. With that they can raise more bees to help out around the hive.

I’d like to draw your attention to three things in the GIF (please go the article to see the full GIF):

  • The amount of collected pollen is the same in both hives whether they are observed or not. This is because care is taken that both levels of simulation meet the same constraints.
  • The frame rate is notably effected when a collection area is observed. This is because the detailed model when the individual bees are shown is more expensive. In this model it is mostly just added collision detection that eat a bit of the CPU budget.
  • When the ”player” moves a way from the bees it looks like they are stuck where last seen. Their positions are no longer calculated and updated at this time. But when returning to the area their current position is calculated from the completion ratio of their current behavior stage.

This demonstrate the basic idea that we can ”get away” with the more lightweight simulation for the macro level behavior, the pollen collection in this case, when there is no reason to know more details about whats going on at the micro level.

The key to this is that all state needed to recreate the detailed behavior is produced by the lightweight model, and vice versa so that switching back and forth between the two models is transparent.

Conclusions

This type of Level of Detail is mostly useful in situations where there is a lot of persistent activities/processes going on in a game. Like simulation of cities, large troop formations e.t.c..

This experiment is a bit to small to say if it is worth the extra complexity or not and I would like to scale it up in the future. However I feel that it is significant enough savings even here to motivate further experimentation at least.

I have also contemplated an alternative strategy more suitable for things like caravans or troop formations. When moving away from an observed activity we would remember that time, their current actions/state and kinematic parameters.

To compute the new position when coming back to the activity, we would calculate an area that the unit could have had time to move within and either interpolate the new position from its old one if its basically still doing the same thing. But if it has changed its action/state we could figure out a more likely position based on that action/state.

If the area of potential current position is larger than a set threshold we could chose an arbitrary position within the activity’s area of operation that is suitable for its current action/state. So for a troop formation scout units would be positioned in a flanking or forward position to the center of the activity where you would find the core of the formation, appropriately spaced and positioned according to the activity’s overall state.

I did not have time to implement this but will return to this when I get some time to spare.

Spite: New Sun – UI

This is from the sixth of the eight games that I was part of making during my education at The Game Assembly, TGA. In This project my largest contribution was in making the UI. (Go to article for full resolution GIF)

I had developed a framework for UI during previous games in several iterations and in this it started coming together as showcased here by the players status and abilities panel.

A* pathfinding visualization

As any one interested in game AI, I have also implemented the famous A* algorithm for finding the shortest path.

In the demo I made you draw a picture and click on a start and an end point then you get to see the algorithm searching a path between the two. It is possible to vary how many cells to open in every frame update, thereby scaling the animation speed. This can also be useful in games to distribute the path finding cost over several frames.

For curiosity: The algorithm is showed above working on a 2D, templated grid data structure where each cell is a UI Element made in my ProgUI framework. By right clicking cells you set a property saying that the cell is blocked and this can be cleared with the middle button.