About pdyxs (twitter: @pdyxs)
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Ludum Dare 21
Ludum Dare 20
Ludum Dare 18
So I’m (rather last minute) deciding to do this. This time, I want to make a game that’s a twitter bot, and play with ideas of virality and narrative.
Tools I’m using are python and Parse (yup, this means I don’t have to do any graphics, sound and so on! Though I spose my bot could post pictures… hmm… interesting…).
Angus and I just sat down to do a commentary for our Jam game.
So after extending what I thought would be a 48 hour jam entry to a 72 hour one, I’m done!
Angus and I are really happy with what we’ve put together, and I’d love to get as much feedback as possible on this crazy genre/medium mashup/thing that we did.
I’ll be doing postmortems, a commentary and stuff (learnt a lot of really useful stuff this time round) once I’ve slept. Coz yeah, I need sleep.
Here’s my first video update on my entry for LD23.
First: yes, I’m in!
Second, I’ve decided to challenge myself a little and make a game which is also a musical. The content of the game and specific gameplay will depend on the theme, but there will be singing (though probably no dancing), and the song will likely adapt to player actions.
My guess is that the game will be no more than 3 minutes.
The plan is to really capture the feel of a musical within this time through both the music and the gameplay.
I anticipate that the graphics will be rather dodgy (or, more likely, nice-looking but super-simplistic).
This will be a jam entry – I’m enlisting Angus, the music extraordinaire, and 1-2 singers (for recording only). I will, however, be completing the game in 48 hours.
Tech to be used is actionscript/flash. I may use box2d and/or flashpunk.
I’ll be throwing everything I can at the community, and would love to get feedback throughout the process. So for now: what do you think is important for a game that’s also a musical?
So we’re doing Ludum Dare this weekend, but not as we know it.
I’ve found in the past that Ludum Dare does an amazing job at helping to build prototypes of games that may have a bit of a ridiculous concept. I’m still holding onto the thought that my first entry might one day make a prettier re-appearance, and I’ve got some plans for an upscaled version of my latest (“Escape from Flatland: An Adventure of Two Dimensions“).
The fact is that Ludum Dare seems to be adding to the already-large pile of games we want to make, many of which need prototyping. And Ludum Dare is great at helping us to create prototypes.
Do you see where this is going?
Yes, it’s true. We’re going into Ludum Dare with a pretty specific game in mind. A game that I’ve wanted to prototype for a while, and needed an event like Ludum Dare to give me both the impetus and the hard time limit to do it. The fact is that if we didn’t make it now, this game might not be made (as it is a little ambitious), and thus I’m going to take the opportunity to make it.
What’s less clear is what happens on this end. We’d be looking to enter the Jam part of the competition (there are four of us), and I’d love to post lots of updates as we go and have the game on the Ludum Dare site as normal, but the fact is that we will be breaking the rules. If it interferes too much with the core idea, we may not even use the theme.
So my question is: LD Community, are you ok with this? I’d be sure to label our entry with the fact that this was a pre-decided game idea, so it’s not like we’d be hiding what we’re doing…
Paul: As you may have seen, James and I both took part in Ludum Dare a few weekends back, where James made Web of Flies, and I ‘Escape from Flatland: An
Romance Adventure of Many Two Dimensions‘. It was an adventure of coding, design, learning new things, and crazy shape (James: and spider web!) physics. It was the most fulfilling 48 hour game challenge either of us have done (this was James’ 2nd LD and my 4th), and the resulting games speak to that.
In this postmortem, we didn’t really want to make lists of what went right or wrong, so instead we’ll lay out some rules we each felt were important going into the weekend (whether we followed them or not), and then talk about how these aspects affected our games.
Seeing as I’m introducing this sucker, I’ll start first:
Rule 1: Gameplay in 6
This, in my opinion, is the most important rule of 48 hour game dev: have gameplay in 6 hours.
‘Escape from Flatland’ had gameplay in 7 hours (so slightly late), which gave me a huge amount of time to tweak and fix the gameplay within it.
So what is ‘gameplay’ in this case? To me, it’s the core mechanic, that thing that your player will be doing most of the time: whether that’s running and jumping, shooting, answering, or (in my case) splicing shapes. The key here is that you should rush towards the most important gameplay feature of your game.
I think it’s important to mention that you really don’t need to have a perfect grasp on what your game is going to look like in order to get to this first gameplay stage. At hour 7, i knew that the player would be a triangle, and that they’d be splicing other shapes… and that’s about it. I didn’t know what a level would look like or what the player goals would be, but I knew that splicing shapes would be key.
James: So, yeah… I kind of failed with this one. Gameplay in T minus 6 hours?
I guess I have two excuses. Going in, I had no real intention of actually competing (it was the same weekend as PyCon AU 2011, and a dozen other things), so I’d mostly just resigned myself to helping host our little LD party, whilst doing other things all weekend. Of course, enthusiasm is infectious, and I was soon caught up in the action. It didn’t excuse me from my other commitments though, so it ended up being a rather fractured weekend with me dashing off every few hours to a concert or whatnot. Self-sabotage at its finest.
I also had a lot of trouble coming up with a game idea, so I started out just implementing all the basic stuff that comes free with other development platforms (player movement, translation between world and screen coordinates, etc.) It was only after about nine hours (while sitting in a Schubert concert), that inspiration finally struck, and I raced back to uni eager to write some spider web physics. The idea was deliberately simplistic; I wanted something small and shiny that would show off the unusual medium, and that I could actually get finished. I could always add to it if there was time (and there wasn’t, turns out simple was hard enough ).
Getting to gameplay in six hours would’ve saved my game from the parameter-tuning problems it currently has, but I guess this time round I just a bit too disorganised, and still adapting to the challenges of the new medium.
Paul: And challenging yourself is really important in getting the most out of Ludum Dare, so much so that I’m gonna go and make a new heading…
Rule 2: Challenge Yourself
This is, to me, the most important part of Ludum Dare: it’s an opportunity to try out new technologies and gameplay types, and doing so is incredibly rewarding.
This time, I went into Ludum Dare with two goals: to learn the Facebook Social API and play with the idea of asynchronous co-operation; and to learn the basics of Ruby on Rails while doing it (more on that one later…). Having this goal helped me to focus my work, forcing me to get to the basic gameplay and design quickly so I could attempt the ‘something more’.
More importantly, the social aspects of the game, more than anything else, have given me a plethora of ideas for my other projects. Trying new things and expanding your horizons will help your game design and development in general.
For me, this rule goes hand in hand with another, and seeing as James has already talked about challenges, I’ll move onward to…
Rule 3: Make Trade-offs
If you’re going to challenge yourself, you need to make trade-offs. If you don’t, you’ll find yourself trying to do far too much in not enough time (see my last Ludum Dare game, ‘The Way Home’, where we tried for an art game which combined and synchronized two completely different gameplay modes… it was a bit of a mess).
If something isn’t necessary for your game, cut it or strip it down. Play to your strengths.
One decision I’m grateful I made with “Flatland” was that I wouldn’t put much effort into graphics or sound. Graphics would be all drawn in-game without sprites (and so any interesting effects needed to be emergent from gameplay), and I’d use Wolfram Tones and maybe some effects generated from sfxr (I ended up not doing this). As soon as I made this decision, it engendered a specific graphical and audio style which can (and did) work really well without much effort.
James: Yep, being able to make tradeoffs is really essential. My original gameplay idea was much more complicated – the web was going to be much larger, a single breakage wouldn’t end the game, and there’d be much more of a focus on strategic repair and pathfinding. By the last six hours though, I was pruning away features left and right, and with not enough time to implement the extra mechanics and physics I had planned, gameplay underwent some fairly radical simplifications. It was painful to do, and resulted in a less exciting game, but there wouldn’t have been anything to submit otherwise. Thankfully my running buddies came to the rescue here with their cool, logical advice; it was time to just admit defeat and polish up what I already had.
Paul: That actually reminds me of another tradeoff I made later on in the development. Initially, I’d decided to do all my serverside scripting in Ruby on Rails, which was partly ‘challenge’, partly ‘a single 2-column table will be pretty easy in rails, and probably quicker (even considering I’ve never coded in ruby) than php.’ Which, let’s face it, is true.
What I didn’t think about beforehand was that setting up Ruby on Rails on my computer meant rebooting into osx (my flash dev was done in windows) and wasting half an hour setting it up. What I concurrently failed to think about was that setting up on a server somewhere would probably waste the rest of the weekend. Thankfully, I only wasted 1-1.5 hours on that particular tangent before coming back (quite literally, as I actually left our dev site to do this) and doing php (which made me a little sad, but was thoroughly worth it).
Rule 4: Turn your limitations into features
Obviously this only works to a point though. There are going to be many limitations that are difficult, if not impossible, to dress up as a feature (buggy game logic, poorly balanced gameplay, etc.). But it’s worth a shot, right?
Paul: It’s definitely worth a shot, and to me, it’s rather necessary. If, for instance, your controls are difficult to learn, it can mean one of two things: you need to fix it or you need to feature it (and by that, I mean admit it’s hard and make that part of the challenge, and probably tutorialise it). That isn’t to say that my game’s controls would have been fixed by featuring them (you can only feature so much, and they actually needed some thought put into them), but it’s a good illustrating example.
As James mentioned, my limitation here was my choice to simplify my graphics. Deciding to go simple on the design could have been a huge drawback in terms of look and feel, but then I spied my copy of ‘Flatland’ on the shelf. Suddenly, I had a way of turning this drawback into a feature, by setting the game in the world of Flatland.
And with that, I’ll awkwardly segue into the next rule…
Rule 5: Release, Playtest and Tweak
So I got two out of three of these, so it can’t be that bad, right?
In actuality, I kinda lucked into playtesting my game. I needed data in my database, and so released a half-finished version and asked for people to play it. And got awesome feedback in the process. I then made some of the tweaks from feedback, but failed to get them all (those awkward controls in the game? unchanged since about hour 4).
Now, I should have known better… I am, after all, a huge proponent of playtesting. And I should really have done a release a bit later on when I had a few more levels, to test out difficulty etc. (as I didn’t really polish this aspect, and there was a bit of sloppy level design going on. Also, some playtesting would have made it clear that social aspect wasn’t all that clear).
All in all, I could really have done more tweaking of my game. In the last two hours of the comp, I didn’t really get much done, and a bit of tweaking would have gone a long way (or, you know, fixing the sound so that the music I’d gotten off WolframTones actually looped rather than playing once and then stopping). In my own defence (against my own accusation? this is getting a little gollumish) I’d slept for 3 and a half hours in 2 days and was in a somewhat delirious ‘holy crap I got that much done? that’s awesome! It’s totally finished’ mood (for instance, the idea that the last level might be too ambiguious didn’t actually enter my mind).
In the end, I’m really happy with what I made, but you never forget those couple of things you ‘coulda, shoulda, woulda’ fixed.
James: Well, yeah, I was an all-round failure here.
Releases? There was one. About 10 minutes before the end of the comp.
Playtesting? Um, I checked that things moved?
Tweaking? Again, nowhere near enough. Parameters like the spider speed, fly strength, and web repair rate were never really tweaked beyond their original values, and while that might’ve been okay for what I’d originally planned, it certainly isn’t optimal given the direction I ended up going.
In fact, I pretty much gave up on tweaking entirely. In the last half hour when I had a mostly playable game, I started work on cosmetic improvements (making the spider’s legs moved as it walked), rather than paying attention to the (probably more critical) playability issues. It was an awkward trade-off, but one I’m not really too upset about. I received a lot of positive feedback from friends regarding the attention to graphical detail, so I guess I’m just glad it didn’t go unnoticed.
Paul: Yeah, the moving legs were pretty awesome.
I think we’ve gone through the things we wanted to, so I’ll leave it there. Thanks to all those who’ve given feedback for our games. It’s been pretty amazing to be part of this LD48, and to be two of the (patently ridiculously) large number of entries.
From James and myself, thanks to everyone who organised it (and got the server back up and running!), and bring on LD22.
So I haven’t had a chance to do a postmortem yet (it’s coming, promise!), so I decided to quickly put together a commentary video for my game, Escape from Flatland.
So, I’m pretty stoked about what I’ve managed to get done this weekend, not just in the ‘oh wow, I got so much done’ sense (although that’s definitely a part of it), but also (and really, mostly) in terms of how people will play the game and their reactions.
For my game is a bit of an experiment.
I’ve been wanting to play with social gaming for a while, but to specifically look at how we might make social gaming more meaningful, and use it to create real shared experiences rather than virtual shared cows.
So this weekend, I decided to go social. To specifically use the Facebook API to create a co-operative gaming experience between each player and their circle of friends, that would result in a different experience depending on how the group played.
I’m not sure if I’ve been successful at this (and in some areas I’ve definitely misstepped, taking time from tweaking gameplay to adding these social aspects, or levels which are probably the wrong difficulty), and so I’m really hoping to get some feedback on the social aspects of the experience, and how they played out.
So yeah, if you’ve got a bit of time, please have a look at ‘Escape from Flatland’. You may want to get a few of your facebook friends to play it as well to get the full impact. Either way, I’d love to hear what you think.
An update on my progress so far… as of an hour or so ago
Here’s the screenshot of Kris’ game, which is looking pretty awesome! (sorry bout the lack of cropping the photo, wordpress is being a bitch…)
So here, almost as promised, is a 6 hour update on progress!
I’m a little behind where I’d ideally want to be, but am pretty happy with where I am. My next 6 hours will be dealing with working out what a level is and making one or two of those.
A quick update on our game. Below is the map, just completed, for a game about traversing a dangerous neighbourhood. It’s gonna be a mixture of top-down and side-scrolling platforming.
There’s 5 of us here at Sydney Uni, and we’ll be doing LD20 in groups of 2 or 3. I’m working with a partner, and we’ll be using Flash, including libraries Box2D, Flint and TweenMax.
So its been a couple of days since my game went up, and I thought it was high time I did a post-mortem. To give a bit of background: this is my 2nd flash game ever (number 3 is in the works), and was my first time doing a Ludum Dare, so I’m fairly new to the whole experience. Overall (spoiler alert!) it was an awesome experience that I’m looking forward to repeating(end spoiler).
The game can be found here – I’m looking to polish it up and do a re-release, so any suggestions are more than welcome.
Now, onto the experience:
Part 1: Brainstorming
My brainstorming session involved me, a whiteboard (pictured below), and Google. The first thing I did was to break down the theme into its two important points: Enemies, and Weapons. Ultimately, the idea of enemies proved to be the more interesting of the two.
Then I looked up google for sayings about enemies and weapons, and noted the most interesting down. The two that stuck were ‘Know your enemy’ and ‘The enemy of my enemy is my friend’. The first implied a game where you turned your enemies into weapons, but you had to figure out who your enemies actually were. The latter made this more interesting by suggesting a complicated web of alliances which.
These two basic ideas are what informed ‘The enemy of my enemy is my heat-seeking missile’. Essentially, the idea is that you find out who your enemies are, find out who their enemies are, and turn them into heat-seeking missiles so they kill your enemies.
At first, I wanted to use a mechanic of asking people questions to find out their allegiances, but this struck me as way too complicated and messy for a 48 hour game. This lead to the idea of using a colour-based detector for allegiances, and so the ‘allegiometer’ was born.
I’m pretty happy with the basic ideas that came out of this initial brainstorming stage, though they may have been slightly too complex to explore in terms of level design and balancing (the programming aspect turned out to be fine). Which leads us to the next stage:
Part 2: Coding and all things new and shiny…
I should probably mention at this stage that this is my first game that required any level design or sprite animation (I’ve done the graphics programmatically in the past). At this stage, I was putting off the graphics, but one of my first steps was to find a decent level design program and test it. I ended up using Ogmo, and am ridiculously happy with it as a level editing tool.
I got a framework together (using flashpunk as a base) that would read in the map, place the player and the bad guys in and have them interact. I’m really happy with my collision and basic movement code – I simply got it working in a way I hadn’t really done before.
At about hour 10 I hit a bit of a brick wall. First, there was a few dodgy dependency-based bugs (the kind of ‘include’ loops you expect in C or C++, not in Actionscript), and secondly, there was trig. At this stage, I have to emphasise how much I hate trigonometry. I’m not bad at maths, and really enjoy most math-based aspects of game programming. Trigonometry is not one of them, and it seems to come up every god-damn time. There’s too many cases that I never seem to get right the first time, and it often degenerates into guesswork as I get more and more frustrated.
In this game, the trig problem was the angle to point the missiles at as they were rising (so they’re pointing at the target at the top). Ultimately, I got it working if the target was below them but not above, but it took so long that I needed to just leave it and move on.
Overall, I’m pretty happy with the code base I made. There’s some real dodginess in the scoring screens (magic numbers galore), as they were done really late, but otherwise it’s a fairly elegant system.
Part 3: Graphics, (aka why there are Summersaulting Robot Ninjas)
At about hour 13, I started working on the graphics. I first tried to do silhouetted stick figures, but without a tablet (hell, with a tablet might not have helped) I suck at drawing, so Robots it was!
Robots were easy, and I’m pretty damn happy with how they look in the end, considering the timeframe and my ability. One or two frames in the transformation into missiles were a bit dodgy, and there’s a lack of a jump animation.
The lack of tilesets was probably a good move given the timeframe, but the simplistic nature of the graphics did hurt the game a little. It’s something I’ll definitely look into in the future.
I’m particularly proud of the summersaulting ninja robots that emerge from the terrain (this was half animation, half programming)…
Part 4: Level Design
This is the part that probably suffered the most due to the short time frame. I managed to create 20 levels, which was great, but without any playtesting, the difficulty curve was way off and the explanations of mechanics untested. In addition, any playtesting I did was kinda defunct, as I knew what the allegiances of all the robots were (as I had just placed them). So yeah: no playtesting = bad.
I think the levels I came up with demonstrated a decent range of the ideas that could be explored with the mechanic, but often I erred on the side of too easy (apart from a few of the later levels, which go the other way) or on the side of too guess-like. The mechanics of the game can make it easy for levels to devolve into guesswork, and that’s something that I worked to avoid, sometimes more successfully than others.
Part 5: Mechanics/Conclusions
In terms of the overall mechanics of the game, the problems are more in omissions than in alterations: a ‘duck’ feature would be good, and different types of robots would allow me to better emphasise types of gameplay.
One thing I didn’t really get to explore was the idea of the colour wheel. The colours used are the primary and secondary painting colours (not digital colours), and a colour will befriend colours that are next to it, and be enemies with all the others. Even though this was never really used in the game, the decision to do this allowed me to have a pretty nice choice of relationships within levels without ever giving up on consistency.
Another issue is probably the ease of simply killing the evil robots, and the rigidity of the win conditions. Sometimes I should have made it so that the level ends after the timer counts down, and other times it should have put a loss condition of when certain required resources were destroyed.
Overall, I was really happy with this game as a 48 hour attempt. I’m really interested in feedback so I can fix it up (particularly anything on particular levels and their difficulty), so let me know if you have any.
So my entry is complete as of about half an hour ago or so: result can be found at http://paul.sztajer.org/?p=56.
I got pretty much all the features that I wanted into this game, but the lack of playtesting possibly hurt it a bit. Trigonometry haunted me (as it always does in any programming venture I ever seem to take on), and there was a rough patch of simply awful bugs, but generally it all went really smoothly (particularly considering it was the first time I’d really done map editing, pixel drawing, a platformer… the list goes on).
Definitely looking forward to doing this again, and thanks to the organisers for putting this together.
Just thought I’d chuck a ‘hi’ post up before the competition starts (with the obligatory desk shot, taken by a crappy camera that gives my monitors a nice radioactive sheen…).
Anyway, this is my first Ludum Dare (and will result in my 2nd released game), so I’m pretty new to all of this. I’m mainly looking to simply get something done in the 48 hours, and hopefully build up my gaming skills. I blog over at www.fabula-ex-machina.org and will probably do some sort of postmortem of whatever game I make over there.
I’ll be using flashpunk with flash develop.