Mountain (play here) is a game about sharing experiences with others while you play alone.
This pit is filled with about 60 people’s shared failures and abusive language.
I’m pretty pleased about it.
LD22: Mountain
December 19th, 2011
Woohoo. Ludum Dare 22 was a happy fun time for everyone. 48 hours to singlehandedly make a game from scratch around a theme that is not announced until the beginning of the competition. This Ludum Dare was themed ‘Alone’, which I understand was pretty unpopular with a good deal of LDers, but then there always seems to be a group angry with whatever theme our glorius leader PoV the people choose.
This Ludum Dare I decided to make an effort to use Unity, mostly to finally see how it actually works and also to make the game more accessible to the ‘I don’t like to download games’ crowd, even though I will have lost my beloved Linux LD comrades votes.
Given that I’m quite unfamiliar with Unity I decided to keep the game fairly simple, and decided to make use of a number of canned scripts and functionality, such as the bog-standard first-person-camera with collision detection and predefined keyboard+mouse controls.
So I decided to make a dangerous mountain to climb alone. An initial test showed that climbing a large low poly mountain was both easy and boring, so I spent some time thinking about how to better meet the theme, make the game more challenging and try and add something a little unusual or interesting to what might otherwise be an extremely mediocre offering.
I’d heard about some kind of message system in Demon Souls, a game I haven’t played, where players can leave messages warning other players of traps and dangers in the vicinity, and often lie in these messages to mislead other players. Sounds like a great idea to me. I also wanted to make the game a lot more difficult to encourage some kind of communication between players beyond obscenities and gibberish, so I wrapped the mountain in almost total darkness and made the messages players leave illuminate their surrounding area, allowing for players to create a trail of lights up the mountain, showing where the dangers are hidden. The player can only leave a message at the spot they die, so even if they decide to write nonsense or query my parentage, their message will help illuminate whatever obstacle was responsible for their demise and so help other players better navigate the mountain. So I whipped up a database back-end and spent some quality time with the Unity documentation for dealing with web streams.
In terms of gameplay, I managed to achieve my goal. The Mountain isn’t particularly difficult to navigate, but does have some pretty mean, unfair areas. The graphics do their job, but aren’t particularly exciting, and the white text on the sometimes white background can become impossible to read. Audio was left until the last minute and really suffers as a result, the music was written in less time than it takes the track to play, and I didn’t have time to record or create any ambient or event noises that probably could have added a good deal of atmosphere to the game.
As it is, Mountain is a slow stroll to the top of the hill through a swarm of sometimes offensive messages, but for me it’s an enjoyable stroll, and seeing evidence of other players passing through the environment makes me happy.
Ludum Dare 22 prep
December 2nd, 2011Not a lot of people play my ludum dare entries. This may be due to their inherent crappiness, but is also due to my bad code or sometimes my inability to produce a game that doesn’t require the use of an installer.
So for LD22 I’m going to have a go at using unity3d, which will give me the option of generating a web version. Honestly though I expect I’ll still end up creating a downloadable game because at the end of the day I just don’t really like games embedded in webpages, which I find difficult to experience any sense of immersion with. Unity will at least make it fairly easy for me to churn out an untested Mac version though, which might win me a few plays from the undernourished Mac gaming crowd.
But. Unity doesn’t produce Linux executables. Although it is not completely impossible to run a unity game in Linux, it probably is not going to be worth the substantial effort to coax wine into running a 48 hour game. So this will be the my first LD where I have not targeted Linux, but given that almost no-one actually plays my entries anyway, it probably is not a great loss to the penguin loving world, but it does make me a little sad.
Ludum Dare 21: INFALL
September 27th, 2011Last month I entered another Ludum Dare competition, LD21. The theme was ‘Escape’. I decided to interpret this as ‘Escape from an anomalous gravity well in a clapped out spaceship with almost no fuel’. My entry, available here, is INFALL.
This is the first game I’ve written that I was genuinely excited to play. The whole time I was writing this some part of my inner-child-brain was already planning all the awesome asteroid dodges and grav-well slingshot manoeuvres I was going to make the first time I played it.
The Plan
If there is one thing the world needs, it’s another space game. A space game with lots of rocks. I just have a thing for rocks floating in space. Rather than spending a good deal of time trying to come up with a game concept, the idea of having to escape a gravity well whilst navigating a dense asteroid field sprang fully formed into my mind. I realise that the premise isn’t entirely original or likely to win any narrative awards, but not crashing into things is a time honoured computer game tradition which has made for plenty of great games.
So once I’d settled on a struggle against gravity and floating space debris, I decided it was time to finally come out of the closet and admit my love of pandas. Panda3D is a 3D all-in-one-even-makes-tea game engine I’ve dabbled with in the past, but never finished a game with. I like Panda because of its excellent Python bindings, and Python is, for me at least, a really excellent rapid development language, which given the 48 hour time limit of Ludum Dare makes a whole lot of sense. 3D engines (usually) need 3D models, and I decided that my familiarity with Blender was sufficient to put together some space rocks and a ship, coupled with my GIMP mastery for texturing. Audio would be made by either blowing into a microphone or created in any of the 100+ audio programs I have installed but have only opened once.
Decisions
Right from the start I knew I wanted to make this game first person 3D. I could have gone third person and made the game a 2D Thrust style game, but I really wanted to try and have the player (who in all likelihood is only going to play this competition entry once or twice) care about not colliding with any of the in-game obstacles. I personally feel a lot more invested in the outcome of a game when it’s presented in first person view, rather than the extra level of abstraction that comes from identifying with a player character visible on-screen. But I didn’t want to go with the static cockpit view that a lot of first-person vehicle games do. The player is not the ship, the player is the pilot sat in the near-useless ship careening down a gravity well, so I decided to try and create a feeling of separation between the player character and ship by having the mouse control the direction of view and requiring that the player look around the cockpit in order to successfully navigate to a victorious escape from the well. This required having some important reason to look anywhere other than directly forward, and so I decided on display screens around the cockpit that would show the player essential information, but would require them to turn away from the main window to view, and so outside the players forward field of view I added an overhead map of the system and a screen showing the distance required for the player to ‘escape’ the gravity well.
‘Realistic’ Newtonian physics were chosen because besides being the easiest for me to model, I really wanted to be able to slingshot around the gravity-well, and space-sims without Newtonian physics just feel like arcadey flight-sims without a floor to land on. I also didn’t want the ship to be particularly responsive, forcing the player to think about how they manoeuvre to avoid incoming rocks, and also to try and create situations where a player slowly realises that their escape attempt has failed and are dragged back down into the gravity-well. I also hoped that this would add some degree of a learning curve for any players that played the game a few times.
Audio was kept simple. I hoped to create a close tense atmosphere through limiting audio to the sounds you might realistically expect to hear aboard a space faring vessel and forego the star-wars ‘sounds in space’ phenomena. Given the limited fuel supply, this would result in a totally silent ship once all fuel was spent and the player is committed to their vector as a helpless passenger. I did decide that I’d include an ‘ominous hum’ that would increase in volume with proximity to the anomaly, but this was my only ‘cheat’ against sound in a vacuum.
Also, black-holes are hard to represent convincingly, so I decided to make a weird purple planetoid as the source of the gravity-well.
Building The Assets
So with a reasonably detailed plan in hand I jumped into creating my media assets. I wanted to reverse the order of my previous Ludum Dare entries and get straight into making some art assets that I was reasonably happy with to see how things looked together, rather than writing a game and throwing some graphics in at the end if there is any time left. First up was the ship cockpit (complete with comfy space chair). This iteration saw the chair upholsterer get flushed out the airlock.
First version of cockpit with chair
It's a low poly rock. Not a lot else to say
The source of all your gravity related woes
Writing The Game
Besides a few learning issues with displaying content on the in-cockpit monitors, writing the game went very smoothly. Having the art assets available at this point made dealing with issues of scale and position a breeze. The physics came together nicely and [relatively] soon I had a playable version of the game. Inexplicably I decided at this point that the game really needed music. I blame the hours I’d spent by now testing the game and staring at the art assets, but I hacked together a vaguely Indian sounding drum-loop that unless you’ve been working on a game for almost two days (and probably even if you have) gets annoying before it has even looped once.
Anomalous Balance
Who knew balancing such a simple game could be so hard? I only had the following factors to deal with:
- Starting distance of ship from anomaly
- Starting velocity of ship
- Manoeuvrability of ship and quantity of fuel
- Gravitational pull of anomaly
- Number and distribution of asteroids
- Speed of asteroids
But I just didn’t have enough time left to get it right. I seriously underestimated the amount of time it would take to tweak these values in order to solve the equation for fun. Increase the power of the ship, game too easy. Increase gravitational pull to compensate, game too hard, etc. Long story short, I failed this part completely. I just wasn’t able to come up with a solution where the game was not ludicrously easy or impossibly brutal. The once time I did chance upon a good combination, it was unworkable for most computers given the huge number of asteroids I’d included. Scaling back the rock count made the game far too easy again, but at least allowed the game to run at a decent frame rate on my netbook, which was the target base hardware platform to ensure I don’t repeat the mistake I made in my last LD entry of assuming everyone is running the game on a fat desktop computer.
Pointless Cockpit
One of the first comments I received from a game judge was that the cockpit was pointless. They didn’t need to look around at all, and had won the game (I assume) without so much as glancing at the map or distance view. Obviously the pace of moving through the asteroid areas was wrong if it could be easily navigated without the map. Another commenter described the rest of the cockpit as ‘a distraction’, again demonstrating that the information available on the monitors was not valuable to the player.
Mindlessly Easy
With the released competition version, it’s a simple matter to orient your ship at a slight angle to the Anomaly, burn your entire fuel reserve, and then safely coast around the gravity-well and out to a safe distance, winning the game. Nine times out of ten, you will miss the sparse asteroids through chance alone and win the game. I should have erred on the side of ‘extreme difficulty’ rather than ‘mindlessly easy’ gameplay for the competition, as this might have helped encourage players to replay the game a few times and notice some of the more subtle aspects of the game.
Subtle Aspects Of The Game
Alright, these were not particularly subtle, but in my intended high tension heat of the moment vision of the game that should have been, they were. I spent quite some time implementing effects intended to induce fear of the Anomaly. As the player descends into the gravity well, the volume of the ominous hum slowly increases from ‘barely audible’ to ‘Really Rather Loud’. A distortion of the field of view also occurs as gravity increases, most noticeable immediately before impact with the Anomaly. I also experimented with a variable focus depth of field shader, but this made my target hardware cry as it tried to emulate the shader in software.
The single ship window in the competition version was intended to contribute to a sense of claustrophobia amongst the asteroids, but instead failed quite severely, and probably contributed instead to forcing players to look forwards at all times. Post competition versions have extra windows, which help look out for incoming rocks as well as allow a player to glance at the monitors without losing their situational awareness.
Installerphobia
You know, every Ludum Dare I’ve been in I always notice that people prefer the games they can play in their web browser. That’s fine. I understand. But outright refusing to play a game just because you have to download it or run an installer is just laziness, especially when I take the time to cross compile to other platforms. I served my time with Flash. It’s just too limited for writing a 3D game in 48 hours. Unity3D would have been an option if it had a Linux client, but it doesn’t and probably never will, which rules it out for me. Of course Joe Judge comes along to rate my LD entry and sees that he can’t play it in five seconds time on the web, so writes an obnoxious comment and doesn’t play the game. One judge that rated my game admitted to me later that he didn’t even play it, but down-voted me because I packaged the game in an installer. So I didn’t get many plays for my game 
. Of course I’m sure that some people just didn’t like the look of it, but that’s a whole different issue.
Outcome
I’m pretty happy with INFALL. Played the right way, the game has the atmosphere I was hoping to create. Unfortunately it’s just too easy to play it the ‘wrong’ way, and there isn’t enough guidance for players that didn’t write the game. At some point I’ll hopefully find a nice balance for the game and release an updated version (probably sans music).
Gameplay
INFALL development timelapse
Ludum Dare 19: Disc Over Y
February 9th, 2011This is a lesson on respect. Specifically, respecting memory. Apparently not everyone has 6GB+ of RAM available for playing Ludum Dare 48 game-making competition entries.
At this point, things were still reasonably sensible
It started off innocently enough. A nice simple map for a nice simple Ludum Dare entry, using my half written caveflyer engine. A map barely 1000 pixels wide, a mere 800 pixels tall. At some point I decided to grow the map a little, then a little more, and just a little more, until it reached 13312 x 20992 pixels, for a total of 279445504 bleeding pixels. And that’s just the background layer. There’s an additional foreground layer of the same size, though around half the pixels are completely transparent. I realised this was a little large and scaled the entire map to a quarter size, and then expanded it 4x in-game to try and compensate a little, but I wasn’t fooling anyone. My game was obese.
Graphic documentating the ridiculous overambition of my map
For some reason I decided that I didn’t need dynamic loading. I lived in some kind of denial, believing it would be no problem for anyone to run the game. I concentrated on trying to progress with the game rather than worry about trivial technical details. The game was running fine here after all. Then I compiled it for Windows.
If this game came on a disc, it'd have to be as big as a person (or robot at least)
At this point I realised I had a real problem. The game loaded in about 5 seconds in Ubuntu, but took closer to 30 seconds in Windows. I copied it over onto a similar machine and the game just didn’t load at all. I tried ten times, and the game loaded on the tenth attempt, and was using 2GB of RAM. Great. Works fine. Lah.
The jagged crystal hell of forgetting to include dynamic loading
I won’t pretend to profess that I know much about how Windows allocates it’s memory, but it seems that repeated launch attempts eventually allowed enough of the map to be buffered that the game was able to launch without erroring out before reaching the main loop. I could have tried to explain this to the people who were about to try and play and vote on my game, but I didn’t expect much in the way of sympathy. So at this point I decided to try and fix the issue. Hours and hours after I’d first identified the existence of the problem. So rather than writing new code in my now very limited remaining time, I tried to rework the existing loader to dynamically load on demand. This worked to an extent, but completely broke the map wide physics of the game, which relies on the map being loaded into memory to calculate what’s happening off screen. This approach is fine for the engine’s intended purpose of simulating a tightly claustrophobic subterranean combat arena, but fails somewhat at serving up seamless large worlds, which really don’t need much in the way of distant physics simulation anyway.
Robo1 contemplating his misfortune to be trapped in one of the worse Ludum Dare entries
But enough whining! What worked? Well, I managed to finish around 60% of the game. Considering how insane an undertaking it was, I don’t feel too bad about not finishing. There are a couple of cool things implemented. If Robo1 progresses far enough to locate the Obliterator, all kinds of fun can ensue:
Tunnel FUN
Probably the one feature of my caveflyer engine that was actually suited to this game was the destructible terrain. The protagonist does not start with the ability to destroy terrain, but obtains the ability through discovery. The original plan was to have the player collect the items which allowed them to fully explore the environment, eventually discovering the Obliterator, which would be used to bust open a sealed hangar door. Once this was open, the player could hop into a ship (already implemented in the caveflyer engine) and fly out into the outside area (left hand and bottom sides of the map image). From here the player would engage in a couple of dogfights before landing and discovering The Final Item, which I won’t talk about in case I actually get around to repairing and finishing this game.
Vigorous hangar door removal in progress
If you’re feeling sadistic, you can go download the game from the Ludum Dare entry page, but I can’t recommend it. I also recorded a timelapse which for me at least, is a bit more interesting than the game proper, bad music included.