Thanks for the feedback so far. Just a quick technical update:

If the menu makes problems try typing the Letters (H) for Help, (Q) for quit and (P) for Play instead of using the mouse. (Escape takes you back to menu and from there out of the game as well). Blender as a 3D App calculates the camera, mouse position and menu surfaces in 3D space to determine if a “menu button” is “pressed”. It seems sometimes it gets a little confused. I am confident the great developer community at blender.org will work that out.

The link to the file (http://www.mediafire.com/file/ozdz3zkmfmm/Roadate.zip) does work. People have tested it several times. If you don’t get to the file please check your ad-blocking software.Also the file in the megapack works. I have tested it on two machines (Vista SP1 and XP SP 3).

Again, another possible solution is to see if you can run Blender by installing Python 2.5.2. from here and Blender 2.48a from here following the instructions for the MSVCPP redistributables as well.

If Blender runs, the game should run as well.-

A friend of mine helped me to port my game to windows just after the compo but there were some problems and i didn’t have time to deal with them. Because of that windows port was pretty useless, but now with the help of another friend i manage the got another windows port of my game. I hope this one works.
Click here to download windows port of On The Road.

I realize the compo version had some bugs. One critical bug was I didnt set the frame delta float variable. So when the game loop updated the positions of the player the player was teleported 10 trillion light years away because the delta was so high.

With version 2, there are now 2 levels and a respawn feature. For anyone that had problems with the compo version, I don’t think it would be a problem to vote with this version if you only play level 1.

Enjoy!

http://impellerhead.com/gamedev/ld13_negativegeforce_v2.zip 4.0mb

Sorry about not being around lately to read comments or judge anything. My internet utterly and completely died. Finally managing to get on now at school, I’ll try and get a few more judged and sorry about the rapidshare link, I know it’s terrible but I didn’t have the time (or bandwidth sadly) to be able to search for a more reliable site. Thanks for the comments, I’m thrilled that people are actually looking at it.

Tags: Hughes net is evil

Thanks for all the comments so far! I’ve enjoyed seeing how everyone has liked the game.

Here are a few responses to some of your comments:

– Anyone who said there needs to be a restart button:
I fully agree, so I added one after the contest was over. There are also multiple difficulty levels in it.

– Anyone who said that it takes too long to load at first:
It’s because the sound files are wav, I’ll put them in ogg at some point. This loading time will only happen once, however, as it caches this data on your hard disk. So once you’ve loaded it once (basically equivalent to downloading it) then you won’t have to again for longer than half a second.

– Anyone who said it would freeze and suddenly rush forward:
I don’t know why I did this, but I definitely spent more time to get a dynamic frame rate going, instead of a fixed one. This was I guess to allow slow motion / ultra speed (you can see that easy mode is slower overall than hard), but I also wanted it to be able to adapt to any computer speed so it would be able to play effectively the same speed no matter what it was on, it would just skip frames. Unfortunately, when a ton of particles fly down this actually causes it to skip a bunch of frames. So I’ll either make it take a frame rate average for a longer period of time or I’ll remove this.

– In response to ondrew saying “I have to give technical 1 for the Java App Deployment stuff.”
I have no idea what you’re talking about and I don’t feel this is justified. Did you give me a technical of 1 because you just don’t like Java, or what? Java is a full fledged programming language and does no more for you than C++. I made it in Java because I prefer Java and because I’m on Mac, therefore it’s more accessible to me. Not because it’s easier or something. All of the technical impressiveness of this game (read: particle effects) would have been exactly as difficult on C++. It’s all using direct OpenGL access  which is equivalent in Java and C++. Please edit your review to explain exactly what you mean by “Java App Deployment Stuff.” Thanks.

– In response to Morre:
I totally agree with you, actually. It’s got sort of the basic gameplay in it but not enough variety to be one of my favorite pastimes. If you’re interested, you can try the post-LD version which improves the scoring a lot, adds in a harder (and an easier) difficulty, and also  fixes that score increase bug.

Thanks again, everybody! Hopefully my comments have been helpful as well.

I’ve begun work on the BLDR Postcompo version! The general consensus seems to be that this is necessary. I shall also be using the first versions of my LD/game library I’m developing as a wrapper around SDL. I’m open to suggestions! My current list…

1. New name – Some people seemed to think BLDR was related to towlr, and some vowels would be nice.
2. Improved graphics – The art was meant to be “temporary”, but all too often in Ludum Dare temp art becomes final.
3. Modify to use the new library – save code space, etc.
4. More gameplay elements – at least a few, though I’ll try to squeeze as much as I can out of the basics
5. The roads – perhaps some changes to the way the road system works
6. Animations – so when you die you don’t just get teleported back to the beginning
7. Level editor – level editors are always nice
8. In-game instructions – in-game instructions are always nice
9. More levels – of course more levels
10. Enhanced menus – ways to access all the new features

And I think that’s it about now… time to get going! Comment!

Tags: BLDR, LD13 - Roads, roads

Badass Frog postmortem – the ‘meh’ factor

After my LD #11 ‘Minimalist’ entry was voted “most innovative” game, I’ve been trying to pride myself as “that guy that makes innovative games”. So I thought long and hard about the theme for LD #13, “Roads”, trying to come up with something innovative. But the creative juices just weren’t flowing, and it didn’t happen (I’d also just bought Shaun White Snowboarding: Road Trip for Wii, which was taking time away from ‘designing time’). After 12 hours, with no good ideas for a game I was actually enthused about making, I decided to make a simple Frogger clone – at least this way I could hone my Processing skills, and learn the ins-and-outs of Mobile Processing.

Some thoughts about developing for mobile devices

Turns out there is a whole “other world” of mobile development that I just hadn’t really thought all that hard about.

I’d assumed that the whole write-once-run-everywhere thing would have been done properly for Java on mobiles. J2ME (and by extension, Mobile Processing) would have some sort of smart abstraction layer that makes things behave gracefully across various phones … right ? Wrong. Not so. It has become clearer to me now why J2ME MIDIlet development can be a royal PITA: significant differences between devices – screen resolution and aspect probably being the most immediately troublesome. This will more than likely apply to Android powered devices too, which once they start arriving en mass with various random specifications next year. The Android SDK deals with heterogenous devices in a cleaner fashion, via seperate “resource files” (which looks like the J2ME Polish approach ??), but it still leaves the developer to make sure variations between devices are dealt with. The iPhone, despite having far less handsets out there in the wild compared with J2ME capable phones, has a distinct advantage for developers at the moment … you are essentially only targeting one device (okay, maybe two if you count the original non-3g iPhones, or three or four if you include iPod Touches). That said, no one would be silly enough to believe that future versions of the iPhone will have the same screen geometry and capabilities, so I think the problems have really just been ‘delayed’ for iPhone developers. It will be interesting to see how these problems are dealt with for something like, say, the iPhone Nano.

The Processing language for games

While Processing was designed as a language for coding visualizations, it has pretty much everything you need to make simple games; graphics (bitmap with transparency, vector graphics, even OpenGL 3D), mouse, keyboard and joystick input, and sound (samples, MIDI, basic synthesis, via the minim library, among others). Since it’s actually just a layer built on top of Java, you can also do some more advanced things by incorporating regular Java code, outside the scope of the simplified “Processing” language. Things like collision detection are missing “out of the box”, but rectangular collision detection isn’t tough to whip up yourself. The weakest link is probably the sound support, which seemed a little flaky for me – samples triggered via minim seemed to have some unavoidable lag (others have reported similar issue on the forums). Overall, I’d say its still a fair contender against something like Pygame for quickly mocking up little games. One advantage of Processing over Python programs is that stock-standard Processing IDE can produce executables for Linux, Windows, Mac OSX and a Java applet with about three mouse clicks, no matter which platform you are actually running it on. I searched but didn’t find a decent ‘game framework’ for Processing – someone (maybe me) should write one, since it could do with some convenience classes and functions.

Mobile Processing – what happened to my floats

Mobile Processing is very similar to the core Processing language, but it can export applications as J2ME MIDlets which can run on Java capable mobile phones. I started writing my game in Processing, then ported it over to Mobile Processing. One thing that is missing in Mobile Processing: the float data type. In my simple game, it wasn’t too hard to just change my floats to ints, and with a few tweaks to deal with rounding errors, everything worked okay. But if you need floating point calculations, there are some tricks to deal with arithmetic of fractional values. Mobile Processing is lagging slightly behind the recently released Processing version 1.0, but most of the function name changes are trival (eg, framerate() vs. frameRate() ).

The collision detection issue

A few people have commented that the collision detection in Badass Frog isn’t great. Well, that’s not a bug it’s a feature :). No seriously, it started as a bug, but then I realized that it nicely gave the illusion of making the frog only vulnerable if it was run over by the wheels of the car. But, it probably doesn’t match the expectations of the player, and so feels buggy; lesson learned … cool ‘features’ (aka serendipitous bugs) may not be so cool if they don’t adhere to pre-estabilished conventions and just confuse/frustrate the player.

Conclusions

So, the game I’d produced after 48 hours was extremely basic, and probably not worth more that ~ 1 min of anyone’s time. I did deliberately tweak the difficultly so it ramped up quickly … I figured it was better to kill the player before they gave up out of boredom. As is always the case, I could have done a lot more with it (online high scores, the classic “river with logs” instead of just roads, bonuses ?), but instead got caught up in technical issues; playing with the sprite sizes / layout to get a version that could work on many screen sizes, and getting sound to work in the mobile version. The result was that I learnt a lot about the issues involved in developing for heterogenous mobile devices, but didn’t have much of a game after 48 hours. Summary: simple game, but learnt lots. I’m pretty happy with that.

Tags: android, iphone, j2me, postmortem, processing

I’ve made a direct mac port, it’s available here:

OSX 10.5 (2.3MB)

It’s identical to the windows one. I had been meaning to tidy up both a little bit before this release, but I haven’t had time.

Also, I’d like to say that I had a lot of fun this competition and, though it took some not inconsiderable amount of time time, and also playing through what entries I could; some really beautiful stuff came out of this competition. I look forward to the next one…

Right, now that I’ve taken steps to correct the control irritations in Only Forward (see below for the updated version) this seems like a good time to write up a postmortem for the competition.

What I aimed for:

LD13 was my first Ludum Dare competition, and whilst I’ve previously dabbled in coding with tight time limits it’s the first games competition I’ve entered into, so it was all pretty new to me.

My goal from the start was to try and make a game that was essentially complete/polished etc.  I was less worried about managing something technically impressive, or dramatically original, I just wanted to *finish* something in the time.  This ended up shaping the majority of the game, I picked the concept I did because it required minimal simulation, the graphical style because I wouldn’t need to make too much etc. etc.

What went well:

I’m really happy with the direction I took, and particularly my choice to bite off as little as possible.  I ended up being able to get the core gameplay, graphics etc. down very quickly, and that left me with a lot of time to polish and polish.  Were it just a prototype (say what I had at the end of day one) I’m not convinced it’d have been very good, but I’m pretty happy with the fleshed out version.

Following (not quite to the letter, but not far off) the Survival Guide paid off to, it’s a very good set of advice.  I think even the time I spent blogging/on irc/or cooking all ended up helping me keep sufficiently distanced to be able keep polishing and improving something despite being so close to it for such a short length of time.

What went badly:

The controls!  I was a little bit worried about them from the very start, and with all the time I spent polishing the rest of the game I could have easily taken the hour or two I’d have needed to do something less frustrating.  I think the problem was that by the time I had the free time to deal with such things I was so familar with the controls I’d put in earlier on that they just felt natural to me.  I should perhaps have got more feedback during development (and listened more to that I did get).

The other issue was that I couldn’t really see a simple solution and I didn’t want to spend time faffingiaround on something that might not have even worked.  The solution now seems very trivial with the benifit of hindsight, you just allow directions to be pre-selected before the junctions.  It’s the only thing I’m *really* unhappy with in the game, and as such I spent a little time fixing it.  The updated version can be downloaded from http://jwhiting.nfshost.com/coding/onlyforwardfixed.zip it is perhaps worth mentioning that the only thing I’ve changed is the controls, and also that if you’re still judging entries do play the genuine entry instead. The updated version for the unlikely event that anyone wants to play a better version after they’ve made their mind up.

Conclusion:

Wow, that was a bit more epic than I was expecting, congratulations if you’ve just struggled through all of it!

Overall I really enjoyed the competition, I’m definitely looking forward to the next one (fingers crossed I’ll be able to enter it).  It was all a lot of fun, and some extremely impressive stuff was done (just not by ‘safe option’ me).  I’m quite looking forward (only forward, har har..) to seeing the results tomorrow too, I never thought I’d care about that side at all, but it’s kind of exciting nonetheless.

Tags: postmortem, update, updated

Time for another mini Ludum Dare competition. This one will take place on the 10th and 11th of January, since the first weekend is very close to the holidays.

The idea behind this one is, to take all of your entries and bind them together in what would look as a single game. To achieve this, this MiniLD will have to themes. The main theme, the red line of the competition, will be the same for all, and set by me. The second theme you can pick out for yourself from a list of themes and reserve it for yourself.

Technical details, start time, etc. will follow.

Tags: announcement, MiniLD #6

Congrats to increpare, bluescrn, PsySal and to all the rest!  And a big thanks to those who stuck around to vote on every entry.

Get the results here!

I just wanted to thank all the people that graded my unfinished game.  I’m very apperciative of all the encourging comments.  Many of you will be happy to know that I’ve continued to work on the game and will keep you posted!  Finally, thanks to the mysterious super secret ludum dare organizers.

Tags: MrPhil

I’d like to thank everyone for helping out with my first experience in LD, especially on the IRC. I was dumbfounded as to what to do with the theme of Roads, but thanks to just randomly typing on the IRC, I got my idea (Very poor, but an idea nonetheless). I know my entry failed, and broke a few rules (audio, pictures of chuck norris 😉 ), but I had fun with it, which is the most important part. I’m eager to see what we have next time around. Hopefully I’ll have a better idea of what to expect of everyone else, and what to do. See you all when LD 14 comes about!

-Brandonman

First of all, thanks so much to everyone who left feedback to me in the ratings area.  I have taken a bunch of the suggestions that people made and have worked more on improving CoMuTor in the past 2 weeks.  Here is the latest work in progress of a post compo version of CoMuTor.  The readme file contains all the changes that I made so far based on my own and others feedback.  I welcome further feedback in the comments on this post for anyone that liked CoMuTor enough to try and play it again.  I’m just having fun working on aspects of polishing and modifying this silly little game.  I look forward to more Ludum Dares!!

CoMuTor v1.1 – Post Compo win32

Changes from compo version:

– added visual score feedback and level indicators
– added 3 minute time limit
– made it harder to eat people
– points scale with faster/smaller vehicles
– rebalanced point system
– rebalanced timing / car release system
– vehicles have different speeds now
– added people to vehicle sprites
– broke out car and suv sprite body for better coloring system
– crushing gas trucks no longer counts towards crush count
– vehicles running into you no longer spawn people
– adjusted menu instructions to reflect new changes

Tags: comutor, gosu, postcompo, ruby, update, win32

Because there was some confusion around my previous post, here is a more detailed description of the way this MiniLD will take place.

At the start of the competition (which will be anounced soon enough) i post the name of the main theme, and a list of themes, that the competitors can select from. A competitor selects one theme from that list and writes it’s name next to it.

The competitors then creates a new game from the main theme, and the theme he selected from the list. The game doesn’t have a menu, insteed it should just have a simple start screen with brief instructions.

After 48 hours the competition end. Each submited entry for MiniLD#6 is then taken, and loaded into a framework which I will create. The entries are then run inside the framework, like levels of a game.

For now, the platform of interest will be windows. If it will be possible to port all the entries to linux and mac, then hopefully there would also be a version for those platforms.

In a nut shell: you get two themse, create a simple game, I take that game and stick it together with other entries, creating on bigger game.

I hope this is clearer than before. 😀

I know that it is late for such a thing, but I still will give it a try.

It was my first Ludum Dare, as also was for many others. My first mistake was using only the first 24 hours of the contest to finish my game. That was because of the fact that the game got more and more detailed in time, and it began to get harder and harder to test the game, which ultimately resulted in me getting bored.

What did the design consist of:

A post apocalyptic world, the ability to build hotels, oil wells and gas stations, fighting different types of mutants and enemies, a story which allows the player to take two different paths, increasing difficulty, the ability to empower your gun and get more and more guards(which had a bug), gambling(which I ultimately removed) and random encounters.

What went wrong:

It was just me, I think. If I had used every bit of my 48 hours, this game would’ve had turned out to be great. But the changes in design and UI pretty much made the game unplayable except me. A programming error in guards which caused the game to crash when there were no enemies was the only critical programming error, I believe. The rest were just results of laziness. The tutorial also was incapable of teaching every aspect of the game.

There still is hope:

I am still developing the game and the engine further. This time, the game will take place in a low fantasy world. The map is now more detailed with randomly generated names, towns and quests, as well as loot. The boring battle part is also removed from the game, to be succeeded by a old prince of persia-like fighting system (I also plan to implement a guitar hero style swordfighting mode). It will eventually be released, though not in this year. It is to be named “Sanity’s Eclipse”.

Wow, I’ve got the best food, and the second best journal.

Hahahahaha.

I can’t say I expected that, but I did expect EIR! to land just about where it did in the other categories. 14th overall, with my other places in that ballpark. That’s top 24% which really isn’t bad, and I said to myself after playing everyone else’s games, “it’s one of the better games but not one of the best games.” And I was right.

One thing that I learned from this whole experience which I hadn’t gotten from my previous game ventures was a chance to see what’s successful. After creating them I think I have a good feel for which of my games have something really good going for them and which don’t, but that’s different than being able to specifically point out what gets acknowledged by the community as “good.”

So, what is good? What does that really mean? In Ludum Dare 13, it means something that looks complete, and not something that looks like it was made within a time limit. The vast majority of the entries to LD13 were more like demos and attempts than completed games (mine amongst them), because people would finish an engine and time would be up. The top 5 places in overall could all be described as games that  set out to achieve something and did it. Complete products, no holes anywhere. That, I believe, is the most important piece of doing well in a 48 hour competition.

There’s more to it than that, obviously. The game needs to have something unique in it to set it apart. Some of the games submitted were complete but didn’t do amazingly well, mostly because they didn’t stand out enough. Increpare, the big winner of LD13, made something that any one of us could have done. His gameplay is crazily simple, the execution of it not at all complicated. But his idea is so standout and brilliant that he went away with 5 medals, all of which were gold. Then there is PsySal, who weaved an engrossing story, and bluescrn who who executed incredible gameplay. All of these approaches are different, but the key point is that they all stand out.

Similarly, you also need to have a sort of minimum level of execution in every other category. If there is one part of your game that is memorable because it’s bad, then you’re pretty much out of the running. When I saw the initial screenshots of these games I thought Fiona’s entry was a surefire winner, because the presentation is so slick and the idea so cool. But when I played it the controls were so difficult that this potential was immediately eliminated. Meanwhile although increpare’s gameplay was ridiculously simple, there was something about creating that movie length time limit and the maddening screw-you-over mechanics that made the gameplay good, and some people spent a lot of time trying to get to an “end.” His gameplay certainly wasn’t the best, but because it wasn’t at all bad, his game was able to seem like (and become) a winner.

So, in the end, what you need is:
1) A complete-feeling and polished game.
2) Something that makes your game stand out.
3) No major or easily noticed problems with your game.

Easier said than done, of course. But the most noticeable thing to me is that bells and whistles and complexity of gameplay are completely unimportant. It’s much better to take a simple idea and make that work perfectly.

12th in Overall and 5th in Innovation. Not to bad for a bugged game I guess. It sucks bigtime that I bugged mission 5, which means nobody got to play the “speed” mission.

The good

The graphics where not great, but people liked them. I’m so glad that I went with the simplistic line style. It saved me time doing graphics and I did not have to load any resources. I only spend like 30 minutes on the car graphics and the line drawn font.

Box2D did a nice job, while I could have tweaked the controls better, the engine acted fine on large load. My biggest fear was that the large amount of ‘objects’ that I created would slow the engine to it’s knees. Special thanks to Erin Catto (creator of Box2D) I think I scored points just because I used this engine.

Time, I never thought I could finish a game in 24 hours (I noticed to late that LD13 was that weekend, and had other plans made already) but with cutting some corners I did finish something. I’m surely back next time. (with food photo!)

The Bad

I should have taken the time to add some sound, and test everything. I broke mission 5 just before my final compile, and I forgot to add the frame limiter (if you run the game at 120Hz the game runs twice as fast as on 60Hz) a few simple tests could have catched this.

Controls, I never got the high speed stearing right. Not sure how to fix it, might need to change the stearing angle depending on the speed. Or ‘fade’ the stearing from zero to max-stearing when you hold the button, instead of giving max-stearing instantly.

The map generator has some issues. The AI paths generated are fine 95% of the time. But sometimes they where just plain wrong. As I spend most time on the map generator I still had to make a game after that.

The AI was stupid, too stupid. They piled up so easy, there is some “teleport yourself away when stuck and not seen” code just to keep everything moving, but that didn’t prevent jams, it just solved them when you where away. I made up the game name later to make up for it a bit.

Also the lack of chooses for the player made the replay value low. After you got to mission 5 there is not much left to do. And if that one worked you got 1 more mission and just random old missions after that. You don’t upgrade anything, surroundings never change, and you never get to shoot anyone. I got the feeling that I could do a lot more in 48 hours next time.

Roads to Nowhere Post Mortem

Tags: post-mortem

Woot! My article got featured on gamedev.net:

Better Programmer Art: Or how to fake it as a game artist.

I use a lot of examples from past LD48 games (mine and others), and most of this is stuff I’ve learned through doing these contests. Ironically, in the most recent contest I didn’t have time to replace the placeholder art so it pretty much ignores all of these tips. 

Hope this is helpful to the community. Enjoy!

Jovoc

Tags: art, article, programmer art, sprites