So right now I have a crude flight simulator where you guide this here airliner in 3D with the arrow keys. Works surprisingly well, and I’m enjoying it. Might get complicated and confusing once I introduce the restricted airspace I had in mind though, but we’ll see. That’s next.

kohina.com for soundtrack

Download for those who want to play right now. Win32 exe, control with arrow keys. Let me know if it seems broken and I might rush to fix it before I go to bed.

This game is more of a resource management affair, with few action elements. All the islands are fairly small and circular in shape. You start out on one of them with a small land vehicle which you can move around. From this vehicle, you can send a probing ray aimed at the mouse cursor, used to measure range. The intended purpose is for you to drive near the edge of the island and measure how far away the next coastline is, and if it would be viable to build a bridge over there. You have a supply of resources for this purpose, like fuel, metal, and wood. There could be different kinds of bridges to suit different situations of resource supply, like wood/metal/concrete bridges.

Anyhoo, if the range checks out, you would start bridge building, which would be automatic and animated in some fashion. When the bridge is complete, you can cross it to visit the other island and harvest its native resources. One alternative system for resource handling would be that you had a swarm of builder agents that would scurry between the bridge being built, and back to connected islands with resource supplies. They would gather material and bring it back to the build site. This way there would be no global material reserve, but it seems like it could turn out kind of complex and tedious to have build time and efficiency depend on the network of bridges, possibly having the drones move all across the map to get things done.

For deciding where you want to build the next bridge, you could detach a helicopter module from the main vehicle and fly over to other islands to survey their contents. Small icons and proportional numbers (like “5 Oil” and “3 Rock”) would pop up when you get near them, or when you land. The helicopter would consume fuel, and have a limited tank capacity. That could mean you end up stranded on an island, and you would have to build bridges to reach and salvage it before it can be used again.

I’m not really sure what the overall goal would be, and if the game should either be win/lose or just sandboxy. Sandbox would probably be the best option, with some tweaking to make it apparent that you’re doing well or not, depending on how you play. One idea that could shake things up (pun!) is to have islands randomly rumble and crash into the sea, taking connected bridges with them. This would mean that you’d have to build new and longer bridges to reach some areas in case a key island was lost.

It might be possible to layer a different and primary mechanic on top of all this, where you perhaps shuttle creatures or other artifacts between islands in some way, so there’s something to aim for and always something to do (they want to go from one island to another, then back again or move on somewhere else). In that case, bridge building would become secondary but still the main important task you perform while playing.

That’s all there is, and you can’t play it. I would probably have started prorotyping one or both of these if I hadn’t made the questionable decision to spend my weekend doing really boring Sculptris code. I didn’t feel like I could relax and start on something else before that was done though, and in hindsight I’m glad that I have the boring stuff taken care of so I won’t have to do it tomorrow.

As always, good luck to those of you making games, and I look forward to browsing the entry masses later. One perk of not participating is that there’s no pressure to vote, for once

The core mechanic has you driving a boat/car hybrid through a kind of archipelago landscape. There’s a jump button, and with each jump you transform between boat and car. It would probably be allowed to switch again in mid-air if you find that you will end up landing on the wrong kind of terrain. Landing inappropriately would lead to explosion and restart/respawn. The transformation would occur as an animated flip/roll along the length axis of the vehicle, so in theory it could actually be built as a car with a boat “on its back”.

Hopefully driving this contraption would pretty much be enough fun to entertain for a while. There would be some nice skidding physics, with the boat having less grip than the car. A bit like my old netboats game.

For added gameplay though, I figured maybe you could be fishing with a trailing line, gathering fish from schools/swarms that roam the waters and casually try to avoid you. You could add any number of fish to the line, but it would also add mass that would make it harder to control movement, and it would also attract sharks that want to eat the fish and/or you.

As an extra twist, to incorporate the land areas and encourage you to actually drive from time to time, I had a weird idea that you could get on land and drag the fish around as bait to lure tigers from the shrubbery, and catch those on the line as well. In the end, you would head back home to a meat market (X) where you score based on the catch/combo.

Not exactly sure how the various elements would play out in the end, but it seemed like it could be a bit of oldschool arcade fun. The playfield would be much larger than indicated on the sketch, with some areas of alternating land/water/land which would be tricky to navigate without losing a lot of speed or crashing. Perhaps seagulls could be chasing you as an incentive to keep moving quickly.

EDIT (after sleeping): Well, of course I had fun at one point, particularly while animating the character, but after that I started to mess up everything and got increasingly tired and hangry.

I learned some stuff though, and it would be interesting to attempt a similar 3D platformer thing with less rush and more polish. Maybe next LD. Remind me to start before half-time break.

I guess a download link is in order: Get it –here– or at the final entry post.

Here’s a collage of notable screenshots produced:

The first raw version ran at an abysmal 1 fps or so at 640×480, but after adding some biliearly filtered variable resolution rendering based on image-space local contrast and threading it to use dual cores, I managed to kick it up to some 20-25 fps for “friendly” scenes (meaning not too much visible edge detail).

Most of the screenshots are from “bruteforce” renders though, showing no optimization artifacts. The optimized version has a mild muddy/compressed look. Putting all of this in a shader would result in much simpler code and greater performance with no visual degradation… I might have to try it some day.

You can download the (messy) source and a few builds here: drpetter-minild-ds.zip

I also made a quick tune based on one of the drumloops given: destroyloop.mp3

Overall it was a fun weekend. Sorry for not producing a game…

Download: DrPetter_LD14_Advance2.zip

Play online: http://www.cyd.liu.se/~tompe573/ld14/

Well, this looks weird.

On my own two feet here. Disregard the Eee, it’s just there to match all the other deskphotos. I’m not going to use it… The little black box beneath the keyboard is my high-tech entropy supervisor, which monitors heat flux in the immediate vicinity of particular computational elements. Calling it a common household thermometer would be a blatant lie!

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

Win32 package: drpetter_ld13_soltcras.zip

(might be portable, for those who feel like compiling… get portaudio and glfw)

(edited 28 minutes after deadline adding a simple framerate limiter to make it playable if vsync doesn’t work)

original, packaged before deadline: drpetter_ld13_soltcras_old.zip

Download and poke around a bit. You might have a minute or two of frustration fun: drpetter_ld12.zip

Download over herely

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 actually had fun this time around, but mostly with irc and blogs rather than actually making a game of my own. Maybe next time.  Now sleep before getting on with all the games!

Giddit: marge.zip (windows executable, and a bunch of code that you probably don’t want to try compiling)

Here’s an image I cooked up to help visualize the problem:

The problem is deceptively simple: Determine what angle to fire a bullet in, if it is to hit a target that’s moving past you at a constant velocity. In other words, both objects are moving at a fixed speed, and you just have to figure out in what direction to launch the bullet so that it’ll hit the target perfectly. Iterative solutions need not apply. Good luck with interpreting the image, it’s pretty confus(ed/ing).