Many thanks to mjau for porting my entry to Windows!

So far, it’s only been tested with WINE, but it should work okay.

Sorry it’s so late, but my source link was broken, and I was absent for a while, so I didn’t find out until a couple days ago. ^_^;

Still, it’s there now! Yay!

I have yet another version of Shafted! with the following changes

1) Increased deceleration when parachute is open

2) The game now keeps track of your high score

3) Fixed collision problems while running on platforms

4) Bats now fly properly in Mac version!

Get it for Windows here

Get it for Mac here

A few of us in IRC did a Micro-LD to test out the blind date concept – each participant makes a set of graphics, and then gets assigned someone else’s set to use to make a game.

Myself, Edwardoka, fydo, Almost, and MrDude did graphics. Fydo didn’t start on a game, and Edwardoka and I gave up – that leaves two (very good) entries:
FLUTTER by Almost (MrDude’s graphics): http://filesmelt.com/downloader/FLUTTER.zip
Space Dodger by MrDude (fydo’s graphics): http://pycron-ld48.googlecode.com/files/Space-Dodger.zip

Just thought I’d give a shout-out

Tags: blind date, irc, microLD

I haven’t fixed the help yet, but I have added another control scheme, improved the ship-to-ship combat, and (in my opinion) improved the graphics.

Windows zipped folder with .exe and all required .dlls here: http://jerryfederspiel.org/exes/PostCompoAdrift.zip

Edit: I’ve gotten the GoogleCode page up!

I’ve decided to keep working on Byte Vs. GNOME.

I’ve recieved some encouraging comments, and feel that it could become something really nice with some polish.

I’ve got the following planned:

• Actually making the random world generator
• Multiple weapons, including a machine gun and a rocket launcher
• Multiple types of enemy, including bosses
• Activators including doors, retractable bridges, and switches
• The game-type bits that were missing from the compo version, like a health bar and a score counter
• User-configured key bindings
• And perhaps even more as it evolves

I’m currently tearing my code apart to allow it to be extended. This is the most troublesome part, after which Good Things can happen.

I’ll be making a GoogleCode page. Once it has gotten reasonably nice, I will likely make a SourceForge page.

Here’s to having a good idea in a crucible, and then refining it into a jewel.

—Mr. Dude

Made by myself, Matthew Hyndman.

I present: Cave Bounce version 1.1 (Windows executable, 1.8MB)

The premise is simple: there are two superimposed caves on top of each other, and you can change which is active at any given time. By doing so you must navigate through puzzles, collect coins, and dodge missiles.

A pretty screenshot: (the player just died and was reset to the start of the level point, hence the seemingly floating)

Changes include:

-drawing the thin outline of the back layer in front of the frontmost layer, so you have an idea of the shape of the back layer.

-a color indication (light/dark green)  of whetehr or not the player is currently able to change layers.

-Several minor changes, including slight tweaking of missile speeds and such; they’re still roughly the same, but they are a little slower/turrets fire a bit less often.

-A subtle gradient background (before it was solid black)

-More levels! I scrapped and redesigned some of the ‘boring’ older levels, and added more new exciting levels, some of which are puzzle only and some of which are missile oriented. There are now 25 levels to the old 20.  Some of the coin locations are now more realisticly obtainable (the staircase screen should be doable for 100% coins now), and there are some new difficult to obtain coins.

-Before, as long as the centre of the player was not a wall on the back layer you can switch, which caused curious half of the player is in a wall situations. I added in a quick feature so that if this is the case, the player should be popped a little bit over to be out of the wall.

-I added some more HUD ocunter stuffs: you now see the FPS and how far you have progressed. seeing that you are on screen 22/25 is more motivation to finish than just knowing that you’re 20 some out of who knows how many

-When the player dies, he is reset to the start of teh screen. Before this did not change the layer, so it could potentially stick him in a wall, so it now also reverts the active layer to the layer of incoming.

-I reduced the number of particles somewhat so things will run a bit faster (not a lot), while still looking the same.

–

–

Postmortem stuff: (After Death?)

Woo! This was my first LD ever, and I loved it, came out great. I’ve entered another 48 hour comp before, but I was less experienced and more or less failed at that one. ( We made a game, it just wasn’t very deep)

The good:

no big problems, I had a fairly cool idea and it all seemed to flow.

Missiles and coins were both last minute additions, and yet the game would’ve been pretty boring without them. I’m quite glad they ended up there.

I made a game. in 48 hours. that is fun to play. I’m happy.

The bad:

No music or sound effects. They are, at the moment, somethign that I do not do. Sorry all.

I overused particles a bit, and so it runs slowly on weaker machines. this slowness can cause bugs like skipping through walls in extreme cases.

the art really wasn’t great (the player is a circle), although it did end up being fairly stylish.

Map design was somewhat rushed, and so wasn’t great (although it’s still good)

Difficulty level is a bit high and intimidates some. Unfortunately for them, I like action games as well as puzzlers, so this is likely still the case. Fear not, it is all quite doable, and there are several screens that are missile free.

Summary:

I had fun and am looking forward to future LDs

In playing through people’s entries I found a lot of them just jump straight into the game and stop when you win or lose.  This is a post intended to inform anyone who doesn’t know how, about a quick and dirty way to create a simple ‘start screen’ -> ‘game’ -> ‘end’ -> ‘reset’ loop in thier game.  I’ve no idea if there is a more ‘proper’ way to do this, but this is quick, dirty, and works.  There may be some differences depending on how your game is structured, but you can fit the idea to most.

First you will need to add one integer variable to tell the program what state the game is currently in (i.e. the start screen, the actual game etc.) called something like ‘gameState’.  Initialize this to 1, corrisponding to the menu screen, so that when the game starts up it shows the menu. You’ll also want to pull out any specific initialization that needs to be done before the game starts into a separate method, not the image loading or any of that, just things like generating maps, reseting scores to 0 and the like.

Now for the magic, wrap any parts that are involved with updating your game in great big ‘if elseif’ statements checking the value of ‘gameState‘.  Leave the normal playing of the game stuff in ‘gameState == 2′.  Now, when at the menu (gameState == 1) draw whatever is needed for a main menu (instructions, keys, intro, etc.) and check for whatever causes the game to start (clicking a button or pressing a key) and when that happens call the game inialization stuff you pulled out earlier and set ‘gameState = 2’.  In the actual game (gameState == 2), when checking for Win/Lose conditions, when they occur (or after a button is pressed after they occur etc.) clean up anything that should be from the game and set gameState to 3 or 4 to go to win/lose screens (or alternativly just back to 1 to jump back to the menu).  If using a win lose screen make sure to have a point in them that will set gameState back to 1, to put you back on the menu.

Using this simple idea it’s quick and easy to create game flow for your game.  You can also have the nice aspect of being able to restart easily by calling the reinitialize method, or to even quit back to the menu from the game easily too.  So please to the peoples out there, add game flow to your game.  It ends up making the whole thing feel like a much more complete and rounded game experience, with only a few minutes work.

Thank you to all the people that have played and commented on my entry, much obliged.  I left it alone for a week, wanting to come back to it with a bit of a fresh head and hopefully fresh eyes.  In replaying it a bit there are a few particular points I think are worth talking about, important aspects of the game which I fell I either did or didn’t get right.

-Enjoyability-

Games should always be fun to play in some regard.  Quite frankly, I don’t think the game is very fun.  Winning is largely up to luck and there isn’t much payoff in a play where you lose.  However, most of the aspects discussed below deal with things which would improve this.

-Exploration-

I feel this was simultaneously the biggest success and the biggest failure of the entry.  The torch mechanic made walking around and feeling your way through the darkness fun in itself, giving a real sense of exploring a dark area.  The problem is that there is nothing to find in the darkness, no payoff for the player, destroying any real motivation for the player to explore and making the fun not last.  The ‘monster’ could pretty much be done away with if the area was interesting to explore, using that as the driving motivation for the player to move.  However, during the time frame I couldn’t come up with any good way to generate a random interesting cave.  Which leads nicely to the next point.

-Level design-

Half way through the development the working idea for what I wanted was actually quite different to the random cave with monster.  I wanted to instead have the player start at the entrance to the cave and venturing in.  The cave would be rough at first but slowly leading to a more structured area, with interesting things to see on the walls and such.  Things would slowly get spookier and the area more ancient-temple-like until you got to the heart of the temple.  At this point something would happen and something would start chasing after you, leading to to a desperate sprint for your life, going back along the way you had come and out to the entrance.  Of course I soon realized, as I was getting caught up in the details, I had no chance of doing all that with the time I had left and my ability with the engine I was using.  I instead focused on having some sort of random map, adding a win lose condition and putting some sort of drive and gameplay to the mix.  Speaking of which…

-Game flow-

I think everyone should add a full ‘start’->’game’->’end’->’start’ loop to their game.  I actually got distracted and wrote a whole post on this here.

-Fear-

This was the biggest emotion I was playing with.  I wanted to make something that induced a sense of fear in the player.  I must have succeeded in this to some degree, having had plenty of comments along the lines of “It scared me!”, however I’m not sure if it was the type of ‘scare’ I was after.  What I wanted was the feeling of blindly running from an unknown fear, but what I got was more of the sudden jump scare.  There is some of the former, but I felt more people experienced the latter.  I think a better level design, as mentioned above, would have achieved this better.  However, another aspect of this that I feel I succeeded with was never really giving you a clear view of the ‘monster’.  Trying to look at it when it’s close causes it to speed up greatly, so you can only ever catch a glimpse of it before it’s game over.   Or alternatively. you can only see the tentacles skirting the edge of the light beam.  I did however, want the ‘monster’ to instill more of a feeling of ‘wrongness’, so prevalent in Lovecraftian horrors.  I’m sure there would be a way to do this with introducing/playing on classic game concepts, then breaking them, but that’s still a bit hazy in my mind.

-The rest-

– Sound worked ok, but would be a lot cooler if I could have added left/right stero pan to give sense of direction.

– Ties into level design, but better and more varied floor/wall graphics would be great.  I got caught up in how to deal with perspective and having things covering other things should work with the light.

– Having the ‘monster’ always just move towards you was a mistake in my part, but the simplest way to do the ‘AI’ for it.  A bit more intelligence would be good, but I again got caught up in how to do it.

– Another concept I wanted to play with was to have some aspect of ‘seeing things in the shadows/darkness’.  Just the kind of stuff that might make you suddenly flash your torch at something you thought you saw, only to find nothing there (or perhaps actually find something…).

– It’d actually be really easy to add in the code things which the torchbeam hits that change the colour of the light.  I’m sure there has to be a cool way to use this, but I can’t think of things that fit (Crystals? Stainglass?).

– Sound should have been done in sfxr, which I couldn’t get my hands on during the comp, but have now.

– A col idea from philomory: “Now I think of it, it’d be really sweet if the map changed around you, but I’m only thinking that because this reminds me of House of Leaves.”

-Finally-

There are a number of directions I could take this if I want to expand on it a bit. The torch mechanic would totally work for a quite a few different styles of game and could be a bit of fun to toy around with more.  I think making the more structured level mentioned in the level design bit above might be something I’ll try, if in my head I can work out the small niggles to it.  Any other suggestions people have are welcome too, for anything that I might have missed or things they felt differently about.  Also, thanks for reading (if you made it this far).

This was my first Ludum Dare, and I was really looking forward to it. Well, I did have fun making a game, but there’s one major problem: I don’t have Windows, I don’t have access to Windows, and I couldn’t find anyone to port my game to Windows. So I kind of feel left out. Not only can nobody play my game, but I can’t play most of the other people’s games.

I always have such a great time with PyWeek I thought for sure I’d like this too. But I really have to consider whether Ludum Dare is for me. If I needed Windows to participate, I would easily choose not to participate. But maybe that’s not necessary. I could write in C++ instead of Python, and maybe more people could run my source. Or I could learn Flash or something highly portable. I still couldn’t play most of the other games, but it’s a step up. We’ll see.

Anyway, it’s been enlightening. And at the very least, I enjoyed making something, so it’s not for nothing.

I’m going to do a last call post some time tomorrow.

If your game previously didn’t work on Windows, but you made fixes after several “it doesn’t work” comments, leave a comment here. I’ll collect up a list and try to make them nice and visible to everyone. Hopefully that will give all the neglected people more proper/updated votes.

Also, we’re short 1 Windows port from the port request posting. Details and a link to the source can be found in the comments here:

http://www.ludumdare.com/compo/2009/09/08/defenestration/

Thanks!

Public/private/whatever. I figure there’s no reason to hide this away in emails.

We’d like to try out the compo system again but for the MiniLD this weekend. Phil added a special mode for the end that will let us showcase the entries, and not require user voting.

I’ve set up a page specifically for this weekend here:

http://www.ludumdare.com/compo/minild-12/

Submitters should go there to add their finished entries. I’ll update it to mention the theme… eventually.

Good luck everyone.

This entry was posted on Wednesday, September 9th, 2009 at 9:53 pm and is filed under MiniLD #12. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

So I’ve tried again, and this time I think I’ve finally managed to wrestle a working Windows build into place: download it here. For some reason I had a much easier time packaging my last (non-LD) game. Suffice it to say, it is probably best for everyone involved if you don’t ask why it’s necessary to distribute SDL_mixer.dll with a game that has no sound.

Tags: Windows

So I’m finally getting around to writing a post-mortem for Mole Cave Tactics. I know it’s better to do it fresh off development, but I needed a break.

Since it seems to work pretty well for a lot of other people, I’ll go with the time-honored format of

The Good

• The concept: I had my concept in mind for this theme (and the many related themes on the list) since well before the theme voting wrapped up. In fact, I had been bouncing ideas for some sort of tactical rpg around in my head for quite some time prior to the compo.
• I finished: The game didn’t have nearly as much content as I had included in the concept, but it was pretty obvious that that would be the case from the beginning, anyway. Given that this is my first LD, I’m pretty happy I managed to upload a game which runs, has things for the player to do, and has defined ways to win and lose.
• The graphics: Ok, so it could be reasonably argued that my sprites would be better classified as ‘bad’ or ‘ugly’, but, I’ve never done any graphics from scratch by myself before, and I actually rather like how the moles turned out. They need some tweaking, but I think they’re pretty good. The terrain I’m less happy with.

The Bad

• Mismanaged time: I kinda knew from the start that this was going to be too ambitious for a first time LD entrant, but above and beyond that I did a poor job prioritizing different aspects of the game. In particular, I spent way, way too much time on AI. I didn’t really appreciate just how difficult a problem doing AI for this kind of game is, I went for way too much sophistication, and as a result I didn’t pull it off at all. I should have known immediately I was doing something wrong when I started writing code to have the AI units look ahead multiple turns in planning their movement. Random walk may not have been very satisfying, but it would have been more than compensated for by the extra stuff I could code in the time I saved.
• No readme: I didn’t ever get around to writing a readme or even specifying a license, so the player is kinda left on their own to figure out what to do.
• Only one map: This game could *really* have used multiple maps, or a random map generator. This is one of those important things that didn’t get done because I was tinkering with the AI.

The Ugly

• The interface: Oh, God, is the interface bad. I should have taken it more seriously when I started adding undocumented keyboard shortcuts for nearly every mouse action in the game. I didn’t think the interface through very well at all during the competition. Having thought it through after reading the complaints, I think that if I want a mouse-driven interface, a radial menu centered on the unit under consideration (think NWN) would be best. Alternatively, just ditch the mouse and switch to all keyboard.
• The Windows port: for some reason, the Windows port was incredibly painful to make this time. For a long time I actually somehow managed to have a build posted which wouldn’t even run on the machine I built it on. I love Ruby, but packaging Ruby applications is a terrible, ridiculous mess. Next time, I’m going to look into Crate.

Pre Vita

All that said, I had a huge amount of fun doing this compo, and I definitely intend to enter again. I also plan to rework and expand Mole Cave Tactics into a full-fledged game, when I have some time to sit-down and code again. Don’t expect a release soon, though: my other game, Operation Lambda (shameless plug) took half a year to complete; it’ll take a few more LDs before I’m able to crank out games of any appreciable quality in a short time period.

Tags: journal, postmortem

EDIT: Oh jeez, I thought it ended on Friday!

Tags: motivation

I’ve been working on my game, and it’s come a long way.  It now looks better, the character moves faster, and there are 5 levels that were not in the competition version.  I think the new levels present some interesting puzzles.

Play Online

I still need to work on making the wall collision less sticky.  Also, I’d like to animate my character and explosion sprites.

I’ve made my decision.

Unless the theme is something really, really interesting, I’m just going to ignore it and do something else instead.

Why not? After all, Mini-LD is just for fun!

That said, I’m more than likely going to ignore the theme.

Instead, I want to make a 2-day roguelike in under 100kB.

I will be using C, NCurses, Vim, and GCC.

I’m very excited about this.

—Mr. Dude

Because I lack the coding chops to access data from a website in my game, I’m going a different route.

I was in IRC lamenting my lack of ability with regards to the theme, when GirlFlash suggested that I simply pick a topic in Wikipedia and run with it.

With that, I’ve chosen m’topic.

Yes, River City Ransom. A clone of it!

I’m going to make it as true to the original as possible without it actually being the original!

(EDIT: I’m actually leaning more towards Python/Geany/Pygame right now, so I really don’t know ’till I write some actual code :P)

And I’m doing it in C++! In Code::Blocks! Using SDL!

Here’s hoping…

—Mr. Dude

I’ve posted about my progress on my blog. Until I get PoV to hook me up with some syndication, here’s a link:

http://pekuja.com/ludumdare/92/wikipedia-mapping/

I’m still having trouble deciding on my idea. >_<;

The RCR clone may not really be what I want to do.

I’ll post again when I have something to show for my efforts. Until then, I’m going to refrain. I just thought I’d get this out so I don’t feel so obligated. 😛

—Mr. Dude