Unfortunately it wasn’t recorded, but here is a very quick and dirty companion to the slides to explain some stuff that won’t be apparent from looking at them:
I got into VR because of the Vive. Nothing else was nearly as good. I spent a few weeks jamming games on Free Lives’ Vive, and made three quickprototypes (one I haven’t put online yet) within my limited time with it.
Things I wish I knew about Vive + VR:
It’s easier than I thought it would be, it has no Mac support, direct sunlight wrecks the sensors.
Look up the poison berries theory, try not to get people sick.
Such an important dimension that humans already know but had to unlearn in 2D interfaces. Now we can intuitively access it again!
Different ways of convincing human minds of plausibility of the simulation.
VR is not anti-social.
VR is one more step along the continuum of technologies that close the gap between one’s private mind and one’s shared reality.
VR brings people back to a less singular vision of stories due to the popularisation of books and film and other single-point-of-view medium
Audio is key to immersion, much more than visual. Remember that!
VR is important because:
See the slides! It’s bigger than any single person!
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
Last Ludum Dare, I went in with pre-conceived notions of what I was going to make, and I felt it would have been better if I didn’t. This time, I went in with a blank canvas. Hell, I didn’t even look at the theme list to prepare myself.
The theme was You Are the Monster – a theme quite a few jammers bemoaned because it’s quite close to a theme a few LDs back – You Are the Villain. I wasn’t around back then (darn kids, right?), but I vaguely had the feeling it was done before. I didn’t care though, brainstorm commenced, there were a few decent ones, but when our chatter made me laugh out loud, I knew I had to do it;
You’re a monster. You’re a pocket monster (pokemon). You’re the lamest pokemon ever. You’re Magikarp. No, you’re so lame, you’re Magicrap. But you want to be the best you can be. Which is Gyrados. No, Gyradeuce. The crap puns flowed. I laughed, and off I went.
A stealth game where you have to eat your cover
That was the final destination of the core mechanic brainstorm, and that turned out to be super important. There were many interpretations of that core mechanic alone – Initially the game was not going to be on a grid, and physics-based, so you would dash around the place and slide and roll, etc. A turn-based version was also considered. But eventually a real-time, grid-based system was decided upon because it was actually the most predictable in terms of building and balancing.
Art priorities: 1. Fast, 2. Acceptable
The process was fairly straightforward, I made placeholder art because I didn’t want to spend too much time on art in the beginning, and just like the previous LD, I didn’t really get a chance to update them later. I think this is pretty much going to be the norm rather than the exception. Make okay placeholder art, but don’t waste time on them initially.
I’m privileged in this regard because I’m an artist/designer primarily. But don’t worry, what advantage I have on art I make up in shortcomings on my coding side.
Three dee two dee
The one interesting thing that I feel like is worth talking about technically and art wise is the 3D/2D effect that I have, where the sprites order correctly. Anyone who knows about z-sorting knows it’s a chore, and I didn’t feel like making the game constantly read y values and re-assigning them to different layers at runtime. So I tinkered and came up with this:
By tilting all the sprites at an angle, they overlapped correctly without having to programmatically set each sprite’s layer at runtime. The camera is a perspective camera with a limited field of vision, so it looks 2D, but is set in 3D.
I really liked how the effect came out – there’s a little 3Dness to it but still has the 2D charm that I love. And I didn’t need to make polygons
Initial feedback on the game was super cool It’s currently sitting on 110 ratings, which I think is the highest I’ve had (though I can’t confirm this, don’t know how to look up past rating counts).
There’s also been a bit of coverage by some really awesome people
Never ever miss a Ludum Dare if you can help it. I missed #LD31, and I made damn sure I would make this one.
The theme: AN UNCONVENTIONAL WEAPON
Which is actually pretty fun. However – a confession – I went into this jam with a preconceived idea of what I wanted to make, and just kinda rolled with the theme. I wanted to make a mecha platformer, and mecha kinda fit “an unconventional weapon” (no not really, I know), so I just went with it and made:
(Easter egg: 2875 is a… visual pun on 2015. 8 looks like 0 and 7 looks like 1)
A visual post-portem
When I first got the riding in a mech mechanic going I was ecstatic:
And then I got the plough-through-the-civilians-if-you-were-running-in-a-mech mechanic :
Then I got to set up a bit of a level with a base of operations:
Slowly but surely, mission one, with mech destruction mechanics:
Eventually and finally, after the Compo period was over, I got to doing some art. so late!
The mechs made of cubes were only ever meant to be programmer art to be replaced later. But then I ran out of time and just animated them instead of upgrading them. And surprisingly, they turned out alright. Mecanim may be unwieldy, but it’s very very useful for doing things on the fly.
In retrospect, what went right:
Going in with an idea of what to make. Having a goal is actually a good thing.
Gameflow polish – I had a title screen, a completable game that had a start, a middle and an end, and a scoring system, and that’s quite valuable. Jam games without a feeling of progression are easily ignored.
Visual polish – the mechs were made of cubes and was originally intended as placeholders, but they actually turned out pretty well once animated.
Visual polish – a variety of particle effects made the game feel quite lively.
Making an accessible single-player game as opposed to a multiplayer one that’s difficult to playtest.
I’m getting better at Unity, so things went a lot quicker.
Using an existing and open-source platformer controller (some may see this as cheating, but I really don’t see the point of re-inventing the wheel each time in a jam, I already made a horrendously messy platformer controller last jam.)
I slept. About 3-4 hours each night, it made the waking hours that much more productive.
Annnnd what went wrong:
Going in with an idea of what to make – My goal (make a mech platformer game) completely stifled creativity and I ended up with a bit of a limp, lifeless game thematically. Comparing my goal this time to the goal I had set for myself for the previous LD, this one was a bad idea.
Overscoped. This is the number one killer of jam games. I fought this hard, but the fact remains I couldn’t make 48 hours and went into 72, and then STILL missed out on a lot of what needed to be in.
Too many interdependent systems – this was a cascading domino set that fell like this:
I wanted mechs to be able to dash.
I wanted the dash to carry a penalty.
So, if you dash, you could accidentally stomp civilians and kill them.
So I gotta make civilians.
And of course criminals.
Where would there be civilians and criminals? A fucking huge sprawling city.
What do you do in a sprawling city?
Missions, of course.
What’s the point of getting into a mech if there’s only one?
Let’s make three.
What’s the point if they all do the same thing?
Give them abilities.
What’s the point of abilities?
Give missions variety, mechs match mission parameters.
Etc etc etc.
In the end, all those systems intertwined too much, building them took forever, and changing one meant changing a whole bunch of others.
No time to tweak and find the fun – this was a consequence of overscoping. Being too busy building interlocking systems.
Intended to do a 48 hours compo entry. Had to “upgrade” to a 72 hour jam entry.
In the end, I think this was the least successful of my three Ludum Dares, despite having experienced up and having made much more stuff in the time allotted than ever before. Sigh.
Although, it has seen pretty positive responses on the concept and its prettiness, which is encouraging. I’ve always wanted to make the mecha platformer, and it seems to be something people want. I just need to settle into the mecha seats and find the fun in the mechanics.
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