Daniel Petersen's Blog

Documenting my struggle to make a videogame, amongst other nonsense


Home Projects

Background Grid Physics

Posted on 2018-02-24

I’m playing around with what to do for the background. The geometry wars style grid here is one of the experiments. I don’t know if I’m going to keep it in as it makes it pretty hard to read the screen


Another Video

Posted on 2018-02-11

Just playing around with this idea a bit yesterday.


Deformable Terrain

Posted on 2018-02-10

I’m sure it’s a terrible idea to work on this project when the main game I’m working on is still unfinished, but once in a blue moon I feel compelled to work on this 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.

I think there’s a total of like 20 days of work on this spread across 5 years, so I put this out there with that huge disclaimer.

For more of an explanation on what this actually is, it’s loosely based on the combat in DBZ. You control a very tiny and fast square. It can fly / teleport and shoot energy attacks.

I’m the yellow dude in this video. The circle around me is how much energy I have. Flying, teleporting, and energy attacks drain energy. Energy automatically regenerates after not using any for a short period of time. Energy regenerates 2 times faster if you’re (more or less) stationary.

If you fly into the opponent square, a melee collision happens, and the loser gets damaged and knocked back. The winner is determined by whoever was moving faster in the opponents direction. It’s all about momentum.


2018-01-20

Posted on 2018-01-20


Refactoring Code

Posted on 2017-07-14

I’ve been spending my time taking my single threaded game and making it multi-threaded in an effort to improve performance. I honestly thought that I could get away with the entire game being single threaded, but it gets noticably choppy late game and I’d like to fix that.

I think if this game was strictly turn based like most 4x games 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. 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. 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.

It’s been a good learning experience, though I do wish I did this sooner.

I’m also taking this time to refactor other aspects of the code. For example, the code responsible for the grid is something that I wrote in 2012, and I was making things up as I went along back then. I still am to be honest, but I’ve got more of an idea nowadays. The grid was entangled too much with code specific for this project. What I want instead 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 making that happen. Code is now cleaner and more flexible. Also now 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 (AI code would need to account for the different grid type for instance), but curiosity of how this would look as a hexmap got the better of me.


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
{
private:
    // 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);

public:
    // city locations are calculated for each continent on map generation and
    // cached in the above array
    void onMapGeneration()
    {
        CityLocationsByContinent.resize(NUMBER_OF_CONTINENETS);
        for (int i = 0; i < NUMBER_OF_CONTINENETS; i++)
        {
            calculateCityLocations(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)
    {
        calculateCityLocations(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

Posted on 2017-06-11

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


Rise of the Sioux

Posted on 2017-06-11

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. They changed the way votes are tallied up so it’s hard to say if this is still true, but at the time it was one of the highest upvoted threads in reddit history. 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, this post probably helped me start thinking in that direction. There was something special about Civ 2, you don’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.


Generals.io

Posted on 2017-05-15

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

generals.io

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.

http://generals.io/replays/St0cFk1vg

http://generals.io/replays/rOIotNgwl

http://generals.io/replays/HFSPXREIx

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.

Next Page


Copyright © - Daniel J. Petersen