Noita Enhanced

Noita is a brilliant action roguelite (I hate this term) where every pixel is simulated. Compared to your standard roguelite, there’s a greater focus on using the environment to your advantage. What really excited me the most about it was the degree to which the game can be modded.

Under the hood

Noita uses Lua for handling all scripting-related tasks. Serialized entity data is stored as XML files and there is a heavy reliance on an entity/component relationships for organization.

Virtually all aspects of the game logic are modifiable via the existing Lua scripts. A modder can override certain scripts or XML files or append new data with relative ease.

What needs changing?

When I start modding a game, it’s usually for one of two reasons: I have ideas for new features that I think should be in the game, or I find certain aspects of the game to be lacking or incorrectly implemented. With Noita, it was a mixture of both.

I skipped over some of the stuff i made since i don’t have a gif for everything, the entire list of mods i’ve made can be found here.

High risk, high reward

In Noita, the player progresses by collecting magic spells to append to their magic wand. There are certain spells which are considered to be must-haves, and once you find them you have a better chance of reaching the end of the game… If you can mitigate their inherent risk. One glaring problem I saw with the game progression is that the variety of these must-have spells is too limited. Creating new spells that fit this category was not too hard, the biggest thing to consider was the risk/reward factor involved. In order to balance out the stronger spells, they have to be made difficult to use.

Both of these spells are incredibly powerful, but they also have some inherent risk in their use. The freezing spell creates a small shower of damaging ice particles that can harm the player, and if the player manages to get caught in the blast they will be frozen for a short period of time. The magma explosion is very short range and also creates a small shower of magma which can harm the player and ignite them. Shooting it straight upward isn’t possible unless you’re willing to take some damage from the magma that falls on your face.

Miscellaneous spells

I made a handful of other fun little magic spells that I thought fit the game well, such as a projectile modifier that makes your projectile suck in nearby objects.

Perks

Perks are a major component of Noita. The player descends through several biomes and at the end of each biome they reach a “safe room” where they can regroup, heal, and adjust their magic spells. At the end of each safe room the player is given 3 random perks to choose from. A perk changes an aspect of the player to make them more powerful in some way. There are perks that make the player more resilient to damage, perks that increase the player’s mobility, and so-on. I thought the selection of default perks was a bit lacking so I created a handful of my own.

This perk makes the player summon sprites that attack their enemies automatically. These sprites are technically an NPC, but i used the entity/component system to give them a projectile component. In a technical sense, they are a living projectile.

Both of these perks give the player an inherent trail of either fire or ice. The trail applies a burning or freezing effect to enemies that enter it, and it also interacts with the environment as you’d expect. The fire trail causes oil to ignite and turns water to steam, and the ice trail freezes any liquid it touches.

Altars

Giving the player random places that allow them to trade objects for rewards was something i wanted to do, so I implemented new altars which have a small chance to appear in any given run.

This altar makes use of the game’s pixel engine to convert corpses into gold dust pixel by pixel. It looks neat and gives the player a way to generate income using nearby corpses.

Magical stones

The world is littered with enemies and treasure, but it also contains objects the player can pick up and store in their inventory, such as flasks of water. There is one unique object, a stone that emits electrical charges, which caught my interest. I decided to make different versions of it.

The holy stone converts impure substances such as blood to water. The fire stone melts through ice and converts water to steam.

Quality of life

There were several small aspects of Noita that annoyed me, so I modded them. I don’t have much footage of these mods in action because they aren’t especially exciting.

Putting it all together

I kept all these mods separate from eachother so that i could allow the end user to pick and choose which features they want and customize their experience to their liking. I created a modworkshop entry containing the github link to my mod collection. It quickly became one of the most popular Noita mods. This, to me, is affirmation that my assumptions about what aspects of the game needed changing were correct!

Mordhau CTF

I previously discussed the process of making a custom map for Mordhau. Finishing my first map left me with a feeling of dissatisfaction, like there was still work to do. With a more complete understanding of what the uSDK is capable of, I set out with a more ambitious goal of creating a whole new game type. The obvious choice for this was capture the flag, something that i thought would translate well to a game where melee combat and teamwork are at the forefront.

Luckily, someone had already created a very barebones capture the flag mod and publicly released it. Much of the difficult work had been done, so I could really focus on the finer details and figure out what needed changing.

Fine tuning

It took several iterations, but i finally managed to massage the CTF mod into something i thought was more appropriate for Mordhau.

Stalemates

The basic CTF mod neglected to implement any sort of stalemate mechanic, which i think is a crucial aspect of capture the flag. The idea is that if the enemy team is in possession of your flag, you cannot capture theirs until the stalemate is broken. This creates a situation where both teams have to simultaneously defend their flag holder while attempting to break through the other team’s defences and kill the enemy flag holder.

A badass flag

I grew up playing CTF in games like Halo and Soldat, and one of the important concepts in both of those games is that the flag runner still has the ability to defend themselves, though it may be in a somewhat limited capacity. In Halo, you could bash people to death with the flag. It’s worth mentioning that the flag also looked really cool. Improving on the appearance of the flag was one of the things I did almost immediately.

Now we’re cooking. Achieving this was easier than i thought. The flag object is derived from the quarterstaff weapon blueprint. The skull, coiled rope segments and flag are all meshes (with all collisions disabled) parented to the quarterstaff with a vector offset to move them closer to the end. Simple but effective.

Since the flag object derives from the quarterstaff, it behaves exactly as the quarterstaff does when you’re holding it. I felt that it was a bit too weak in this state, so I tweaked its damage numbers upward slightly to give it a little more utility in combat. It’s not the strongest weapon, but a flag runner can defend themselves with it in a pinch.

A proper HUD

Capture the flag has its own unique HUD requirements, and thankfully the uSDK makes it possible for modders to create their own. I copied an existing HUD for one of the other official game types and made a few changes. Red and blue scores on the left and right, and a time limit in the middle. That’s all you need.

Both flags also have a HUD widget parented to them that indicates where they are for all players. I made some changes to the widget so that it used color instead of text to denote which team it belongs to.

Sound cues

The original CTF mod had notifications appear on the HUD for when the flag is taken or returned. I added some sound cues for these situations, and also added a celebratory noise for when a team scores.

The map

With my tweaks to the game scripts complete, i could focus on creating a rough level to test in.

I didn’t put as much effort into the visuals on this level, partly because the design was so absurd from an aesthetic standpoint that it didn’t seem to merit a serious approach. The goal was to make a map that was fun to play, not necessarily a realistic depiction of a castle like so many of the other Mordhau maps.

The colored dots indicate spawn positions and the colored X marks indicate the flag positions. It’s not immediately obvious, but the players spawned on top of a raised platform to make it a bit harder for them to be attacked as they spawn.

The general concept of this map was to have 2 symmetrical bases very close together, with a chasm dividing them. There’s an emphasis on lateral movement rather than straight lines. There are 5 bridges at ground level, as well as 2 risky bridges on the outer edges between the higher levels of both bases. In the middle, there’s a large wooden elevated structure only reachable if you jump to it from the upper level of one of the bases.

Playtesting

I thought this was an interesting layout, at least for a simple test map, but I was totally unprepared for the general response from the community.

After releasing this map i had left town for a couple of weeks. Upon returning i found several letters in my inbox discussing the CTF mode. Apparently a tournament had been organized by competitive Mordhau players and the map received a lot of attention.

So much attention, in fact, that I received a message from one of the developers for Mordhau. We set up a small group chat between myself, the developer, the fellow who created the original CTF mod, and a prominent figure in the competitive Mordhau scene. We discussed CTF and how it has the potential to be a game fit for the competitive Mordhau scene. His goal is to iterate on capture the flag further to figure out which aspects of it are fitting for competitive play.

A new version of CTF is now being worked on, with my map being the de-facto test map for it. The rules have become more complex, with players having to plant stolen flags in a specific zone and defend them. Even if this new game does not catch on with the competitive scene, I think that it has potential with the broader community.

Next steps

My goal now is to finish a few better looking maps that work with CTF. Based on feedback from players, it has become apparent that bigger isn’t always better with CTF maps. This is great news for me since it means i can produce good looking maps faster.

I’ve been able to publish a handful of maps on mod.io and they have been received well so I’ll probably rent a server for a few months and set it to only run CTF maps and see if it becomes popular.

Mordhau

Mordhau is a brilliant first-person melee game with deep mechanics and very satisfying crunching sounds when you club someone over the head with a sledgehammer.

The first person melee genre has been sparsely populated for a long time. Mount And Blade: Warband came out in 2010. Chivalry: Medieval Warfare came out in 2012 and enjoyed relatively little competition up until the release of Mordhau in 2018. Mordhau immediately took its place as the de facto first person melee game, and for good reason.

The combat mechanics in Mordhau follow the “easy to learn, hard to master” doctrine perfectly. The skill ceiling in this game is ridiculously high, but the skill of the average player is low enough that a bit of practice will make you an effective player. For those who are really dedicated to being the best at the game, there is always room to grow.

The combat system in Mordhau is so good that you could place a bunch of players in a big, flat, boring room and it would still be fun. The developers of this game were more ambitious than that, though. Perhaps to a fault. At launch time, the game had a collection of interesting maps where players have to complete various tasks such as pillaging a village or pushing a cart from point A to point B, all while fighting with the other team.

This mixture of combat with team-based objectives is absolutely a good thing, but this is where my praise for Mordhau stops and my criticisms begin.

Pick up that barrel

The main mode that players flock to in Mordhau is the objective based one. These servers can have either 32 or 48 player limits, so you get big fights that are always interesting. The maps these servers run always have some collection of objectives for teams to accomplish in order to win the round.

The basis for these objective based maps is a collection of capture points where teams need to stand in order to gain possession of that particular point. These capture points act as the focal points for the battle, and players are inevitably funneled to them. These capture points also determine where players will spawn, so owning less capture points means your team spawns further back in the map and therefore owns less territory.

These capture points often come with a prerequisite task, such as:

  • Pushable carts or siege engines which must be moved from point A to point B before your team can advance further.
  • A collection of NPC peasants you must slaughter in order to capture the next point. The defending team must defend these peasants to stop your team’s progress.
  • Buildings that a player from your team must carry a heavy barrel of explosives to in order to destroy it. Typically you have to defend this player while they haul the keg since they move slowly and cannot defend themselves while holding it.
  • A collection of buildings that your team must destroy using your weapons in order to advance, such as wooden barricades.
  • A player-controlled VIP sort of character controlled by the top scoring player on the enemy team. These characters are taller than average and have a very strong weapon, but cannot heal themselves. The enemy team must defend this player while your team tries to kill them.

I personally don’t dislike some of these sub-objectives since they tend to make gameplay interesting, the problem is that some of these things only look good on paper.

  • Objectives such as “slaughter X peasants” or “break X objects” typically do not take much effort for one team to complete. They are, for all intents and purposes, gimmicks.
  • Player controlled VIP characters might sound fun but they create several problems. If one team is known to have this objective on one of their capture points, it creates an incentive for all the good players to rush to that team when the game begins (recall that the VIP character role is rewarded to the top scoring member of the team). The nature of this objective also means that players will try every dirty trick in the book to make it as miserable as possible for enemy players to reach the VIP. On certain maps, the VIP can hide in a house and have his teammates cover the entrances with spikes and barricades. On other maps, the VIP is given no cover at all and slowly has their health whittled away by enemy archers.
  • The objective where you must carry a keg of explosives can be very difficult to achieve, and its difficulty varies greatly depending on the competence of your team and the other team. In many cases, players seem to just ignore the objective since nobody wants to be the guy who has to haul the keg to the objective and risk getting their head chopped off.

The pushable cart objective is the only one i don’t have major criticisms for. In the right setting i think it can be a good thing since it helps move the focal point of the battle and keeps things fresh and interesting.

Is it possible for a map to forgo these sub-objectives and just focus on the basic capture points though? It certainly wouldn’t be as flashy as the maps that have a jillion different tasks for your team to do in order to win. Would the primary focus on just capturing points be enough to make gameplay interesting?

This is the question I tried to answer by designing my own custom map.

The uSDK

As it turns out, this game does not have a fully functional SDK (yet). The community, with some help from the developers, cobbled together a project called the uSDK that resembles Mordhau but is populated with mostly placeholders. Mordhau is built in UE4 and as a result, many of the placeholder elements use the blueprint system. It turns out that this unofficial SDK has a lot of official game code contained within all of its blueprints.

This was my first time ever using UE4 but since i have some experience with working in the Source engine, it did not take long for me to get acquainted with the editor.

The general floorplan of my map was going to be a U-shape, and it was going to take place in a canyon. I made this choice because there was a glorious collection of cliff mesh assets included in the uSDK and i really wanted to make use of them. Every other aspect of the design of this map was just kind of thrown together on the fly. I find that improvisation can result in some very interesting stuff.

From start to finish

I maintained videos from every test session for this map since it’s always fun to see something built from scratch.

This is the earliest build i made of the map. A very basic layout lacking proper textures and lightmaps. It hurts my eyes just to look back on it. Still, it was an important milestone since I was new to the whole lighting bake process and the configuration of lightmaps.

I have an approach to design that might drive some people up the wall. I tend to start in one area and immediately flesh it out, rather than arranging a rough layout of the entire map off the bat. This is probably a bad idea for most people but I had a very clear picture in my head of what i wanted to go for.

You can see from these videos that the map was built from one end to the other in a linear fashion, with emphasis put on fleshing out each area with the “main” props before i continued forward. Lighting was still very rough around the edges since i hadn’t yet started tinkering with the myriad lighting settings under the hood.

This build was a huge step forward for me in several regards. The initial general placement of props was complete and i could visualize the map better. I fleshed out my landscape material using some existing textures from the uSDK and did some rough painting. I also did a little photoshopping to come up with my own cliff textures since the default cliff materials were mossy and not at all desert-esque.

I figured out a lot of minor improvements with this build. Lighting was improved, prop lightmaps were properly configured, capture point objectives were placed where i thought they should go, and detail props were added in some places.

It was around this time that i asked around the Mordhau modding community if someone could lend me a server for testing. This also helped with cleaning up the bugs you never find in singleplayer, and also allowed me to explore the map with other people and discuss bugs and spots that could be designed differently.

It’s amazing what a difference good lighting and a little atmospheric fog can make on a map. With this build i had also started detailing areas where there was too much empty space. I added patches of weeds, more detail props, and made revisions to the map layout in a few spots.

Lighting is incredibly finicky and takes several iterations to get just right. With this build i also added a bunch of decals to the ground to make it more interesting. I avoided large areas with a contiguous ground material since these kinds of areas really stick out as unpolished. The human brain is very good at noticing patterns, so I avoid displaying wide open areas of a tiling texture. If that’s unavoidable, i scatter detail props on the ground (such as planks of wood) and add spots of dirt or grass to break up the monotony.

I also dabbled with using spline meshes to create roads around the map to make long stretches a little more interesting. This, to me, is like sorcery.

For my official 1.0 build there was a lot of under-the-hood stuff to do. The game logic i wanted had to actually be programmed via the blueprint system.

I gotta say, the most impressive thing from my newbie perspective is the power that the blueprint system gives the level designer. I’m used to the game logic being a totally separate entity from the level, which isn’t the case here. I used blueprints for several aspects of this map.

The top blueprint was used to create a flickering light effect on the campfire. The second blueprint handles the score calculations for both teams. The final blueprint is used to make an audio emitter play a random sound from a specified list of sounds at random intervals. This is useful for adding ambient sound around the map, such as creaking wood on the wooden walkways.

This blueprint system is tremendously useful, if something doesn’t behave exactly how you want it to you can just program additional functionality for it. But blueprints also have a dark side…

This is the blueprint for my custom game state. Normally since i’m deriving from an existing game state i wouldn’t have had to change much, but I had to bypass the parent class in some cases and use its parents logic. Blueprints become exceedingly difficult to manage as they grow in size and i’m glad i didn’t have to do this too much.

Materials

Materials deserve their own section of this post because the unreal engine has such a crazy material system. There are several noteworthy materials i had to make from scratch for this project. The most obvious is the landscape material, which blends 4 different textures.

For decals, the uSDK provides the textures but no corresponding materials. So i had to create my own materials to get them working as intended.

This footsteps decal is meant to just apply a normal map to a surface to give the appearance that there are a bunch of footprints. In order to accomplish that, I plug the normal map into the normal input for the texture and then use the blue channel of the normal map to determine the opacity of the decal. This works well enough and allows me to make it look like there’s been a lot of foot traffic in certain areas.

For wagon tracks, i just combine a simple transparent decal with a normal map and reduce the opacity by 40% so it blends a bit better with the ground.

Next steps

Now that this map is fully playable and fleshed out, i’ve released it on mod.io so that server owners can access it. So far it’s not being used all that much, i’d like to do a live test session as soon as possible. Currently the map is at 850 subscriptions so i’m hoping it will get even more popular as time passes and see some action on a server that’s populated.

Maybe once it’s been playtested enough i’ll be able to get an idea of which areas need tweaking. Until then, i’m gonna give it some time to circulate through the community.

Anatomy Of A Space Station

Space Station 13 is a brilliant game concept. It was originally created in 2003 using the BYOND engine. A more detailed (and in my opinion, very interesting) accounting of the history of Space Station 13 can be found here. The jist of it is that the source code for Space Station 13 was released to the general public. Not long after that, several communities were created, each with their own branch of the code with their own features and ideas for how the game should play.

The concept is simple:

  1. Take 80 players, give each of them a job, and stick them on a space station.
  2. Pick a random game concept from a hat and activate it. Maybe one player becomes an alien that has to stealthily absorb the DNA of several crew members and escape the station safely. Maybe several players are designated as rogue operatives who have to set off a nuke in the station engine room. Maybe several players are given a specific task or target to assassinate.
  3. Watch as the space station slowly descends into utter chaos until it becomes so bad that an evac shuttle has to be called. Generally this happens within a half hour, depending on how chaotic things get. Once the station becomes too unsafe and too many staff members are dead or at risk of death, the station commander will call the shuttle.
  4. Once the station is evacuated, reveal what the game was and who won.

What makes this formula work is that Space Station 13 has a lot of depth. It is first and foremost an atmospheric simulator. If a room is breached and exposed to outer space, it quickly becomes freezing cold and players without a breathing apparatus will suffocate.

In addition to simulating the atmosphere everywhere in the station, the game allows players to interact with damn near every entity on the station in nearly every conceivable way. You can inject light bulbs with highly flammable liquids and watch as the hallway bursts into flame when someone turns the light on. You can spike someone’s water with LSD. You can open the maintenance hatch on an APC and snip some wires to disable the power for an entire section of the station. You can open the maintenance panel on an airlock, engage its locks, disable its power, then weld it shut for good measure. You can tear up the floor tiles and reroute the garbage chute so it empties trash into the captain’s quarters. Any nefarious thing you can think of is probably possible in this game.

Since Space Station 13 grants players such a large degree of freedom, there’s a lot of potential for abuse. There are a lot of rules that players have to abide by or face discipline from an administrator for a particular server. For example, players who have not been designated as a rogue operative get in trouble for murdering people freely. The idea is that you’re supposed to act in good faith. If you sign up as a janitor, then you’re expected to at least spend a bit of time keeping the station tidy. As long as you don’t ruin the game for other players or break certain rules you are free to do whatever you please. It is for this reason that every game of Space Station 13 ends up being something different and interesting. Every game has its own story and every player plays a part in determining the outcome of the round.

Players are also expected to roleplay a bit, since everything is described through text. You are allowed to create your character as you see fit and choose which jobs you would prefer to do.

All players are equipped with a radio headset and can choose to talk into the headset or chat with the person next to them. There is an incredible amount of depth to the communications system, communication is a critical element of the gameplay. If you lose your radio headset, you have to rely on wall-mounted intercoms to communicate over the station radio channels. If someone steals your headset then welds you into a locker, all you can do is scream for help and hope some player nearby can hear you.

The station

I enjoy playing SS13 a lot, but what really caught my eye is the level of detail that goes into the space station itself. Every aspect of the station has to be carefully considered for both aesthetics and gameplay purposes.

Here is an overview of what people consider the gold standard for space stations currently. Players vote for this map the most often because it plays exceptionally well and is aesthetically pleasing. But what makes a map good? There are a lot of design considerations a map needs to tackle while still looking good.

  • The medbay needs to be somewhat central and accessible. Players will inevitably get injured and if medical facilities are too inaccessible, injuries will turn into deaths. Often a map will also have small medical hubs in the areas that are too far from the medbay.
  • The security sector needs to be somewhat central as well, because players will misbehave and if security officers can’t deal with them easily, the station will fall into anarchy.
  • The bridge and station AI room need to be well protected. If they get destroyed, the station becomes a much more dangerous place.
  • There are lots of non-essential rooms that should still be fairly exposed to major traffic arteries, since otherwise players will never visit them. A good station has many social hubs where players will naturally end up visiting since you want to force interactions between players for the station to stay interesting.

These are just a fraction of the considerations that have to be made.

The plan

Before starting any work I had to figure out how I wanted to approach the design. Every person that makes a space station has their own ideas of what it needs to look like. Making a space station is a lot of work so planning ahead is a no brainer. Having to redo vast portions of the station is not a good problem to have.

I started by drawing my layout roughly on graph paper.

I wanted the station to have more looping hallways than other existing stations. Instead of being one main root hallway with a bunch of branches, the station would instead have a web of interconnected hallways. The dark blue tiles represent these hallways in the image.

I had several principles in mind when i started creating the layout:

  • No room will be larger than the player screen size. If a department has more space than that, then it needs to be properly partitioned.
  • Main hallways should be 4 tiles wide, secondary hallways should be 3 tiles wide, maintenance tunnels should be 1-2 tiles wide.
  • The research sector and engine should be kept on the external fringes of the station since they’re the most likely to cause catastrophic damage. The engine that powers the station is powered by a small black hole and nefarious players can unleash this mini singularity and watch as it moves around and randomly destroys sections of the station.
  • Social hubs such as the bar and cafeteria should be near the center of the station. Medbay and security should also get prime real estate.
  • The map needs to be aesthetically pleasing but also designed in a way that uses the least amount of space possible and promotes good gameplay. This can be harder than it sounds, sometimes the best looking solution isn’t always the one that players will enjoy.

From start to finish

With the rough draft finished, i started working on the actual map. The first step was to create the rough footprint for the walls and floors. There’s a few changes i made right off the bat that contradicted my original drawn plan. I moved the evacuation shuttle to the southeast corner and rearranged a few other departments.

My approach to designing the map was to start at the top and work downwards. If i needed to resize a department for any reason, i could simply add or subtract space from its southern neighbor. The arrivals shuttle, botany, animal storage, kitchen, bar, jazz lounge, rec room, crew quarters, tool storage, head of personnel and captain’s quarters were the first departments i worked on.

My first attempt at making the security department was an overwhelming failure. The layout of the department was too clunky. The brig was exposed to the main hallway which meant jailbreaks would be common. The layout of the rooms was clunky and maze-like.

I continued to revise rooms. Crew quarters was really poorly set up so i gutted it and started over. Security underwent 3 revisions before i was satisfied with it.

A lot of rooms took up way too much space, so I did a lot of downsizing early on. It’s easy to overestimate how much space a room will require.

I spent a lot of time planning out the medbay initially before committing to working on it since it’s one of the most important parts of the station. From the medbay lobby, the northern route brings you to the surgery rooms and the southern route brings you to the corpse processing areas: the cloning lab (where dead players are brought back to life with the cloning machine), the morgue, the robotics lab (where dead players can be turned into cyborgs), and the genetics lab (where corpses can have their genes modified before being cloned). In the middle there’s a reception desk and a cryostasis chamber where patients can be put in cryochambers. The west side of the medbay contains the less important rooms, such as the storage room, a quarantine room for infected patients and the medical director’s office.

The medbay and security department were built, but far from perfect. These are the most important departments on the station so i spent a lot of time sharing screenshots with SS13 community developers and getting opinions from people who have made maps before.

I redid security again after getting plenty of feedback, tweaked the medbay layout a bit, added the station bridge and worked on finishing the first pass for the research sector. The station bridge is kept airgapped from the rest of the station in the middle, which makes it very hard for villains to break into it without a space suit.

The security department and research department were mostly complete at this point. I did my first pass for the chapel, quartermaster’s office, pool, owlery, arcade and mechanics’ office.

I decided to have a bit of fun with the engine design. Normally, a space station has a single engine that provides power to the station. The engine can be a thermo-electric generator (which is relatively safe to operate) or a singularity engine (which is easy to operate but also fairly dangerous since it’s pretty easy to turn off the containment field that stops the mini singularity from moving around and destroying the station). I opted to make a dual singularity engine.

With the engine finished, all i had to do was finish the engineering sector, the mining sector, the escape shuttle bay, and a few other miscellaneous departments. Even with the rough layouts for the departments completed, there was still a lot of work to do.

Solar panels are needed for backup energy if the station engine dies, so i placed 3 different arrays at different locations. I also added a wreckage to the northeast which serves as a separate spawn area used in certain gametypes (for example, the red ship is where rogue operatives will spawn).

A good space station will also have a network of mail chutes that allow players to mail items from one department to another, so i worked on that. Space stations also need a disposal chute network so players can send trash to the disposals room for processing. Light fixtures (with lightswitches), electrical wiring, area power control panels (also called APCs), security cameras and emergency air injectors are also something that every room needs.

It’s a good idea to really nail down your room layout before placing all of the auxiliary stuff like mail chutes. If you mess something up and it isn’t caught until you’ve placed all these things, you’ll have to do a lot of tedious surgery on your station to fix your mistake. After finishing everything and taking a step back to examine the station as a whole, I do have some regrets about certain aspects of the layout. The map has not been playtested yet so I can’t say for certain which areas really need to be reworked.

Since i used version control to keep track of my changes i wanted to make a timelapse animation showing my gradual progress. It was too much of a hassle to do, sadly.

The vital organs

I took some screenshots of the various networks of underlying systems that all fit together to make the station.

The disposal and mail pipes:

The electrical wiring (with the contrast turned up to make the wires easier to see):

The walls and floors with all other stuff hidden:

The wiring and pipe networks all follow the main hallways of the station since it makes them easier to access and generally just makes sense.

Is it good?

The map has gone through a lot of changes since I started work on it, but the question still remains: Is this map good at all?

This is a difficult question to answer. This map was designed using the goonstation codebase (recall that there are several communities, each with their own custom SS13 build). Since this map was made for goonstation, it needs to be tested on their servers (ideally with a good handful of volunteers). Getting a map accepted into production is an arduous process since it needs to pass inspection. This means that the administrators and coders need to sign off on it being admitted into the map pool, and any major design flaws need to be ironed out.

What constitutes a design flaw is kind of difficult to determine. Obvious mistakes like putting the medbay way too far from the center of the station will probably negatively impact a map’s impression on the community. There are many other aspects of the map that can be nitpicked, and it’s not always black and white. I fully expect that this map will be dissected and roasted many times over once it’s released as 1.0. Whether it will actually be accepted into production depends on how many aspects of its design are considered acceptable by the community.

There’s also a minor issue: I can’t get it to compile. It was designed using a third party map editor tool, and while i can open it with that tool, i can’t open it with the BYOND dev tools. Some aspect of the map file is causing the compiler to freak out and the error message it gives is too cryptic to be helpful.

For now this space station is stuck in limbo until I can coordinate with the developer of the other mapping tool to try and debug this map and figure out what is causing the crash.

Generic Zombie Game

Another game i wrote in Lua around 2011(?).

It is a round-based zombie survival game, with rounds typically lasting 15 minutes (although often ending much sooner when all human players die). You earn cash by killing zombies which can be spent on weapons and supply airdrops. If you die, you become a zombie.

Some notable features:

 

• Challenging gameplay. A strong emphasis on teamwork and inventory management.

• A dynamic weather system. Thunder, lightning, particle-based rain and wind. The weather is randomized each round.

• Random events. They happen over the course of the round. Some are good, like scientists and supply crates appearing. Some are bad, like temporary radio blackouts. There’s even an event which causes a wicked storm using the weather system.

• Intelligent zombie NPCs that hunt you down. They can also break through doors, breakable walls and windows.

• A bunch of scripted weapons which implement scopes, ironsights, bullet penetration and more.

• Melee weapons, including a hammer which can be used to build barricades using wood planks.

• An inventory system that is very modular. You can add your own items with ease.

• 4 human classes and 4 zombie classes, each with their own perks.

• Fancy effects. Motion blur, postprocessing, realistic drunkness/infection/etc, blood spatter on your HUD, and probably more.

• Lots of gore effects. Blow the torso off of a zombie with a winchester, create showers of guts with explosives, instantly fry zombies with laser weapons and blow the heads off of zombies with pretty much any gun.

• Ailment system. If you are attacked by certain zombies you will start to bleed. If you are hit by zombies you become infected. You can also become irradiated from certain things.

• Replayability. Never play the same match twice. The infection antidote spawns randomly around the map throughout the game, and the evacuation helicopter has multiple landing zones.

• Stats. At the end of the round awards are handed out to players who have accomplished great and not-so-great things. If you’re one of those fellows who hides in a corner while his teammates do all the work then you will get publicly humiliated. If you are a skilled player then you’ll get a pile of accolades.

• Parameters that give the server owner complete control over most gameplay aspects.

• A custom entity loading system for maps which do not officially support the game script.

I originally wrote this game several years ago, before the original Left4Dead game was released by Valve Software. There are a bunch of gameplay videos on youtube, search for “ReDead Gmod” or something along those lines if you want to see more.

There are plenty of gameplay videos on YouTube as well.

The scripts are freely available: https://www.assembla.com/code/redead/subversion/nodes