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.
I would have posted this version earlier but I just took a week off to tour a college and didn’t bring my laptop.(which was a stupid mistake on my part considering all the free wifi.)
There Is No Screwdriver
Fixed an error of being able to leave the first room without actually opening the door.
Cleaned up the code slightly.
If there are any other bugs or if anyone has comments feel free to leave a comment for me.
In response to this comment, “What no one else has said so far is … what the hell kind of class names are those? “Thing”, “Dood”, “Baddie”, and “Shoostings”? =P”
Yeah, I really don’t normally code like that. Right at the beginning, I couldn’t think of a good base class name for what became the polygons. It wasn’t the player, and it wasn’t the enemies, because it was both. I ended up just putting ‘Thing’ there to get the ball rolling, and it all went downhill and into the gutter from there. After thing came Dood for player, then Baddies, Shoostings, and Lewt.
I talked briefly about this in IRC: It was pretty funny at first, but, since I don’t normally code like that, it got to be confusing and bug-inducing later on when I couldn’t remember if I spelled it lewt or loot, dood or dude, etc… Back in college I had fun telling stories / being clever with my variable names, but generally, I recommend picking a reasonable naming scheme and sticking to it, especially with a deadline no more than 48 hours away.
Still, thanks for noticing. I hope you got a kick out of it.
The only changes in this edition are to do with making the game play a little nicer with some people’s systems. If you’re computer supports 320×200 resolution in fullscreen, and is 32 bit, you should find very little difference between the previous release and this one. If however you have a 64 bit operating system, would rather run the game in a window, or can’t support small resolutions in fullscreen, you should download this 800×600 resolution version:
There are no gameplay or balance fixes, as I am saving game updates for post competition.
The biggest problem people are finding with the game is with the control. I did conciously choose to use sim-based controls rather than arcade, as I find them much more interesting. Unfortunately they seem to be harder to pick up than I realized. As for future versions, I’m not sure how much I am willing to dumb the controls down, but I’ll admit they might be a little excessive at this point. One thing I had been planning to add at some point were better ships that had more engines (perhaps a reverse thruster) or better engines (easier turning).
Personally I do find the control a little hard, but also a lot more fun than it would be if there were velocity or angular speed limits. You can’t just hold your thrusters down, because you will continually accelerate (both in turning or moving forward). Just a little bit of force is enough to get you turning. If you want to turn faster, hold it down more. If you want to turn slower, hold the opposite key slightly. I am really glad I tweaked turning before release (It was twice as fast before one of the final changes I made), but apparently I didn’t tweak it enough.
Game balance in general is pretty random I admit. I spent the majority of my time on physics, particle effects, and ai, saving the very last few hours to actually balance the game. Not only are the trade runs rife with exploits or the planet names rediculous, but the random spawns are far too random, and most enemies shoot too fast to put up with them. For the immediate future, I hope to have some variety with enemies, and keep most of the starting areas much safer. I also want the game to be less random in general, with more simulation behind the scenes. I just didn’t have time for this before. The game would be more satisfying if you could go toe to toe with some enemies more often, instead of having to constantly run away I have had a few fights that were very exciting and winnable, but they are very rare. It’s also possible to be killed 3 seconds into the game, which is just dumb.
There is also a bug with the planet police. If a pirate attacks you and manages to hit a civillian ship, the police will come out and think you are the culprit! The police were invented to protect the exploit of camping the civilian ships for all of their cargo. (If you haven’t ever won a fight, you may not know that ships drop cargo when they die) So I made the police extremely tough. As a result of the bug and the strong police, any fight near a planet will quickly result in destruction, as a stray bullet from the fight hits a civilian ship
I also received several comments to this effect: “This game is so tiny! But how does it fit the minimal theme?” This may have not been communicated adequately, but I went for minimal window size and minimal code size. I also went for a minimal space sim, and there weren’t any features that I felt I could take away. But the screen size was the main source of minimal. This fixed release kind of takes that away, but I suppose it had to be done.
I will be improving this game once voting is over. First I will tackle the bugs, and then I will tackle the spawn system. I plan on adding some semblance of story or an overall goal too, with trading being a means of completing that goal; and numerous interesting events and things to see throughout the system. I don’t plan on adding any form of hyperspace, and I probably wont add quests like they are usually implemented. Oh yeah, and there will be a way to save your game! I’m real sorry I didn’t have time for that one
I’ve made a few improvements to Col-4, so that now at least I think it’s fun.
Relevant changes are:
– Smaller playing area, but higher.. kind of
– Different speed scale
– Special block
– Now middle area swappable instead of the upper one
– Preview of next block
Download source and Windows binary. Extra clarification note and reminder: this is post-48h, and shouldn’t be used for the voting.