It’s only 1 AM, but having never programmed a basic platformer before, my meager attempt to get jumping has failed miserably for the past 2 hours or so. I should probably finalize an idea first. All of them are probably unoriginal, though I have a few scenarios I think are interesting. I think that’s what I’ll do. I keep of thinking of ideas and then settle on making the game on the most interesting one, not necessarily the one I think I can get done on time. How else am I supposed to improve if I don’t push myself? For, now, G’night!
Archive for the ‘LD #11 – Minimalist – 2008’ Category
Maybe this is what I should have been doing for the last LD… It took me two days to make and it’s based on the code of my LD11 entry (I didn’t even miss Felicity!)
Making “just a game” was kind of enlightening, since I didn’t have any real technical challenges to overcome and could just get on with content and putting in simple control logic to make it all come together. It’s pretty much an unthinkable project viewed in terms of what I’ve been doing the last few years, but since both development and result were enjoyable it’s a pretty clear hint that I should be doing it more often.
However, I ruin that immediately by having a natural impulse to make some kind of convenient editor/engine which would reduce the need to write copious amounts of replicated-but-slightly-modified code for instance when I want new enemy types etc. I have made these before, and each time I end up spending weeks or months working on it and then never really use it because I get increasingly unhappy with how it’s built. Still, I couldn’t possibly make a game of say 10x the complexity/scope of this one without using more structured code at the very least. And defining animations, scripted events, enemy patterns etc would quickly get tiresome and repetitive to do in code+Photoshop if you have more than one or two types to deal with. The grunt of this game (discounting image loading and input code) is a 1500-line C file, where almost all logic is directly in the main loop – wonderfully spontaneous way to work but of course breaks down with increased program size due to convoluted value/flow dependencies, loss of overview and the need to repeat code.
The fact that I did manage to create this in just two days though, and that I didn’t run into any major hickups along the way, probably says something about suitable code vs application complexity. If I had gone and made “a perfect design” with fancy classes and streamlined algorithms for everything, I would most likely not be done yet. More importantly, I probably wouldn’t even have started since such a small project doesn’t really justify that kind of work. Not without the prospect of a larger product coming out of it, and if there was one I would probably be too intimidated by the thought of that and keep trying to out-think myself in terms of what stuff I’d need to make that “great big thing” work eventually.
I think Derek Yu recently said something about coders being able to “doodle” games like artists sketch with pencil and paper, and that’s probably an important thing. A sketch is never meant to be used for anything substantial, it’s just playing around with the tools of your trade to make something spontaneous and fun. If it turns out nice then you could potentially do it again from scratch but “do it right” and expand on it if you wish – but you should definitely not be doing it the roundabout way to begin with since that would destroy the spontaneity and make it a laborious task instead of a free-minded sketch. When sketching you can only use whatever skills and processes that come natural to you, without considerable planning or conscious mental effort. Of course, with increased experience this set grows larger and some people could probably do advanced class hierarchies without thinking too much about it. All the more power to them.
Since I made this thing in such a short timespan, I have a pretty good overview of all the techniques I used and the bare-bones code needed to make them work. This could provide some extra value when designing larger game systems as I might be able to target my efforts more carefully, and not get overly general or implement pointless things. For trying out pure game ideas though, I still feel that it would be sensible for me to “sketch” in a more streamlined tool… a kind of game maker for sure, but definitely not Game Maker (for the simple reason that I’m incapable of using any tool that is close enough to what I could potentially build myself, which is a most unfortunate condition in terms of productivity… but creating a tool to fill some (possibly imagined) need of my own is just so very rewarding)
I put up an article on basic sound synthesis yesterday. It had been requested by some folks. Touches on fundamental aspects of sound in general as well as more specific details relevant to classic retro waveforms and the kind of stuff sfxr does.
What worked well:
- Building a good infrastructure: Clean object system & usable level editor = worth a lot. I only really started building levels around the 40 hour mark, and that worked like a charm.
- Cutting stuff in the end: Music wouldn’t have helped me a lot. Not having an ending was smart too: Everyone who noticed that must have liked the game anyway
- Ruby, together with an ad-hoc autoloading mechanism, made for one of the smoothest coding experiences ever.
- TIME MACHINE! I knew I’d need a backup system sooner or later (turned out to be true), but I really didn’t feel like bothering with Subversion because I always forget to add files etc. and it wastes time, so I just watched Time Machine do its background work every hour. Boy was that a relief.
- Periscope: While my timelapse wasn’t highly interesting, it only took two clicks to create, so no time wasted here for a low score
What didn’t really work:
- People had various problems with the gameplay (controls, motion sickness, …), and even if I knew that earlier, I probably could not have done much about it except getting into a panic.
- Needed to do more optimizing than I usually do, and some levels are still slow. Will revisit this and try to improve on this from the Gosu library’s side.
- I had a cold that made thinking pretty hard. Anything that involved maths was buggy, which caused a minor panic just before the deadline. It also made IRC very hard to follow
Next time’s plan: Keep the solid workflow, hope that the game concept works out better with regards to the Fun, and consequently Overall category, try to be more experimental technically. Can’t wait
Also, did anyone play the game with a gamepad? Would be cool to know for the next time, because it was hard to decide between a small ending screen and gamepad support in the last few minutes Thanks!
Firstly, I’d like to thank everyone who voted for providing kind and constructive comments in the voting area. They’ve really encouraged me to continue developing this game. Keep in mind when reading my comments that I too am trying to be constructive, and I’m not trying to come across as a complete butthead. In my mind anyone who even got half a final entry completed has done an amazing thing in such a short time. Secondly, let me apologize for including a few levels that were far too hard …. actually I’m almost certain now that they were impossible.
So, I’ve prepared an updated version of Mondrian for those who’d like to play it. I thought I’d leave this release until after voting, to ensure that nobody could accidentally judge based on the non-48 hour version. You can get the latest version a my OMGWTF Games !!1! page. This new updated version includes: (more…)
I’ve found out that level mode is troublesome on Vista system. Running my game in a browser solved that problem. However, performance goes down a lot in the browser. To get decent framerate shrink the browser window until it feels good. Here is the game
Same as the exe but online.
Here’s a new version of Minim Madness:
- Completed in-game instructions.
- Added easy difficulty mode for people who found the original too hard. Activate it by pressing D to toggle difficulty.
- Added playback/recording mode.
This version includes some recordings of me playing the game. There aren’t any new levels, but hopefully I’ll manage another release in another couple of weeks.
While I was doing the compo (and before), my computer was suffering from a disease I like to call “imabigstupidjerkofacomputerandimgoingtofreezeeveryfifteenminutes”. It made coding extra fun, but by the grace of Billy Idol, I managed to submit something.
I noticed the comments and stuff on my entry about it basically being a piece of junk, so I went back and (hopefully) fixed those bugs. Yet my computer was apparently just being a saucy taunt-face, because pretty much right after I’d packaged and tested the bugfix release, the thing froze before I could upload it anywhere. It now freezes about one minute after it starts, thereby disallowing my every effort to get the update posted.
In all fairness, the computer’s about six years old, which I think is a pretty impressive lifespan for a laptop which I’ve worked pretty hard every day I’ve owned it. I guess Ludum Dare must have been the straw that broke the camel’s back.
Anyway, in summary, I won’t be able to get the new, fixed, maybe-working-for-Windows version up before the voting closes. If you can’t get it working on your system, feel free to judge it on the last-minute drunken stupor of a README and the sexy graphics in the gfx directory.
Also, I’m not going to be able to really rate anyone else’s because I only have access to computers which are not mine to install dodgy games on (no offence).
Peace out, and good luck to everyone whose computer isn’t a steaming pile of wreckage!
Say thanks to keeyai for making this exe!
In one 48 hour period, I made a simple game based on the theme “minimalist”. I didn’t try to stay awake throughout the entire Ludum Dare competition, so the game was made in less than 48 hours.
What Went Right:
- Used my build script to create a distributable game from the beginning.
I have a build script from a previous project that allows me to use a single command to take my project source, build it, and create a .tar.gz file to distribute for GNU/Linux users. Towards the end of the competition, I wasn’t spending too much time trying to figure out how to get my project into a judge’s hands since.
- Mouse control was easy to do and easy to use.
Since I was learning SDL, I tried to make my game as simple to use as possible. I knew that using a mouse was a lot easier than expecting someone to use the keyboard, but I had never implemented mouse control in a game before. Luckily, it turned out to be very easy. As a result, the interface was very simple since you’re just moving the mouse around, and the game that this interface produced was better for it.
- I got really involved in it.
I had food photos and a time lapse video, and I even received two trophies, one for my eclectic food choices. Hanging out with all of the other Ludum Dare participants, even if just virtually through IRC, was a lot of fun.
- I finished!
Of course, finishing was also a lot of fun. While I could have used some more playtesting and would have loved some feedback before it was submitted, I think I put together a decent game in a short amount of time. It feels good to finish things.
What Went Wrong:
- My work environment was horrible.
A couch is comfortable…but not for marathon game development sessions! My back still hurts. I need to clean my office. Right now, I am using it as a giant inbox:
I prefer development with my laptop because the CRT of my desktop is harsh on my eyes. Still, it would be nice to sit in a real chair while working. Alternatively, I can finally buy an LCD for my desktop.
- My cats love to hang out with me.
Even if I was sitting in my office, I know from experience that my cats would still jump up into my lap and try to rest their heads on my arm. When you’re using a laptop, there isn’t room for it AND a cat or two. Having an office door to close would help, of course, but the cats were quite a distraction for LD#11.
- I didn’t practice using SDL before the competition.
It was a problem especially since I had decided not to depend on the Kyra Sprite Engine for future projects, but I really only used libSDL for input and creating a window prior to this project. When the first 24 hours are finished and all you have is a window rendered and the knowledge that the mouse handling is working (even if it isn’t visible), you might be afraid that you won’t have anything to show at the end of 48 hours. I did manage to pull it off, but by the next competition, I want to be able to work with less of a focus on technical details and more of a focus on game development.
- I spent too long in the beginning trying to mock something up in the GIMP.
Similar to the previous point, I was spending more time on technical issues than on creation. I thought I was more familiar with the GIMP than I was, and I spent a lot of my early hours fighting with it instead of just using pencil and paper. The worst part about it was that the initial idea was one I ended up discarding, and if I wasn’t wasting time with figuring out how to do some simple things in it, I might have been able to figure it out sooner.
What I Learned:
- My kitchen goes to entropy during LD.
When you’re focused on game development for most of your waking hours for two days, other things have to take a lower priority. One of those things was cleaning. I had a bit of a mess to deal with after the competition was over.
- Even something incredibly simple can be a good game mechanic.
I knew I wasn’t going to be drinking multiple cans of Mountain Dew or Red Bull, and I don’t drink coffee, so staying up for 48 hours wasn’t going to happen. I needed to work on a game I could finish, so I picked the simplest thing I could. Surprisingly, it was fun, and some of the judges have said so as well. At the end of the competition I already had a list of ideas that could improve it, and I hope to release an updated version with those improvements.
- It’s possible to do a lot in a single day.
Even though I spent some time learning how to use SDL, I still managed to make a game. The best part is that I can incorporate what I have learned into my personal library of code for my future projects. Also, there were over 70 games submitted, and it is amazing what some people were able to do in 48 hours. Some of them were learning how to program!
I set aside most of a 48 hour period, and I have a game, some new code, and more experience. If I could work on a project with a similar scope each month, I think it would go a long way towards improving my ability to create video games. Also, it’s a lot of fun, and I will definitely be participating in future Ludum Dare competitions.
From reading the comments, I got this feeling that not everybody has understood how the grinds and walljumps work in Tiny Hawk. The way you do them is you have to be holding the button when you hit a rail or a wall. Most commonly, you’ll do a jump and you’ll keep holding the button until you hit the rail or wall. Also if you’re walljumping up a tall column, just keep on holding the button, you don’t need to let go for each jump. The walljump is actually kinda buggy, and won’t always work if you’re falling down. This is because the game thinks you’re landing on a tile instead of hitting it from the side. I’ll likely fix this at some point. Also if you hit a rail on the very edge, you might hit the rail but fall off instantly. I’m going to call that an unintentional feature, because it’s kind of a neat thing that you can “almost” hit a rail.
A lot of people have been asking for a button for changing directions, but I think that not being able to turn around and playing the game with just one button is a pretty big point. I’m probably not adding that in. The actual problem is of course level design. There should be more blocks around so that you can bounce off a wall if you want to turn, or climb up quicker if you fall down.
Anyways, people seem to be liking the game, so thanks for that. I hope this little explanation clears things out (if there was anything to be cleared).
I must have screwed up the build somehow. It runs OK on my MacBook Pro, and I did bundle the Bullet/SDL libraries, but it seems others have had the bus error (and someone else was able to launch it, but the graphics didn’t work properly). I’ll try to fix it and post a link to the working version (if anyone is still interested…). Should be possible to compile and build it also, on any Mac, if you download Bullet and SDL.