Today we’re launching ALPHA 5 of All Walls Must Fall: DAILY CHALLENGES! As well as the headline feature, this update has mostly been focused on polishing and balancing a few things about the game. For the full patch notes, click here.
A CHALLENGE A DAY…
The biggest new feature this time is a brand new game mode: Daily Challenges! Every day, we generate a new mission, the same for everybody across the world. It’s taken from our pool of regular campaign missions, but with a randomly generated loadout and difficulty level. You can only attempt it once, but if you succeed your score and time will be added to the day’s leaderboards – with an achievement for being in the top 10% on any day!
The inbetweengames team will be competing alongside you all as often as we can! Follow the inbetweengames twitch account[www.twitch.tv] to be notified when we stream our attempts!
ANIMATIONS AND SOUND
As part of the ongoing animation push, we’ve added new player animations for shooting and dashing, as well as improved the walk cycle and added poses for being in cover. There are also new sound effects for enemy weapons, as well as tweaks to the player weapon sounds, and extra sounds for UI feedback.
CAMPAIGN TWEAKS
The campaign has had some small adjustments for this update also, as we’ve heard from some of you that with the RPG elements update, the player could get a bit overpowered and make the campaign too easy in some situations. While things are still far from final, we’ve tweaked the health pool of enemies a bit, as well as their spawning patterns. There’s also a new Nemesis enemy type, though that’s very much still a work in progress – we want to add specific abilities for some of the enemies, which will hopefully come in a future update.
We’ve also adjusted the way missions unlock during the campaign. To make the initial experience a bit more consistent, now the first three missions of the campaign will be linked together, and the campaign map will only be unlocked after those three are completed.
WAIT, WHAT? WHO GAVE YOU ACCESS?
Thanks for everyone who’s been giving us feedback about dialogues! We’ve added more variety to some of the backroom dialogues to make them a bit less predictable and hopefully more understandable.
#ActuallyFree: THE MAMMOTH: A CAVE PAINTING ON STEAM
Have you played The Mammoth, our first project as inbetweengames? We made it back in 2015 as part of the Ludum Dare game jam, and it went so well we decided to go indie and make All Walls Must Fall as a result! Well, today we’ve released the game, for free, on Steam, and now with controller support and additional languages!
Today we’re launching the fourth update for All Walls Must Fall: RPG ELEMENTS! The focus for this name has been on adding progression and variety to your playthroughs by achievements and having more choices in the shop, with items that support different playstyles.
Will you focus more on improving your emotional manipulation to talk your way through, go in guns blazing and take as many enemies down as you can, or upgrade your time abilities and manipulate the timeline enough to make everybody’s head spin? Note that for the first time, a zero-casualty playthrough is now possible! Although it might take some time travelling to get there..
We’ve also improved the combat experience by adding more variety to the enemy types, as well as improving their AI behaviours and pathfinding. And for the completionists out there, we’ve added support for Steam Achievements and Trading Cards! For the full patch notes, click here.
Last but not least, we’re happy to be part of Steam’s Halloween sale – it’s 40% off until November 1st – and on itch.io too!
My Pheromones are Augmented
The shop has been augmented with a new AUGMENTATIONS category, where you can unlock and improve passive abilities for Kai, your character.
New feature: Weapon and Ability Upgrades
All weapons can now be upgraded up to 3 times, with each tier improving stats like damage, firing speed, and clip size. Time abilities can also be upgraded, to reduce their resource cost. Fully upgraded time abilities can unlock new strategies that involve using them for long durations!
Enemies with different weapon types
Enemies now also get four types of weapons: Pistol, SMG, Rifle or Shotgun.
Improved AI behaviours
AI can now crouch behind cover, and will often seek cover out instead of just running towards the player. Also, two AIs can no longer be in the same tile, and can handle walking around each other.
New Drop Rewards and Combos
We’ve added more rewards to awesome moves during the Drop, as well as a combo counter that feeds a multiplier for the total Drop Reward. The counter resets whenever you take damage.
New club room variations
We’ve added a number of new variations to some of the club rooms, including huge holes in the ground!
NPC Names
We’ve added names to the Enemies, Bartenders, Bouncers, Clubbers and DJs – including names from Kickstarter Backers!
Let us know what you think of the new features in the forums, or by using the GIVE FEEDBACK buttons in game (which now includes the option of sending a screenshot with your feedback!)
Steam Halloween Sale and merchandise!
As well as being part of the Halloween sale, we’ve also opened up a Teespring shop for merch if any of you missed getting add-ons during the campaign, you can once again get awesome goodies shipped to you – and still support the dev team!
To celebrate, in this post I’ll cover the custom procedural music mixer that our talented Audio Designer, Almut Schwacke, and myself have put together to play music in the game.
Berlin, 2089
All Walls Must Fall takes place in Berlin, in an alternate future where the Cold War never ended – and entirely in a sequence of Berlin nightclubs. We’ve put together a soundtrack to match, with a few tracks from Almut alongside a number from guest composers, who we’ve drawn from both the Berlin Techno scene of today and the world of Video Game composers. You can check out the full OST playlist here, but today I’ll be focusing on the latest track that we’ve put in the game, Synaesthetic by Ben Prunty (FTL, Darkside Detective, Into the Breach). This was part of the Drone Warfare stretch goal that we hit during our Kickstarter campaign. The soundtrack version of the track is awesome, but in-game the track will sound different every time you enter a club where it’s playing, as the music adapts and reacts to the gameplay and the progress of each mission. You can check out the track here, but read on to discover how it works in-game.
The Beat
All Walls Must Fall is a tactical game where every action happens on the beat of the music. We use a hybrid system for keeping track of time that’s similar to a simultaneous turn-based system: the game is paused while the player is deciding on their next course of action, and when the give a command, the game unpauses, the action is played, and then the game pauses again. Every action happens synchronised to the music, and different actions have different timings, so for example, the shotgun has a steady BOOM-BOOM of the double-barrel, whereas the SMG has a quick rat-tat-tat.
This all has to be tightly synchronised to the music, and the music itself must be able to play through the entire mission. To achieve this, as well as have the music dynamically adjust itself based on the gameplay, we decided to create a system that emulates the way a techno producer lays out a track in a sequencer, by separating tracks into loops and having the game tightly control which loop is playing at any one time. We do all this with Unreal’s native audio engine – no third-party plugins are used.
Loops
A “loop” (or “stem”) is a single sound file (essentially a wav) that represents one repeatable piece of music, normally played by a single instrument. In the case of Synaesthetic, the track is playing at 110bpm, and each loop is 8 bars long with a 4/4 time signature. Some examples:
The basic Kick Drum loop that underlays the track
One of the 2 variants of the the main melody
One of the 6 melody variants that the bells can play
This is one of the two variants of the high hat
This is the other variant of the high hat
The composer creates different loops, each one with a different instrument and with a number of variations. These are then delivered to us and are tagged with metadata, which the mixer uses to determine which ones should play at any one time. Synaesthetic has a total of 26 unique loops, spread over 11 instruments.
Mixes and Transitions
At any one time, each instrument can either be playing one of its loops, or no loop at all. A selection of loops is called a “mix”. The game begins a new mix by selecting a valid loop for each instrument in the track, and then choosing somewhat randomly for how long the mix should play – 8, 16, 24 or 32 bars being the valid mix durations for Synaesthetic.
We’ll cover what is and isn’t a “valid” loop later, but for now check out this example of the mixer cycling dynamically through 8-bar mixes.
You can see which loops are playing at any time, and when a mix comes to an end instruments crossfade between loops as necessary to switch between the different mix setups. Note that one bar before the new mix ends, a “transition” sound is played; this is a short wav that’s there to give some anticipation to the change, as well as smooth things over nicely.
An example of a transition
Gameplay States
That about covers the core concept of the mixer: crossfading between loops on the fly. But how does the game know which loops to choose at any one time? This brings us to our tagging system and how that interacts with the gameplay.
Each mission in All Walls Must Fall has the player infiltrate a nightclub with a secret agent, in order to achieve some objective, like recruit a potential informant or gather intel on a smuggling operation. As you explore and uncover the club, you’ll find yourself transitioning between different gameplay states. Each loop is tagged with compatible states, and only those that are tagged as for the current state can be played at any time. On top of that, we also increase an “intensity” value every time the player completes a sub-objective. Loops are also tagged with a range of intensities, and only play when the current intensity is within their range.
Paused/Unpaused
As mentioned above, the game switches between paused and unpaused when the player is interacting with it. When thinking about what to do, the game is paused; when an action is playing out, the game is unpaused, and everybody in the club all moves together. This is one of the key pieces of information that we want the music to convey to the player – if the game is currently paused, waiting for them to act, or not. Most (but not all) of the tracks represent this by adding some very noticeable percussive element when the game is unpaused.
In Synaesthetic, this is achieved simply by bringing in the Kick Drum. All other loops are tagged as being valid for both the paused and unpaused state, but the Kick loop is tagged as unpaused only. You can see (and hear) that in this video – when Kai, our player character, walks into the dancefloor, the state (on the left) changes to Unpaused, and a new kick loop comes in (on the right). When he pauses between moves, the kick goes away again.
Exploration and Combat
There are two main states the game can be in while the player is in a mission: Exploration and Combat. In exploration mode, you’re mostly walking through the club, chatting up bartenders and checking the place out. Everybody’s happy to see you. In Combat mode, however, you’ve been spotted by some people who don’t like your face, and it’s fight or flight time. The core gameplay mechanics of giving your agent orders and having the game paused while you make your decisions are shared between both modes, but we add some extra UI to the combat HUD to give you more tactical info in Combat mode.
For the music, these two modes are reflected through the tagging system. While the game can toggle between paused and unpaused very often, as the player gives orders, combat mode can last for quite some time, allowing the composer to create a different composition for this mode. We want to imply additional tension as the stakes are high: Kai may be a time-traveller, but he’s still very mortal.
Here, Kai has to hack into the club’s computer systems, but they’re guarded. The guard isn’t very impressed when Kai tries name-dropping Zoltan and pulls his weapon. As the combat transition sound plays and the UI changes, the supersaw and some percussion come into the mix.
The Drop (and Rewind)
In combat, you use the pause mechanic to plan out your strategy and take down your opponents. While you have the luxury of time manipulation, for everyone else on the ground, this intense firefight has only lasted a few seconds. Once you take out all your opponents, the game rewinds back to the beginning of the combat sequence and replays the whole thing in real time. This sequence is called The Drop; the music gets turned up to 11 and all the gunfire, shouts and explosions happen in time with the beat.
This is achieved with another two tags: Rewind and Drop. When the player is in control, that’s Planning mode, but once the combat ends, we do two things: first Rewind to the beginning of the combat sequence, and then replay through it in real-time, with the Drop tag applied. In Synaesthetic, some otherworldly glitch loops come in for the rewind, and finally, during the drop, we hear the key melody loop.
As you might guess, we’re inspired by the concept of a Drop from Electronic music, when a Break serves to build up tension and anticipation, before the bass comes in and the dancers go crazy. The Planning mode where the actual combat gameplay happens serves to create the tension, the quick Rewind is a thinning out of the track in anticipation, and the Replay is the Drop, with the most intense loops kicking in and the gunfire providing much of the beat.
Intensities
As mentioned, during the mission we increase an arbitrary intensity value at a few points, and new loops come in and out as we do. One of the key moments this happens is when first entering the club. Outside, the intensity level is only 1. When that door opens, we immediately push the intensity up to 2.
As the player goes through the mission and the intensity keeps rising, the music gets more complex with additional loops being added, both new instruments and more ‘intense’ variations of existing ones. By the time you’re at intensity 5 and making a mad dash back to the car, the music is at its most powerful and exciting. Each time the intensity increases, we play a transition designed specifically for the new intensity.
The transition used when entering intensity 2.
The transition used when entering intensity 5.
Tagging and Testing
Putting together the tagging for each track is quite a bit of work – we normally take an initial setup from the composer that gives us the information about what they intended for each mode and intensity, and then play through the game a few times to see how it feels, before making small tweaks and adjustments to get it just right. To help with that, we have a visual display of the mixer that allows us to play with all the settings in real-time to check out all the possible mixes that it can throw out.
It’s a system with a lot of moving parts, but without it we wouldn’t have been able to build the game we have. We’ve very grateful to all our composers for putting together such awesome tunes and working with us as we’ve ironed out the kinks in the system! Check out the game – and the Original Soundtrack – on Steam when it enters Early Access on August 8th.
All Walls Must Fall is a Tech-Noir Tactics game. We have a thing for classic tactics games, and we’ve drawn a lot of inspiration from classics like X-Com, Fallout and Syndicate. We’ve created a tactical gameplay system that also mixes in time travel. This is one of the key fundamentals of the game and we’re happy with how it works, so in this post, I’m going to give an introduction to this aspect of the core gameplay – but if you need a general introduction to the game, check out our Kickstarter campaign first.
Pausable Real-Time Tactical Actions
Time is at the core of All Walls Must Fall, and everything happens on the beat. However, as the game is played in pausable real-time, you the player don’t actually do things on the beat – this isn’t a rhythm game. As a tactics game, you need to choose the best course of action, and so the game is paused while you’re planning what to do. Once you select an action, the game unpauses, the action is carried out, and the game pauses again. To external observers, your agents appear to have incredible reflexes and decision making, but as time-travellers, they’re actually aware of this pausing of the clock.
Everything your agents can do is an action. Movement, shooting, opening doors, talking: all are actions. Each action has a duration, which is measured in beats of the music. Walking allows you to move one tile per beat, so an 8-tile move would take 8 beats. Agents can also dash, to double their speed while spending some resources, so the same move would only take 4 beats. Some actions are longer than others (like reloading), and while your agents are performing their actions, enemies, other NPCs, and the environment are all doing their thing at the same time. You can think of each beat as being like a turn, and all characters in the game take their simultaneous turns together.
Combat and Tactical Mode
So Kai’s just hanging in the club, looking for a quiet place to chill and totally not trying to find the owner’s secret warez stash or anything, and these goons get the wrong idea and think he’s busting into their private ‘meeting’. They pull their side arms and point them at his face. Now you’re in tactical mode. All the rules stay the same, but there are a few changes to the controls, with the biggest one being that now you confirm actions before they happen. This allows you to preview what you’re about to do, before you do it.
Kai managed to get a pistol past the weapon detector at the club entrance (he and the Bouncer go way back). The equipped pistol has two actions available: a quick tap to the body, or an aimed shot to the head. All weapons offer two different actions when equipped, meaning choosing your kit before heading into a mission changes what approaches are available in each situation.
The tap is fast, taking only half a beat, and stuns the target for 3 beats. However, it only does half a point of damage. That means it’ll take 6 taps to take down one target, emptying the pistol in the process.
Double-Tap, Headshot
That’s one down, but as we were busy shooting his buddy managed to get a shot in, and Kai lost one health, plus the pistol’s empty. Right now, your agents have 3 health, and the only way to regain health is to use your time abilities – there are no magic health packs that cure gunshots in All Walls Must Fall. We want combat to be tense, so losing even one health point can be a problem. Kai should be able to handle these two and come away unscathed: he’s a time traveller after all. So let’s use the Undo ability to go back in time to after Kai took the second shot. Using time abilities costs time points, which we show in the bottom-right. If your agent dies, you have the opportunity to undo that death – as long as you have time points. If not, it’s mission failed.
With one enemy stunned for a few beats, he’s not a danger at the moment. But his buddy has already taken a shot, and we know from our previous timeline that it will hit Kai in two beats. That gives us a window of opportunity: Kai can double-tap this second guard in one beat, at which point they’re both stunned. With one beat remaining before taking damage, a quick Dash move to the side gets Kai out of the bullet’s path. Following up with two aimed headshots, Kai’s the last man standing.
Drop the Beat!
That concludes this combat. The game now plays The Drop, a sequence where the entire combat plays out in real-time from beginning to end. As everything happens on the beat, this creates a synaesthetic effect, where the sounds of your actions become part of the music. In this case, the double-tap-aimed combo creates a rhythmic element that becomes part of the percussion. This also gives us the opportunity to show you what “really” happened, from the perspective of the world around you. In the player’s timeline, there was the first attempt which got undone: nobody else in this timeline was aware of that though, and it’s not in the drop. For the Undo ability, this is pretty straightforward, but for some of our more advanced time abilities, it can get pretty mind-bending.
It seems these guys weren’t really relevant to the mission after all. Kai would rather just undo the whole combat and leave them be. Of course, he remembers what didn’t happen, and the fog-of-war in that room is still removed for you.
How we got here, and what’s next for Tactical Combat
Back when we were in pre-production in late 2015, we went through quite a few iterations of our core combat mechanics, with things like manual pausing, different rules when in tactical mode, as well as more experimental ideas like having each musical bar play out separately, or having the game constantly loop a few beats that you edit on the fly. We’ve been happy with our core mechanics for a while now, and what I’m presenting here will be unlikely to see drastic changes as we head into Closed Alpha. The UI is still a work in progress though: right now the health of the enemies is displayed on the circles under their feet, and we’ll probably move over to a more traditional display with bars above them instead. The confirmation button is a relatively new addition that went in after we got playtest feedback in the last couple of months, and that will be reworked to display information more cleanly with some of Rafal’s lovely icons. We also have an extended cover system planned and funded, as it was part of our Kickstarter campaign‘s first Stretch Goal, VANDALISM:
This scenario was one of the simplest you’ll come up against in All Walls Must Fall. In an upcoming post, I’ll be covering advanced time travel abilities like the Rewind and Trace-Back, as well as how to predict the future.
We’ve been in full-time development on the game since April 2016, and have been running a pre-alpha for friends and family for a few months. We now think it’s time to open that up to a wider audience. A game like this needs feedback from the community to really become something special. That’s why we’ve decided to start a closed alpha, exclusively for Kickstarter backers, that will begin in May this year if we reach our funding goal.
We’ve spoken to a few publishers to help get the game to the finish line, but none of these talks went anywhere. Most publishers think of the game as too niche, too hardcore, too complex, too old school, or too political to make the kind of profit they expect. The is why we have come to Kickstarter, we are not in this for profit. We are in this to make the kind of game we believe in, the kind of game that you don’t see that often. However, it’s also the kind of game that could potentially resonate with a group of people looking for something a little different, in a genre that has a lot of potential for unique gameplay ideas.
All Walls Must Fall is an ambitious game. While we already have a basic version of the game, there is so much more we want to do with it! We are certain we will be able to ship it in some form already. But to make it what it truly can be and deserves to be, we will need you help!
Hello, I’m Isaac, the programmer at inbetweengames, and in this post I’m going to outline the algorithm we’ve developed for creating levels in our game All Walls Must Fall.
All Walls Must Fall takes place primarily in the nightclubs of Berlin. One campaign takes place over a single night in the city, and will see you visit multiple clubs to carry out your missions. Each venue is procedurally generated to be unique for each playthrough. We call the system that creates these levels the DiscoGenerator (Disco here being short for Discotheque, the venue, rather than Disco, the musical genre…).
Above you can see how a few layouts currently look in-engine. Of course, it’s still early days for our project, and this is a somewhat rough version of the algorithm. It’s very much subject to change as we continue development, but I’ve had some requests for detail regarding how it works, so here we go!
Design Goals
Guiding the design of the generator is, of course, the design of the game in general. We have to take into account both the spaces we want to create themselves, but also how we want our toolchain to work for authoring content. As a small team, we want to be able to reuse assets as much as possible while still creating spaces that feel different each time you play. As such, we have a number of high-level requirements:
Clubs must be relatable spaces that are recognisable as real places – for example, they must have a front entrance, which connects to a lobby, which connects to the rest of the club.
Clubs are composed of rooms. These rooms are custom-authored by a level designer, as individual levels in the engine. The generator doesn’t deal with actually loading the levels, only about creating the map of how these should slot together, with doors and walls in between.
Rooms can be either public or private. Public rooms must all connect together, and must be reachable from the public entrance.
Clubs exist in a square or rectangular space, and must fully fill that space with rooms. The space is split up into a grid of ‘cells’, within which rooms must fit.
Unreal Engine Integration
Before getting into the details of the DiscoGenerator’s algorithm itself, I’d like to describe how it fits into the engine we’re using, UE4. The generator is an independent plugin, with no dependency on our gameplay code. It consists of a runtime component, which is used by the game to generate level layouts, and an editor component, which allows us to visualise the levels generated in the editor itself. The gifs in this post are taken from this editor component, which you can see in all its glory here:
Algorithm Overview
The general approach that I’ve taken is to treat the generator as a packing problem, whereby a finite space must be fully filled with as much stuff as possible, such as filling a truck full of furniture. In our case, the space is the area that the club should take up, and the stuff is the rooms that go inside.
However, it’s not an optimization problem: the task isn’t to find the most efficient way to put our stuff in the space. Instead, we have a few constraints that we want to be fulfilled, such as ensuring that certain types of rooms are present in the club, and that they can be reached from the entrance. Otherwise, we want to use randomization where appropriate to generate as many valid clubs as possible.
The underlying approach is a greedy algorithm. This is an algorithm that chooses whatever appears to be the ‘best’ decision at each stage, without regard for consequences later on – hence greedy. We start with an empty club of a defined size, and each iteration of the algorithm involves making a decision about what to add to the club – a room here, or a door there. A valid solution is determined by ensuring a club has the required number of rooms, and that they have their own adjacency requirements met – it’s not about ensuring the space is being filled efficiently. In our case, clubs have a finite space, so we prioritise larger rooms over smaller ones, and rooms with more requirements over those with fewer, so that we fulfill the requirements as early as possible.
Traditionally, a greedy algorithm implements a scoring function, which assigns value to solutions and is used to decide which choice is the ‘greediest’ in each iteration. In our case, we don’t explicitly implement such a function, but instead implicitly define it by simply sorting rooms before adding them, to prioritise those that have more requirements (to minimise the number of unfulfilled requirements) and are larger (to minimise empty remaining space).
0. Selecting Rooms
Before the algorithm starts placing things in the club, it must first choose what rooms the club should contain. Each club definition (created by a level designer) has a set of required rooms, as well as a number of optional rooms. Each room has a type, such as bathroom, dancefloor, or bar, and a set of possible sizes. The generator randomly selects which rooms the club wants to contain, and the desired size for each of the rooms.
1. Placing Entrance Rooms
The first rooms that are placed in the club are Entrance Rooms – that is, they contain a door to the space outside the club. These are pretty important – without them, there’s no way to get inside. Right now, we have two types of entrances: public and private (such as a back- or side-entrance).
We start with the biggest, and gather all the valid locations we could place the room. In this case, those are around the perimeter of the club. We then simply pick one of these at random.
Whenever a room is placed, there is generally at least one requirement that must be fulfilled regarding what the room is adjacent to. As well as placing the room in the correct spot, a door must be placed between the two areas. In this case, the requirement is that it must be adjacent to the external area, so a door is placed there.
Rooms can have the requirement that they are adjacent to a specific other room. In our case, the Lobby must always be adjacent to the Front Entrance. In keeping with the Greedy approach, we want to maximise the fulfilled requirements at each iteration, so as soon as a room is placed upon which another room depends, the dependant room (in this case the Lobby) is inserted. This means that the order of placement is first Front Entrance, then Lobby, then Side Entrance.
2. Placing Chosen Rooms
Once we have valid entrances, we can get on with the meat of the generator, which involves placing all the other rooms that we chose in the first step. Before placing the rooms, they are sorted as follows:
Public rooms are to be placed first, then private rooms
The largest rooms are placed before smaller ones
As public rooms have the requirement that they are adjacent to other public rooms, and large rooms have the implicit requirement that they need more space, this greedy approach minimises the chance of an invalid club being generated: if there’s only one spot where a large room will fit, we don’t want to place smaller rooms there first. Similarly, we don’t want to place private rooms in places that will prevent public rooms from being connected together.
3. Placing Filler Rooms
At this point the club requirements should be met. All the rooms that were chosen have been placed, and we should have a working club level. It is possible that some required rooms couldn’t be placed, in which case the club is not valid. In this case we simply increment the seed (the number used to initialize the Random Number Generator), and try again.
If all the required rooms were placed, however, there are still empty spaces in the club. To fill up this space, we have a special “filler” room type, which has no requirements and can be placed anywhere. The generator simply places these whereever they will fit, until they can fit no more.
4. Placing Corridor Rooms
Finally, there may be some spaces remaining that are too small for real rooms. We take the same approach as with the Filler rooms here, but instead with special ‘corridor’ rooms that are only a single cell wide.
5. Placing Doors
Now all the rooms have been placed, along with doors that were needed to fulfill room requirements. However, extra doors may be placed to give the club alternate pathways. Each room type has a minimum and maximum number of doors which it can support. We simply add doors to rooms until we fulfill at least the minimum number of doors, and randomly add extra doors to those rooms which support more.
6. Placing Outside Rooms
Outside “rooms” are not really rooms, but are ways of adding some context to the entrance by placing some objects outside the club in sensible locations, such as a queue of people waiting to get in, or a couple of bouncers. As far as the DiscoGenerator is concerned, they are simply rooms that must be placed outside and adjacent to an entrance. These are placed last.
7. Choosing Levels
The club is now complete. We now connect the generated layout to levels that have been authored in the Unreal Engine. Each room placed so far has a type and a size, and there may be multiple room levels that support this layout. For each room, we simply choose one level at random from the pool of supporting levels.
Disco!
The job of the DiscoGenerator is now complete: we have a finished club layout. Now it’s the job of another system to actually spawn the club and make it playable. How we do that is a topic for another time, but for now here’s a video of this loading happening. Note some of the rooms are empty – those are the (private) backrooms which we haven’t yet authored.
So that’s the basic algorithm we have so far! Of course, it’s very much subject to change as we get further into development. For now though, it has really helped us as it allows us to playtest the game with an unexpected experience every time, even as developers. going from a hand-made level to one where we didn’t know exactly where the objectives are was a great moment!
Let me know if you have any questions (or suggestions) on Twitter or in the comments. Also follow the inbetweengames team for more updates on the game, on Twitter, Facebook, and sign up to our newsletter! Being able to work without any NDAs is awesome and we’ll be posting more updates about our progress soon!
So after our entry last Jam, The Mammoth: A Cave Painting(17th overall, 6th mood), we decided this time around to go for the fun and humour categories. The Mammoth was a little bit on the sad side and we opted out of the humour category completely then. This time around we focused on the gameplay and tried to make it a light-hearted celebration of a certain aesthetic. Let us know what you think by rating OSHIYA! PUSH!
We re-used the crowd AI framework that was used to power the hunters in The Mammoth for the passengers in this game, and also pulled in a rhythm framework that we’ve created for another project. Everything else we did from scratch in the 3 days of the jam using Unreal Engine 4, with a team of 4 full-time developers plus our friend Almut Schwacke, who provided the audio. Check out this timelapse of development from Isaac Ashdown, showing c++ coding and Blueprint and UMG scripting:
We’re starting to get into open development – the NDAs of AAA are a hard habit to break, but we’re trying – The Mammoth already available as an open source project if anyone’s interested in the codebase. Feel free to pass on any development questions you have to @eyesiah or @inbetweengames!
We’re proud to announce that we are going indie! Wooohoo!
inbetweengames are three former AAA developers who worked together at YAGER in Berlin on Dead Island 2. When that game got cancelled, we started thinking about what we wanted to do next. Turns out we wanted to keep making video games! So now we’re happy to announce that we’ll keep doing that as an indie team!
To celebrate, we’ve released our Ludum Dare 33 game, The Mammoth: A Cave Painting, on iOS and Android! You can play it here!
Follow us on on Twitter and Facebook to see what we’re up to. If you’re into these kind of things you can also check out our Presskit.
Here’s who we are and also a little interview:
Isaac Ashdown
aka Disruptive Technology – 1st Horseman of Indiepocalypse Isaac Ashdown is the best gameplay programmer you’ve never met. With over 7 years in the industry including at YAGER and Zeroscale he worked on a myriad of games including Demolition Inc. and Dead Island 2. He’s also very excited to be finally responsibile for his own failures: no more blaming it on the publisher! Even though according to credible industry source KPOPSTARZ he was ‘Deep Silver Boss’ all along!
Jan David Hassel
aka Low Barrier of Entry – 2nd Horseman of Indiepocalypse
David was raised on German medieval festivals before being adopted by YAGER for 8 years where he helped develop Spec Ops: The Line, an undisclosed project and lastly Dead Island 2 as Staff Designer. In his spare time David enjoys talking to imaginary characters and his cat while hitting people with swords and wearing silly costumes.
Rafal Fedro
aka Lack of Differentiation – 3rd Horseman of Indiepocalypse Stemming from a dynasty of classical artists in communist Poland, from an early age Rafal had nothing but crayons and tons of art supplies to play with. This gave birth to the 15 years industry veteran we now know (or in your case: don’t) who in his free time likes to obsess about art a lot.
What is this, are you guys interviewing yourself?!
Isaac: Someone’s gotta do it.
Rafal: I treat it more like the FAQ. Sometimes it’s good to stop for a while, question yourself, look at yourself from afar to establish who you are and what you do want to achieve.
David: We are doing a lot of prototypes right now for Art, Design, Tech, etc. in a way this is one of them.
Who are you guys anyway?
Isaac: I’m mostly a gameplay coder. That’s what I’ve done most of my time in the industry. But like all gameplay coders, I’m really just a game designer who can actually get shit done.
Rafal: We are three game developers with quite some years of professional experience. Maybe tiny bit tired of bigger, “AAA” projects. The game designer, the coder and the artist. I frankly couldn’t imagine working with better coder or designer than these two guys.
David: These two guys happen to be a dream team of everyone I worked with over 8 years condensed down to the minimal team size that makes sense for us. For some reason they decided it would be OK for me to join too. I guess I fill up the middle of whatever isn’t covered by them. Overall we’re covering the major disciplines of tech, art and design with 30 years of combined experience in professional game development. We’re also all out of gum.
So you guys are going indie, why should anybody care?
Isaac: Well if you like playing video games, you might be interested in the video game we already released The Mammoth: A Cave Painting. If you like that you might want to play our next game, which will happen in the future.
Rafal: Also we’re going indie but we’re not doing pixel art nor puzzle platformers.
David: We’re doing this after getting repeatedly cancelled for what.. the last four years? So while we have Spec Ops: The Line under our belt we still feel like we have something to prove. We want to make games and give them to you. That’s what we’re here for. That didn’t really work out in AAA the last couple of years for us. So we will have a go at this indie thing and don’t hold back intending to punch above our weight class as hard as we can. It will either work out or it will go up in flames. But it will be fun. You should watch.
Rafal: We decided to go indie to take responsibility for our potential success or failure in our own hands. You are kindly invited to witness that, to join our journey. Either we fail or succeed – it will be rather spectacular.
Going indie in the times of #indiepocalypse: you think that’s a good idea?
Isaac: A few weeks back when we were putting this thing together there was a tweet from Jonathan Blow about how if you’re thinking of quitting AAA to go indie you’re 3-4 years too late. But I’ve been doing this for other people for 8 years and have lost my job 4 times. Can indie be any worse than that? What’s the alternative, go work for a bank?
Rafal: As fun as it is to create video games – we also have serious approach to it. Our past experience in AAA development taught us that. It’s the work we love and we would like it to pay our bills also.
David: People are I think wondering about the fact that you may be can’t be an amateur indie developer and make money quiet as comfortably anymore. So you either have to take this seriously and try to set it up as a business or just accept that it is going to be your hobby which will not pay all your bills. But we’re not here to do this as a hobby. This is what we do.
Wait, weren’t you four people last time I checked?
Isaac: Our team member Daniel is staying with YAGER and has joined the Dreadnought team. So has our friend Bairbre who was The Mammoth’s narrator. You can actually recognise her voice from the Dreadnought trailer, and she’s joined that team too. We hope we’ll manage without them!
Rafal: Daniel, our Fourth Horseman of the Indiepocalypse, decided to stay with our former employer, YAGER. He wants to ship a big game so that decision is understandable. He is among the best game designers Yager currently has and I am pretty sure he will be an amazing addition to the Dreadnought team.
David: He’s going to kick metric fraktons of ass on Dreadnought. You should watch that too.
So you guys didn’t ship anything since Spec Ops? What happened?
David: Follow the money.
Isaac: I didn’t actually work on Spec Ops, for the record. I joined YAGER when Dead Island 2 was going into production. But yeah I haven’t shipped anything in a while either.
Rafal: We “shipped” The Mammoth! But seriously – we went through bunch of prototypes and two cancelled projects. I also worked on the prototype for Dreadnought. I am not sure what exactly happened with Dead Island 2 cancellation – I guess that’s the question you should ask Deep Silver and YAGER respectively. For us the good side of what has happened is that we probably would never have thought of going indie and doing something together if Dead Island 2 wouldn’t be cancelled. And here we are.
What’s up with the name inbetweengames and the logo?
Isaac: The name started off as a pun on being in between jobs and stuck. The Ludum Dare was just a week before we were all made redundant but we knew it was coming and it was rather on our mind at the time. Mammoths are cool.
Rafal: We came up with the name before Ludum Dare 33 and it stuck. We were in between projects then after we learned that Dead Island 2 was cancelled. Also the three of us are always in between games: either playing them or creating them.
The logo was a little bit of the struggle. We spent quite significant amount of time, went through 100+ ideas from more figurative to more abstract ones. It’s hard to be satisfied with whatever you come up with if you are emotionally attached to something like our endeavor.
The mammoth, we call him Rupert now, is the character from our first project together – so we thought using it as the reminder how it all started would be cool. When you put it on the tightrope you get interesting contrast – something heavy, yet in the air, balancing between the two safe places of the beginning and the end of the tightrope. We also wanted it to be easily verbally described: “you know, those guys with the pink mammoth on the tightrope”.
David: There are a lot of different layers to the meaning of the logo by now. I guess we might have been overthinking it. But that’s ok because I expect us to keep on doing that. We also presented 8 different options for our logo on Twitter and Facebook to see what people’s reactions would be. I also expect us to keep on doing that.
The Mammoth game and Ubisoft?
Rafal: Haha… straight coincidence! I was really surprised when I’ve seen announcement trailer. We have this running joke that we are the “trend-setters”, but of course that’s not true. To be able to ship it in 2016 – they must have been working on it for at least 1 year now. It’s an interesting direction Ubisoft is taking for Far Cry series. I am really curious about the story, narration and dialogues. i.e. will the characters speak English?
David: We were joking with some artist friends of our about making a AAA version of the Mammoth were you would play stick figures on a realistically lit cave wall. But it seems like Ubisoft has that covered now so I guess we can move on now.
David: It’s also going to be touring through France on its own Arcade machine soon! Not the most reachable option from where you are now perhaps but we’re still pretty excited about that one.
What engine are you using? Unity right? Unity is so great! Everybody loves Unity!
Rafal: Everybody does! At least majority of indie developers are using Unity… But for now we are sticking to something three of us knows pretty well – Unreal Engine 4. We have combined around 20 years of experience working with Unreal. We only have heard great things about Unity and how easy it is to build prototypes with it. Maybe we will give it a go at some point.
Isaac: We’ve been using Unreal Engine 4 since before it was publicly released. My first thought when Epic announced the public release was, indie here we come. Frankly, it’s just so great for rapid iteration, that’s my main reason to use it.
David: Yeah we are sticking with what we know. Hopefully this will also help to distinguish our games and keep them visually interesting.
What about VR and AR? That’s the future right? Why aren’t you doing that?
Isaac: We don’t have any experience in it at all. Generally it’s good to stick to your strengths.
Rafal: I am very curious about these technologies but we are only three guys and we would have to spend all our resources on research itself. Maybe it is the future and it could happen that in the future it will be our future also.
David: People are really excited about VR and AR right now. But it seems to me that this is mostly an idea in people’s head. Sure there is prototypes, great tech, demos and lots of marketing hype but it’s not like you walk into any subway in the world and see people playing AR games there or in their homes. The reality is that people are playing games on PCs, consoles and mobile. So we will have to see what the future really becomes. We just want to make games now that people can actually play already and the real future is time travel anyway.
What kind of games do you want to make?
Isaac: Ones I’ve never made before.
Rafal: The ones which our small team size allows us to pull off properly. It’s probably easier to say what kind of games we will rather stay away from: first person shooters, MMOs, racing simulators, puzzle platformers, etc. We want to explore various art styles like stylized 2d or vector art rather than realistic 3d or pixel art. We want to dig out and explore different gameplay mechanics and mix them up.
David: I hope we’ll make games that choose which conventions they follow and which they break for a purpose and that this purpose will be the experience of the player. Also even though we’re going to make a game we can do with a small team in not a lot of time it’s not going to be a puzzle platformer. People seem to have those covered well enough and personally I suck at platformers so that probably wouldn’t work anyway.
So what’s your next project then?
Isaac: Good question! If only I knew…
Rafal: Ask David…
David: We’re working on it! Currently we are making a lot of prototypes and are exploring different approaches to it. We have a general idea that we think could be fun and interesting. However you never know with those things so if it turns out that our assumptions are wrong or we find something more interesting along the way we will change direction and go with something else instead. But we will drop whatever we can share as soon as we can.
When can we see something of that upcoming super secret project?
Isaac: Well one thing that’s really exciting about working independently is that we can be totally open about what we’re doing! So once we’ve got something we want to show, we won’t have to wait for any publisher to tell us it’s ok. So hopefully pretty soon!
David: We have given ourselves the rest of the year to explore those ideas we currently have and then hopefully can really show something off the beginning of next year. Until then you should follow our Twitter and Facebook to see what we’re up to. As soon as we have any bits to show we will do so there and we will also ask people’s opinions a lot like we did for deciding on our logo.
Want to watch 3 days of coding in 10 minutes? Here’s a timelapse video of inbetweengames’ Isaac Ashdown writing the gameplay and UI code for The Mammoth in Unreal Engine 4:
All of the team currently work at YAGER in their day jobs, where we’ve been using UE4 for several years on a AAA project that was recently cancelled. We thought it would be interesting to see what we could pull off in the engine in just 3 days, which for us is a pretty big change of pace compared to our normal way of working. We’re really happy with how it turned out!
We created the entire game, including the concept, in the 3 days of the jam. Beforehand we did some prep for some of the systems we knew we’d need for the game we wanted to create: a custom 2D flipbook material that allows us to animate sprites similar to Paper2D while giving us the full functionality of Unreal’s material editor; controls for a top-down or “isometric”-style game; and finally a basic framework for flocking/crowd AI. This last system was pretty heavily hacked up to create the AI for the hunters and mammoth babies.
We’ve been relaxing a little since the jam ended, but now we’re ready to start playing and rating some games! We aim to rate every video game that leaves us a comment on our page, so play and rate The Mammoth: A Cave Painting now: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=56968
