Daniel Petersen's Blog

Documenting my struggle to make a videogame, amongst other nonsense

Home Projects


Posted on 2018-01-20

Refactoring Code

Posted on 2017-07-14

I’ve been refactoring the codebase lately with the goal of increasing performance, mostly from multithreading it.

Prior to now everything was a single thread. I had no proper experience with multithreading, but I knew that it added a lot of complexity and I honestly thought that I could get away with the entire game being one thread.

I think if this game was strictly turn based then it’d have been fine, but it’s not. You press one of the speed buttons up top, and then turns start happening automatically on a set interval depending on the speed chosen.

As I’ve started to add in more complex AI behavior and the number of units and cities grew, it became clear that I’d need to make the game multithreaded. On the fastest speed, turns happen about once every 600 milliseconds, so when the game was a single thread those 600 milliseconds were essentially wasted, as the game was waiting until the 600 milliseconds were up in order to calculate the next state of the game world. It led to a noticable pause every time a new turn occurred.

So that’s how I’ve been spending my time lately. Truthfully it’s not as bad as I thought it’d be, though I do wish I did this sooner.

Since I’m refactoring the codebase to allow for that, I’ve also taken this opportunity to improve other aspects of the code. The grid for instance is something that I wrote in 2012 when I was much worse at programming than I am now, and it could really be better. Notably I had entangled it too much with code specific for this project. What I want is something independent which can be reused in other projects. It’d also be nice if it supported multiple grid types (square, isometric, hex).

So I spent some time working on that and it’s been a pleasant success. It’s now faster, more flexible, and you can set the grid type at initialization. Currently supports square, isometric, and I spent about an hour last night adding in hex support. The game is mostly agnostic to what type of grid it takes place on, so I can now generate a world using any of those grid types, which is pretty cool. I’d have to do some work to make it truly playable on a hex grid (for instance, some AI code would need to account for the different grid type), but curiosity of how this would look as a hexmap got the better of me.

I’m hoping to get back to actually implementing more gameplay soon.

Ai City Location Mapper Update

Posted on 2017-06-20

So yeah, the method I described yesterday for allowing the AI to pick city locations is now implemented and seems to be working all right. It needs some tweaking, but I think it’s a good start.

Ai City Location Mapper

Posted on 2017-06-19

Today I’m going to try to implement an algorithm which picks city locations for the AI.

If you’ve ever played civilization, you should have a good idea on what this means, as it’s more or less the same problem from that game. Maps in my game are much larger than in Civilization, and my game ticks along at like 1 turn every 600 milliseconds, so performance is a pretty huge concern.

I’m still debating the exact city ring size, and I’m going off memory here but I think cities can currently grow to a maximum of 5x5 tiles. You can see the maximum growth of a city by the black outline around the center city this screen

I’ve come up with something that I think will work (high level code outline below), but I wouldn’t be surprised if there’s a much better way of going about it.

// Only one  object of this class will be instantiated, and each AI will talk to this object 
// in order to get a city location
class AI_City_Location_Mapper
    // first dimension is number of continents on the map 
    // (where a continent is a group of connected land tiles)
    // second dimension is a vector of tile indexes where cities should be placed
    std::vector<std::vector<int>> CityLocationsByContinent

    // where the magic happens
    void calculateCityLocations(int ContinentIndex);

    // city locations are calculated for each continent on map generation and
    // cached in the above array
    void onMapGeneration()
        for (int i = 0; i < NUMBER_OF_CONTINENETS; i++)

    // if the human player settles a city, the city locations for that
    // continent might need to be reworked to make more sense.
    void onCityCreation(int ContinentIndex)

    // basically, the above two functions are the only time when city
    // locations are going to be updated.  

    // when the AI wants a location for a new city, it calls this function,
    // and passes the unit index for the settler in question. the game iterates
    // through each possible city location for the continent the city is on, and 
    // does a simple calculation based on distance and city desirability to determine
    // which city location to settle. -1 if no city available 
    int requestCityLocation(int UnitIndex);

For calculateCityLocations(), I’m thinking that I’m going to divide the map up into a larger grid, with each cell in this larger grid representing let’s say a 5x5 group of cells. Perhaps that size will be determined by the city ring size. I then think I’m going to assign a city location in the center tile of the actual grid for each cell in this large grid.

So essentially calculateCityLocations would be iterating over each city in this list and moving the city location over 1 tile for each loop iteration, based on the best location of its neighbors. If the initial city location happens to be on a water tile, I’ll have to do a check to make sure that doesn’t happen or fix it when it does. I already have a function which ranks how good any given city location is, but I’m going to need to expand that function to take into account tiles which are already owned by another city (obviously those tiles would be degraded in importance).

I’m aiming to do all of this today, but we’ll see how it goes.

Tile Outputs and the Eternal War: Rise of the Sioux

Posted on 2017-06-11

I’ve been making good progress on It Usually Ends In Nuclear War lately. There’s still a lot of work left to do, but I feel like I can see a light at the end of the tunnel now.

In the last post about it I talked about how I changed the name of the game from “It Always Ends In Nuclear War” to “It Usually Ends In Nuclear War”. The name was meant to be a commentary on human civilization, but I decided to change it as I was afraid that the old name could have given the wrong impression about the gameplay.

I also talked about how I changed the graphics, opting to get rid of the pronounced psuedo-3d height visual effect going on. I liked the way it looked and I put a fair amount of work into it, but it was purely aesthetic and it prevented me from using tile colors to display information about a given tile.

I want to go more into why I did that and how it works, because it’s actually a pretty huge and beneficial change.

In most if not all other similar 4X games there are a set number of distinct tile types. In Civilization II for example, a tile could either be grassland, swamp, forest, plains, desert, or tundra. Each tile type had a specific food, production, and science output. I want the output of a tile to be somewhat dynamic, and I want the player to more or less be able to tell the output of a tile by its color alone.

So I still have a base set of tile types which have a specific food and production output, but the tiles are blended in with their neighbors, and the outputs are averaged together (as is their color). On top of this, I’m also further applying a bonus to production or food to select tiles, and I’m using the the shade of a tile color to communicate this to the player. Darker tiles are better for production, lighter tiles are better for food.

I can’t say how anyone else will receive it, but I really quite like how it turned out. At least in my head, lighter green tiles look more like grassland tiles and accordingly have great food output, and darker green tiles look to me more like forests and have great production output.

The reason I’m happy about this is that most maps will have huge swaths of land which are a single tile type. In the old system these tiles would all have the same output and I honestly don’t know how I would go about balancing that. This new system allows me to have those large swaths of land which are the same tile type, but vary their output depending on the shade, which for example would make some tiles in a huge swath of desert still desirable.

I’ve done a lot of other stuff since then, but those two are I think the biggest and most obvious changes.

Older look

Screenshot fro a few months ago. The map is completely flat here

Screenshot from yesterday morning. I readded height to the map here, but the tile shadows from height are no longer present. Kind of a compromise between the two

On another note, back in 2012 someone created this topic on reddit which described a game of Civilization II that the poster had been playing for almost a decade. It described a 1984-like post apocalyptic world in which 3 world powers were locked in a never ending struggle for supremacy. The year was 3,991 A.D. and the world had been wrecked by nuclear weapons and global warming.

Civilization II is one of my all time favorite games. I’m not sure if I began work on It Usually Ends In Nuclear War before that thread was posted, but if it was after, I don’t think that’s a coincidence. You wouldn’t get games like that in the later iterations of the series.

Anyway, a subreddit popped up for this in which people posted stories about their playthroughs of the game. I took a good hard look at the world and realized that the OP of the original post had actually neglected to talk about one of the nations still alive left in the world. On a small island in the center of the planet existed the Sioux, a small band of 100,000 people. They were a republic in a world of superpower religious theocracies and dictatorships.

I decided that I had to take up a game with them as my mantle. I wrote up this story about my playthrough back in 2012, and it got a fair number of positive comments.

I never completed that game, though. 12 months ago someone pm’d me on reddit about the possibility of continuing their story, and I decided yeah, why not. 11 months ago I had spent a day playing almost 400 more years into the game, taking a ton of screenshots along the way. I finally got around to making a write up of the game and posting it to reddit one week ago. You can check it out here.

This type of thing is what I love. World building through nothing but solid mechanics and your own imagination. I very much want to recreate this feeling in the game I’m making.


Posted on 2017-05-15

Ladies and gentlement, my game of the year for 2017:


It’s a browser-based strategy game which I’ll describe as taking the essence of RTS games like Starcraft and simplifying them down to their most core elements.

The game takes place on a randomly generated grid of varying sizes depending on the number of players. I mostly played 1 v 1’s, though FFA’s are also a lot of fun (and I believe more popular).

Each player has a starting tile which is where their general is. If an opponent captures your general, you lose the game. The game ticks along at a solid rate, with each tick being analgous to a turn, and lasting 500 milliseconds. You want to expand and capture as many tiles as you can, because every 25 ticks each tile you own will produce 1 armies. Cities are also scattered about the map, and capturing a city will give you 1 army per tick.

Capturing neutral tiles costs 1 army, and you’ll need about 40 armies to capture a city. I love the strategy in this, because it all comes down to knowing where to expand, when to expand, when to take cities, and when to attack. There’s also some micromanagement involved in knowing when and how to efficiently gather your forces. I think the strongest point of the game is that you can be ahead and still lose if you make a mistake. It’s pretty fair.

I know my explanation isn’t quite doing the game justice. I’m going to leave a few replays here, with the 3rd replay being the craziest game I’ve seen.




I was playing this religiously for a few months around the turn of the new year. They released a patch a few months ago which I’m not a huge fan of (it made the game easier), but still, I highly recommend checking out the game.

Seven Month Update

Posted on 2017-04-20

Hello hello. Status update on where I’m at and what I’m working on nowadays.

It Always Ends In Nuclear War A civilization building game in development for Windows and Linux. I’m creating this because I want a simple 4X-like game which keeps micromanagement to a minimum yet allows for large empires.

Project is still alive and being worked on. In retrospect I think I bit off a bit more than I should have, because holy crap there’s a lot of work left to do, but it’s slowly getting done.

I’ve made some big sweeping changes since I last talked about this. Most noticably, I’ve gotten rid of the psuedo 3D height effect in favor of a flat map. This allows me to have more varied tile types which was impossible to do with the tile-height visuals, it’s a huge improvement in terms of gameplay. I am a bit sad because I put a lot of work on getting the 3D height in and looking good, but I think the change is for the best.

The other major change that I want to talk about is that I’ve changed the name of the game. It’s now called “It Usually Ends In Nuclear War”. Initially I came up with this as a joke, but the more I thought about it, the more it made sense to me. The original name was supposed to be tongue-in-cheek, but I can see people getting upset that every game did not in fact end in a nuclear war. That’d be a nightmare to design! The intention with this new name is that it’s more obvious that the name is tongue-in-cheek and should not be taken too seriously.

Most of the work that is left is AI, though there are things which need to be fleshed out. When I feel that the game is ready, the plan is for me to start talking about it on a regular basis. I want to record weekly video blogs similar to what the developers of games like Overgrowth / Production Line are doing.

Unnamed Project

I’ve been working on a few prototypes for a 2D action-roguelite that I’ve had in my head in some form or another since 2012. The driving idea behind it is a minimalistic 2D game based on capturing the feel of a DBZ fight. LBZ is the closest game I can think of which is out there, and it’s not quite what I want in terms of game feel or style.

Below we’ve got videos which show a few prototypes made with this project in mind. The latest version is based off the second video shown below.

  • a video showing off a particle system I built during a sleepless night
  • a video showing off three programs -- a possible energy attack effect, an experiment on how to achieve malleable terrain, and a simple gameplay / flight system mockup I had made back in late 2012.
  • The ragdoll physics video is something which I converted to C++ / SFML from an open source Java program. The code was licensed in a way where you're not restricted in what you're allowed to do with it, but I feel better mentioning that as a disclaimer. Coding a ragdoll physics system from scratch is out of my ability. In porting it I now understand the logic behind it, but yeah. I really need to brush up on my math skill.

  • Plan for the Next Year

    Posted on 2016-08-31

    For the past two years I’ve been saving my money with a vague idea that I would take time off from working full time in order to finally finish It Always Ends In Nuclear War. That time has now come. I just finished moving into a place where I’ll have a much lower monthly burn rate, I’m going to have enough money to at the very least last a year.

    Finishing It Always Ends In Nuclear War is now my priority. I’m still going to be working a few hours every week for what was previously my full time job, but the amount of time I can devote to the game has increased to at least 30 hours a week. To put this into perspective, it was rare that I could spend that much time a month working on the game.

    Until now this game has basically been a cool hobby for me, but it’s a very time consuming hobby. For my own sanity I need to finish it and put it behind me. When the game is done I’m going to put it up for sale and see what happens. I’ve read enough video game post mortems at this point to realize that I have almost no chance of making any money, but that’s all right. It’d be really dissapointing and I’m sure I’d be upset, but I’ll be happy just completing the game and having something to put on my resume.

    I think it’s going to be a fun year for me.

    Use Local Backups, Control the Things You Can

    Posted on 2016-07-15

    I just read this story about an artist who had been keeping a blog about his artwork on Google’s Blogger Platform. Google disabled his email and blog account for an apparent terms of service issue, though they haven’t communicated exactly what term had been broke.

    There’s a good lesson here in having multiple backups of the things you care about. I think most people understand that. I think it’s less obvious that relying on a service like Blogger is inherently dangerous. You’re giving someone else control of what you can do / say, and if they happen to not want your content for whatever reason, you’re allowing them to remove that content at their discretion.

    Where you can, I think it’s important to not put yourself at the mercy of others. Own your website domain. Own your website data. If possible, make your website content platform agnostic so that you can switch to another host if need be.

    This site is just static HTML, for instance, so any website host in the world should have no problem hosting the content. Something like Wordpress would be just as good. There’s a tradeoff here as I think using a service like Blogger or Tumblr will drive people to your site. I just don’t think it’s worth the price of admission of allowing another entity to control access to your content.

    This isn’t just about blogs. People who rely on Youtube for a living are very much at the mercy of Google. The same goes for websites which rely on adwords to make revenue. Steam has a near monopoly on the PC video game space. Unfortunately, I don’t think there’s too much that can be done about those three.

    Making Solid Progress

    Posted on 2016-07-14

    It’s slow but steady progress on the game front. I’ve now got a design which I’m confident in, which admittedly has happened before, but I think it’s truly solid this time.

    I’ve also been making some great progress on the coding front. I’m not a morning person in the slightest, but I’ve started getting up at around 6 AM, which allows me roughly two hours in the morning to work on the game while I’m fresh. It’s actually made mornings a lot more pleasant for me, as I have something to look forward to every day (making progress on the game!), and it makes me feel like if I do nothing else that day, at least I’ve done a small part of working towards completing this game and thus completing one of my major life goals. Making this change has been one of the best things I’ve decided on in a good while.

    I’ve recently discovered a design document from one of the early iterations of the game, and it had a cool little gem in it – I had written down the day that I started work on It Always Ends In Nuclear War. 11/24/12. It’s been very on and off work, to be honest, and what I’ve wanted to do with the project has changed drastically over time, but it’s cool to know how long I’ve been at it.

    I’ve started some other small projects from time to time while working on this game, and usually what I’ve done is either start those projects from scratch, or try and take some code from It Always End In Nuclear War to use as a base. This has been a pain, though. A few weeks ago I decided to abstract out the core, reusable bits of It Always Ends In Nuclear War into a framework which I can use for other C++ programming projects. This was a surprising amount of work, but it’s done now, and I’m extremely happy about it. It not only cleans up the code for It Always Ends In Nuclear War, but it gives me a base to work from for other projects.

    Finally, I spent a little time last night and this morning on getting unit range to work. Basically, if a unit enters the range of another unit, the game now knows about it. This is the first step towards getting a good working combat system. The screenshots below shows this, with the numbers below each unit being an identifier for units which are in range. The first screenshot is missing a small edge case so it isn’t entirely accurate, second screenshot has it working 100%.

    Next Page

    Copyright © - Daniel J. Petersen