We shared a space with Paul, creator of Clutchfighter:
(Steven Tu and Paul Campbell Potgieter, photo courtesy of IGN Africa)
Just before rAge, NAG put out a challenge – create a game in 72 hours (with the theme “Don’t Touch That”), and show it off at rAge. We made a game for it – Royal Smash Royale, a four-player arena where players have a hammer and must smash a horde of pesky critters – but watch out – every once in a while King Roy declares one of the species protected, and you mustn’t touch them, or you’ll incur the ire of the Royal Turrets of Protection Policing!
The game was SO GOOD (but not too good) that it won 4th place where a 4th place wasn’t planned initially. NAG created a spot just for this game, and for that we are eternally grateful (and bemused)!
Here are the bits of coverage that we’ve seen so far on our appearance at rAge, thanks to the press for playing our games with us
This was a tough one – the previous Ludum Dare’s theme was, to me, a lot more restrictive, and thus felt more interesting. It’s the old saying of if you tell someone they can do anything, they most likely will end up doing nothing. Restrictions breed creativity.
So we tried to break the theme down into restrictions we can try to apply:
“We” – “It’s What do we do now?”, so that implies some kind of group game – implying multiplayer, which is my personal favourite. But multiplayer experiences tend to not do as well in jam setting (as we discussed in the previous Ludum Dare blog), and we just did one in our previous LD, we also wanted to stay away from that.
A sense of being thrust into something unknown – that’s the feeling those words “What do we do now?” elicit. We wanted to make people feel that panic and confusion.
Not a scripted narrative adventure game – we realised very quickly that the theme lent itself too much to a kind of point & click adventure that would have players solve things by working out contextual puzzles, so we wanted to stay away from that. We wanted to base the game on a mechanic rather than a stream of content.
The deed is done, the mark is now a body. “What do we do now?”
Now, we call the Cleaners.
Bodybag is a game about what happen after the inconsiderate asshole assassins leaves a messy botched job behind. It’s your job to get rid of the body in whatever way necessary.
It can be played as a 2P game with each controlling a character, or ambidextrously by a single player. This
It’s a physics-based game which we haven’t really had experience with before – No More Boxes was physics but this had elastic bodies and all that which relied a lot more on physics than wrangled quasi-physics.
Not sure on the name “The Cleaners” sounds better but a tad generic, “Bodybag” sounds too heavy-handed… But for now this’ll do
We either overscoped or underestimated the tweaking it takes to wrangle a physics system to do what we want it to do. In any case we had quite a few things that we wanted to include that didn’t get in, which would have been easy to implement, but we were too busy working on wrangling the physics system.
So we didn’t manage to finish everything we wanted to
Learnt a bunch about physics bodies in Unity, it made me understand why Chariot (that game I learned about over the weekend) made their design choices (round characters, among others). I feel much better equipped to make more crazy physics games now
Learnt to do level design. Something I’ve generally stayed the hell away from.
If you’ve read any of my posts from Ludum Dare 31, you’ll have seen how I celebrated this theme as a great restriction. While many moaned about the theme being too open-ended, I really enjoyed that it was a mechanical restriction rather than a thematic one.
(I guess the “everyone hates it” perception comes from confirmation bias for seeing negative posts but no “YAY LOVE THIS THEME” posts, after all the theme didn’t just materialise out of randomness – the majority of it voted for it in the slaughter for it to be chosen!)
How I interpreted the restrictions
In summary, I boiled “Entire Game One Screen” theme to these strict restrictions:
The entire game must exist on the screen when it starts
That means no instantiating new things
And because of the previous point, removing things would be bad as I couldn’t make new ones.
That means no bullets, no treasure chests/powerups/whatever, no collectibles.
No falling off the edge and disappearing… etc.
The thing with restrictions is that they really spark something different. Creativity with no restrictions is really, really stifling, in fact. So, embrace restrictions!
Setting learning goals
After I set that restriction for myself, I thought a bit more around what I wanted to get out of this jam. We as gamedevs (or gamedev wannabes) often have ideas that we don’t get around to making, and often that’s because we simply don’t have time or don’t know how. But if we never know how we never will know how.
So I thought about the stuff I wanted to learn with this time that I have now, so I can try and do THAT.
I had been thinking about making a platform arena shooter. I haven’t really made a platform game controller before so I decided I’d do that.
My platformer idea I had was to have players that could pilot robots, so players would control different things in the game at different points in time.
I wanted to use built-in physics for hilarity – I usually stick to restricted movements with my game designs.
So with those in mind, I set out to design my game. A look at the outcome will show you that I’ve basically hit my learning goals:
I made a platformer – the platformer controller was really tricky to get right, I could still improve it, but I now know a lot more about platformer controls. They are NOT easy at all, as I suspected when I started, but now I *know*.
Players would come back as different characters, so I got the swapping controls between objects thing working, and I now understand it.
Wrangling built-in physics so that it provided a good stable background against which platforming could happen was VERY tough. I had some experience with one of my previous prototypes Bear Chuck, but this was more freeform and thus harder. The results were glitchy but satisfactory, and a lot of learning was gleaned from it. As well as an idea of how I could improve the system.
Bonus: Give people the best chance of playing your game
As I sat through this year’s entries into LD I noticed a lot of problems that was excluding people from playing their game. Hell I made a fundamental “mistake” too, so let’s talk about that:
The basic principle: LOWER BARRIER TO PLAY. This sounds so simple but so few people seem to keep it in mind. This encompasses many things:
Web player. This is the single easiest and best way to get people to play your game – it works across Macs, Windows, and is usually the best option to deliver your game on if you want people to play your game. And you do, obviously.
Be aware of current affairs: I said “usually” in the above point because Chrome is having a row with Unity web plugin. You can find more details if you Googled for it, basically Unity acknowledges it as Google not liking a tech that they’ve been using and Google’s shut it down with Chrome. I’ve been using Safari as a backup to continue playing Unity web games, but so many people won’t know this and it just appears as if the developer screwed up. So…
Deliver in as many platforms as you can: So yes you got a web player, but it’s better to get a Windows and OSX build up alongside – not only are more options intrinsically better for getting more people access, it also gives streamers more options, if you get their attention.
Single player option – Always *try* to make your game so it’s possible to play single player. Finding other players to play with is TOUGH when everyone basically just finished a jam, is dog tired, and is in front of their laptops at home. That said, I obviously went and made a non-single player game… So I broke this rule, but I thought long and hard about it. If you have time to make a single player mode, or some REALLY RUDIMENTARY AI, or whatever, do it.
Clear, simple, quick instructions. FIRST. Consider the possibility of people not reading. It will always happen, and their failure to get stuff working is your loss, not theirs. I stuck my instructions at the top above the game, and made it as simple and clear as possible. Fuck sentences, just get people to understand it.
So, whew, that’s a lot of text just on how Ludum Dare went. So I’m not gonna talk about the game for now. I might come back and write more about it, definitely gonna do a post-jam brush up of it, and finish up Amy, and maybe add more features I had in mind while playing like a shifting arena or 6 more characters
The rAge Expo has always been a landmark gaming event in South Africa, and this year has been no exception. Twoplus Games was there with a gaggle of fellow indie game devs with MakegamesSA and to show off some top-notch home-brewed entertainment!
Dead Run, of course
Arthur Godstruck on Dead Run
We took two games to rAge, and the first is the soon-to-be-released endless twitch zombie-bashing runner Dead Run, which has repeatedly surprised us with how much people love playing it even in an expo environment – see, it was designed for quick play sessions while waiting in a queue, but instead people were queuing up to play it. It brings a smile to our faces
The second game we brought was Beat Attack, a game we had been prototyping in the last month or so. rAge was the first time we had shown it to the public.
Beat Attack is our rhythmic one-button love letter to combo-licious competitive block-matching puzzle games – it was designed because we love versus puzzle games like Super Puzzle Fighter and Puyo Puyo, but couldn’t really find any that worked with my iPad. So we made our own! We also love DDR, and it all just fit so beautifully together. But more on Beat Attack’s origins later. Beat Attack was super well received, the simple one-button competitive play was a joy to show people and just watch them fall into the game, trying to get better and beat their friends’ ass. Which is exactly what we want out of Beat Attack!