Twoplus Games went to rAge 2015, and it was fantastic!
There were 14 local developers at the home_coded section at rAge this year, everyone showing off their awesome talent and games.
We took along three games: No More Boxes, Beat Attack and Invader Crush, because we couldn’t decide on one. We made a cool Arduino game selector gadget:
(The Arduino game setup. Thanks to IGN Africa for the photo)
We shared a space with Paul, creator of Clutchfighter:
(Steven Tu and Paul Campbell Potgieter, photo courtesy of IGN Africa)
NagJam
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)!
Coverage
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 😀
In all, rAge 2015 was a fantastica experience. A great big thanks to NAG for organising, and for everyone in MakegamesSA for pulling together and making it happen as a collective!
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 🙂
