8 hours to go, and what’s this? Joining with tradition of posting food pictures, I present to you my tasty dinner for the weekend (and today for that matter):

This:

Became this:

And This:

mmmm *drools all over my monitor*

You can download it here! (windows only for the moment, I’m afraid)

On a totally unrelated note, there’s a contest-like-event taking place this weekend that I’d like to let you know about – RPGDX are hosting a 48 hour RPG making jam! The theme is LoFi. More details here, if you’re interested!

Some time has past but I still wanted to finish my LD13 project. Maybe some of you remember the big 3d-bug I published! Hehe…well the game is still not very intuitive but I added instructions, fixed lots of bugs added some graphics and models! I would say it looks almost like a game! And that was my task! I learned a lot as it is my first game I finished.

Have a look here:

http://thomas.trocha.com/wp/?page_id=19

plz read the instructions in the game before starting!!

Here is a video-tutorial how to survive the first three levels. Maybe that will help to get a clue what the game is about .

http://thomas.trocha.com/wp/?page_id=88

Now I can start finishing my miniLD Cryptogame! (On LD#14 I will finish in time! I’m sure )

CU, ToM

PS: I want to thank everyone who tried to figure out what the first version was about! I know that must have been a hard time that surley was followed by massive nightmares!

I finished the songs that I posted for the LD Christmas Album weekend (‘All I Want for Christmas is Presents’ is now all Phil Spectoredy, yay!) and recorded a few more. Then Ian did the lion’s share of everything else (He even made an incredible 8-bit song, The Ice Storm, that makes me wish I could us him for Ludum Dare’s). Anywho, here it is:

http://www.devonscott-tunkin.com/nonweb/xmas_album.zip

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

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.

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.

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”.

I’ve added some stuff to the game, mainly the option to generate random tracks (and save/load them). Also I added mouse controls for one player, in case keyboard sharing gets uncomfortable. Furthermore, there’s a fullscreen mode and slightly different track graphics.

The game still starts up with the same default track, and the gameplay code/simulation hasn’t changed.

Download here: soltcras.zip

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

-Brandonman

Get the results here!

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.

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…

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.

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!

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.