/ dev

Calamity (Game)

I spent the weekend just gone doing a mini game jam. A first for me. The project is one that has existed for a little while, the game was thought up by my lodger, Elysia (artist), and she enlisted help from Boomer (programmer) and Mikey (musician). This means that I've joined the project midway through its life. We decided to have the game jam to try get a chunk of the work done as progress had slowed a little. There were three of us at the jam (at my house), we were sans musician as he doesn't live locally. The three of us all work together so we decided to just start once Boomer had gone home and then walked up to mine, this gave me time to set up tables, power and get my computer moved. Once Boomer arrived we had a bit of a general faff and got some Domino's ordered before settling down to get shit done. The Game

Calamity is a multi-player survival style game. You play as a school kid in a school where strange things have been happening. The calamity is an event which causes monsters to come into existence. You spawn into the game with a few of your classmates (be it human or AI controlled) pre calamity and have a period of time before the calamity happens. What the calamity actually is still hasn't been decided. Post calamity all of the lights have gone out and there are suddenly monsters populating the school. For some reason these monsters want to kill you. The idea of the game is to be the last man standing, there are three rounds and if you die in one round then you come back as a monster in the next. Living players can kill each other and human monsters but the AI monsters are invincible, part of the skill is identifying which monsters are human and which are AI. At any point if there is only one player alive then they win the game, if the game lasts the full three rounds then everyone loses. There are, at time of writing, 3 pickup items in the game. 1 weapon and 2 helper items. The weapon is used to do your killing and is a knife, they're sparse in the game and have limited uses. There's a paper ball, which is a throwable item used to distract the AI monsters whilst you leg it away. The final item is the mandrake root, this makes the player invisible to the monsters for a short period of time. I think that it's a fun concept for a game which could be a lot of fun to play. Whilst simple in design there are actually a few layers to the gameplay and it could be quite tactical. You can team up in the knowledge that you'll have to betray each other later or you can just go it alone trying to kill everyone in whatever way you can think of. There's an element of Battle Royale in there. Toothy: Mandrake root: RainAI

My first task was to make Toothy (the main monster) behave correctly as he was a bit erratic. He should slowly patrol a set of waypoints until he sees a player at which point he should break into a run and give chase until the player is dead or until the player manages to lose him. At any point a player can throw a paper ball near Toothy and he'll be distracted by it. The distraction went through a few iterations but we decided that he should be distracted by the audio aspect of the ball rather than visual. If Toothy hears a ball hit the ground then he'll run to the source of the sound before returning to what he was doing, if he was chasing a player and the player is now out of range then he'll start patrolling again. The AI system that Boomer chose to use is called RainAI so I stuck with it. It took me a while to get my head into how it all works but, all in, it's a pretty good system that hugely reduces the amount of work required. There are several aspects to it, the main ones that I use are: Entity rig, AI rig, Way-point network, navigation mesh and the behaviour tree, as well as a hand full of custom scripts. The AI rig is a component that is applied to the game object that you want to be AI controlled. It's made up of: mind, memory, motor, animator, navigator, senses and add-ons. I won't touch on the add-ons or animator as I didn't touch those at all. Each of these properties comes with a basic controller, these are pretty good anyway. You can also write your own controllers, I just used the basic ones although I did write my own navigator which I wound up throwing away. The mind handles things like the behaviour tree, which is where you create all of your behaviours for your AI. Memory is like a global variable store for your AI, the variables are accessible from RAIN scripts and from the behaviour tree. The motor is what moves your AI, handles speed, rotates it etc... The navigator is responsible for how the AI will navigate waypoints and/or the navigation mesh. Finally, senses are how your AI detects other entities. The basic sensor has audio and visual sensors. You can set things like whether it should only use line of sight and which layers it should see, e.g. walls. The actual behaviour of the AI is controlled by the behaviour tree. This is something that can take a while to get your head wrapped around but is very effective once you do. It's difficult to explain but the tree is composed of nodes, and there are various node types such as waypoint patrolling, constraints, detection, custom actions, there are quite a few! You cobble these nodes together in a manner that gives your desired effects. Entity rig: this is what is applied to the things that you want your AI to interact with and detect. They can be audio or visual and are just applied to the game object (or a child thereof) of what you want to detect. They're really easy to set up. I'll probably write another post on RainAI as there were a few things that I struggled to find much information about. At some point on Saturday I managed to get the paper ball detection and patrolling working correctly. We had a basic avoidance custom action so I plugged that in too, it doesn't work quite right but it's OK for now. After I had Toothy working how we wanted it I started work on AI players. Again, I used a waypoint system to dictate where the player can move and created a custom action to let the player stop and hide until they detect a monster or another player. The avoidance script actually seems to work OK on the players too. I'm kind of tempted to give it some sort of artificial endocrine system but that might be a bit much for this! Waypoints: Behaviour tree: Whilst I was doing this stuff Boomer was working through getting other stuff done like making the menu systems, making the mandrake root effect work, sounds, level design. The man gets a lot done! Elysia churned out rad artwork all weekend and did work on level and UI design too. I feel like I've made light of the amount of work that they did there. We worked until 1am on Friday and Saturday nights and around 10pm on Sunday, was definitely a really fun weekend. It felt like we got quite a lot done and the game is becoming very playable. Boomer and I have decided that, going forward, he's going to work on the multi-player stuff, i.e. making it. I'll work on lighting and shading to try make things look shiny. There's a helluva lot for me to learn on that and I'm looking forward to expanding my knowledge about it all. So far I've managed to make a moon (with Elysia's help for the artwork and Unity pointers) which uses some emission for glow and a simple directional light with a low intensity. I'm planning on writing shaders to put in the windows to make moon rays shining into the buildings, that should be a challenge. I have a feeling that rays are probably a mix of some sort of refraction and dust. Given that this is aimed at webgl I'm not sure dust modeling is going to fly but i might be able to fake it somehow. I think that I'm starting to get my head round emissions now and, on Boomer's suggestion, plan on using them quite a lot rather than lights as lights are seemingly expensive. Lots to learn and lots to do. Level design of the first level: Level select: The moon: Glowy pentagram: A noticeboard, I'm not sure what that note is about:

Calamity (Game)
Share this