9D Final Major Project

08/05/26 That was that then. My forth and final project of the year. My final project of this course too. It's all over now.

The Wrap Up (Round 2): I think I did good. My goal to create a demo of a game that I could create later in the future has indeed come to fruition. My specialism in specifically game's design and development has had me focussing on how to make something, not making a lot of something. This was always the plan, and I'm very happy for it. The game isn't playable, but that wasn't the plan. Making a game that can run in the way it does whilst doing so much in the background is a really big achievement for me. These systems all act independently and are the cornerstone for progressing on in the future. It's also just really good practice in general. The goal was to make something that I enjoy. I don't enjoy the product very much. I didn't make a product though, I made a project for me to do later, and this entire project was really fun to do. I've always talked about how that kind of programming is my favourite part of game development, and I loved every part of this one.

My self-directed brief was to create a demo relating to something I liked, and I did it. Was the best thing I've ever done? No, but it's still pretty cool. It's a shame that the Armoured Transport elements never truly came into it, but that's the issue with making a larger game by scale. All of my theory is there though. I've got everything needed to make the project, even if I never intended to make it all come together by the end of it.

I still really like the premise of the game, so I think I will continue it further past college at some point. So, how effectively have I worked? Really well actually. I've not done as much as in some other projects, but this was a much more relaxed experience compared to them. That also being part of the brief. Keeping myself out of restricting timelines is good for an enjoyable project, so not working every hour like some of the others was really good for me.

26/04/26 It's now over, the main development of this project has now concluded, and I can finally reflect on everything I've done up until this point.

Development Conclusions: A proper product needs user feedback to truly evaluate progress. This is because a product is made for consumer use, there's no point in evaluating from a developer point of view. The issue with this project, is that it isn't a product. It's not supposed to be given for review for opinions as a product. It's a demo meant to focus on well made core systems. So, how does a developer focus on only that part of review. It can't really be ran by players, so how can I test the validity of it's performance and effectiveness. Basically, I don't. I don't test with users, since the systems themselves aren't consumer facing enough to give players issues. What I should evaluate though, is how performant this engine is. But, how does one judge what performs well, when players could be using any kind of hardware?

I've already discussed about steam being the overwhelmingly used game publishing platform for the PC market (the one I build for). If I'm getting any players at all, they would likely also play games on steam. I quite literally discussed about the steam market, and used tags and trends to figure out an audience I wanted to target. If I'm going for those people, why not focus on those people? Valve provides developers with results based on user hardware across the platform. This data is quite literally a cheat sheet for what potential customers would be using. If I can find an average for at least 80% component power across the platform, I can then compare to see if it would actually run well on consumer hardware. So let's figure out the minimum viable hardware for this engine!

I started running the game with 5 full regions, a decent amount of spawned mini structures, and an average amount of NPCs surrounding the player (remember that these instances automatically deactivate when not needed). I ended up using 8.7% of my CPU in this instance. I opened up a fresh GMS2 project and ran the game without anything inside. I got 5.4% usage on that, so my contributions end up with 3.3% CPU usage overall. Since the game isn't complete, I'll give some generosity to the amount of processing power I will end up using, and double it. (I doubt anything else I add will equate the entire NPC, structure, regioning and online systems but alas). This makes the total use from me 6.6% on top of the 5.4% from gamemaker. CPUs work on cores and threads. This means that applications can use these threads to run their code as they will. Meaning that 100% of my computer actually ends up being 16.6% per core, and 8.3% per thread. Since looking at the manufacturers website for my processor claims I have 6 cores and 12 threads.

Gamemaker runs as a single-threaded, single-core application. With the entire engine running on one core, minus certain aspects like graphics and audio being on different threads / GPU. Therefore, the game can only ever use 16.6% of my CPU at once. Considering that it currently takes 11%, that is really good. Much lower that the required. Although, that also implies that I run the game at a reasonable framerate.

The game currently runs at an unlimited framerate. I can reach up to 10000 usually, and with everything in the game, here I get about 600. That is an unreasonably high framerate. If we count the industry standard as 60fps, then I can do about 10x the content ran on top of that extra 5.6% of CPU I have left to spend. Imagine that amount of power. So, after that consideration, what could I run this on? What is the reasonable limit of lower-end hardware that I can pull from to make this run for? Intel Core i5-4570 CPU 4 cores, 4 threads. 3.2ghz speed which changes quite a lot. Basically, this CPU from 2013 has a comfortable amount of power to run not only the game, but others in the background too. Think of the 100s of google tabs players have, steam being open in the background, streaming the game to twitch and YouTube with OBS, it can easily run the game at 60 and do this stuff. That's a comfortable place to be I think. Especially for an open world game at least.

Over all of my testing, I couldn't get the game anywhere over a gigabyte of memory being used at once. No matter how hard I tried. I never expected memory to be a problem considering the small screen size and object count. The regions being just a big table really helped to keep this down rather than having many other places of excess data. 4GB of RAM should do us nicely. Right, nothing else should be an issue for the player. Let's compare to steam!

I calculated that on average, 3.07% of steam users don't meet that requirement I set out for our CPU. What that means, is that 96.93% of users do meet our comfortable requirement. That is absurdly massive given that we highballed the amount we'd even use in the first place, and gave users much more space than required. That probably won't be the case when the game is done, but my predictions are much more satisfactory than I anticipated. My realistic 80% mark got smashed to bits with this one!

16/04/26 We're approaching the end of the tech demos development, and the last big thing I want to add is a proper behavioural AI system. Something relatively in depth for this game, as the idea of multiple factions and connections between them make it hard to make.

Behavioural Intelligence: When you see that term, you may think that I'm using a fancy term for artificial intelligence. You're right, it isn't a real term. It's actually more of a branch of that topic though. To make NPC characters that behave in a particular way, I need to determine what their current situation is, and make them act accordingly. So how do I do that? It's easier said then done making these entities figure out what they should do in what order. Luckily, the industry already has a method of figuring out things like that.

The industry standard protocol is to make a flow chart. This is a document designed to visualise huge tasks easily. Like a mindmap, but actually connecting each node for the purpose of making a process, not just throwing ideas. These types of documents aren't just good for me developing the game, but also for presenting the project to outside investors or project managers. They won't typically be knee deep into the inner workings of the project, so making something small and digestible for them is a really important element of proper work in the product development industry. Not just for games, but for basically everything.

Read as you want (if you can, the image is tiny). This is my flowchart for how entities react and navigate their environment. Going from figuring out if they should be active at all for performance reasons, to figuring out their wandering patterns and instance interactions. This type of document is the foundation for going forward, so let's make a system based on this flowgraph then. This took a hell of a long time to do, and I'm quite happy with the result.

Right then, the first consideration is about performance. That is the overall goal of being a good developer right? Making the game work effectively and efficiently. My concern is about running multiple large scale behaviour systems at once every frame. It's going to screw the CPU up massively, and make the game unplayable for people with lower-end hardware. This problem is actually much easier to fix then the other performance issues that I've previously come across. The first time was related to initial terrain generation. Something that happen once at the very start of the game, and then continued to be absent for the rest of the game's lifespan. A mechanic that had to be optimised on an instance level. I had to fix how I approached generation, not how I run it. The second was about drawing the game. Something that had to be done every-frame to maintain the monitor refresh-rate, and avoid issues with the graphics card. Another mechanic that had to be delt with at a instance level. This time, I'm doing a non-core process repeatedly. Not something that is dependant on being done instantly and consistently, but something I have to continue to do later.

So, I can incorporate a currently unused system used in most industry games. The tick system. To break it down, the tick system is basically a timing system that functions as a way to batch functions together and split the workload between ticks to make each individual frame much less impactful. For this example, I use delta based timing to function with any PC at any framerate to be as consistent as possible. Let's explain it this way: Four NPCs needs to run code. So, rather than doing them all at once, I run four ticks per second that each run the NPC code at different times: Per Second: TICK 1 - NPC 1 - 0.25x Process TICK 2 - NPC 2 - 0.25x Process TICK 3 - NPC 3 - 0.25x Process TICK 4 - NPC 4 - 0.25x Process Each tick per second does 0.25x of the process, rather than doing 1x the process all at once at the start of the second. The big performance hitters of the code don't need to happen every frame. Therefore, we can just tell them to run at different times frequently, it puts way less strain on the CPU. On the topics earlier of good presentation to bosses, owners and investors, I've designed a few graphics to help visualise this problem.

This graph shows how much processing (Y Value) is done per frame (X Value). The red on the chart being the percent being done that frame. When all code is being ran every frame, you are maxing out the amount of work the CPU has to do in the game. This is bad. The above graph shows that the entire process is being done at all times, meaning that the entire graph is red. This does need to happen in some instances of programming, but not here.

This is what happens when you start putting it off onto certain frames. Here, the system now runs at 0% processing for 3/4 frames per second. This is really good for those frames. This means that the computer isn't doing nearly as much as it was before to achieve a similar goal. Not all functions have to be done every frame. The problem with this graph however, is that it still offloads 100% of it's processing onto one of those frames. This is how frame stutters work. The frames that do the work will run worse than those that do nothing. This means that 1/4 frames will *always* be slower than the others, and 100% of the processing is not exactly what is important here.

This here looks perfect. Every frame takes up 25% of the workload rather than 100% on just the one. This is offloading the tasks to the places that aren't being utilised. If I have the four NPCs running one per frame, then that splits the workload and allows the CPU to only do 25% of work at a time rather than 100% all of the time. The only downside being that the NPCs don't update at a per-frame level. Something that isn't needed anyway, and is a good optimisation for game tech. You can never get a game to do 0% of it's work (unless nothing happens), but you can absolutely minimise the amount of work needed done to help lower end CPUs do the same stuff. The NPC systems now only use 25% of what they would have, and all for a simple tick based chunking system. The other optimisation I can do here is culling which NPCs are even in the player's region. I've already talked about culling though, so I won't go further on that.

Heck, even if the NPC systems are really efficient in of themselves, this extra boost is always welcome to maximise what I can do as a developer to make the best and most accessible product that I can. (Even when I'm not making a commercially viable project this time around). It's good practice.

So, I talked about factions and that logic would be determined based on NPC classes before, so I created a script that defined the basics of those parameters here. The idea is that I can easily come back and set more if necessary. An easy lookup table.

Thinking about it logically, the NPCs in this game should look and feel like entities similar to the player. In that case, rather than duplicating that player code and maintaining that for the rest of the project, I can simply just make a child of the player, and add all of my NPC code into the parent. The player entity already sections off the player code anyway thanks to my multiplayer integration. So I don't really need to worry much about this going forward.

NPC movement actually shouldn't be collision based, because they shouldn't be pathing into solid spaces anyway. So, how can approach movement of the NPCs? Well, I already have an MP grid from each region's create code that updates based on the grids I made, and the dynamic wall objects. I can easily borrow this here to make use of those mechanics, rather than creating new data structures for the NPCs themselves. This is basically reusing existing codebase, and it's way more performant than making it again.

I created all of the reaction code based on that data set I provided earlier. This runs not only against the player, but against other active NPCs too, meaning that they also react with each other. There are 3 types of faction relationships: ALLIANCE | NEUTRAL | HOSTILE. Alliances will never react to NPC actions from other Allied factions, and when another ally requires help, they will react towards that original aggressor. Making them react when others react. Neutrality means that nothing happens between factions unless provoked. This sets off a temporary Alliance/Hostility between them depending on the action done towards them. Hostiles will react immediately upon contact with the opposing faction. Causing a call to arms with others of the same faction and their allies. It's basically a massive friend enemy system packaged here.

I made a behaviour override machine that acts as the calculator of these relationships in real time. Allowing for these characters to actually adapt to the circumstances happening around them. This also allows me to do some cool stuff when it comes to attacks on the player's armoured vehicle thanks to assaults and retreats. I can manually add these through my console and through scripts when I come to that.

The reactions of these NPCs are ATTACK | FEAR | STOIC. Attacks are self explanatory. The character will approach the target at a respectable range before using the pre-existing player weapons (That I can set with factions and code), and use them appropriately. Fear NPCs will run away from hostile entities. Basically escaping any situation. This is good for third party entities like civilians, because they can run away from a faction when fighting starts. Acting like real civilians and adding more weight to scenarios. In the cases where neither apply, the Stoic reaction basically allows the NPC to act like normal, ignoring anything going on around them. Great for NPCs that won't engage in nor remove themselves from a situation.

Wandering basically sets them a region to randomly move around in. It means that they can move too far away from spawn unless doing something important, but gives them freedom to wander like NPCs. This is just pathing to a random spot however. Once reached, they wait a little while, and then wander again. Escaping finds the nearest threat and asks if they are too close for comfort. In that case, they find an available spot to path to in the opposite direction of the target. Then they book it over there as quickly as possible until the threat no longer concerns them for a while. Attacking sets a preferred distance to a specific target based on their weaponry (Long, Medium, Short, Melee), this allows them to spread out a bit more based on their proficient weapon. Along with this, they will occasionally weave away from this area and reposition themselves somewhere else. To give some extra depth to fights. Enemies will start taking cover on objects once damaged enough. Some will completely ignore this though and either push harder, or start retreating. The cover system is pretty fun, I basically just find an area near to them that doesn't have a line of sight the player. The other mechanics are just the escaping stuff and shortening their range. I think this adds way more depth into NPCs, and I wish to add much more like this in the future to change how encounters work on a case-by-case basis.

Here's some little friends for the player to work around.

Here they are engaging in some friendly warfare.

08/04/26 In the quest to make a procedurally generated map filled with points of interest, I need points of interest. Simply just having generated terrain is pointless when there is nothing to travel to.

Generated Structures: Structures in this game would act more like pre-determined level sections placed randomly in the map. They would include exclusive objectives and equipment for the player if they choose to go to them. It would also fill the map up a lot more with things to do, along with the main quest. Generating these structures would happen at the map load, but would be built independently from everything else. These structures would be completely isolate from the built map past fitting into the environment correctly, and making sense for the current area. These kinds of structures would include things like: Transport Depot (Where the players start) Delivery Depot (Where the players end) Service Stations (Vehicle Repair & Resource Refilling) Roadblocks (Path Deviation) & More (Other Events & Purposes)

I've talked about Minecraft before when mentioning terrain generation, and I'll talk about it here again for structural generation. In this game, these places are themed builds randomly placed around their designated biomes. This gives them a more recognizable feel, as you can always identify where to find these places. They have their own challenges and purposes. Some having exclusive mobs or items, some containing rare loot for those who wish to engage, some are just decorative. In Minecraft, these are made outside of regular terrain generation, because these aren't part of the terrain. Builds like these in context would have been built regardless of location, significantly after the world was made. So, why have them relate to world generation at all past world context.

They are saved as their own Java files, and then loaded into the world as objects. This helps when making them, since building them directly into the code is significantly harder, and more time absorbent. Maybe in a smaller project I would have time to do this, but at the end of the day, it's a losing battle.

I have built a system like this before. In an old game of mine, I made a small level loading system for RNG based changes to the maps of the game. This isn't quite the same scale, but the concept would work just as well here, as in that game. So, am I going to build a similar system to this? No. This system was pretty crap overall. It's been three years since I made it, so I know that I can make something way better than that now. Despite that, it would take a LOT of time to make well. This isn't just set environmental changes, but entire structures and maps. That would quite a while to build myself. So, I think it's time to employ that discussion we had earlier in this documentation.

YellowAfterLife is a user online known mostly for their contributions to GMS extensions. Mostly from tools like GMLive that allows Gamemaker code to be edited during it's compilation so that you don't have to restart the game after every edit, and GMEdit which is a high-end code editor for GML since GMS2s one is pretty incapable. They've produced a bunch of really useful extensions over the years. After my 5D project ended, I included their INI File extension for better control of file saving. Not entirely necessary as GMs INI tools are fine enough, but a helpful script none the less. I also ended up including their Gameframe tool which allows for custom window frames that helped with a few engine bugs with moving the existing window around causing the whole game to freeze. (Which isn't good in a competitive online game). My point is that I've used certain assets from them before. Assets in this context are really just aids to development of the game, not really parts of the game themselves. In this context, it really does just become about helping the development along. So, I've decided to use another of their tools.

GMRoomPack is a room exporting tool for Gamemaker. In short, it allows rooms (levels / worlds) in the gamemaker engine to be exported to a JSON file, and then be loaded into other rooms whenever needed. Basically exactly what I was trying to make in my other project, but much more refined and functional. It's intention IS to be used to export levels between clients, and also to be used to load separated structures into levels. A really handy tool that only costs $4.95 (£3.65) exc. tax. A bargain if you ask me.

I got it. Just as decided.

Importing it into the project was a simple task. GMS2 support direct extensions and prefabs, so I don't need to mess around with the extension nor engine to get it to work. Just opening the file with the engine allows me to install it directly. I took a read of the documentation to see what I was really working with. Overall, it is quite simple to use.

The files contain an executable that runs in the windows command prompt. This program is a tool used to find GMS2 rooms and package them into scripts and JSONs, that I can then import into the game during runtime. It's important that I set these up properly to not cause issues when loading them later. Trying it out for myself was really easy actually. I was quickly able to open and run the command line to package a room. I ended up choosing to load it into a JSON rather than a script because it makes it more portable for testing, and allows me to manage the room packs better than if using built in scripts.

02/04/26 I made a minimap in my last final major project, and since it makes way more sense in a game with randomly generated terrain that makes learning the map impossible for repeat attempts, I think this is a worthwhile endeavour.

Map: Getting around the current terrain is kind of a pain in-game. This is due to a lack of navigation, and unlike a pre-made map, I can't just leave this be. People need to know where they are going, so I think I need to make a minimap.

I did make one for the last FMP, and I don't plan on changing much of the general idea. The player should be able to open a menu showing where they can or cannot go, and get markers on where important things are to help them along with actually getting them done. In a big map like this, they will be very important.

Here's what I had last time. Hold RMB to show a grid tile map around the player, with coloured markers to show what everything is. This worked in this game. It would only show what's around the player since the player would never have to look around much further than where they currently are. It would give markers to show what in the game is interactable or not. It also had a transparent background so that the player could always see what was happening in the game whilst viewing the map. Development wise, this map sucked for performance. It almost doubled the drawing work of the game and left it difficult to run for poor performance hardware. Luckily, the game itself was quite small, making it less of an issue overall.

This cannot be possible in this new project. You can see from the screenshot above that rendering the whole map at once took the game down to 3fps on decent hardware. That doesn't include other structures later on either, so I need to build for the future.

I created a mapping object, this instance will run all of the code for calculating and drawing the map when needed. What I've done here is set up my possession code to make it possessable by the players. It can be interacted with the bring up the map like being in any other instance or widget. A good use of my existing systems built around expandability. To make it work, I needed a way to grab up to date region info. So, I literally grabbed the region mapping surfaces that I used for surfaces, and draw them relative to the player character.

This solves most of my performance issues of needing to redraw frames when needed, since I can reuse old parts from other systems to draw these out. This basically avoids taking resources altogether, cutting out any calculations past just figuring out where to draw it on screen. For player convenience, I added the abilities to move around the map by clicking and dragging the map. With that, I also added a scroll wheel function to zoom in and out of the map when wanted. This is for easy navigation of the mapping, and focusing on the parts that you need.

I added a marker system as well to draw placements on the map that show tags when hovered over. These will be symbols unique to the game world instance, meaning that the player can easily recognize important elements on the map and discard whatever is useless information to them. If they don't recognize these symbols yet, the hover text will tell them everything they need to know. This is good for player readability. It allows players to get a scope of what is where and how to navigate to it. This is especially important in a game about navigating to the goal. Adding more user-friendly functions like zoom and dragging makes the system much more useful and enjoyable to interact with. This isn't a gameplay mechanic, more of an quality-of-life/accessibility mechanic. Something important for keeping players engaged when playing.

30/03/26 Last day of march, it's time to touch on a topic that will NOT be expanded on very much. The game's original soundtrack.

Soundtrack: My objective here is to create an overall vibe that fits with the genres of the game itself. An original soundtrack will really help bring that to life. My goal is to create a starting point for the game's soundtrack later. Past this, I don't plan to touch sound much more. To find the correct sound, I need to look at the surrounding examples for my genre. Let's go back to Heat.

Heat's soundtrack in this scene is extremely minimalist. Nothing notable to come away with. https://www.youtube.com/watch?v=qaswBIpWtyU&list=PLE66750CCA74A73E0 (4:34) - (END)

This scene's soundtrack is very aggressive. The entire thing is backed by a plucked bass on the exact same note throughout. The entire song is very repetitive overall, being that there aren't any major changes in pace or instruments. Repeated riffs from amped guitars and synths get plastered over. Some drums too. I think the point of that is show pressure. The scene itself is about ramming into an armoured truck, blasting off it's backdoor to get inside and in the end killing the three guards with gunpowder. All very loud and intensive sounds that pressure the ears. It also reflects on the pressure of actually being in this confrontation. A pressure in both the events that happen, and in what will happen if something goes wrong. They even comment on this in the movie:

The explosives used to open the truck deafening the driver and guards to the point where they are barely even lucid to the situation around them. Pressure on the ears and strain on their hearts. Overall, a sense of pressure.

Every single instrument used in this scene feels like they went through an electric amp to sound more crushed, giving a lot more of a gritty feel. The actual composition being a continuous rhythm also made the song feel like continuous pressure with random intervals of drums and changes to throw off the music from feeling too samey to the point where it feels it goes into an expected direction. So, what did I make? https://www.youtube.com/watch?v=rn5APaFyFxY

Basically what I described. A 3:32 demo of what this would sound like. Faster-paced rhythm with a harsh bass, harsh synths and raw drums.

Set in C-Minor at 124BPM, the song is quite simple overall. That is exactly what the original reference was though. I fiddled around with bass for a really long time because I couldn't figure out how they got that "gritty" feel to them. I eventually decided to try adding a electric guitar amp like I mentioned earlier, and it worked really well. It sounds really chopped and electric now. The other thing I added was some chorus and wah to give the bass that more synthy feel. That electronic edge that makes repeated bass sound much more pleasurable to the ears. Without it, the bass just sounds like crap.

29/04/26 I want to quickly go over hand weapons and inventory here so we can move on to bigger things, but also go over my thoughts about documentation.

Handguns & Re-treading Topics: Very uninteresting stuff here, so it won't be my most detailed post, but I need to get across another point following this. Video game tools were typically mechanics that players would use to overcome certain obstacles. Think Portal. A game about using a device that connects two Euclidean spaces together in a non-Euclidean way.

You overcome puzzles using this tool and a few others to progress your way through the game. These tools encourage the player to use their brain to figure them out, that being the fun part of the puzzles. This equipment always works the way that is described to the player, they never faulter or have unexpected outcomes when using them, because they reflect player intention. Not that nothing can go wrong when being used, but that the player always knows the possibilities of what can happen when using them. Think back to The Escapists. Another game I mentioned on my favourite games list.

The prison guard's outfit is a tool players can equip to fool other guards into believing that they themselves are a guard too. This allows the players to go into areas that they would be penalised for going into before, now undetectable. However, the HEAT mechanic in the game (a value that determines how suspicious the player currently is) will slowly increase when interacting too closely with other guards, as eventually with high enough HEAT, the guards will notice that the player isn't actually one of them, and immediately send enemies their way. This player tool has an entire mechanic that hurts the player. This isn't an issue with the game however, this is game balance. The player always knows that when equipping this guard outfit, they will gain HEAT, that will harm them in the end. This is a trade-off for having using that item.

Items like these are designed to change the way people play the game. The players can now easily walk into areas without resistance, but overall prison suspicion becomes higher. A trade-off that the player specifically makes. This is fun because it gives the player choices. Despite that, player equipment shouldn't just randomly do other things unless the player knows that they can happen. Otherwise, it can create a disconnect between what the player thinks they can do, and what actually happens. This is a frustrating experience. When designing player tools later in game design, the thought of multiple options of approach to gameplay comes to mind. Having different tools to accomplish the same goal is a really cool way to have players interact more with a game, then just the original way the game intended them to play. It becomes more replayable, and in-turn more fun.

Tangent aside, where do my firearms come into this? I've created a stuct system that creates values to be read by the game and applied as functions for basic weaponry. With every intricate value change, I can make weapons feel distinct amongst themselves, and give the players more choices into how they approach missions. A lot of these stats and values are very common in FPS games, I don't think I need to go over them much unless you plan on playing the game for yourself. The weapons systems and inventory system I made for it don't really need much attention either, because they end up being very simple with my modular control and timer systems that I've made in this and other projects.

I also don't think I need to go too much into why I'm adding firearms, weapons, equipment and more into this game. I've talked about how the heist genre uses different tools and approaches to make each objective more unique and customizable. These are tropes of the genre, and I've gone heavier into those in my pre-production phase. What I'm saying here is, that I'm actually starting to add the things that I mentioned in my pre-production specifically. The methodology that other games have used to recreate this genre is something I'm also including for the same reasons. I felt like my 5D project's biggest problem from a documentation standpoint was that I almost completely ignored the research made for the game. So, taking some things from earlier literally and implementing them here should actually reach that grasp much faster. Otherwise, my other discussion is about time here. These projects aren't marked together sadly, despite how much I would like to link back to older posts that I've made about these exact topics.

These two screenshots are from the two projects I've made in this engine. (5DFMP & 9DFMP) Both initialisation scripts in an instance named "OG". My controlling game instance. Try guess which one is which, there is a hint in the code itself for you. My point is that both are really similar. This is obviously expected. Compare two Vincent Van Gogh paintings, and you'll see that they use similar art styles. Of course what I'm making will look similar to other things I've made. I use similar initialisation in my 4D and 7D projects as well. My point is that a lot of things are the same throughout, but when doing the 5D project, a lot of things I made were completely undocumented up until that point. It was a chance to showcase what I could do. Now though, it's already been done. Can I really make another post about arrays and their performance? Or about how I can manipulate animation curves and other graphing to make a game? How many more posts like that can I make. I look back at that project and see all of the tiny little details I made on that game, but here, I'm focusing on only the big things. I think two things changed between projects: 1 - These posts are way more detailed. On average, I wrote 10 Paragraphs per post on the 5D project. On this one, I do about 20. The most I've done is 39 on my "Idea 2" post. The amount of detail I want to add to each entry has heavily increased on each post. Even this one here felt like it needed a tag along about posts themselves to push the word count a little. 2 - The game I am making here isn't in the details phase. Maybe a larger scale game wasn't the best idea for this project. It hasn't helped this far, making the project look worse in comparison at this stage because of how little I've comparatively done, despite the total word count and lines of code total being similar/higher.

26/02/26 It's that time again. The sixth week in our thirteen week plan.

Quarterly Evaluation (Pt.2): We are now on 28,851 words now, when we were at 17,008 words in the last quarterly evaluation. About 11,000 words this time. I was expecting way less from this, mainly because I know that keeping up with this blog isn't my biggest attention grabber right now. All previous projects have heavily focused on being mostly about my documentation of pre-production, because the blogs are the pre-production. Moving on to this quarter, I've only been doing the bare minimum boring concepts like terrain generation and player control. These systems are a lot more work than things I've made before considering my game's scope, and the pathway that I've chosen to get there. I want to talk about that way more in another post, so I'll leave that thought there.

My compiler suggests that I have written just under 7,000 lines of code in the last 3 weeks. My 5D Project was at 23,000 by the end, but as I quote: "I do not think this is accurate however, since a lot of lines will just be closed brackets I left on their own, or comments. I doubt this would actually leave to total line count lower than 20,000, but I will just round it to 16,000 because it only covers what I know that I have written.". Remember, each item, stock option, crafting recipe, and more was hard-coded data that took at least 10 lines each. This doesn't sound like a lot, but makes a much more bloated project in the end. Mind you, those should have been condensed better with scripts anyway. Lazy me I guess. A lot of code in that project was repeated and sloppy to be made quickly, as that was the goal. To make something complete in time allotted. This project is not about making something complete but dysfunctional, but making as much as I can correctly. Most of my code is in external places like scripts to be reused, and extensions to be created. This is much more efficient and scalable than the other way.

24/03/26 One thing that was on my targets for this project was to improve something from my last projects, and I think the player character is a perfect vessel to complete this in.

Character & Personal Connections: The core reason I want to focus on the player character right now is attachment. Right now, I'm feeling a drought of personal involvement in this project, one that has prevented me feeling that sense of determination to complete this project. The timeline for the 7D Studio Project was a rough one. A lot of things I did were towards the end of the allotted time. The end of the project just seemed more enjoyable to make than the start. The biggest contribution in my opinion, was the enemy characters.

I'll go over my thoughts on this project in the upcoming Quarterly Evaluation, but I'll give a rundown. The characters in my games are usually not the most interesting in design or concept, but those, along with the environments, the text elements, and other personal touches that I can make are way more involving than developing a floppy disk inventory system, or a server binary, or a world generation system. Not that these aren't fun or interesting, they are. But, if it has no connection to my personal input in the project, they can get really boring. Along with that, adding these kinds of things can give me more of a stable direction of where I want to take these later. This isn't a post about making a character because I need a character for the game right now. This is a post about making a character because I need an personal input to the 1000's of lines of code and research I've done thus far.

Making my character for my 5D project was done about 10 days earlier in this project then the last one. It was a necessary attachment of my personal input to the large mechanics that were already made at this stage, and I think mixing that with everything else I was making, was a really good balance of important game mechanics and enjoyable developing. It was a requirement to keep interest in the project. Coming from me after completing this task, I feel so much better about this game than before today. STOCKWAVE ONLINE's characters were pretty crap. The section was literally titled: "Cheap Visuals And Animation". And they were cheap. The characters were based on Hotline Miami's character design, being completely top down. Since I'm not an artist, I had to make some way to make similar characters without all of the complicated geometry and colours.

My characters ended up being a single sprite layered over a flipped arm and leg sprite. This made a really believable animation for running. Using shading to make depth in the sprite, and using the positioning and layering really well.

This was barely ever changed later on. If you look up the game and see it's trailers (I can't add them here for some reason), they look almost entirely the same no matter what you do with them. It works well enough though, since the focus isn't on the characters, but your positioning and fighting. No one is looking too hard on the characters themselves. I do want to improve on this today. Not make a repeat of that game's characters, but make a new one with way better animation and visual identity. I think I have it.

This is a mockup of a character I made in Paint.net, and I kind of like it. Instead of a Hotline Miami inspiration, I took a little from other top down games like the lesser known "Monico: What's Yours Is Mine", and the very hidden gem "Apocalypse Express".

The character looks a lot like the base of Monaco, with the visual style of Apocalypse. I really like the visual style of the latter, because it screams a more cartoony look that I've always liked for these parody games, but in a really simplified way. The eyes looking slightly up is a really cool way to add character to a face, in a perspective that doesn't allow faces to be seen. (Although I've talked about facelessness enough already). What Monaco brings to the table, is it's use of modular character building. Each character piece, the head, body, arms, legs and more, is connected at joints rather like a skeleton mesh you would see in 3D. This kind of thing would be calculated in real time in game programming, rather than an animation software like usual sprites. That sounds like something I can do.

Since each element is a single sprite, It means that I have less work to do when actually making the sprites. Less artistic work is much preferred if I can make it in code. Like that main menu in STOCKWAVE ONLINE made entirely of primitive shapes drawn like HTML. So, how do I make a modular character system using these pieces?

I gave the character instances a bunch of variables, those being sprites for pieces, offset vectors, rotations, and a few more that aren't too necessary to talk about. When it came to my 5D project, my characters were pretty simple to make, so I could draw them to screen in a few draw functions. My big issue though, was having to put in places that weren't my character. As any update to that code, meant I had to update it everywhere. Put it in a script you say? Well yeah that works, but what about when I need pieces and vectors from other places? It sucks working with scripts like that. Excess code being ran in the draw function to compensate for lazy writing. Let's go another way.

I made a script that creates a JSON filled with character information. One that easily takes all arguments needed, and allows sharing of character draw info between instances, and customizability that doesn't require tons of exceptions and fixes to make work. I can just grab the character JSON from here, and use it in a drawing script wherever I want. I can even save it to file rather than drawing it out manually. This means that I can more easily transport data to other players on the network, and load the file in the game later when needed. A backend performance boost, on top of a backend usability upgrade.

Here's the drawing script if you want a peek. A bunch of vectors and sprite manipulation here that I don't think warrants much more of an explanation after talking about drawing earlier in the project.

Here's the little guy I made in the end anyway. I changed some proportions and stuff from the original I made to fit the vibe I want more, so here he is improved. But how do I improve the animations?

Here's an example. Because of the modular character builder and vectoring system, I can literally make animations in game code using it. In this example, I made the player head follow where the cursor is. Only the head though. The whole character in STOCKWAVE ONLINE followed the cursor with no animation to back it up. Just rotation. In this system, the body actually only moves when far enough away from the head rotation difference. Like in Minecraft where the players can have their body up to 45deg away from their head rotation.

If you are closely paying attention to the code however, it doesn't work. What's the error? "if angdif > 45 or angdif < 45 {" should ask if the body is either more or less than 45 degrees than the player's head. However, the angle difference should be > 45 and < -45. Positive 45 would just make the whole thing fix itself the entire time. What ends up happening though, is the whole body slowly fixes itself all of the time rather than under that 45deg requirement. I ended up liking this more though, so I call it a feature, not a bug, and move on.

The next thing I wanted was a movement animation. Walking with arms and legs. But not like 5D where I used poorly animated sprites to do it. Actual walking with code.

I'm not going to decipher this entire wall of text here, but the run down is that I make a lerping value when moving on an animation curve, and use more trigonometry to figure out where each limb should go whilst walking.

You can probably cite me somewhere saying that Animation Curves and general Graphing is my favourite feature of modern development. They are cool. Really cool. Using curves and graphing to evaluate positions in a non-linear way. Meaning that you always get an accurate result no matter the input variable. The thing with lerping, is that it makes the legs and arms actually move like they would in 2D space, rather than animating it that way. Higher framerates will see those in-betweens accurately, rather than animating it like a film. So legs and arms actually move like they would in real life. This is why I made a vectoring system. It allows me to make custom positions and manipulations that I couldn't make elsewhere, a truly remarkable way to add movement to drawing in a simple way. It allows me to lerp between these animation curves too, meaning that locomotion between animations exist as well. An arm will move back to it's resting point from anywhere in this animation, rather than snap back like a premade one. Working how it should with code, not like it's animated in a game. This also allows me to override animations, and make some cool locomotion systems with stuff like emotes and interactions that actually use the arms and legs of the character previously drawn. Another big benefit of vectors and overriding them, preferably over the sprites system. I also made blinking too to give the character more life in the world. I don't think the code is that interesting though, so I'll just show you the result.

22/03/26

One of the biggest selling points for a game is the establishment of the world that the player resides in. Whilst I'm quite a while away from building that out, it's important to look into what direction I'm heading when it comes to this game.

Worldbuilding: My last two major project successes were both "almost there" with their worldbuilding. As I mentioned, worldbuilding in games is a very important establishing point as to what the world the player uses is like, and how they fit into it. When most people think of worldbuilding however, they think of bibles filled with lore and story about their IP of choice. In this context though, that isn't what I'm referring to. Creating a narrative or a fantasy will always be the best way to hook someone in to your media. Either linking your game heavily with a story you want to tell, or give the player the ability to act as a character in an established world, is basically industry standard at this point. As I've mentioned before, I couldn't care much less about narrative games as a whole. I prefer fantasy games since they focus much more on gameplay than on story. For example:

PAYDAY 2 is a game about the fantasy of being a bank robber. You're put into a modern Washington DC as this bank robber power fantasy. There really isn't much story to speak of. The game focuses on you acting as if you were your own character in this world, not so much as a game that tries to show you a narrative about these characters. This opens up gameplay. This let's players focus on allowing what they want to do, but still gives them that fantasy world that connects them to what they are doing.

Counter-Strike is very much like this too. The game barely has a story, but still has this idea of modern terrorist vs counter-terrorist fighting over locations to defeat each other. This is the world of counter-strike, where these confrontations happen frequently. It's a fantasy that allows players to play as either side trying to complete their goals. My point is that these games have a very obvious world that the player is taken into, and this world is the explanation and challenge that the players comes across when playing. A good world makes it clear what role the player takes.

My 5D project had this as well. A world about stock-traders trying to earn as much money as possible by killing each other. The world itself wasn't explained that well in my opinion, despite it being there and making a decent amount of sense. What drove people to this gameplay however, was the natural want of money. Worldbuilding can come from a natural urge to do something. Same reason you try to attack every friendly NPC in games to see if they'd react. Just a habit of testing the game limits and seeing what you can do in this world.

My 7D project wasn't very good at this in my opinion. The world had been thought out enough, but it really wasn't explained to the player at all. This was a massive defining factor between the 5D project gaining positive reviews, and this one gaining nothing but confusion. The world wasn't explained enough. No one knew what anything was about. Nothing had purpose, and therefore, the player had no purpose. Surely though, I should remedy that in this one?

This projects goal has already been set by me earlier. Player takes an armoured vehicle of valuables through a set of cave-like systems whilst trying not to get ambushed by a bunch of robbers. Well, who is the player? What are they transporting? Why are they transporting it? What cave-like systems are they taking it through? Who are these threats trying to ambush them? Well, that's what worldbuilding does. It answers the contextual questions that the player will have when questioning what they should do, and why they should do it. If I can answer these questions easily and obviously, then player motive and interest will be established. That is the first step to getting the player involved into a game, and the also the first step to getting the player into actually playing and enjoying the game itself. So who is the player? In STOCKWAVE ONLINE, the players were faceless and nameless stock traders working under a company only referenced as a passing name. This worked really well for that game because the actual identity of the characters are unimportant. In the grand scheme of things, the player isn't automatically important. It takes the player winning at the market to get their name at the top of the game leaderboard. Their actions in the game make them important, not their relevance to the player themselves. For this game, I actually think this faceless & nameless ideology works, but for a different reason. Let's look at the end credits of the previously referenced movie Heat (1995).

These are the actors who played the armoured car drivers in the very armoured truck heist I took so much inspiration from. Where are their names? In this movie they are only listed as titles and numbers, described as their relevance to the story rather than as people. This is because the movie doesn't need to give them names, they aren't important to us when the movie follows the heist crew. They are the main focus of this heist, not the personnel themselves.

Remember this real armoured truck hit in Italy I also mentioned? Who was involved in this? As far as I can see, no names of any personnel on duty in that scenario was ever named online. Backed up with a search with ChatGPT just in case I missed something. This makes sense though. I wouldn't assume that the people involved would want any attention to be brought to themselves from this, but shows again how little the victims of these incidents are focused on from this perspective. It's actually quite unfortunate how little people give interest to victims of these crimes. People focus of the criminals who try to pull these off, the more focused and interesting element of these stories. It's the reason we keep following the crew of Heat rather than Gage (the armoured car company in the movie) and their employees as they recover from this incident.

You may even recognise that name in passing, as I gave a slightly random tangent on it earlier. If you don't remember, Gage was also the name of the Arms Dealer you get weapons from in the PAYDAY games, using that as a link to the original Heat links of the first game. This company literally has no relevance to the movie at all, but still comes up in conversation more than the characters pivotal to the scene and continuation of the story.

This is actually a link to advertisers. To simply plaster a name somewhere tiny and irrelevant to build recognition when it comes to recounting it in future. A type of brand recognition where the more you hear about something, the more of a connection you get to it. That has nothing to do this topic though, but a real world use of this labelling thing.

Another link back to 5D FMP as well. A company shown occasionally as a name, but one with no real significance. The characters themselves being the most important aspect of gameplay, but have themselves no face or name. So how do I want to incorporate that into this game? Should I make another uniformed blank slate character only referred to as a collective? Yes.

Here's my idea. In almost all media I have mentioned so far, the main characters named all wear masks to hide their identities. For the purpose of heists, this is to make the wearer unrecognisable from anyone else so that no one can figure out who's committing this crime. In Heat, they wear matching white hockey masks. Literally encapsuling the black faceless persona they take when doing these heists.

PAYDAY 2 also has 440 masks, and a whole mask customizer to edit each one of these masks with 140 materials, 234 patterns and 42 colours to finely tune a mask to your liking. A huge system that otherwise serves no purpose beyond cosmetics.

Even in other media I mentioned right at the beginning, HITMAN's excuse for anonymity is that Agent 47's face was designed without any real defining features. A literal blank canvas face that no one could really remember a description for outside of just "plain". So, what if every player, character, NPC and entity wore a mask? The player's rocking a recreation of the Hockey mask from Heat.

20/03/26 Drawing out the environment in the way I am is very taxing on CPU, let's expand on that.

Drawing Performance: I feel like my post quantity is slowing down recently, and I think it is. Although, I am doing much larger posts, in a more long winded project overall. So I'm not that worried overall. Anyway that isn't what I'm talking about today, today's exploration is into drawing out the worlds that I made last time. The reason I'm heavily focusing on this, is because whilst generating the worlds in a one in done deal, drawing them is important on every frame.

So far, I have a debug drawing system for each of these regions. One that demonstrates where walls and regions are in the room, all drawn at once. For the final project however, I'm going to need to do something a lot more polished to submit as a game. Drawing out an actual environment however, is tough work for a CPU. The difference with this game in debug and release, is that I need good performance as well as function. And to make the area look good, I'm going to need a lot more than a simple grid drawing algorithm. So, let's develop one! Test One:

This test here is to focus on basic drawing mechanics, and more importantly, culling.

Culling is a very strong word relating to segregating a part of a population through slaughter. Obviously in computer graphics, it means something slightly different. Culling selectively removes tasks from the draw stack to reduce on processing power to render them. Basically, you take textures and faces that aren't viewable by the current camera anyway, and don't render them. The image above explains the three culling types. View-Frustrum - Removing elements that are outside of a camera's view. Back-Face - Removing the sides of elements facing away from the camera's view. Occlusion Culling - Removing elements that are behind already drawn elements, or reducing really far away ones down to simpler to draw instances. Since my game uses an orthographic camera, I can't reduce far away instances since they all look the same at any distance away. The fact that this game also uses 2D sprites, means that there are no back-faces to cull. Culling elements behind others though, and removing instances outside of camera view, are both very important to a large world like this being rendered.

Back to this image here, I've successfully culled instances off camera. The box here being the size of the player's actual camera, and the viewport here being my debug camera. I only draw everything in the camera box, and a little outside it for safety.

Basically, I check the player position in grid terms to figure out where I need to start drawing from. So I grab the current drawn positions and size and figure out if they are different from the last ones. This is for a temporary system where I re-render the whole screen based on what changes. For this reason, I create a surface and buffer to hold the current screen position. In short, a surface is a temporary texture that can be drawn to like the screen. The screen itself is actually a surface, but the only permanent one. With these surfaces, I can draw the level part I need to them, and then manipulate them however I want. The reason that I also create a buffer to store the same information, is that surfaces are kind of stored in a weird way. Drawn data ready to be used by the GPU, but also data that needs to be stored in the RAM. This creates an instability where occasionally, the GPU will just delete the current surface saved.

This is normal. Think about the little black screen that you get when entering and exiting a fullscreen application. It's just the CPU and GPU clearing the currently drawn screen to conserve on unused resources. This is why I keep a backup buffer just in case. The RAM never clears data from an application, unless the application is closed or the computer shuts itself down. The buffer is a backup of the surface that I am using for ease of access. Not that this is the biggest issue in the world, but it is an issue to be solved none the less.

I check if the buffer is cleared, (which happens when a new one needs drawing on command), and proceed start drawing the world the screen inhabits. I use the same scripts as the collision system to get grid positions and data to figure out what to draw. For this demonstration, I am using a quick tileset that I made as the flooring, and made all of the walls black.

I also made a rim to go around these walls to blur the tile system a little bit. This just improves readability, and isn't designed to look like this. Dev textures.

I then just draw the surface where needed. A quick first draft of rendering the world. This script was made to be very modular, being able to be expanded in any way I needed, but one issue still remains. The grid is static. Re-rendering the whole screen every frame is an absolute waste of resources. CPU is important to keep as free as possible for other processes in the game. Therefore, the best plan is to avoid using resources to recalculate surfaces every once in a while.

For this, I ended up making another grid of buffer stored away to be converted to surfaces later. I originally thought that this would increase performance, but after doing some testing, the conversion between surface and buffer ended up being more that re-drawing out the screen anyway. So I quickly removed it and tried something else. I then also tried replacing my collision system's code with a more specialised one for this instance. Focusing on a single check rather than multiple collision checks. This somehow ended up being even slower than the other one. I actually have no idea how that happened.

My last attempt to optimise this was to shift the currently drawn screen to the side when re-rendering, and then only rendering the section of screen that wasn't currently drawn. I couldn't get this to work properly though. I struggled to get the correct parts of the level to re-draw, and ended up having the surface clear accidently, making the whole system obsolete. I would call this a setback, but honestly not a big one. I'm still doing well on frames for the time being, and if I can't figure out a way of doing this well by the time I need to optimise, I have another trick up my sleeve. Edit: I found the biggest hitters for the drawing system.

18/03/26 If you couldn't tell by the jump in post time periods, this one is big. Maybe even the biggest. It needs lots of care and attention. So much that I can't even do it all in one go.

World Generation: I already established procedural generation in a cave like system that I wanted to mess around with, and see if it would come up with a cool map for the players to travel around. A map of slightly tight corridors and big open caverns. This is why I made the region system. To connect these areas seamlessly into one massive cave system. My question is now though, how do I make caves. Personally, I haven't really touched procedural level generation like this. Every game I've made is a big user of RNG, but not to this scale. How do you even make geometry with code? Then to also make it purposeful? It seems like a tough challenge. The geometry part was not the element I was worrying about to be honest. My instinct was to go to tilemaps and tilesets for something like this. It may be grid like in the end, but something like this probably should be. My concern with using these, is that they are functions designed for beginners to use the engine to build their small games. This isn't a problem, but they aren't built for the kind of scale that my regions occupy.

No, I'd need something more raw. Something much more dynamic and fast to read from. My next thought would be to go to buffers, but that seems excessive. It would be necessary if the whole map is used at once, but considering I only need it all loaded at once, it's not worth my time and energy. No, what I need is Data Structures. Raw data saved in array-like systems, but without all of the safety and convenience features packed in to make it slower. More specifically, I can use a DS Grid (Data structure grid) to save my data in.

Basic, not too costly on memory, and really fast to read and write to. Considering that these maps will be holding data in the hundreds-of-millions, even something like this will take some time to write to, but it shouldn't be that bad. I can always come back around and revert to my original idea of straight buffers. That's the easy part though. There's still the monumental task of actually figuring out the shapes and implementation of these caverns to do. And honestly, I have no idea how I'm going to do it.

I looked around for a while on games that I'd previously talked about with these. That being Minecraft and Deep Rock Galactic. I still came out with no idea on how to do this. I then just searched "cave generation" on bing, and found a niche little itch page that seemed be a cave generator similar to what I had imagined.

It literally was exactly what I was looking for. A basic modular system of generating cave systems with big rooms, passageways, and having the ability to alter the generator with tags. This small generator project by watabou just proved that it was possible to make something like this. I knew it already was, but seeing it in action made it much more believable. This generator was intended to make map images for people's RPG games like Dungeons & Dragons (another linkback). It's really well made. Makes a really fast small map of a cave system with tons of customization and additions that make each one separate itself from the other. Seeing this was inspiring, but not the most helpful to me right now. I already knew what I wanted to make, just not how to make it. And this doesn't help me figure out any methods to go about it. However, this project has a little rabbit hole I went down. And it saved me.

BorisTheBrave.com is another indie developer website that actually went inside the project and explained how the entire thing worked. I knew of neither of these people before this post, and now both of them are hard-carrying me through this process. Well, the theory at least. I actually need to figure out the code myself.

The cave generator does indeed use a grid as it's template, but then makes the mesh with post-processing. But does it make the shape? Well with Seed growth. (Seed growth being the name used here, as far as I can see, this isn't a well documented topic and doesn't have an official name.) It's basically a system of taking a point on the grid, and expanding it in all directions randomly until you have a nice round-ish shape. Now, I have seen this technique before for generation of biomes in some games, but didn't really consider it's application here. I guess it was my fault because it seems like an obvious out in hindsight.

What interests me here is that nothing seemed that complicated here. I was imagining that these algorithms have some massively complicated technique to them, but that isn't necessarily the case. It's impressive and tight, but not out of my depth to recreate myself. I did consider borrowing a bunch of the formulas, but that feels like stealing. I don't really want the exact methodology used here anyway, due to how it's supposed to look for it's smaller grid size. Remember, I'm going bigger. So whatever I make here, needs to be well optimized and well implemented into my code. It would make more sense to make it all myself anyway then. The following process was about 4 days of trial and error of getting a system that fit the games needs, and is as efficient as possible. It wasn't made in this order, nor did it go as smoothly as this post makes out. It was quite annoying in places.

The highlighted areas are the cave openings themselves, whilst the darkened areas are inaccessible wall tiles. The FPS Counter here shows 13 frames, but that's simply because I'm rendering 16x HD to show you all of the regions at once. That will be fixed when it comes to display and mapping, but in game I get about 8000fps with everything loaded in engine without compiling to YYC (The faster one) and on college hardware (Which is medium-good in processing power). I think actual performance isn't really an issue here. I'll talk about it's shortcomings a little later. The code for this adds up to a tad over 700 lines. I won't go over every single one, but I will go over the process and the issues I found here.

This is the first important function after creating the data structure. I simply add a bunch of randomly placed starting points for our big rooms, comprised of a big number that is unique integer taken from the x and y position of that tile. I then push it into an array to be used later. I do this so that I can find every place that needs expanding, rather than setting tiles up with unique data. This way, I can easily skip the tiles that have nothing on them, saving more processing power and speeding the generation up. I did try the other way, but it was very slow. It took 28s on average per region. That isn't good. This method does it in about 4s on average per region. A heavy hit, but necessary. Luckily the only big hit this system does. (Again though the specifications of the build will make it slower than it will be when compiled for launch). I use a unique integer instead of expanding the array because I actually found it to be quicker. When testing the Oil Rig idea with it's data manipulation system, I found that nested arrays are also very slow. So, manufacturing a unique id instead of using two separate ones is much easier on the processor.

This was simply a happy accident that I found this out, I would never have realised that nested arrays are as bad as they are. The speed decrease on that server went from 30000fps to 600fps once I switched from regular to nested arrays, and went through them like I do here.

I also edited the region spawner that I made last time to give the approximate locations of the exits to the region, and put them as special case hubs. There is a reason for this that I'll tackle later.

I then use a repeating script to grab each of these placements, and randomly spread them like the the post mentioned about seed growth. This is the most unoptimized part of this entire system, but I'm not going to worry about it too much right now since it only hits once every time you load a big level. That won't be often, likely after every half and hour or so. Therefore, a single heavy performance hit for about 10-20 seconds (depending on player hardware and accounting for later loading) isn't that bad. I decay the spawners and eventually remove them from the list until nothing remains. I makes a really nice randomly expanding circle room. When combined with others, it makes really nice hubs and play areas.

I then quickly clean up the decay and make sure the data grid is only filled with binary data, not other random numbers that aren't wanted. Very small part of this system.

We can't just leave it there, because this isn't a cave system. This is a bunch of tightly packed islands of different sizes. If the islands don't connect to each other, (and they definitely won't by themselves), then the player won't be able to reach the other exit. Caves typically have small passageways in between their hubs, and that is what connects them together. Let's do that then.

This is where I go a little off script from the original website that I found, since the paths are calculated way differently from how I did it. The map in that generator is so small with everything packed so tightly, that it'll just find two touching regions on the other sides of a single tile and remove the rubble between. I can't do that, because the world is so big that that rubble might be 100 tiles in between. And I can't just calculate that by the usual method because that would bring the game up to a 10 minute long wait. And I can't control how well that system works. What I do instead, is use MP grids which can be converted to and from DS grids really easily to figure out which original rooms I made are touching. MP grids are basically just more limited DS grids that can be used for pathfinding. So, I did that, and made an array filled with all of the isolated islands.

The next system is really complicated and I don't want to go over it too much. But basically, I then find two islands that are the closest together, find the individual points between the two that are the closest together, and then make a path line and put that into a new array. I then append the two islands together in that array and call it just one island. Because I already have the path calculated, I can assure that both will be touching by the end. I repeat this until only one island remains in that array. Now, the paths gathered from appending them should make every single part of the map connect together.

I calculate a bunch of new points to use my seed growth mechanism on using the new paths as guides. I then just run it through that growth to make the paths. I calculate a bunch of new points to use my seed growth mechanism on using the new paths as guides. I then just run it through that growth to make the paths. That is the bulk of calculations for making the caves done. The actual area is carved out but still not looking the best. Now it's time to polish the area up a little.

This next part is very experimental. To get rid of the artifacting in a lot of areas, I decided to smooth out the cave walls and areas using surfaces and buffers. I basically draw the whole grid out with some extra smoothing on the grid. Making some areas much more rounded and fixed than without, and then turn that surface into a buffer to extract that data and turn it back into the grid. It's a very minimal addition, but greatly improves the general shape of the environment. It really does feel like a natural cave now.

The last issue to discuss is about player boundaries.

The player should never be able to simply walk off of the map. All edges of the map should be covered to insure that players do not leave the designated areas.

I wrote this script here to create a natural boundary that applies to the grid after everything else has been generated. This system basically just creates random numbers from each edge tile to set as empty. Very simple, very quick. What's been forgotten about this however, is the fact that the players DO need to leave the map. They need to leave in-between the gaps designated by the region markers to go between the regions. "I also edited the region spawner that I made last time to give the approximate locations of the exits to the region, and put them as special case hubs. There is a reason for this that I'll tackle later." - Earlier in the post. This is where that comes in, I run some code to basically ignore the areas around the exits when creating boundaries. This does exactly what it should do, and makes the whole system clamp to the middle areas of the region, minus the exits between them.

Overall, this system is now done. The whole map now generates and renders properly with very little issues with performance and data management. I'm very happy to report that this system is ticked off my list for now, but not over entirely. To make the unique regions that I wanted to do, I will need to tweak the region spawning code to make some more unique circumstances. But, for now, it's all done!

13/02/26 One of the first big tasks I need to accomplish, is the basics of building regions out in game.

Regions: I mentioned before about a linear system of "regions" connecting the game. Making the player pass through multiple landscapes before reaching their destination. These regions making up a "cave-like" system by the end. This system was described similarly to how PEAK uses different mountain biomes to add milestones and progression through it's levels.

These biomes would have different mountain structures, different environmental hazards, different enemies, and different challenges. This is to add diversity to the games content, and give the player a multitude of challenges to beat. Rather than going through just one the entire game. This system lets the players have segmented goals. A system where each peak of the mountain is a target in of itself. Similar to my 7D project's "just one more extraction" with it's gold cases, but much better, with much better of an objective and variation in it's gameplay. In this same way, I want to add a linear set of regions that the player can pass through like small achievements. To do that, I need to develop a world generation system that can do that.

I made a markup in paint of what I want to make. A very simple system of boxes being ran in this way allows me to add a linear system of regions that the player traverses. By having the objective be on one end of the map, and the player start on the other. I made these boxes because I would need to make the individual areas themselves using some high-level data storage and manipulation system that would need to be persistent between games. This system is not negotiable. I need a system that can handle data as large as these maps would need. The layouts and sizes of the boxes would be randomly generated to make each run feel unique. The player will never feel that they've run the same map twice if the entire layout of the game changes. So let's make this!

Done. The system is done. I spent the better part of 3 hours making this system that generates these region boxes, and it was kinda just annoying. Not hard in the way that most design is, but really awkward.

This system uses an integer seed to make it's random numbers. This system is really cool because I can send over a single integer between clients, and have both make the same level independently without syncing game data. It saves a whole lot of trouble and data needing to be managed between clients if I do it this way. It might even be impossible without it. This system was also designed so that I can set separate properties and creation details of each region. (As per the colours). I can make regions in any direction, size, and any other variables I want later on.

Here is the code I used. The hardest part of making the regions isn't actually creating the boxes, but making that they are all attached to each other. I use a starting direction to figure out which side I want to attach the first region to, and then figure out the size that the box can be, before changing it's position to match the starting point.

Here, I also add some deviation in position in the axis not bound by the box connection. This makes the region boundaries much more natural looking, rather than forced.

The lines in the game imagery are the region spawning points linked together. One big path of connector points linking up to make sure that the entire map is connected like a big branch. I use boundingboxes to figure out the bounds of each new region, and apply a new variation in the path direction from where it starts. Only reaching out between -44 and 44 degrees from the current direction. This is so it has a decent distance to travel across the region, so the entrance to the next one isn't directly next door.

This entire system is really complicated, but to use directions, angles, and points of interest, I had to pull out trigonometry. By using cosine rules, (hypotenuse = adjacent_length / cos(adjacent_angle)) I could get the distance between the start of the region, and a point on the edge a decent distance away to create the next one. Along with that, the side in which it points towards for the next calculation. It's math. Y11 math at that, but still just math. Which is basically all software development is at the end of the day.

The annoying part was planning for grids. If I'm going to make a more detailed map, I'm going to need to make a dynamic grid system to manage the game world. So that every regions grid is lined up correctly, I needed to round every boundary and position to a multiplier, again one of my choosing. You can calculate rounding to any integer by rounding the value divided by that integer, and then multiplying it back again. Always brings a rounded result.

This caused some issues internally originally. The generator started unlinking regions together and placing them in separate places. For this, I added a failsafe that corrects positions and directions if needed using a simple position meeting at the new region's start.

My other big problem was figuring out how to stop regions from occasionally colliding with each other. I just realized though that this is pretty rare, and I can just reroll if it's so much of an issue. If two regions collide, I just do it again with another seed.

12/03/26 To save time and page space on mildly interesting topics that I've covered before, here's a rundown of basic player instancing, the possession mechanics, and parity between devices.

Player, Possession & Parity: So, my first task with making game mechanics, is to make a workable player character to control. For this, I made a player character with the same basic controls as the one made in my 5D project. I used almost exactly the same movement and collision code from that project, and it works perfectly.

This player character looks small and rubbish right now, but it will get better. It's important in these types of projects to focus on getting the thing to work first, and then focus on visuals and controls later. This is seen in a whole lot of projects, with most games starting out looking like this:

When making this player last time, I made each player only have one real character in their game, but then sending over their player data to be read by other games. I then used a surrogate character to draw this user out to screen. A fake user you would have in your game. Because this project is going to be using character like AI, I've decided to make a more robust character system. Still sending character data to match up two players games, but this time, each instance is real.

(Ignore the orange lines, I'll talk about them later.) The characters in this game are all real player instances made to be controlled by individual players on their respective screens. In this project, I use a custom indexing script to figure out which instance belongs to each player. Overall, whilst the game itself might run slightly slower because of this, the overall networking hit this game will have will significantly decrease from last time. Meaning servers have to do less work, and players with worse WiFi will be less impacted. STOCKWAVE ONLINE managed to still catch 250FPS at minimum on my decent 2018 computer that I used. I don't plan this game to be as performant in the future though. Because of the AI, and the Open World, and the Physics. I'll come back to that later.

I made a custom indexing system. An indexing system is basically a way to organise each of my in-game instances, and be able to reference them when I need to. In most engines like GMS2, Unity, and Unreal, these engines assign a large index to everything currently loaded in the game. This is great, because I can call on a specific instance whenever I need to with ease. However, the consistency of this indexing is not very good. Opening two of the same project with the same random seeding (The integer that decides random outcomes) will still always return different indexes for each object. This isn't ideal for an online game, where matching everything up is really important. Not to mention the differences between framerate and ping. This is where custom indexing is important. I use this system to create my own indexes, and call them between games whenever I need. Now, when a player punches a wall, I can be sure that every player receives damage on that same wall. (For example).

One massive part of this project along with player character movement, is also about vehicles and transport. So, making sure players can inhabit and utilise these vehicles is very important. For this, I made a basic vehicle movement script that allows specific players can control.

This was actually one of my biggest challenges in gamedev yet. Since to make a good ground vehicle, you need somewhat realistic vehicle physics for it to feel good. For this here, I didn't want to make something too real, or else it would feel very annoying to drive when actually playing. I also didn't want to make a too cartoony arcade system, since driving is meant to be more thoughtful and engaging than that. I struggled at first. Vehicles that work aren't hard to make, it's making them feel good that's hard. I tried brute forcing it originally, but it came off as very floaty off-putting.

For this reason, I started looking into vehicle physics, understanding that speed and turning angle are much more complex that just rotating an object. It must move along a pivot made by the wheels of the vehicle. The speed must be a fraction of the friction, or you get drift. After some tweaking around with this, I added that turning radius, drifting and friction into the game. As represented by the lines, it's much better now.

It's not absolutely perfect, but I actually think that isn't a problem. If driving all of these massive transport vehicles was easy and reliable, then it wouldn't be much of a challenge, let alone the main challenge of the game. A unique off-ness to the driving I think will make the experience more fun. If not, I can always edit again with ease to make it more realistic.

GTAV allows players to control axis rotation of their cars in mid air for more control. Not because it's more realistic, it doesn't even make sense why you can control rotation of a ground-based vehicle in air. But, it makes the driving experience more fun. In the same way, GTAV also removed a mechanic they were planning to add about refueling your car when low on petrol. They removed it, because players don't really want to go and refuel their cars frequently, because that's boring. Realistic != Fun. The last thing that I wanted to look at today was possession between these characters and objects, and how I can make a heavily focused possession system between them.

The system is run using a script I made with custom variables holding entity identifiers. This is also a really good use of the custom indexing, so that possession can be synced between clients. This system is based on the original interaction system from 5D, but much more aggressive and invasive to other entities. The reason I need this is to figure out what entities are interacting with what in a much more reliable way. Making a massive system like this to set possession is built way better to handle stuff like this. Rather than only using identifiers to figure out what possessed instances can do, I can easily identify object possession from other instances from a single call. That's the main difference from a front-end view. On the back-end, a whole lot has changed in relation to programming this.

09/03/26 As I said, getting basic multiplayer done before anything else is very important. Games with multiplayer need working from the start. So, here we go.

Online Multiplayer: I mentioned about having a niche that I'd take on as an independent. I've mentioned about how I like modern multiplayer titles a whole lot, even in the games I reference in research. So you know, why can't multiplayer games be my niche? When debating whether or not to add online multiplayer, and thus expand this project further, I really needed to consider whether it is worth it or not. Multiplayer in this game makes sense for the most part. Cash-In-Transit jobs are done by teams of two or three people anyway, so doing these jobs with others fits directly into the theme. The only problem I can see with adding this, is that it's a lot of effort to make.

So, interestingly enough, I've already done something like this. In the 5D project, I made a perfect server executable that runs perfectly in this way. I made this server specifically with the mindset that it could be used for any purpose, and with some tweaking, I could give it the purpose of hosting these games instead. This was only my second try at making a game server, and the first time in making a lobby based one. I spent over 7 months working on the game since that project ended, and know a bunch of the issues that I came across whilst developing it. So, I went and made a copy.

This version has now been slightly edited to focus on this new game's lobbies rather than STOCKWAVE ONLINE's. I've made changes to how the source works, improving it to run at 120 ticks, rather than the 60 from before. Doubling it's performance. I also cut down tons of the flack that this system had going into it. By making everything much more simple and clean, whilst keeping that same code.

Before, I made a list of packets. Explaining what data was where in the server binary. This small documentation was very helpful in deciphering what I had done a year ago, and was a really smart idea to make at the time. Saying that though, it's long. It has many useless functions that aren't explained very well. So, I remade a lot of the game structure.

Much cleaner. It explains everything the server does, and how to communicate with it. This is a much improved document, for a more improved binary. I cut return messages down to make more sense. I changed lobby data to be more refined. I added a delta system to make the server run better with it's own performance. I also added a lobby list function along with matchmaking to improve player experience. Allowing them to look though a list of available lobbies, rather than just hope one is available and get sent into it without a choice. It seems that a year of developing online games for college has actually increased my ability to make online games. (Shocker). My development skills for this project have grown based on what I've done before. My specialty has matured not only my process, but my product as well.

It took a little while, but here's the functioning new game creating a new lobby. It works! Oh yeah, here's the new game by the way. I've doing some more in other projects, trying to test how they all work. I think this project is going to take lots of research into computer physics to make, so black screens with text is very important.

I've improved the performance of this system by going all in on buffers, rather than using arrays for this server. The original idea was to use arrays to store information to be passed along as buffers on the web. The arrays could be passed as a JSON, and then processed across the web. It's not the most performant, but it still works, and doesn't make THAT much of a difference. Buffers on the other hand are way more performant. Whilst reals, strings, arrays, data structures and more are all data types passed through the CPU, buffers are different. Buffers are raw memory. It's the data type that the RAM uses to store everything. It's also how literally all data is stored. The very base of variables and data. It's incredibly fast to parse in this way. Think of it like trying to have a conversation with someone from another country, who speaks another language. Having a translator to convert everything they say into English can be pretty performant. But actually speaking that original language and cutting out the middleman is instant. That's why buffers are incredibly fast. Everything is a buffer anyway, why not read directly from them?

Buffers and raw data is really fast for networking. That's why it's used. Buffers can be really helpful in the future, but I haven't had a reason in any college project yet to use them. None of these projects are big enough for that much optimisation. This one though, might take that prize.

Linking this back to earlier, assets are good. They are really good for speeding up the process of making a game. In indie terms, most people think that assets are just devs downloading stuff online and slapping them into a game. But in my case, I've already used an asset. My own.

This server is a pre made asset that I created myself. The fact that I made it doesn't make it not a multi-purpose tool to implement in other games. Again, this is my specialty. Online technologies and building up these structures is the thing I did the best at last time, so why not suffer from my own success here again, and improve on last time. I am quite obviously ripping myself off here.

A company like activation reuses their own assets all the time. Their specialty is this type of online PVP game. Call of Duty uses similar servers between every game. Uses similar but improved visuals and programming for each title. This is because they make a genre of games that can borrow from each other. Most commercial devs do this because of the fact that they focus on a niche. Which brings me back to the creative industry, where a successful company focuses on a niche, and expands on it. Obviously this doesn't mean they can deviate from that, but they need some kind of ground point.

08/03/26 It's that time! End of week 3, and a quarterly evolution is very necessary.

Quarterly Evaluation (Pt.1): 19th post in and here we are. I did this for the 5D project, and was 28 posts in at the time, with an overall post count of 86. This is significantly less than before. Even before that evaluation, I actually started producing that game before this point, so in development timeline, this was much slower than last time. But, the quantity of work has significantly increased. (I hope at least). My thesis is based on a statistical evaluation, rather than a methodical one. Over both projects pre-production, I wrote a whopping words for my 5D FMP. That's a lot of words for a document like this. However, that number gets blown out of the water this time with 17,008 words written for this one. That's just 233% of my original post, or a 133% increase in word count. Sourced from the blogs themselves.

This doesn't feel that impactful to me though. My topics on that project related to a wide variety of topics like theme, related games, methodology and more. What I remember from that project though, was continuing to research topics as I went along and did the project. With a lot of those posts being earlier than needed. Especially in this case, where I already have decent enough information in everything I plan to do here. The contextual research is the only required thing I need to talk about right now. So, I guess I'm still in the running to make as big of an impact as last time.

This project isn't just about my goals though, it's also about the goals set out to me by the course. And that, is to produce the necessary documents to go alongside this documentation here, despite the clash between what I talk about here, being very similar to what is asked there. I think of documents like the project proposal above as the composited notes of this massive wall of text you are reading right now. Like how a game gets composited into a clean and playable project, using the source code as a base. To make it easier for the reader to see the important parts in a designated viewing format. That's why a lot of topics talked about here is almost exactly as how I described them here. I'm not going to cover them on this post either. It's there in the sheet provided, and also earlier in this blog. Not something I need to provide context for again.

The one difference in this project compared to the last is the lack of a project plan. I talked about it in the 5D project. It was bin worthy. It didn't provide enough context about be done. But even if I had done that correctly, it would have been useless anyway. I think a project timeline in this case is mostly pointless, because timelines are made so that everyone in a project can see what needs to be done. An idea is made, the company gets to work. It gets made. In many cases though, the plan never comes to fruition. Most commercial games made always get delayed, or parts get cut and scrapped. Once something iterates from the original idea, (which in this industry, it will.), the whole timeline becomes obsolete.

On my 5D timeline, my first objective was to create a functional server executable to base the rest of the game on. This was supposed to take 7 days, but was done in 4. Unsurprisingly, I didn't want to wait 3 days to move onto the next thing. If I did it like that the whole project, the game would not be as good as how I submitted it. Constant approval from higher up planning is a killer of modern games and their best interests. A better game is made through dedication to making it, and avoiding things that halt development. A common issue found in this project's biggest reference: PAYDAY.

A timeline in this structure is really good for higher ups and investors who want to manage the time and monetary involvement they put in, but it sucks for the project they're actually investing in. Time and time again, underbaked releases get sent out to the public because of decisions based on those expectations. This project though isn't a big one with a hierarchy of people looking over it. (Well, it is, but not in the sense I'm referring to). I don't need to set these deadlines to my own progress as a developer, what was the reasoning behind the brief again?

06/03/26 Danger. Darkness. Dwarves.

Deep Rock Galactic: I mentioned about a game called Deep Rock Galactic that gave me a really good impression when it came to making a game about procedurally generated missions. Using the caves and caverns systems I thought about, and also set in an objective based hoarde shooter like what I wanted to make. That was my impression at least, unlike the games that I usually talk about, I've never played Deep Rock Galactic.

So, to find out if I could learn anything from it, I went to the steam storefront wallet in hand. The game was on sale (Yippee), so I grabbed the deluxe edition, and played for about an hour last night.

My first impressions were not what I expected. The game was very heavily geared towards co-op multiplayer, similar to the other PVE heisting games I've looked at. But this one went further. The game revolves around having four classes built for different tasks. So no matter what, I was playing at a disadvantage in some way. There is a supplement for solo players in the form of a little AI companion that does most of the things other players would do. The game also focused more on loot gathering than combat. Traversal was a huge part of each level, but most of that is to explore for minerals to mine to reach the quota. It's closer to the horror extraction genre I've talked about before with Lethal Company, R.E.P.O. and Content Warning, but with mining. This game is a lot better though. Instead of a horror environment, it's a combat zone. The would rather have you clear an area of enemies, rather than have them come for you by themselves. I think it works here, but it's not the PAYDAY-like that I know. Not that it's supposed to be, but I need to find the comparisons to see where this game goes different to the other games that I look at.

The entire environment is destructible. Every wall, every mineral, everything can be mined, and carved into a pathway. It's a cool mechanic for a mining game, but I think that's where the differences will start from. Rather than this Cash-In-Transit idea be about fetch quests and mining, it will be more geared towards pushing through the combat sections and trying to survive. Like in Deep Rock Galactic, but less focused on generic exploration of tunnels, and more of following a path that the player can figure out at the very beginning.