Morbus

Author: remscar

  • First Playtest Results

    Last night was the first playtest for this version of Morbus and so I thought it would be good talk about the results.

    Video courtesy of Chad Diver

    Players

    There were roughly 27 different players across the 2 hours we played. We peaked at like 15 players at one point which was pretty exciting.

    No major bugs

    There were no existential, game breaking, fun ruining, bugs. The worst thing that happened was one round (near the end) every player was a brood alien, but all the other brood aliens appeared as humans to them. It was really strange, I have no idea what happened or how to reproduce it. We’ll just call it the Trouble in Brood Town bug.

    Morbus Moments

    I saw a couple of “Morbus” moments happen. What I mean my “Morbus” moments are moments of gameplay that I think are really cool, fun, and unique to Morbus.

    One of these moments was when I was a swarm alien. It was late in a round, maybe 25% humans remaining and the lights were out. A handful other swarm aliens and I saw two humans in the showers. The humans knew we were outside so they were hunkering down waiting for us to attack.

    About 5 of us swarm aiens gathered and then rushed them all at once. I was the first to be killed, and the humans had some pretty strong guns so I don’t think any of them were killed, but I immediately knew it was probably a really fun encounter for the humans to fend off a wave of swarm aliens like that.

    Guns

    I thought the guns were actually decent. Bigger guns like the M4 and the shotgun were much more rare. Finding one felt like a treat. There were many rounds where all I had at first was a pistol and I had to hunt around for an SMG or Rifle.

    Ammo was also somewhat scarce. I never ran out of ammo but I was always aware that my ammo was somewhat low and I needed to be somewhat deliberate about whether I shoot or not.

    Mid Session Swarm Alien buff

    About 30 minutes into the playtest it became very apparent that swarm aliens were too weak. I think the biggest offender was that they moved too slow.

    I was able to buff their movement speed immediately since I had the server running in the editor and it made them actually fun to play. My experience playing the game wasn’t amazing since I was in the editor, but being able to make a quick change like this was very nice.

    Lots of great data

    Seeing people play the game gave me a lot of data points on how people are interacting with what’s there. Things are still early and rough but I think I saw a lot of positive signs.

    Annoying little bugs

    There were a couple annoying little bugs that I don’t know how to solve.

    One of which is weird black lines that almost look like shadows being casted from a player’s model to what I imagine is the origin of the map. It seems related to the highlight component so I’m wondering if it’s an engine issue and not me (that component is built into the engine.)

    Some bad attitudes

    There were some people who joined to play who said some very negative things about the game. They called it bad, poor quality, that is sucked, etc. I don’t know how they found out about the playtest, or if they even knew it was a playtest, much less the very first playtest of a game. It was somewhat discouraging hearing such criticism. Yes the game isn’t amazing yet, it’s still early in development, it lacks polish, the map is barebones, but I don’t understand why some people have to be so rude about it. Maybe they’re insecure or jealous that someone else was able to make something better than they could? Maybe they have nothing better to do with their life? Maybe nobody loves them so they need to take it out on someone else? Or maybe they just don’t understand that their words and actions can have an impact on people?

    Long story short it kind of sucks hearing that. It’s vulnerable having people play something you’ve made, especially when they’re the first players. I’ve put a lot of effort into this game so far, I think the HUD looks sicks, I think the tab menu looks cool. There’s a lot of gameplay systems already in. In the ~5 weeks I’ve worked on this project i’ve done more than I think I did in a whole year when I worked on original Morbus. Compared to Shoothouse I think i’m way farther than I was 5 weeks into that project too. I think I was hoping people would come in and say that they thought it looked cool, that they had fun playing and that they were excited to see it improve and play it again later. I know that many people did feel that way and i’ll continue to remind myself of that, and that the original Morbus was amazing and this version will be also.

    I think i’ll put together a more hand picked set of playtesters in the future. Early on the game should be played by people who’re going to be supportive, not demoralizing.

    Glowstick Hell

    I somehow forgot to make glowsticks despawn after awhile, and they also stuck around between rounds. This made it so eventually the map would just fill up with glowsticks. I pretty quickly started to get performance hits when playing and I started to manually delete all the glowsticks from the scene in the editor between rounds.

    This was quickly patched.

    Bugs bugs bugs

    There were lots of little bugs that popped up. Some easy to solve, some not so much. The most frustrating type of bug is the ones that make no sense. For instance sometimes players will lose the ability to see their HP. No idea why this happens, but I added some safety rails and a system that will hopefully notice when this happens and print debug information in console.

    If you watched the video above you’ll notice that HP bar bug, and also that no nametags show up.

    Next playtest

    I’m going to go back to cooking for a week or so. I’d like to get some basic brood alien upgrades in, perhaps even some new guns. Swarm alien upgrades could also be good, or perhaps a basic starter ability for them.

    The next playtest might be on the weekend of 6/20 so stay tuned for that!

  • Crew Menu and Status Effects

    This is going to be a shorter blog post because we’re gearing up for our playtest and we’re a bit behind on these posts.

    Crew Menu

    In the original Morbus when you opened your scoreboard you could mark players with a tag. Something like “Friend” “Suspicious” “Alien” and when you looked at the player in the world, that tag would be shown next to their name.

    This made it so you could leave notes for yourself, making it easier to remember who you trust and who you don’t.

    This iteration of Morbus needed something like this, but instead of calling it a “score board” i’m calling it the “Crew” menu.

    There was also the ability to “mark” a dead body, tagging that player as an alien for you and other nearby players. If you find a dead body you can know for certain that player is an alien now (either swarm or brood.)

    Improvements

    There are a couple things I wanted to iterate and improve from the original Morbus.

    Each tag has a little icon associated with it. This icon shows up on the scoreboard aka “crew menu” as well as on the little nametag display you see when looking at them.

    A tag that’s related to aliens makes the whole row for that player red, making it very easy to see they’re an alien. When you look at them in the game their name tag is also in red.

    If you mark a dead body, they show up on the scoreboard as a “verified alien” now too. Making it crystal clear that if you encounter this player they’re for sure an alien and you should shoot them.

    Last Seen

    There is also a “Last Seen” column on the crew list. Whenever you see a player the counter resets, and starts counting up. This will help you remember how long it’s been since you saw someone last.

    Status Effects

    There’s temporary effects that need to be communicated to the player. For instance if you are a brood alien and you recently transformed into your alien form, you have a cooldown before you can transform back into your alien form.

    This isn’t always clear to players that they cannot transform back. In the original Morbus the “alien” icon in the need section of their hud disappeared while this cooldown was active. I never liked this solution since it’s a bit ambiguous.

    I’ve added a sort of “Status Effect” system where players can be afflicted with Status Effects. These effects can be time based too, expiring after an amount of time. In the case of this Brood Transformation cooldown, it’s now a status effect that lasts 6 seconds. While you have the status effect you cannot transform back into brood alien form (though you can transform out of it.)

    The status effect is shown on your hud, and if you open your inventory you can mouse over the status effect to see a tooltip explaining what it does.

  • Glowsticks and Grenades

    Glowsticks are an iconic part of Morbus. I don’t know when or how I came up with the idea back in the day but I just love them so much.

    Grenades are kind of silly and a bit mixed in usefulness. The idea is that you could chuck it at a group of swarm aliens, or some aliens chasing you and it possibly take some out or buy you some time.

    Glowsticks

    We’ve got the standard 3 types of glowsticks, Normal (green), Sticky (Orange), and Anti-Grav (blue)

    You can also break them like in the original Morbus, but instead of it being by pressing E on them you either have to punch or shoot them (or swipe if you’re an alien.)

    There’s some cool little colored droplets that shoot out when you break them, and it leaves behind a little splatter of glow in the dark goo. This goo still emits a bit of light for a time being before the light fades away.

    Explosive Grenade

    The classic explosive grenade. I wanted to keep the “Look out!” voice line that plays when you toss a grenade. The original used Half Life 2 voice lines so we have some more modern ones now.

    The grenade also makes a scary little beeping noise so you know where it is, as well as a flashing light on it.

    Other Grenades?

    I was thinking that an incendiary grenade, like a molotov cocktail from Counter Strike, could be very helpful for humans. The particle effects for this are going to be a bit tougher so I’m holding off on it for now.

    A cryo grenade could also be cool. It freezes nearby victims and slows if you’re further away.

    Flashbangs and smoke grenades seem useless for humans to use, though a Brood Alien tossing a flashbang into a room and then transforming would be very cheeky, which makes me kind of love it so maybe we’ll see a flashbang get added.

    Other stuff

    I’ve been tweaking guns a bit more lately. I’ve added damage fall off as bullets travel. Most of them are are an ease out curve that looks like this:

    Within 15% of max range the bullet does full damage, then it slowly decreases. At 50% of max range it does 90% damage, but then rapidly starts to decrease, doing only 50% damage at 80% range.

    In most situations this won’t make a difference. In the chemical labs map shooting down pretty much the longest hallway with a pistol the bullets do ~80% damage and a rifle does 95%. Shotguns on the other hand are greatly nerfed at that range doing only 50% damage.

    There’s also accuracy penalties on movement now. Moving increases spread and recoil, jumping even more so, while crouching reduces spread and recoil.

    Spread will also bloom more when you’re moving, making moving and shooting very quickly lead to inaccurate shooting.

    What’s next

    We have a lot of the core mechanics in and we’re pretty much ready for our first playtest next week. I’ve started working on the “scoreboard” and hammering out any bugs I find with networking. I’ve added a little bot system so I can more easily test things like round and player states with fake players.

  • Inventory System

    It’s been a great week of development so far. I could’ve written a blog post earlier but I haven’t been taking my end of day breaks to write these like I was doing in prior weeks. Anyways, let’s dive in.

    The Past

    The original Morbus was a bit confusing when it came to inventory and weapon slots. You had 6 (?) slots and each slot was for a specific type of weapon.

    Slot 1 Crowbar
    Slot 2 Pistols
    Slot 3 SMG’s
    Slot 4 Rifles
    Slot 5 Utility items
    Slot 6 I think also utility items?

    There were a ton of different guns in Morbus so you’d run up to a gun, try to pick it up, and have zero feedback on why the SR-4 Phaser is actually an SMG and you already have a R22 Automatic Compact SMG in slot 3 so you should go pound sand.

    It also created weird restrictions where you would have to choose between carrying a grenade OR a medkit, and maybe you want both!

    I didn’t want any of this confusion in this iteration of Morbus.

    Requirements and Goals

    I had these principles guide me when designing and inventory system for this version of Morbus

    • Allow flexibility of loadouts
      • I want players to have variation in what they’re carrying around
    • Restrict the number of “big” weapons
      • Ideally a player should only be able to carry a single “big” gun
    • No arbitrary slot restrictions
      • If a slot is for a big gun, then why can’t I put a smaller gun in it?
    • Allow for multiple utility items
      • Grenades+Glowsticks+Medkit+XXX should be possible
    • Simple
      • Needs to be intuitive to learn
    • Strategy
      • Certain loadouts should enable certain strategies

    Where we ended up

    This is an experiment, it’s not final, and playtesting will reveal if it makes sense, BUT, I am pretty happy with things at the moment. Let’s start with a video before we dive into explain it.

    Let’s break down what’s happening;

    0:03 I pick up a pistol, we see me using my scroll wheel where it shows a weapon select where we can see my hands or the pistol

    0:07 I pick up an M4, we see my inventory flash for a moment to show where it ended up in my inventory. And then when I scroll we see a simpler version of just my weapons. Scroll then Left Mouse Button selects the weapon to select it.

    0:15 By pressing Q I open my Inventory Menu. I see 4 “slots”, with slot 1 having my hands, slot 2 having my pistol, then an empty slot 3 with 2 spaces in it, and a Slot 4.

    We can also see next to each Slot a few boxes. These boxes are a secondary representation of the “size” of a slot. We see that Slot 3 is Size 3 so it has 2 spaces in it.

    I drag my pistol from Slot 2 into a space in Slot 3 and then back into Slot 2.

    0:19 I pick up a glowstick and we see it was placed into Slot 3. I readjust my inventory and move both my Pistol and Glowstick into slot 3.

    0:24 I click 3 on my keyboard, which toggles between my Pistol and Glowstick since they are both in Slot 3.

    0:29 I reorganize my inventory so the Pistol is in Slot 2, Glowstick in Slot 3, and M4 in slot4.

    0:35 I walk up to a shotgun with my pistol drawn, I cannot pick it up since I don’t have slot space. When I take my shotgun out I see underneath the nametag “E SWAP” (Hold E to Swap)

    If I tap E it still says “No Slot Space” but if I hold E then i pick up the Shotgun and drop my M4 on the ground.

    0:46 I walk up to a MP5 on the ground. I pull out my glowstick in Slot 3. I then hold E to swap the glowstick out for the MP5.

    The MP5 is 2 sized weapon. We can see in my inventory that Slot 3 is now completely filled.

    0:55 I just continue to swap stuff and mess around with the system for awhile

    1:10 I have a glowstick from Slot 3 selected. Slot 3 is currently filled with two items (size of one) making it completely filled. When I approach an MP5 (size of two) I can hold E to swap.

    This swap will drop BOTH items in Slot 3, picking up the MP5 into Slot 3.

    1:15 You can drag items out of a slot in the inventory view to drop them

    1:23 This is I think the coolest thing ever; I open my inventory menu and then when I mouse over items in range it displays their name.

    I can then click down and drag those items from the world into my inventory slots.

    Why I like this

    I like to base game mechanics off of realism. If I pick up an item in a game, where does it go? Depending on how “realistic” a game is, it could just disappear from existence until you need it, to it goes into your backpack which has finite space and weighs you down.

    On the slider of “not real” to “very real” I want Morbus to be “plausibly real-ish.” I think a horror game is scarier if it’s a bit realistic. If it wasn’t realistic then why would it scare me? How can I relate this experience to my actual life and the danger my actual life would be in if I were in that situation? Or something like that.

    Anyways, this is a long way to say I was thinking one day about “In Morbus, where do weapons in your inventory go?” “Wouldn’t it be cool if they showed up physically in the world on your player model?”

    In Morbus, seeing someone run around with no weapons is big alien energy and could almost warrant an instant shoot on sight. If I were able to visually see another player’s inventory it could give me more evidence on why I should or shouldn’t trust them.

    Okay so if I want to put a players weapons on their character then there’s only so many places we can put weapons.

    Unless they’re Neo of course, then they can have like 50

    More realistically I think there are 3 prime places;

    Each thigh and the back.

    To gamify things we can say that one thigh can carry more than the other, and the back can carry the most (big gun) so this breaks down to 3 slots, each of a a different size.

    To keep things simple we say: Small (Thigh) / Medium (Thigh) / Large (Back). And if you get stuck up on the different sized thigh slots, perhaps there’s a perk or a class that gives two Medium sized thigh slots?

    This served as the foundation of this system. Give the player 3 slots, each of a different size; 1, 2, 3.

    Rifles and big guns would be of size 3 so they can only fit in the back slot.

    Pistols and utility items would be of size 1 so they can fit anywhere. If a player wanted a Pistol + Rifle they get 2 utility slots.

    Submachine gun like weapons are size 2. So if a player wanted to have one of those they could have 3 utility slots on their back if they wanted. Or they could have 2 different SMG’s and have 2 utility slots, or 3 if they don’t have a pistol.

    6 “slots” in total, with lots of different ways on how to fill them!

    The most confusing thing is the distinguishment from a “Slot” (Thigh, Other Thigh, Back) and the “Sub Slot”/”Size”/”Space” in each slot which distinguishes what and how much can go in it. I’m still working on terminology but I just call them Slots and Sub Slots right now.

    Right now ammo is free. You can pick up ammo of a type if you have a gun that uses it and there’s an arbitrary limit to how much ammo of each type you can carry. I’m debating whether this should change. Maybe ammo should take slots, maybe you get more slots then?

    Other ideas

    There are a lot of other inventory systems we could explore. This is going to be our “1.0” inventory system to try out. We can throw the whole thing out if it’s too confusing.

    A “simpler” system could be to do something like give the player a 6 slot grid inventory, then let them organize it and assign items onto hot bars. It’s very RPG like though so i’m not the biggest fan.

    Inventory systems like this are often times slow and cumbersome.

    DeadSpace also did something kind of like this, but you could have 4 weapons and then your inventory was just things like ammo

    Ammo management in DeadSpace was really stressful (and fun.) I’m torn on whether I make ammo a resource you have to carry around and takes up space. It makes inventory more complicated but allows for further expression of strategy for players.

    Weight

    Item weight (that causes your character to slow down) hasn’t been implemented yet. It might just be that weight is based on slot usage, or individual items could have different weight values.

    Conclusion

    I’m excited to see how this inventory system will land with players. I doubt this will be the final iteration of it but I’m excited to take this system into the first playtest.

  • A short week: HUD and Networking

    This week has been a short week of development due to some travel commitments but it’s a week with a lot to show!

    Let’s start with a demo;

    In this video we can see the HUD coming together, it’s very reminiscent of the original Morbus HUD.

    Ammo Counter

    As mentioned in the last blog post; we’ve got a “holographic panel” connected to the players weapon that shows ammo. This isn’t actually a HUD element in the traditional sense, it’s actually a “World Panel” which is UI rendered onto a plane in the world.

    I made the system to each weapon can define it’s own attachment point, and dimensions of this panel.

    We can see in this video that they’re all in a slightly different place. I’m not sure which looks best yet, so we’ll probably move them around as time goes on.

    Status Section

    This changed a bit from the original Morbus.

    Instead the 3 bars being; Battery, Health (and Name), Role, we’ve moved the name to the same role bar. I felt like the bottom bar was being under-utilized and there was no need for the role to be so big. I think this looks slicker.

    Without putting the HUD on an actual WorldPanel, which I didn’t want to do (even though i may need to) I tried to emulate the perspective/skew effect that the original Morbus had. It’s not perfect, but it’s okay enough for now.

    The HP bar is a bit smaller now too, but I made it so it would show the amount of health you’ve lost because you haven’t completed your need.

    This health can’t be healed by medkits, and is essentially a damage to your max health. I think I like this over just plain damage and having the additional warning in your HP bar telling you where this damage is coming from could be helpful to newer players.

    Punishing bad Broods

    I also had an epiphany on how to leverage this “need damage” to punish Brood Aliens who kill humans with guns. Right now Brood Aliens who shoot at humans with guns have no damage reduction on their gunshots. This makes removes the ability for a cheeky human to say “shoot me to prove you’re an alien” however, if a Brood Alien kills a human with a gun, they suffer Need damage.

    This need damage can only be healed by successfully killing humans in alien form. Thus the Brood Alien suffers a reduction in max HP as a penalty for killing a human with guns, though they can redeem themselves by infecting other humans.

    Thematically this makes sense to me. A Brood Alien desires to infect humans, if it kills them in a way they cannot spread the infection (guns,) this goes against their desires, and thus causes damage. Whether this damage is mental, psychological, or whatever is up to debate.

    The Top

    The rest is pretty much the same, we’ve got the need area, the timer, round state, and then notifications. All themed to match.

    We might expand upon these later, but they work so why fix what aint broke?

    Announcements

    We can send announcements to players about important things. This is used for things like victory messages or to tell Brood Aliens they’ve suffered need damage for killing a human with a gun.

    Alien Theme

    Aliens get a red themed HUD because they’re dangerous.

    Nametag sounds

    You might have to watch the demo video again to catch this one.

    I wanted to add subtle sound cues and effects with the name tags for items, players, and bodies. Just to add a bit more life to things.

    I’m not sure how I feel about them, they could still be a bit too loud and obnoxious so we’ll have to see how player feedback goes.

    Networking Reworks

    I’ve moved even more systems over to be host authoritative. At this point I don’t any core system is client managed. Health, Needs, and Alien Transformation were the last bits and now that they’ve been handled I think we’re doing good.

    I’m still very concerned about smoothness, I can test in the editor with a local instance faking 100ms lag, and it’s ~okay~ but I still wish it was better. S&Box just doesn’t give us great built in tools to handle these things for us.

    Bonus Content:

    This is a silly one but M0ji_l in Discord brought up the Morbus HUD evolution so I figured I’d highlight it here:

    June 2011

    We can call this the “wow I made my own HUD” era.

    I hardly knew how to program at this point, and I still sorta remember putting this HUD together. I thought doing the subtle “lighting” effect on the HP bars was so cool,.

    November 2011

    This is the HUD that people actually know if nowadays. I can trace it back as early as late 2011 which was a lot earlier than I thought it would be.

    This HUD was inspired a lot by the ammo counter, which I didn’t actually make myself but was an addon from garrysmod.org which I repurposed for Morbus. I had taken a class on programming, still knew hardly anything, but managed to hack together this HUD.

    What helped was I probably had a much clearer vision of what I wanted, which was holographic, Sci-fi, 3D, visor like.

    May 2026

    Which takes us to today.

    First Playtest

    Okay don’t sue me if this doesn’t happen, but i’m tentatively planning for our first playtest to be 6/8/2026, around 5-8pm Pacific Time.

    It’s going to be rough, but if you’re interested in trying it out I’d be overjoyed to have you play!

    Join the Morbus Discord server here for updates and information on the day of!

  • Guns, Ammo, and Nametags

    There’s been a lot of great progress over the last couple of days; let’s start with the video:

    Item Refactor

    I did a big refactor of the item system. I started thinking about how easy it would be to cheat with the client trusting model I was using. Cheaters make everything harder than it needs to be. So now the item system is host authoritative; only the host can create items and all the clients must request item creation which will be validated by the host based on the circumstance.

    Guns

    There are now 4 guns in the game, I think it’ll stay at this amount until I get real, thematically correct, gun models. Here’s what we have:

    USP – Pistol Archetype

    Classic pistol, light but lacking in power. These will be the most common gun.

    MP5 – SMG Archetype

    Fast firing but eats up ammo, light weight considering it’s fire power. It uses pistol ammo and will be more common than any other stronger gun.

    M4A1 – Rifle Archetype

    Powerful, the bench mark for all other weapons. Will be somewhat uncommon; not everyone will get one.

    SM4 – Shotgun Archetype

    A powerful shotgun, excellent at close range but lacking at distance. Will be just about as uncommon as the M4A1.

    Philosophy

    I want powerful guns to be a bit more scarce than in the original Morbus, but I also want all guns to have some purpose; even a pistol should be able to kill a brood alien (if you get lucky and the brood alien is bad.)

    Ammo

    Minor in the grand scheme of things but ammo now works as intended (reloading uses ammo in your inventory.) You are limited by how much ammo of each type you’re allowed to carry, and if you drop your last gun that uses a specific type of ammo, you drop all your ammo with it.

    Also we have a slick “in world” ammo counter.

    Nametags

    Items and players have nametags when you look at them. I’ve been playing around with how the effect works; you can see a bunch of iterations I made:

    I was considering leaving it as the White/Transparent styling, but the ammo counter is that holographic effect so it seemed like I should keep it consistent instead of mixing styles. We’ll see how it pans out later, this isn’t supposed to be the final HUD.

    So many little tweaks

    I swear whenever i sit down to work on something i’ll find something else that doesn’t quite feel right and needs to be tweaked. There’s lots of little things like repositioning the player flashlights, or creating a world and a view flashlight based on if it’s your own flashlight or someone else’s, or fiddling with the player eye position, that are so small and insignificant that they don’t deserve sections to themselves.

    I’ve also found ~5 bugs in S&Box in the past week which has been a bit annoying, but Github issues have been filed for all of them so hopefully they get sorted out. Whenever I find a bug I typically change my design and plans to not be impacted by the bug. It doesn’t feel great making something that isn’t right, and cannot be right for reasons out of my control.

    Playtest?

    My todo list is getting shorter until the next playtest, we need to finish the basic hud, add in dead bodies, a simple player list, voice chat, victory messages, and place some weapons.

    Then, in theory, we could do a simple playtest to see if any of this will hold together under pressure.

    The pace things are going is pretty good right now, if they keep up we’ll easily have our first playtest by the end of June.

  • What is winning?

    In this iteration of Morbus I want to explore humans having a victory condition besides just killing all the brood aliens or running out the clock. The original concept of humans running out the clock was that there was some sort of outside (human) party that arrives and they learn of the alien threat. The result would then be that all the aliens would be exterminated by some “off-screen” force, or maybe more sinisterly, all players (humans and aliens alike) are killed by this party because how can you tell who’s an alien and who’s a human?

    This means that the ultimate alien objective was to convert all humans, so that when the next group of humans is detected, they’re none the wiser that an alien is amongst them. If just one human remains, they could snitch on the aliens. Or if we take this one step further, the ultimate objective is survival.

    Meanwhile the human objective isn’t survival like running out the clock implies. Their objective is to alert the world that there are shapeshifting aliens and to not let them spread. Similar to the movie The Thing where the dude at the end of the movie destroys the research station to prevent the spread of the alien.

    I like this idea of “I know I can’t win, but I could prevent you from winning too” and I think it could be played around with.

    Self Destruct

    Most Morbus maps takes place in space, either a space station or a space ship. There are a few earth based maps or remote planet colony maps but it’s a usually small building/facility.

    What if the human team, when realizing that winning the game would be difficult, could decide to try and tie the game instead? A tie for the humans could mean “everyone died, humans and broods alike.” So how do we make this happen?

    Let’s say there’s a nuclear reactor on the map, and you can activate a reactor overload, or a self destruct sequence. There’s a 2 minute period of time where if the sequence isn’t stopped, boom, everyone dies and the game is tied.

    So how do you start this self destruct sequence?

    Obviously you wouldn’t want to make it something you could start any time. Someone could grief the game and just start it at the beginning of the game. This is something that’s supposed to be used only when all hope is lost. So how do you turn this “story” into a gameplay mechanic.

    A simple way is you add some basic check, if half the humans have been turned into aliens, then you can start the self destruct sequence. But then you get someone who camps the button and waits for it to activate and then presses it.

    Obviously you could cancel the countdown, but then it might become meta to always have someone waiting at the button. I’d rather this be a tool in the toolbox of the human players that’s used sometimes instead of a constant occurence.

    There could be “keys” hidden in the map. Perhaps you need 2 keys to be able to start the sequence, even cooler, you might need 2 people to turn both keys at the same time. The same could be said about deactivating the self destruct sequence. Maybe swarm aliens can’t turn the keys too?

    Now this requires humans to search through the map, or just stumble upon these keys. The requirement to have half the humans turned into alien also might become irrelevant because now it will take time for humans to actually find those keys.

    But how do we explain the “half the humans are turned alien?” Maybe the ship/station has some sort of global bioform scanner. It can detect the presence and quantity of aliens, but not the location. As more brood aliens are made the presence level goes up which unlocks the ability to self destruct.

    Is this really a tie though? As we discussed earlier the default Morbus victory condition for humans for was to run down the clock, which in a way implies that all humans died anyways. So maybe this isn’t a tie but just an alternative human victory, just a lesser one.

    Major Human Victory

    Killing all the aliens seems like a major human victory; It leaves no doubt in mind that humans are victorious. If running out the clock seems like a “sorta” victory and causing a self destruct is also a “sorta” victory, we should give humans a choice to just “win” (besides killing all the aliens.)

    I want to give humans more to do than satisfying their needs and pointing guns at suspicious people. A purpose to existence, a goal in life… i mean an overarching goal in a round.

    I think Among Us is cool because in that game the crewmen have random responsibilities around the ship to do. It’s like Morbus where they are forced to split up to accomplish tasks, however not accomplishing those tasks only delays victory, it directly doesn’t harm the actual player. The indirect harm is it gives more time for the traitors to kill other crewmen thus reducing their chance of winning.

    So in short, do your tasks, and if everyone does them, then you win.

    Zombie Panic Source was another cool game back in the day with a similar idea. Humans vs Zombies, and for humans to win they need to complete a set of tasks on a map and then they win (ie escape.) These tasks were shared across the whole team though, and like Morbus, it was an FPS.

    I think it would be really cool to give humans in Morbus a way to win by completing a set of team wide tasks. It’s adds to the “sandbox” dynamic of Morbus where every round is a different experience and plays out a bit differently.

    Objective Victories

    There are a couple types of objective victories I can think of

    Escape

    In this objective, one or more human escapes from the map, they live to tell the other humans of the alien threat. This is a loss for the aliens because they’re found out and assumably killed by off-screen humans.

    The steps for this type of victory could be;

    • Gather proof of alien existence
      • Perhaps a brood alien must be killed and a sample harvested from them
    • Repair an escape lifepod which was damaged before the round started
      • Run around the map finding materials and tools
      • Complete little minigames to conduct the repairs
    • Launch the lifepod

    Brood Aliens could possibly sabotage this victory

    • Put some sort of remote explosive device inside the lifepod
    • Shoot the lifepod down with some sort of ship turret
      • Within some timeframe after the lifepod is sent away
    • Be inside the lifepod instead of a human

    Alert the outside world

    This objective is similar in result as the previous one, but it doesn’t require a human to escape. In this scenario we should imagine that the communications to the outside world have been disabled for some reason, and the humans must repair them and use them to alert the outside (human) world of the alien threat.

    The steps for this victory could be:

    • Gather proof of alien existence
    • Repair the communications array
      • Gather materials and parts around the map
      • Complete minigames/tasks across the map
    • Transmit a warning message

    We could imagine that transmitting the message takes some time which leaves the brood aliens a chance to deactivate the transmission process.

    The Brood Aliens could also possibly sabotage the communications array again, thus delaying the humans.

    Alien Killing Virus

    This objective would see the humans winning in totality.

    Through “science” the humans could create some sort of alien killing virus or bacteria. This virus could either be a hand held weapon used by humans, that’s super powerful against aliens, and/or it’s administered across the whole map via HVAC system (or life support) which causes either an immediate or imminent human victory.

    The steps for this victory could be:

    • Gather alien samples
      • Presumably by killing brood (and/or swarm aliens)
    • Research/science mini games / timed tasks
      • Perhaps there are multiple labs across the map
      • You have to conduct research in all of them
    • Manufacture the virus
      • Once again some mini game or timed task
    • Disperse the virus
      • Take the virus to the Life Support hub which will disperse it across the map, thus killing all aliens

    Brood Aliens can interfere at multiple points along this path. What could be cool is after the virus is manufactured, the human is given a virus sprayer (spray bottle?) which does massive damage over time to aliens in close range. The aliens could have one last kamikaze rush to try and stop the humans before they get it to the life support system.

    Security System Activation

    Similar to the virus but instead the humans activate automated turret security guns across the map. Maybe this isn’t an instant victory but it almost assures a human victory.

    Minigames

    There’s been mention to minigames in this post. I like the idea of forcing players to do silly minigames in the middle of a stressful situation. I think the Helldivers franchise is amazing for this; you’re in the middle of a huge firefight, explosions, bombs, gun shots, and you have to do a stupid button click sequence perfectly or the landmine you’re defusing will blow up in your face and kill you. Absolute cinema.

    I could see the minigames in Morbus following a similar theme. Timed button clicks, sequential button clicks, dragging wires from one side of the screen to another. I’m really focused on clicking the button at the right time and oh my god was that an alien that just transformed next to me!?

    Summary

    I think there’s a lot of cool directions to explore victory conditions in Morbus. I would like to give human players more to do than just “survive and hunt.” These victory conditions could coexist with the timer victory, but perhaps the default time victory condition is longer, for instance 15 minutes.

    Lot’s of cool ideas. Right now we’re still really early in the development of Morbus. None of this stuff is critical to creating an enjoyable “core” experience for Morbus, but they’re longer term features that will flesh Morbus out and make it more dynamic and replayable, and help build out that “sandbox” i’ve been referring to.

  • Power & Lights

    In the original Morbus, maps often implemented a light switch or generator which would turn off some or all of the lights in the map. In this S&Box iteration I wanted there to be the tools for a lot more control over lights, or more importantly, what powers lights.

    This might mean more than a simple generator with an on/off switch. Perhaps there are relays or circuits which can be broken for specific parts of the map instead of the whole map. I wanted a flexible system that was also fairly simple.

    In this post we’ll be exploring what this system looks like from an architectural and technical perspective, followed by how this looks in game right now.

    Component Architecture

    Let’s first look at relations;

    Power Source

    A power source provides power.

    A power source could have a “parent” power source, if this is the case, the power source is more like a pipe instead of a generator of power; if the parent power source is off, then the child cannot provide power.

    The label is just a friendly name for us.

    The status is the power source itself, whether it’s on (powered) or off (unpowered.)

    The effective status takes into account the parent power source as well.

    Power Sink

    A power sink uses power provided by a power source.

    A power sink could have multiple sources, and it may need more than one source to be powered. If it has enough sources that are powered, then it too is powered.

    A backup sink just means it’s status is inverted. So if the power source is unpowered and we’re a backup sink, then we are powered (think emergency power or backup power.)

    This backup idea could’ve been implemented as a “backup power source” that gets activated when another power source is activated, but that would be more complicated I think.

    Power Area

    A power area is a representation of an area that a power source affects. Think of it as a big box, and any power sink inside of this box will be affected by the power source.

    This also acts as the sort of messenger between power sources and power sinks. I kind of imagine a power area as invisible wiring between a power source and a sink, so it makes sense to have it be the messenger.

    Power Switch

    Something needs to turn a power source on/off, this is that.

    Players can interact with it and press it, thus toggling a power source.

    Okay so what about lights?

    Lights would be considered a power sink, and I needed something that would translate a power sink changing status (powered <-> unpowered) to light components being enabled/disabled.

    I could’ve solved this translation as a separate component, but instead I decided to make it a derived component called LightFixture.

    Under the hood this LightFixture component will find any child Light components and then enable/disable them based on the power status.

    Cull Status?

    It seems like S&Box performance is greatly lacking when it comes to automatically culling lights and geometry that aren’t visible. This is very frustrating since you’d figure this would exist by now. To try to improve performance I built a system that would cull lights if I think they aren’t visible to the player.

    I accomplish this by setting up my map with these MapAreaBounds components, which are bounding boxes of specific rooms and sections of lights

    Then every frame I look to see where the player’s camera is aiming. I cast a trace along their aim and see if I will intercept one of these bounding boxes. No collision is used, but since I can figure that in this map the player will never see more than 5000 units in a direction (due to walls and doors) I only trace 5000 units ahead.

    If this trace intercepts a box, then I know that the lights in that area are necessary.

    You can see this system working in this video:

    I could’ve possibly used an angle based approach for this, and I might revisit this later. What I really hope is Facepunch builds something into the engine to handle this.

    Placement?

    Placing stuff manually in an environment kinda sucks. I want to click a button and have my ceiling light automatically placed on the ceiling, or have it placed on a wall a certain number of units from the ceiling.

    This placement section is just tools for me in the editor, I can click a button and it figures out the appropriate place to put the light. The models themselves are child objects so this is easy to do.

    You can see in this video I place a ceiling light, hit a button and it snaps to the ceiling.

    Or with the wall light it casts a series of traces to find the closest wall and then positions the light on the wall for me.

    Material Groups

    Light models also need to change material group based on their on/off status. Any decently created light model will have a material for the “on” state that has self illumination to make it look lit up.

    This i created as a separate component to test out the modularity of the system.

    I’ll have to see if making an uber derived component or a multiple smaller modular components that interact and respond via events is the better way to go in the long run. Though I suspect smaller modular components will be the best.

    The demo

    Okay you’ve survived the technical stuff, or maybe you skipped past it, let’s see how this all looks in game right now

    We can see I press a button, which causes the main lights to turn off and a red emergency light turns on. There’s a power down sound effect that comes from those white generators in the room.

    I’ve also tested all of this in a networked setting and it works. We’re one step closer to our first playtest!

  • Find what you Need

    Finding needs in the original Morbus was a pain in the ass. In this iteration of Morbus it can be better. It’s great that I actually know how to program and have 10+ more years of experience under my belt.

    S&Box has a nice NavMesh system built in, I can generate a NavMesh of the scene in the editor, then at runtime I can query it for a path between the player and the need location they need to go to.

    You can see in this video a simple debug path being rendered.

    And if we then make it so we shoot “particles” along the path with a trail, we can get an effect like this:

    These videos were taken a few days apart so you’ll notice some lighting in the map that gets added. The map is still WIP and i’ll post a more in-depth update on it later. You might recognize it as Chemical Labs from the original Morbus.

  • Health Systems and Infection

    Most video games have just a simple Health/Hitpoints system. You have 100 HP, you take 50 damage, some time goes on and then you heal 20, and now you have 70 HP.

    Some games then have armor, and how they handle armor varias from game to game

    • 2 Armor in some games means you take 2 less damage every time you get attacked
    • 2 Armor in some games means that you effectively have 112% of your normal max HP (each armor point increases health by 6%)

    Some games will have attacks that affect your maximum HP as well as your current HP.

    The other day I got a cool idea for Morbus.

    Health in Peak

    Peak is a game about climbing up a big mountain. You don’t actually have health in Peak but you have a stamina bar and when you climb you lose stamina. When you’re not climbing you regain stamina.

    You have to eat in Peak, and when you don’t your max stamina decreases. It also decreases when you fall and hurt yourself. All of this “stamina damage” is portrayed in an incredibly intuitive way.

    Your Energy Bar never changes size, instead it starts to be filled with these “damages.” And if your bar is ever completely full of damage, your character passes out (and then you probably die.)

    What this has to do with Morbus

    In Morbus humans sometimes have to accomplish “needs” which are silly things like eating, sleeping, showering, or using the bathroom. It doesn’t make any sense why you’ll need to do one or all of those things within a ten minute round but it’s a video game and there’s gameplay reasons why these exist.

    If a player doesn’t have a need, has a random need assigned every 3ish minutes, and they have 1-2 minutes to “satisfy/accomplish” this need before it becomes critical. They can only accomplish their needs in specific places so they might need to hustle to get to where they need to go.

    In classic Morbus, if the need every becomes critical (they haven’t accomplished it in time) then they start taking damage every second. This damage is inflicted directly to their health.

    Now what would be cool…

    In our new iteration of Morbus we use a similar health system as Peak, where the players HP bar is divided up between Actual Health and Damage. When a player’s need becomes critical they take Need Damage which effectively reduces their HP but the player can see what % of their health is lost to not completing their need.

    When a player goes an accomplishes their need all, or a portion of their Need Damage is removed, effectively restoring their HP.

    Instead of thinking about Health as a resource, we think about Health being the absence of damage.

    In classic Morbus completing a need restored 20-30% of your health, regardless of whether you had been shot at or if you had taken Need Damage. With this system, we’d only be removing damage you had taken from your need being critical.

    We can also introduce some interesting dynamics; Imagine a need normally takes 8 seconds to complete. If you have taken more than 20% need damage, then every 10% of need damage beyond 20% causes the need to take 1 second longer to complete. So there’s now an additional trade-off of delaying your need; it takes longer to accomplish.

    This gives us another lever to help balance humans and reward or punish them.

    Intuitiveness

    I remember watching some YouTuber’s play the original Morbus and when they were unfamiliar with the game they were confused by why they were taking damage for not completing a need. This could more easily show them why they are taking damage.

    Need Reducing Items

    The Morbus community added a “Pills” item to Morbus which would extend the amount of time you could wait until your need became critical. An interesting item which I think could be supplemented or replaced with an item that heals only Need Damage.

    Other Types of Damage

    When players are attacked normally they would take a “Wound” damage type now, which would be healed like normal by the Medkit.

    However we can explore the additon of additional damage types, whether they be permanant or temporary.

    Aliens having venomous attacks could be really cool. They could build over time and then decay, or just be inflicted in addition to a normal wound. This venom damage could then decay over time, or perhaps only be healed by an anti-venom (instead of a medkit.)

    Temporary damage, or certain types of damage, when they are inflicted and push the player into the “no remaining health” zone could also incapacitate a player, knocking them out but not killing them right away. Giving their allies a brief window of time to resuscitate them (by healing a type of damage.)

    I think these are all cool ideas that i’m excited to experiment with as development continues.

    Infection

    In the original Morbus when a human player is killed by a brood alien (while in alien form) the human comes back to life as a brood alien. I’ve always thought it would be cool for brood aliens to have a way to secretly infect players while in human form, or for an alien infection to grow within them and then result in their transformation into the brood alien side.

    A long time ago I played a game called Zombie Panic: Source which was a really cool mod about a bunch of humans working together to escape a scenario while they are killed and turned into zombies one at a time. It shared some similar mechanics with Morbus where based on the guns and equipment you carried your movement speed would change (heavy shotgun = you move slower.)

    Sometime that could happen in that game is if you were hit by a zombie attack then you had a chance to become infected. As a human you were unaware that you were infected for a period of time. Zombie players could tell you were infected and might even stop targeting you since they knew you were to soon join their side. After some period of time the game notified the infected human player that they were about to become a zombie. Giving the player a chance to get into a compromising position for their soon to be human enemies.

    It was a ton of fun being this infected human.

    In the original Morbus I implemented a “Brood Alien Resurgence” mechanic. It happened if there was only one starting brood alien and they were killed before they were able to infect any other human. My imagination behind this mechanic was that there was some covert infection of a human that finally converted a human as the last brood alien was killed. I don’t think a lot of players liked this mechanic because it was a bit confusing, and i think it could’ve been executed a bit better.

    In this latest iteration of Morbus I want to explore the idea of covert infection. I’m considering making a type of damage “Infection damage” which reduces health just like “wounds” or “needs” do. If a player dies while they have infection damage then they would become a brood alien.

    I’ve had ideas on how to play with this infection idea:

    • Infection below a certain threshold is benign and does nothing
      • Once infection hits a certain point, it starts to increase
    • Infection is hidden from the human player until it grows to a certain point, perhaps until the human has been infected fully
    • Infection can be revealed by medical scanning items or map features?
    • Beyond the initial brood aliens, a few players may have slowly growing infections
      • Could result in a natural resurgency mechanic
      • This has other gameplay implications though

    There are some things to iron out; for instance if infection damage is hidden from the player, then from their perspective they may die quicker than they expected, this could be frustrating.

    Infection damage could just be another stat, not communicated via HP bar.

    There could be a sort of “Infection Potential” which is actually inflicted, and slowly if the player has “Wound Damage” those wounds are replaced with actual “Infection” which does what we described earlier.

    It could create interesting dynamics if a human player knows they are infected, communicates it to their allies, and they work together to cure the human instead of killing them. I think having items to cure infection would be crucial for this dynamic to arise.

    The Sandbox

    When I realize how many ideas and mechanics that could be introduced to Morbus I get excited. I view Morbus as a kind of multiplayer social deduction horror sandbox. I think that all, some, or a varied subset of these mechanics could all exist and result in a fun experience. It might be annoying to play with all of them all the time, but I think making things modular and either randomly turning them on/off or allowing server owners to tweak them could create some cool experiences.

    Something you may thought about earlier is the concept of “some humans start the round with a hidden but growing infection.” In the original Morbus it would be kind of boring if a minute into the game you kill the one and only brood alien. Then you spend the next 3 minutes waiting around just to find out your buddy was infected and is now a brood alien too. I think in the current round framework of Morbus where the only human victory condition is to run out the timer (or kill all broods, which we’ve taken away with the hidden infection) this doesn’t work. Instead we need to introduce an alternative win condition for humans that involves completing tasks. This is something I want to explore later with Morbus but it’s still too early to address.