Tag Archives: roguelikedev

Mystery Conquest Project (PART 1)

Posted on by
2

Follow me on the twatters.
Subscribe on youtube for vidya.

Hello! It’s time for miscellaneous Wednesday. I recently started the development of a new project that I think is pretty interesting. I can’t think of any roguelikes (or modern games in general) that go for this kind of thing anymore. I’m going to start documenting its progress before I get too far ahead. What is it, though? It’s a horrifying combination of my favorite elements from a million different games all shoved into one.

The core of the game is largely based on two games. I’ll focus on those. There’s galactic conquest mode from the Star Wars Battlefront line of games and Warfare mode from Arma 2. There’s a bunch of other Arma modes (and mods) that provide additional inspiration but talking about them is beyond the introductory scope of this post.

So, let’s start with galactic conquest. The name is pretty self explanatory!

Your goal is to conquer all the planets. To do this you move your fleet to worlds you don’t own yet. You can have more than one fleet but you can only move one of them per turn.

The neutral worlds are instantly claimed when your fleet arrives while enemy worlds require a fight. This is where the fun begins! Each planet can be thought of as a collection of maps.

To capture the planet you have to take control of all the maps by defeating the enemy on every single one of them. Each planet is a tug of war battle for total control.

Here is my attempt to peel back the layers a little bit more to help further explain things. This diagram was made in a free program called Dia. The red and blue planets represent the two different factions while the black one is neutral. The orange planet is contested which means they’re fighting over it. The rectangles connected to the contested planet are its maps. You can see how some of the maps belong to different factions. The orange one is where the current fight on the planet is located. If all those maps are captured by one of the factions then they capture the whole planet!

The maps are your standard control point based affair. If you’ve played any multiplayer FPS game before then you know what I mean. Even if you haven’t then you probably still know what I mean since it’s such a common mechanic. There’s also a ticket system. Tickets are basically respawn points. Every time a team member respawns one of those tickets gets taken away. This means that there are two ways to win. Either capture all the control points or kill so many of your enemies that they run out of tickets.

This is where my project begins to take on a form of its own. First, I plan to make planets and the maps on said planets more important. They’re going to be a source of bonuses instead of just territory. This will add a little more strategy to what you decide to attack and defend. Battlefront has bonuses but you just buy them with the credits you earn from fighting. It’s a pretty underdeveloped system that I forget to use most of the time. It’s unbalanced, too, since some bonuses are overwhelmingly better than others! I’ll always choose increased weapon damage over that stupid control point defense turret, for example. This is what a galaxy map in my game might instead look like.

I left faction ownership out of this example to avoid over-complicating things. You can see that planets and their maps now have bonuses tied to them. If you control a map then your faction gets the related bonus. If you control all the maps on a planet then you also get the planetary bonus. The bonuses hint at some of the fun stuff I plan to add later. I’m not going to talk about those yet, though!

I’m getting antsy with excitement and want to start working on the project so its time to move on! I’m going to start by making a map with control points. There’s also going to be two factions on the map that will be fighting over said control points. I’m not going to do any planet or galaxy stuff yet. There’s no point without the maps working.

To help keep things balanced for more sustainable testing purposes I’m also going to give each faction a headquarters. That’s a special type of control point that can’t be captured. This way, if one faction captures all the control points then the other faction will still have a place to spawn. This is an idea I got from Battlefield 2142. I forget what they’re called but that game has a few maps with the same mechanic.

The green base with the red crossed out circle cannot be captured. I don’t remember what the in game term is for these places but I’m going to continue calling them headquarters. Enough talk, though. Let’s go! I’m going to use the paint image to game map conversion method I’ve previously talked about in my super project series.

There’s not much to look at since everything is so simple right now. The red and green dots are each factions respective headquarters while the grey dots are neutral control points. The AI are finite state machines with two interests: capture control points and attack any enemies they come across. That’s it! I’m going to have each faction spawn an agent per turn at their HQ until a maximum of 100. Let’s see what happens.

Ah, yes. Truly flawless programming. There’s a ton of things going wrong! The agents aren’t attacking one another which probably means field of vision calculations are broken. They’re spawning near the top left corner instead of at their headquarters and for some inexplicable they’re pathfinding to their own headquarters? Mysteries abound.

Okay, I did some fixing! They’re now spawning at the proper location and targeting control points. The targeting system is still broken though so they’re not shooting each other yet. I’ve also now given them the code necessary to capture multiple control points whereas previously they would stop after getting the first one.

It looks weird. They move like flocks of birds. The agents tend to get all stacked up since they’re allowed to occupy the same tile. I need to get combat working.

I ripped my poor targeting code out since its not working and replaced it with a scummy brute force method. It’s slow but it works! Unfortunately, a problem I predicted might happen is actually happening. The pathfinder, due to being so efficient, is causing agents to move around the map in massive streams. This is due to the whole straight line between two points being the shortest path principle. I don’t like this because it means the player would be up against a never-ending line of enemies. The player needs to be capable of capturing points on their own and otherwise standing a chance in combat. That’s not going to be possible with how things currently are!

I need to spread the AI out a little bit more to reduce this wall of death phenomenon. First, I’ve randomized each agents sight radius. This helped a little bit when it comes to agents clumping up during combat since they detect each other at different ranges. The next thing I did was slow down the agent spawn rate. There’s now a spawn delay of 10.

It helped a little bit but also introduced a new problem: unbalance. If I let the simulation run for long enough then one of the factions always becomes the dominant force. This is because the units have a tendency to slowly form into groups and as a result they steamroll anyone they come across. This causes a scenario where the other faction cant replace their losses fast enough. It’s a death blow that can’t be recovered from. I guess that’s technically fine, though? If this was a full game rather than a prototype for testing then the faction being dominated would eventually run out of tickets and lose.

Let’s get back onto the pathfinding topic. I booted up Battlefront 2 classic and entered a random skirmish with the AI. The goal here was to just watch how things played out. Even though I can’t see the actual code I can sort of figure out what’s going on behind the scenes just by watching how things play out. I don’t know if this is a unique ability of mine or all developers in general but here’s a clip of what I was watching.

If you can set aside the obvious graphical differences between this game and mine then they look very similar! In regards to agent behavior, at-least. The agents go from control point to control point and attack any enemies they come across. I noticed a few major behavior differences in agents between my game and Battlefront while watching.

First, the agents seem a little more efficient when it comes to control point selection. In my game, the agents choose one at random whereas in Battlefront the agents seem to individually pick the one nearest to them. I’m going to go ahead and give my agents a targeting upgrade by implementing this feature in my game. This is what it looks like.

I think its better as a result. It’s kind of weird how similar my agents are to the Battlefront agents now. I turned my map into a crude representation of the Endor map so the similarities are a little more obvious. The majority of combat is focused on the center of the map while the occasional guy slips through and captures a rear point. Unfortunately, I didn’t capture a good video on this update and I’m too far ahead to make a better one.

The other thing I noticed is that Battlefronts agents, while going from control point to control point, aren’t doing so in perfectly straight lines. I’m not sure why but they seem to spread out a little bit more. I originally thought its because they were getting thrown off course due to combat but then I saw some AI spawn and take an inefficient path to a nearby control-point without them getting involved in combat.

I think instead of pathing directly to a control point they’re pathing to a random coord near said control point. This makes sense on further examination. The control points in Battlefront don’t work like mine do. To capture them you just need to be near them instead of directly on them. I’m going to make that change in my game. The control points will now have a radius and agents will path to a random coordinate within said radius instead of directly to the point itself.

It looks more like Battlefront but it didn’t do much to solve the snowball affect. In fact, the red faction really spirals out of control near the end. I’ll have to find a better fix.

I’ve now made some major performance improvements behind the scenes. The game now rarely goes below 50fps whereas previously it was struggling to stay above 20. I’ve increased the maximum amount of agents per faction to 200 to take advantage of the improved performance. I’m not sure why but 200 seems to be the sweet spot balance wise. The ball of death phenomenon seldom seems to happen at that specific number. I also turned off the respawn delay to more quickly test mass agent behavior. I’m pretty happy with the results now. The blob, while not properly fixed, now only shows up on occasion. I’m going to move onto other things until it becomes an issue again.

The next difference I noticed is how spawning works. In my game agents spawn one at a time. In Battlefront, though, multiple agents seem able to respawn simultaneously. That makes sense since its a multiplayer game. It would suck if players had to wait in a long que to respawn! I think theres a separate respawn counter for each agent rather than a single shared one. I’m going to implement that next!

I’m pretty happy with the result. It actually increased the pace of things since multiple agents can now respawn simultaneously and get right back into the action. I didn’t see anything even close to a wall of death form, either! What else can I do? I think the next thing I should add is the ability for agents to spawn at owned control points.

Looking good. I think I’ve reached the limit of what I can accomplish on this map, though. It’s so small that more advanced testing is out of the question. The agents are constantly in such close proximity that its hard to see any real patterns anymore.

Unfortunately, the game is already at the limit of what my 1920×1080 monitor can handle. I could increase the map size but then portions of it would be off screen. The game is setup for map scrolling but in order to properly test things I need to be able to see it all at once. It’s time to switch over to pixel scale rather than ascii representation.

This is the new map. The previous one was 101×101 or 10201 tiles and was being drawn with 8×8 ascii. This one is 301×301 which is 90601 tiles. I’m now drawing things at a 4×4 scale using boxes. I still have a good amount of wiggle room if I need to reduce the size further! I’ve come to realize, though, that enormous maps like this probably wont be very fun to play on due to all the traveling involved. I could add automated pathfinding for the player or transport options such as vehicles and teleporters but it would nevertheless be best to keep things small. For testing, though, this is just fine!

I’m going to go ahead and give the agents a new routine now. It’s a short range patrol that causes agents to occasionally path to a random nearby location. I’m doing this to help further spread agents out for the same reason I’ve done it previously.

I’m pretty happy with the result! Each agent has a patrol counter and once it hits a certain threshold they patrol to a random nearby location. They still prioritize combat above patrolling but patrolling comes before capturing control points. This should make combat a less frustrating scenario once the player finally gets involved. I didn’t record a video for it, unfortunately. I was on a programming binge and forgot. You can see it in the following videos, though!

What’s next? I’m going to make the map a little more interesting by adding obstacles. Then I’m going to finally add the player! Creating obstacles will make the map actually look like a map finally. There’s going to be corridors to navigate and all sorts of stuff.

Okay, I’ve added buildings. I was originally going to make it symmetrical but decided not to. In fact, I went haywire doing the exact opposite! I removed the corner control points and instead added a new ones near the top and middle bottom. The design is inspired by planetside 1 and 2 with all its interesting building layouts.

I think that’s enough for today, though. Come back next time for player gameplay!

Zombie Update 1

Posted on by
Reply

I’ve decided to start sharing change logs! This is just a compilation of the most recent notable changes. I’ll make proper full change logs that detail every single thing in the future once its released. For now, though, you only need the essentials! The current goal right now (and probably for the foreseeable future) is to get a basic zombie apocalypse simulator up and running. I’ll add the fancy stuff once the foundation is up!

  • Zombies now chase survivors. They’re not very good at navigating complex spaces as expected. Move intelligently and you can lose them!
  • Zombies randomly lose interest in targets they cant detect anymore. Leave their line of sight and they’ll eventually stop following you.
  • Zombies have better pathfinding now that results in them surrounding targets. Move carefully or you’ll find yourself in the middle of a horde.
  • Zombies can now attack and kill survivors.
  • Survivors will rise as a zombie after a few turns if killed by one.
  • Zombies eat fresh corpses and most will ravenously swarm it.
  • Zombies will ignore most distractions while eating. Take advantage of this to escape or alternately put a few easy zombies into the ground. Or, if you’re a real meanie, kill someone to really distract them with a fresh meal.
  • Zombies use rects for target selection instead of fov calculations. This is less realistic but dramatically more performance friendly.
  • Improved tile drawing speed by only processing the bare minimum. This means only tiles that are both visible and within the camera viewport.
  • The game now starts with no zombies. Instead, a few survivors begin as infected. They randomly succumb after a few turns and turn into zombies.
  • More survivors spawn at a random location if there’s too few of them.
  • If there’s no zombies left then a few random survivors are artificiality infected to give the apocalypse a reboot.
  • I added a zombie spawn limit since it was getting to a ridiculous point where almost every single tile was filled with them in really long games.
  • Greyops random event has been added. They’re a squad of elite zombie slaying special forces that enter from a random map edge and carve a path of destruction to random waypoints. They prioritize zombies but will engage survivors that get too close. They have some special anti zombie items and high end military gear.

The undead masses

Posted on by
Reply

I implemented a swarming behavior today for zombies! They now actively surround targets. If you’re not careful then you’ll end up in the middle of a ravenous horde. You can actually see this happen to several survivors here.

The zombies ignore me so just pay attention to the yellow S’s in game or the yellow squares on the minimap. This is a natural result of how their pathfinding works so its still very performance friendly as there’s no need for flanking calculations or other frame devouring non-sense.

Previously, they would just form a nice and orderly line due to how their pathfinding worked. It’s like they’re patiently waiting for their turn to get a bite. You could sit their for a million turns and those zombies would never move. It just looked wrong and doesn’t seem very zombie like to me. They’re stupid, sure, but they’re also hungry! In media zombies will usually bunch up together in tightly crowded packs or even climb over one another. They never just patiently form a orderly que when fresh brains are present.

This is happening due to how the zombies move. They path by searching their neighboring tiles to find which one is closest to their target. Then they move to it! That’s literally it. They ignore walls and other movement blocking terrain when analyzing these neighbors. However, if said tile is occupied by a fellow zombie then they don’t move. That’s where the problem came from! I shouldn’t really call this pathfinding since there’s no real thinking involved but I don’t know what other term to use.

I had to give them a form of pathfinding that was not only believably stupid but also capable of somewhat trailing a target. It also had to be performance friendly since there’s potentially hundreds if not thousands of zombies active at once depending on the map size. If you look at this example again and look in the corner you’ll notice a counter displaying how many zeds are present. It would of been easier to just give them astar or dij-whateverthefuck but then they would of been too smart.

The way I made this possible is actually pretty simple. If the tile a zombie wants to move to is occupied by another zombie they will choose a new random neighbor and move to it instead of waiting in line like gentlemen. This clears up traffic jams which enables the swarming behavior as a result.

Minimap goodness

Posted on by
1

I added a minimap to the game. It was originally just to help me with debugging but it’s actually pretty useful for normal game play. The minimap allows you to see the whole map at once. This lets you find errors with terrain generation, pathfinding anomalies and all sorts of general wonkiness that you might otherwise miss.

For example, here’s a minimap view of a few survivors pathfinding to random waypoints. There’s something wrong going on, though. Try to see if you can find it!

I’ve now got it specifically set to not clear each frame which causes a noticable trail affect. This allows us to see everywhere the survivors have moved instead of only where they’re currently at. Can you see the problem, now?

The little buggers are pathing through walls! That’s no good. I do plan to eventually add ghosts (to be discussed in a future monster post!) but now isn’t the time. I wasn’t aware of this issue previously, so without the minimap, who knows how long it would of taken to discover?

The source of this problem was the path map. I accidentally created it using (y, x) coordinates instead of (x, y). That means it was basically flipped or mirrored. Or, in other words, the path map did not align with the terrain map. Here is an example of what that looks like. The left example is the messed up path map.

The beings use this path map for path calculations. The terrain map is just so I know where to draw what. It otherwise has no bearing on gameplay. This is what was causing them to path through walls. They were actually doing exactly what they’re supposed to do. It was my fault for feeding them the wrong information.

Also, just for the heck of it, here’s a bunch survivors moving around while the bug is still active. This makes it far more obvious. It also makes it look like a busy subway map! The minimap is a incredibly useful tool and I strongly suggest other developers implement it for visual debugging.

Here’s the same trail affect using a corrected path map. Much better!

Let me show you some other fun stuff I shoved into the minimap! Here is a heat map. This first video is just the heat map on its own.

This is the heat map overlaid on the terrain map.

Every time a survivor moves they add a 20 to their location in the heat map. Every turn all the values in said array are reduced by 1. The more beings that visit the same tile the hotter it gets as that locations value doesn’t have enough time to fade away. This allows you to see the most active portions of your map.

The side walks near the middle of the map are obviously the most traveled areas followed by building corners. The least traveled areas are the map edges and building interiors. This remains true no matter how many times I randomize the map as shown in the video. The last example in the video was actually the worst. The buildings were so big that their weren’t many roads to use. This also caused a noticeably lag spike.

This heat map could actually help me with fine tuning the map generator. Everyone is sticking to the roads because they’re really the only path from point A to B. The buildings never connect to a neighboring building so they’re all dead ends. That’s just asking for disaster in a zombie apocalypse! Moving through buildings, across roofs and other less visible or otherwise alternate paths is a common trope in zombie media. I need to give buildings more doors, add alleyways between buildings, convert some buildings to empty plots and more to better support that. I’ll show you the results of these improvements in a later post!

The heat map could also be used for game play purposes. I could have cautious survivors avoid pathing through areas with a lot of zombie activity. I could also have zombies move towards areas with high survivor activity. Maybe animals want to avoid any activity all together! There’s a lot of potential uses.

The minimap works by drawing everything on a 1×1 pixel level instead of 12×12 ascii tiles. That allows me to see an entire level at a glance even if its pretty big. I can fit up to a 720×720 sized map on a 1280×720 screen using the minimap. That’s 518400 tiles! I can only fit a 60×60 area of the map on screen at the current 12×12 ascii font size so you can see why the minimap is handy. That’s 3600 compared to 518400 visible tiles.

If you were wondering, this is what a 720×720 minimap looks like.

It’s also stupidly fast since I’m using pygame surfarrays to just straight up blit the numpy terrain array. That means I don’t have to manually loop over every single tile and draw them. I can’t do any efficiency calculations, such as drawing only tiles that are within the camera viewport, as we’re purposely drawing the whole map. Even for the default map size, which is a moderate 200×200, that’s 40,000 tiles! I did a test to see how slow individually drawing all those would be and it knocked my frame rate down to unplayable single digit numbers.

Here is a standard minimap in its native habitat. That’s pretty hard to see, huh?

I realized that, too. I’m going to add some controls that will let the player scale the minimap by pressing the + and – keys. Later I’ll be adding a more traditional full screen style overview map that the player can zoom much closer to and also drag their view around. I’ll probably let them doodle on it, too. That way they can mark supply caches, zombies hordes or just draw dicks. Implementing this feature will make it easy to later add support for other beings having maps that the player can loot and analyze for information. Maybe you can find treasure maps, paths to hidden safehouses, directions to settlements and more. That’s all for another day, though. I need a writing break!

Foray into game development

Posted on by
Reply

I’ve decided to start talking about the various projects I’m both currently making or planning to eventually make. Today we’ll be talking about my zombie roguelike. I know, I know. The whole zombie thing is old hat these days. Everyone is sick of the undead. I need a simple project to get started with, though, and you can’t get much simpler than zombies!

I’m going to be giving my game a unique spin or two. This will help separate it from the competition and give it reason to live. The first attempt at doing so will be giving the player unfettered customization options. Everyone has their own opinion of what a zombie apocalypse entails so I’ll be giving players the proverbial keys to the city. This way they can setup a campaign to their exact preferences by having access to just about every variable that exists.

Want a day zero kind of situation? Then you can crank up the survivor numbers while limiting the zombies. The zombies will be highly infectious but relatively limited in number. Then spawn a good amount of military personnel to simulate them trying to maintain order. Turn up the event weights for military road blocks, patrols and special forces endeavors. Maybe throw in some scary men in hazmat suits performing field research. Increase survivor panic levels so they’re more prone to fighting one another or otherwise engaging in criminal activity like looting businesses. Then have utilities like water or power start going offline as infrastructure fails. Boom! Those tweaks alone should give a decent first contact vibe. The outbreak has just started and all hell is breaking loose. You can force the game to remain in this state or have it slowly transition to a different one over time by adjusting times. In media this initial chaos usually slides into a more typical zombie apocalypse setting after a few days to weeks.

Maybe you want a far off post apocalypse? Everyone has become used to zombies in such a setting. They’re more of a nuisance than a threat. Their numbers are much lower as many of them have simply decayed away into nothingness. Human numbers are low enough that new zombies are rarely made. The few that do exist, though, might be unusually tough or have mutated in some unique way. Gangs fight one another for territorial control of what little resources are left. Mother nature has made good progress reclaiming her land. The many abandoned cities dotting the world are now full of wildlife. It’s becoming hard to tell where the concrete jungle begins and the forest ends. The great highways of our time are lost beneath grass, vines and roots.

Their aren’t many vehicles left as they’ve all been scrapped for building material. The same goes for furniture and practically anything else that could be of use. If you want something then you need to trade for it or make it yourself. More natural predators such as wolves are a greater concern than zombies now. The power vacuum left by humanity teetering on the brink of extinction has allowed the animal populations to explode. The outbreak could of evolved, too, so perhaps now there’s undead animals roaming the wilds. Good luck with that undead black bear! There’s a few well known bastions of human life that provide some degree of stability. I imagine each of them belonging to a unique faction and having their own atmosphere. The adversity of survival would guarantee they’re all different.

I originally had paragraphs of faction examples here but I’ll save that for a future post. This one is already a miniature book. Nevertheless, I think its important to have a world full of grey zones rather than strict good or bad morals. I thus try to sprinkle it into everything I make. These settings would give your campaign a more Fallout, Metro or Stalker like vibe to it. The coolest part is that only a handful of settings would need to be changed in order to make it happen. Make zombies less common but more powerful or unique. Increase the number of factions. Enable the gang warfare system. Turn up the ruination level so buildings are damaged. Turn up the overgrowth factor so its bleeding into civilization and animals are more common. It’s really not that hard.

Or you could just shoot for a more average but perfectly acceptable range of settings. The good old survive for as long as you can in a ever worsening situation. Supplies are becoming ever rarer. Survivors are getting aggressive out of desperation. Zombies more numerable. That kind of thing. This will probably be the initial goal I’ll shoot for. Then once the basic foundation is laid I’ll begin adding customization options and expanding the scope of possibilities and supported play styles.

The biggest things I’ve learned over the years is starting simple. The things I’m talking about doing might sound hard to create but they’re really not. The difficulty comes from trying to do it all at once from the get go. Take baby steps and you’ll arrive at the desired end product naturally!

None of this is above my skill level. I’ve been making roguelikes as a hobbyist for at-least a decade now. I started right after quitting the waste of time that was college in order to independently learn how to code so I could work from home. Then I got wrapped up in caring for mentally ill family members so I’ve had nothing but time on my hands to learn. The last couple of years was almost literally nothing but making all sorts of roguelikes. I have several rather extensive roguelike libraries full of code built up because of this and have made probably around a hundred or so prototype stage games over the years. I’m probably under exaggerating on that number, too. I’m planning to go through a lot of those really old projects and write about them in the future. It will be a fun trip down embarrassingly bad code memory lane.

I just lacked the experience all those years ago to fully realize them. That’s the problem, though. I haven’t actually released anything. It’s one of the main reasons I’m starting this whole project. I need developer experience. I need to learn how to patch games, take bug reports, share the executable and all that hullabaloo. Hopefully you’ll help me get it!

I probably should of started doing this a long time ago but I was in that infinite loop of waiting until I was better. That moment of feeling ready never came, though. I don’t think any creator ever feels fully satisfied with their works. I kept noticeably improving in all sorts of ways but never felt like it was time to go public. That’s why I’ve decided to just go for it. It’s scary but I’m taking the leap!

Anyway, that’s enough for today. I’ve already spent too much time writing and not enough coding. I don’t want to be one of those budding developers that make promises and then never deliver. Come back later! I’ll either be talking about more personal behind the scenes game design stuff or sharing actual game progress.

Also, a teaser: