Gameplay Video

Post-mortem

Firstly, I had a lot of trouble with the theme. I wasted 26 hours of the competition trying to come up with a decent yet feasible (to finish within the remaining time) idea. However, once I knew what I was going for, the bulk of the game was finished with around 10 hours left.

I went on to add sound effects, but when I got to making background music, I just couldn’t get anything decent that I decided to scrap background music after wasting maybe 5-6 hours trying a bunch of things. This left me with very little time for smaller details I had wanted to add in, such as power ups.

The only power up I managed to get done was the shield. I had a grappling hook functional (It would shoot up and carry you several platforms up) but it was a bit buggy and would have ruined the quality of the game. That wasted time on the grappling hook could have added a first aid kit of sorts which I had also planned.

Overall I’m happy with the finished product, but of course there were things I should’ve spent less time on (background music) to make room for things that I was more confident I’d be able to properly implement. In a nutshell, it was (like always) a hectic 48 hours. However, it was very enjoyable and definitely worth it.

Entry Page

Well, that was a fiasco.

Well, for me, anyway. Great job to those who finished.

Here’s how it went for me:

I initially had an idea I liked and knew what tools to use. Then, I decided to change all of that. That was Friday night and Saturday.

Saturday I stayed up late, had nightmares when I did go to sleep, and woke up ill and tired. I decided not so soldier through it, and abandoned the day.

Monday, I looked at the clock and decided not to even try. Disgraceful.

So, when it all comes together, I started with certainty, changed my mind, mismanaged my sleep, and gave up too easily.

What Went Well

Not a whole lot. I did begin with a good idea, I think. It was very ambitious, though. That’s about it.

What Went Badly

I abandoned my first idea on a whim.

The second idea I chose (Same premise, differently language/library) was also abandoned too readily.

I tried to stay up through Saturday night, woke up Sunday after nightmares and was too tired to work.

Gave up Monday morning because I didn’t think I had enough time left. No desire to do anything for the jam.

Basically, I gave up too easily and didn’t take care of myself.

Where to Go From Here

One thing that working with Panda3D taught me is that I am not good with making models quickly. That will be a point that I will focus on before the upcoming Mini-LD.

I also learned that I need to discipline myself in not giving up on ideas. That’s another point for me to focus on.

In the near future, I plan on finding a project to work on and sticking with it. I’m not entirely sure what it will be, though. I’m also going to start looking for a job this Friday, so that may cut into my time.

Peace,

— Mr. Dude

Hi,

A video of my game made by a website dedicated to video games from my country – Chile (www.glitch.cl). It’s in spanish 😉

My entry

After a few days to reflect on my game and get comments from people, here’s a brief post-mortem:

Overall, responses have been positive.  Between the comments here and from friends, the general consensus is that my game is based on a cool idea, but that there’s not enough gameplay there.  It’s too simple/easy.  Also, people have often said that the sonar sound gets annoying over time.  I definitely agree with these opinions (and sometimes hear that sound effect as I fall asleep).  These are certainly issues that can be fixed though, and I plan to update the game in the coming days/weeks to get it up to a state where I feel comfortable giving it a wider release.  On to the specifics:

What Went Right:

Brainstorming/Planning – It didn’t take me long to come up with a few ideas that used the theme, and I’m definitely happy with the one I ultimately chose.  My initial planning of the game- the general design, what pieces of code I needed to write, and what content I had to make– also went well.  Having a design that didn’t require many changes certainly helped with working in such a time frame.  I was able to budget my time a lot better because of this.

Coding the Big Pieces – Though not perfect, I got the core pieces of the game working in good time.  The level generation, sonar, and control code didn’t take too long to get working on a basic level.  Debugging and getting things working just how I wanted took a bit longer though.

Asset Creation Process – Although I didn’t get as much sound in the game as I wanted (I’ll get to that in a minute), the creation of the art and sound that did make it into the game went a lot smoother and quicker than I expected.  Obviously I’m no great artist, but I’m happy with the way everything looks, particularly the monsters death animations, and none of it took me very long.  I made the music and sound effects in the last hour of the competition, and that too was quicker-going than I expected.

What Went Wrong:

Not Enough Playtesting – Definitely the biggest problem.  I was so concerned with getting all the basic functionality and assets done that I didn’t take much time to actually play the game.  If I did, I would have realized that it’s a bit simplistic, as well as exploitable.  Next time, I will certainly leave more time for playtesting, as well as getting opinions from friends during the process, not exclusively after I’m done.

Not Enough Sounds/Music – My game ended up with one very short piece of music and two sound effects.  Not at all enough for a game based on sound.  I think prioritizing other aspects of the game was the right decision, but I wish I fit in more time for sound, especially figuring out how to make the sonar less annoying over an extended session.

Key Bugs – There were a few issues that took way too long to resolve.  For example, being a bit lazy with determining how fast the sonar should beep led to at least an hour of debugging caused by a shortcut that would only have saved me five minutes.  Though I can’t think of specific examples, there were definitely a number of other bugs that really slowed down development for long periods of time.

What I Learned:

That I can release a game!

That I can make a game with a small scope that is still interesting, and that I should do so more often.

Even though I already knew the importance of playtesting and rely on it heavily in my larger project, I learned that even on a small project it is one of the most important aspects of game development.  Especially when working in such a tight time frame, I get to know my game so well that I can’t make any objective judgements about it or consider alternate solutions.  Therefore, I need a nice dose of outside perspective.

That about wraps it up.  If you haven’t played my game yet, give it a try and rate it.  If you have, keep an eye out for updates to fix some of the issues I talked about here, as well as those which I didn’t address but that are mentioned in the comments.  I put the first (small) one out about an hour ago.  And of course, I can always use more feedback!

-Tim ‘Fueelin’ Beck

So it’s time to look back at my 48 hours of game-making, like many are doing. Let’s see what happened during the development of A Steampunk Axebot Supply Run.

What went wrong

The Theme – “It’s dangerous to go alone” was the one on the bottom of my list. Why would anyone vote for it, I thought, when there are so many interesting alternatives, like nihilism, or climbing? Why, indeed. I had nothing prepared whatsoever for this theme, and spent the first 2 hours panicking over what to do.

The Level – It occured to me only later that I could have made this in 2D, or using tile-based movement, either of which would have made creating this stuff considerably easier. Oh well.

Textures – As in “I don’t have any”. Adapting UVs is a grueling and time-consuming task,which I would rather avoid, and spend the time otherwise. Using the toon-shader for all 3d-objects was a great choice, but it would have been prettier with added textures. The terrain clashed with this. I couldn’t use the toon-shader on it (so far I know), and creating extra textures for it alone was not efficient.

Preparation – Slept too little the first day. Woke up at start-time (4am), but forgot to check the theme. Felt unmotivated and guilty for first 36 hours, bevofre I finally kicked into non-stop game-making mode.

What went right/not-so-wrong

Timelapse – It felt weird, at first, knowing that my every move was being recorded. But the video makes everything seem ultra-efficient

Music – this one actually surprised me. I never really composed anything bigger, and I just aimed for something unobstrusive. I ended up with a sweet theme which fits the game awseomely, complements it, and people actually like.

The Title – No matter how good or bad this was going to turn out, “Steampunk Axebots” sounds awesome.

The Scoring system – Your profit is determined by several systems, which are based on enemies killed, health of the robots, extra fuel left, and over-healing. Each robot has an own pattern and unity set of enemies at different times, so it is quite challenging to figure out the best combination. I still haven’t.

The fuel gauge – The rockets can travel only for a limited time, before they crash. I intented this to stop players from hovering over the playing  field or leaving it, but the time-constraint added another tactical layer. The rocket takes some time to reach its target, but once it passed a certain point, reaching the other targets would be impossible. It was however possible, that the robot you tried to heal died while you were on your way, meaning you had to carefully decide where to shoot. But since all robots converge on a central point later in the game, it became at that point possible to switch targets should something happen.

3D-models – My first though was a little knight, which I would have need to animate. Unfortunately, there was no time to either animate one or learn how to include animations in Unity (note to self: learn how to include animations in unity).

Biff-Particles  – They are quite a good substitute for fighting-animations.

Healing-Particles – They look much better than I planned.

What I would have liked to add

More stages – which become increasingly complex and tell a story

A menu – Which I already had  around, but no time, and no good reason (with only one level) to implement

No introduction screen – I’ve always hated these. Dammit, I want to play the game, not read a novel! There are ways to start the game at once, and teach the player on the fly.

Destroyed robots and rockets – Which I would have added were it not for a game-stopping bug I encountered with only 40 minutes to spare

Having the title of the game appear somewhere in the first level – Like I did in Unstoppaball. I love that gag.

-Matthew

Tags: 3dsmax, max, music, photoshop, post-mortem, postmortem, soundtrack, timelapse, unity, unity3d

Before Evil Come

Well, I really made it. This is my first Ludum Dare, and actually my second playable game.

Before this competition start, I’m  so exciting and also doubt whether I can finish it. I made a strategy for myself, no collision detection, no physic and no animation. I know they’re important for a game, but I can’t count them in before I really conquer them.

Game Overview

This is an evil game like the title said. You’re a demon, came to our world, because good man protect us you have nothing to do without some buddies. So you go to the wild and hope get some buddies join you. Although it’s wild, still some enemy out there. You can have rest in house and graveyard, but be careful your enemy also rest in some house. After defeat your enemy, you gain exp and may level up. The more buddies and hight level you have, you can kill more people. If you don’t have any buddies, you die.

Developing Tools

I used below great tools.

Libgdx: an open source Java game engine, also supports Android. It’s really good and best game engine on Android in my mind. The texture packer and bitmap font generator tools are very helpful for me in this competition.

Gimp and Inkscape: all graphic assets are made by this two software.  I think Inkscape is a good tool to draw cartoon style graphic.

Bfxr, LMMS and Audacity: The BGM was made by LMMS and other sounds were from Bfxr. Audacity handle the polish work.

Developing Process

Ok, enough background, I want talk about how I made this game. When I knew the theme It’s Dangerous to Go Alone, Take This., the first idea was ant. Tiny ants group a great army to defeat strong army. Based this idea, I split gameplay to two steps, first summon army and second defeat big boss. The bigger army got in step 1, the easier in step 2.

Because I like dead creatures so I replace ants with zombie and skeleton. I’m not expert of complicated control game, so one click control is my choice. Top view, tile map and my cute dead creature, first stage is done.

When I start made second stage, I hesitated. It’s actually a totally different game, did I have enough time to finish it? I give it up at last, instead I made a slot machine mini game, whose digit number is lead by gain points in first stage.  (OK, actually I am just lazy 

After add story board of game background, this game finally done. It’s mini and some kind shabby, but I really love it. So do my girlfriend, though she just like click things and don’t care game content.

Conclution

Cons:

1.Not enough feedback when player made decision.

2.Inside game mechanic is too simple. OK, maybe it’s some kind pro  .

3.Not enough introduction, player would be confused 

Pros :

1.It’s really very easy.

2.My cartoon characters are cute, isn’t it, especially when player lose. I love the skeleton on the cross.

Hope you like this game and my poor English not disturb you. 

Tags: design, game, libgdx

Thanks to you all nice people out there, I’ve got some interesting feedback and decided to update the game a little bit.

Updated controls: jump using UP key (instead of SPACE), attack by shortly pressing X (instead of Z), clone yourself by holding X (400 ms).

Throughout the levels, spawn points now appear – this should give some action to the clones at the rear of the group.

Play in browser (FLASH): http://www.jarnik.com/pub/ld20/index-v6.html

If you care, share your thoughts, please.

I liked some of the sprites, so I’ve created a little mashup of the in-game graphics on DeviantArt.

Tags: flash

[Timelapse here]

Upon starting this Ludum Dare competition I was, like many others, surprised. But only for a short moment. The thing being, I believe you can pick really a lot of different “themes” or “words” or “sentences” – and distill something out of them.  When I read the theme I wanted to try to make a mechanic that would “read“: “It’s dangerous to go alone. (Take this)”.I believe this is possible and that someday we will be able to pronounce it through games and play.

So this was my main goal for this Ludum Dare: Try to build a mechanic that feels like (or incorporates) an interpretation of the very theme-sentence.
And honestly: this took me a very very long time. It took me so much time that I was (often) at the point where I saw, that this would fail. Fortunately for me, Ludum Dare is a 48 hour competition and with a little bit of determination you will pull it off anyway, in a way where it doesn’t matter whether you can submit the game or not. Certainly that’s what we tell ourselves during development but in the end it makes all the difference. We can learn from both. But while one variant is hard and painful, the other one is rewarding and encouraging. I’m sorry for all who weren’t able to finish in time.

Concept

My Ludum Dare concept started out as a stealth game. The reason why it was dangerous to go alone in the first place, was that the player character was different – but not in the sense as it turned up in the final piece. At first, the avatar was something like a thief. But she should’ve looked like the rest. In one of my notes it says: ‘like blending in AssCreed‘. That was essentially what this game would’ve been. I wanted to design the rules in a way that you’d have to switch between moving crowds and you would only have a small time window to switch from one crowd to another. Then you’d have been spotted and – well [insert punishment here]. But after half a day I still wasn’t happy with that and in the end I was glad I changed everything (if only by little).

1) I had no plan. I had tools but I hadn’t checked that everything would work fine. I.E. Since the last time that I had used flixel a lot of stuff had changed and I forogt how to do other stuff. Bottom Line: I wasn’t prepared – at least not coding-wise.

2) Ever-changing core concept: As I illustrated above, I tried to interpret the theme as a mechanic. But I never actually got around writing everything down. I knew roughly what it should play/feel like but never set clear directions for myself. This cost me a lot of time. Time that I should’ve invested into building everything in an according size.

3)  Tilemaps: I said before, that I had not worked with flixel for quite some time and therefore wasn’t sure (I never really knew) how tilemaps in flx work. My bad. Again. Should’ve checked the engine out before. In the end i hardcoded the borders of the levels. But then again – I’m an artist not a coder (so I wouldn’t even call it a hack).

4) Visuals: Jumping into the production of graphics too early made me develop a character, and a style, that was too expensive resource-wise. I even had a walk animation for the character. So much wasted time. I never fell in love with the character and the visual style I was about to enforce on this project. This most likely had to do with the lack of fleshing-out the main concept of the game.

5) Audio-stereo: Upon waking on the 2nd day I had this great (at the time) idea of measuring the distance between player and a soundsource and then adjusting the amplitudes of left and right stereo channel. I never did that – but sure enough I wasted time on it.

1) Visuals: During the failing process of my first art-attempt I discovered a black-and-white character which was much smaller than the one I developed at the time. And it worked perfectly. This lead me to rethinking everything. I don’t know how and when I came up with the new concept. Looking at the character now, she looks like a negative of Chell’s jumpsuit (I didn’t play or possess Portal 2 but it was in the media lately) + I like to have other ethnicities in my characters + white for contrast + a hairstyle I personally find very interesting. The remaining visual style was really a lucky accident that came about after realizing that the dominant green of her jumpsuit didn’t fit the colors of the environment.

2) Music: I did all the “composing” in Logic Studio, which comes with a huge library of Software Instruments. Although the look proposes something 8bity I decided to go with some more-real-sounding instruments. Bass plays a very important part in my pieces (I used to play bass in the past) and it is my belief, that this instrument can support a lot of emotionality. Instrumentation is in fact a key aspect I try to think of. E-Pianos and Pianos have this deep melancholy to them. You can do so many amazing things with that. Basses can span from cool to confident-melancholic – which is it’s role in my ambient track. I think pad sounds provide sort of a transcendent quality. These are all things I didn’t learn but hear from other pieces of music. At the time I was listening to a lot of Tortoise and Mogwai – hence probably the focus on bass. The composition came out of a variation of bass patterns AND the . I really like how the track turned out.

3) Finishing: Although I found it hard to submit such a short game in the beginning – I  realized that I had implemented the core gameplay I wanted to have in there. I think the mechanic has the potential to expand on it. The comments suggestet that the game
was too short and that the mechanics could’ve been conveyed better with a certain length and I absolutely agree.But finishing some game and achieving my main goal – if only in part – was quite something.

CONCLUDING
Lessons learned?

1) Never constrain yourself to do something other people can enjoy lightheartedly.I know I was never that kind of guy – and boy did I try. I obviously can’t make “fun” gameplay? My understanding of “fun” is broader than the term suggests. Deep down I probably am a mess. But resigation and melancholy have a unique aesthetic to them – and I think we should embrace that.

2) The lack of clarity in controls or mechanics can be backbreaking for a game.
I hope some of you could enjoy the game. If you haven’t played it yet I would appreciate if you’d take some time and play it once or twice HERE. I am very thankful for all the comments Entity has received and am glad for every single one of them. Thank you organizers and staff of Ludum Dare. It was a great experience for me. I hope I’ll be able to participate again. That’s it from me – take care everyone – LeafThief

ADDENDUM

My thoughts or rules behind the design of Entity (spoiler alert?):

1) You strive for independence – some may call it individuality as well.

2) You can not go alone for long. It is dangerous not to have social contacts.

3) A majority of people are not really interested in you. They wear a mask and won’t open up to you.

4) If you become independent from that social pressure people will take their masks off and open up to you ( this feature wasn’t implemented – you could’ve turned masks into people without masks who’d provide you ).

5) If you depend too much on a society that is not interested in you, you will become one of them, thus putting on a mask yourself.

6) Memories can content your social needs. They can help you build up your independence ( this feature wasn’t implemented).

Tags: Entity, LD #20 - It's Dangerous to go Alone! Take This!, postmortem

Hi guys! Long time no post. It’s been pretty hectic for me, unfortunately, so it’s taken me almost a week to fix a few small but crippling bugs in the game:

• Elevator shafts are now less lethal to enter
• Elevator damage is now higher if you end up being crushed
• The ability to restart from last checkpoint has been added (press R)
• Removed the stuck-behind-a-staircase-forever checkpoint, if you get stuck there hit R

If you haven’t already played it, play it by clicking here!

The entry has been updated with a link to the new bug-fixed version with the original one left there for comparison. Now, the post-mortem! It’s a little short because I’m new at this and not so sure what I’m doing.

Those scuttlers served no purpose other than to look threatening.

What Went Well

Considering this was my first Ludum Dare, I’d say it was a pretty big success. In 48 hours I actually got a game from a bare basic moving-a-box-around-other-boxes to something that was actually more of a game! I was even able to factor in a few miles walk at the start to get my brain going. The coding went pretty well and I got in every single feature I wanted except for a boss fight I was on the fence about adding to begin with. The programmer art I ended up keeping in as the final art due to a far more positive reception than I was expecting (and also to save time as covered later).

I think I kept my scope realistic for the deadline, and am overall happy with the result, except…

What Went Badly

I of course ran out of time. I wasn’t so good at time management and perhaps spent a little too long on breaks than I would have liked. I massively underestimated the amount of time it’d take to create and add content like graphics, sounds and music to the game, but the number one thing that tripped me up was the level editor I used, DAME. You may notice that I never mentioned DAME in my initial “I’m In!” post. This was because I literally just remembered I had it as I started the competition, and so I spent a good deal of my 48 hours looking up various features in it and learning my way around it. Well, lesson learned for next time: familiarise myself with every piece of tech I have even the slightest chance of possibly using.

I also left most of my content planning to the last minute. Bad idea. This is why one of the rooms ended up trapping the player behind a moving staircase – I had to rush the play-testing so I could submit before time ran out.

I also regret not being able to give my timelapse better background music. I apologise once again for the choice of background music.

Behold the most hastily rendered sunset I've ever drawn.

What I’d Do Differently Next Time

Next time I’d definitely familiarise myself with the tech and probably plan a little more rigorously than I did this time (where I spent about 30 minutes planning before giving up and going back to coding). I’d also consider elements of the game that would make it easier to recover from error (either the player’s or mine) by including features like a restart button, and perhaps focus less on a game demanding a level and more of an endless arcade sort of game.

Future Plans

I aim to eventually (not immediately, due to various real life things whirling around me) get the game polished, with better graphics, art, sound, and cutscenes, and aim to include more than one level (probably five or sixish). After that I’ll be submitting it to somewhere like Flash Game License to see if I can get a sponsorship for it and go from there. I’m completely new at this so my ideas are likely laughably naive, but hey, if you’re fully aware I’m walking into an obvious trap, I’d appreciate it greatly if you could leave a comment for me 😀

I feel a bit guilty posting this in the compo blog, but I think this is a legitimate inquiry that might be of help to others besides myself.

Here’s the deal:

I want to set up a personal website as a permanent portal for my game development news and any games I write.  To this point I’ve been using dropbox to host files and linking them from my tumblr blog.  I’d like to find a solution that allows more flexibility than tumblr in site layout but still supports a blog format.  Being a game development site I would need to be able to support hosting my projects and ideally I would like to have support for embedded flash content since my recent experimentation with flixel.  Another want is the ability to write completely custom html and css, while php would be a bonus.

I’m interested in what solutions other developers (like you) are using.  What has worked for you?  What hasn’t?  I’ve experimented with Google Sites, WordPress, and some other options but I haven’t found anything to really fit the bill.  So what do you use?  Are you happy with it?  Would you recommend it as a solution?

I trust LD community and its varied experience can provide some good input on this topic, just as I am sure there are others in the community with the same question I have.  Thank you.

P.S.  This would be an excellent question for an LD forum if there was one…

This past LD was great, now i want a Mini LD, does anyone else?

Hey there! Now that LD20 is submitted and done, and I’m busy trying out all your awesome games, here are some updates.

Short development cycles
First of all I’m already looking forward to the next LD, or mini LD. I really liked this style of making something small in a small amount of time. Most of my other projects have been much larger scale and much longer development time, which often can result in lack of motivation to complete the project. I’m also very impressed to see what everyone has come up with in such a short amount of time. I’ve tried some really great games so far and looking forward to trying more!

Music
Before the deadline for the jam I managed to put some music in my game too by landon podbielski, you should check it out! You can toggle the music on the ‘m’ key, incase you are playing for longer periods of time.

Beyond my Expectations
One thing I was very impressed with, is that some people played my game way beyond my own expectations, so much so that I had to add even more extra content to it. I’m also keeping a local highscore list in on the projects page just for fun, be sure to tell me if you want a place there.

Timelapse
Finally, I got to putting together the timelapse I made of the development of my entry ‘hollow’. Used that killed app that Keeyai made. (Thanks man!)

Check out the timelapse here!

Finally
I’d really appreciate if you would try out my game and tell me what you think with comments and ratings, I’ll be sure to try out yours as well!
Your feedback is really worth a lot!
http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=3933

Contest Link
Web Player Link

Intro:

Air Pirates was developed in a very fluid way, meaning the game I was planning and the game I ended up with varied greatly over the course of development. Many of the game’s features were thrown in at the last minute and not properly tested. However the core components of the game I wrote at the start of the contest were flexible enough to accommodate these wild design changes.

What went Right:

Used a known technology

– I decided to use Unity v2.6 because I been using it for over a year. I knew the names of the native classes and functions that I needed, and how they work. I tried Unity 3 at a friend’s house and I found the slight difference in interface jarring.

Code for reuse

– Many of the classes I wrote in this contest pull double duty, or more. The AirPlane class for example was used for the player, airship, and friendly/ hostile fighters. The texture and performance difference between these objects were implemented via public variables changed in the editor.

Just because I can doesn’t mean I should

– Unity has a terrific feature set including physics, shaders, and animation blending. But to take advantage of these features I would have to sink a great deal of time building 3d assets for them. Instead I went with 2d Sprites attached to a square polygon which always faces the camera.

Using Airplanes

– Airplanes look cool and don’t require animation for their idle, moving and attacking states.

Low rez pixel art

– My art pipe line for the airplanes went as follows: Make a hand drawn sketch on graph paper. Scan sketch and resize it to 128×128. Trace sketch on new layer. Bucket fill with solid colors. Add shade and highlight with color offset. Using a pencil sketch caused me to worry less about exact pixel placement. Using fewer colors gives the game a clean retro look while allowing for palette swaps.

Knowing when to cut my losses

– As you will read in the “What went wrong” section not all the features I wanted made it into the final product. At 6 hours to dead line I decide I should stop messing around with the cool stuff and make a game out of this. Had I continued to dick around I would have release a really cool tech demo instead of a game.

Want went Wrong:

Was too ambitious with original concept

– I have wanted to make a game involving epic battle between airships and airship launched prop fighters for a while. Needless to say the game did not end up like this and I wasted a good amount of time laying the foundation for features that would not be implemented.

Not enough time spent brain storming

– I was writing code less than an hour after the theme was announced. I did not spend much time figuring out what the finished product should look like. I knew I wanted to do something with airplanes and interchangeable weapons pods, and assumed I would figure the rest out as I went along.

Didn’t do long term tests

– I tested my code frequently, but most tests were a few seconds long to make sure the latest feature worked. As such a game breaking bug with the enemy respawn system slipped though. If I had played the game for over a minute I probably would have spotted and fixed this bug.

Didn’t sleep enough before the contest

– The contest started at 7pm on Friday for me. I tried to take a nap after work, but was too excited about the upcoming contest to get any rest. My first night of coding suffered from this.

Didn’t think of the end user experience

– I got too caught up in how much fun I was having implementing the features that I didn’t take into consideration how the game would feel as a whole.

Conclusions:

Using the Unity engine to implement a simple sprite based game saved me a lot of time. Its editor, GUI , and particle features allowed me to make a much more complex game than I would have been able to make from scratch in the time provided. I regret the lack of planning and testing that resulted in the bugs in the final version.

Check it out here!

Thanks to all the positive feedback from everyone who played p.i.g!
I’ve used a lot of suggestions to improve the game.

The enhanced version includes:

-original music from the composer for ‘endeavor’
-3 new unlockable levels with a new mechanic
-level select screen to replay levels
-enhance portal funneling feature to make portalling easier
-bugfixes!

Go play it, and have fun!

Hey I’m going to talk a bit about PSYCHOSOCK now!

It took me a couple of hours to develop the concept for PSYCHOSOCK. The original concept was thought up whilst brainstorming with my wife about the theme, she suggested a man trying to escape from a hospital and some item he need so he could escape, a sock for example. I then ran with this and decided to turn the item into a secondary playable character, making things somewhat more interesting. I also decided that to fit more closely with the theme, the character of the sock would be the player’s only means of offense, making it essential he take it with him and use it to deal with danger.

What went well:

I started mostly by experimenting with the visual style. I wanted something rather distinctive, different from my usual pixel art style, but also quick to produce to stay within the time constraints. I settled on a colourful, bold, childlike art style- which I feel helps the game stand out. The style itself was rather fun to work with as it meant I never got bogged down in character details and could make art assets at high speed.

From that I started to work on the basic gameplay concepts, considering things such as nonlinearity, an expansive map the player can explore, stealth systems and multiple approaches. I decided to go with none of these aside from a basic stealth system- to have done so would make it far too ambitious a concept to knock out in 48 hours. I settled on a linear basic stealth adventure, with a couple of environmental puzzles, and a basic enemy to be defeated or avoided. The character of the sock was always fairly clear in my mind- it’s a homicidal item of clothing. I originally thought of many puzzle concepts for the sock such as slipping through air vents and laser fences, but decided this was too complex and allowed him to strangle people, pick up items and flick switches; which still allowed for some basic puzzles.

Level design was a big step forward for me in this project, the rapid development process left no room for error, and I tracked every room, item and door object numerically on paper so I could immediately see how everything linked together. This was vital as it saved me a lot of headaches and backtracking by knowing exactly where each room transition object should point to, and how it was numbered. I also numbered all of the rooms, and using a few basic templates I was able to quickly design and populate the levels of the game. Going forward I will undoubtedly use this system of mapping on paper with room transitions and naming codes to keep track of my level design.

Soundwise I spent about an hour composing the two tunes in the game, just some simple chiptunes made using SFXR and LMMS. I made all the effect in SFXR in about 10 minutes, and added a little voice acting to the guards with my Rock Band microphone. The sound was a lot of fun to make and thought a lot of people neglect sound in these projects, I feel it can really enhance the atmosphere and feel of such a small project. The way it can be so rapidly generated using tools such as these really helped.

What could have been done better:

The final stage was rather rushed as I was running out of time, leading to it being very corridor based and a bit sparse. The final art assets I created for it are also noticeably rushed, as sadly I didn’t have time to make them look better.

Due to the time constraints I was unable to make much of the narrative either. My original idea was to have the player initially escape with their sock, then between each level I would have a scene where they talk and I could flesh out the characters and setting more. As it turned out I had barely enough time for the narrative that is in as it is, having to really speed draw the background for the opening and closing scenes. Perhaps I’ll revisit it and provide an updated version with the full scenes as originally intended.

The explanation of the controls was intended to be non-intrusive. I felt text prompts would break with the visual style of the game, so I put all the controls aside from movement in thought bubbles above the character’s head. This worked fairly well as a hint system, but the control for strangling guards (mashing X) did not come across clearly, leading to some people repeatedly being caught after failing to strangle them. This is unfortunate, and I have since put notes on the game page to help with this issue. Overall I feel animating these would have helped but as with most other things I simply did not have the time.

Lastly, though I think I managed to handle all the showstopping glitches, there are some left in the game. Testing is one of the most time consuming parts of any project, so I had to really cut it to a minimum. Notably one of the guards is stuck inside a locker and can’t move, and if you are caught whilst strangling a guard, the strangulation sound effect will loop endlessly until you kill somebody. On the plus side this does mean you get some further exposure to my wonderful imitation of asphyxiation.

Overall:

I’m really pleased with the way this project went. I feel I made a pretty good game and learned a lot about how to develop more efficiently, as well as getting to experiment with mechanics and styles I hadn’t tried before, as well as being able to release a game at the end of it. Perhaps if I’d have stayed in and not got drunk on Sunday evening it’d be a little more polished, but really I’m happy with how the whole thing played out.

Please give it a try and let me know what you think of it: PSYCHOSOCK

Time for a quick postmortem of my entry, “An Old Man And His Quest”:

What Went Right

• Initial concept: although I’m not a big fan of this theme, my wife helped me with a basic idea so I could jump right into working on the game
• Getting scripting working: this really helped me get the game working as I intended, and really made it easy to add powers and cutscenes to the game… I’m probably going to merge that component I did in the compo onto the framework for the next time.
• Graphics: by going 3d and using some pixel art skills I picked up on the latest compos, I could do something that didn’t look completely terrible.
• Music: Again, WolframTones served me well for 48 hour game music…
• Cutscenes: I love doing cutscenes, specially in this kind of limited environment… Having to think on ways to twist my meager artistic skills and limited tech is very entertaining for me
• Mixing the “game” stuff and the “menu” stuff in a single framework… All becomes more interesting, and it’s less work to make behave properly, especially with the scripting engine

What went wrong

• Time managment: Again, I failed miserably in estimating development time, most of it by not considering the rest of the things that went wrong
• Going 3d: I almost always think about going 3d and don’t do it because it’s normally harder (even 2.5D like in this game)… This ended up being no exception, and I had loads of problems getting the initial setup working correctly… It also led to some driver-related problems and things like that, that made me loose loads of time… :\ The end result is a mixed blessing: it looks better, but it took longer…
• Bugs: Ran into some bugs after the deadline, which meant the game seems more buggy to everyone than it seems to me… :\ Fixed most post-compo, but that’s too late…
• No time for level design: In all compos, I promise myself I’ll code something simple and let 4 or 5 hours at the end for pure level design, game balancing, tuning and polish… and I always fail at this… 😐 This time was no exception… I had 5 levels thought of, only had time to make 4 (and the last one was terribly unbalanced)
• Using Photoshop as level design tool: what seemed like a nice idea ended up being more complicated than it should, which kind of defeated the purpose… next time I think I’ll be back to ASCII text files… or a good tile editor, if I can find one that suits my needs (haven’t found any so far, all demand too much work getting to work properly or require me to write a weird importer)

The game has circa 3000 lines of C++ code and 1100 lines of Lua code, and the framework about 17000.

Tools used:

Code: Visual Studio 2005
APIs: DirectX 9 (Feb), FMod, Win32, Lua
Graphics: Photoshop CS4
Sound: WolframTones (very awesome, only had 20 mins or so to play with it), Midi Converter Free (online free midi to mp3 converter), Sfxr
Blogging: Internet Explorer
Listening music: Winamp

On an end note, I’ll probably grab the 3d tiling stuff and scripting binds and merge it with the rest of my LD framework, for future use… I still want a competition where I can actually spend time working on the game, instead of the technology!

Thanks everybody that participated for an exciting weekend!

Ok so after tinkering around a bit I finally managed to upload my game at http://www.scs.ryerson.ca/~aalksne/icarusGame/run-applet.php

It may have some trouble running on IE; I haven’t been able to find a clear way around that yet other than to use Chrome or Safari instead but hopefully it won’t cause too much trouble for everyone.

I have polished the game since ‘finishing’ it back on monday and although it’s really basic and my first completed game I am really proud with how it turned out. What I’m most excited about is that now I have a framework created that will allow me to dedicate more time to the actual ‘game’ portion and less so on the ‘figuring out how to add a model without it breaking the scene’ portion for next competition. Can’t wait for LD 21!! 😀

I have started to clean up the code of “Bloboy’s Journey”.
What more, the sprites will be improved.

Check out the work of Medea, the GSM Productions graphist!

This sprite sheet has become

(GSM Productions is a young Belgian game development team composed of Grungi Ankhfire, Medea and myself.)

I compiled a spreadsheet of all the games that can be played from the web for easy voting access.

Web Playable Games

Also, because I’m a fan of data, I was wondering if anyone would be interested in a technology and platform survey to gather stats on what tools, frameworks, and distribution channels LD participants are using. If there’s enough interest we can work together to get a survey up (and if something like this already exists, that’s even better!).

It wasn’t pretty, but I managed to shoehorn my 2D game engine on top of Unity3D.

The process was ugly, but the result is better than I could have hoped – the game looks and runs almost exactly the same as the Windows version (bugs and all – I didn’t make any changes). Unlike other web platforms I’ve tried that have framerate issues (I’m looking at you, Flash), it runs butter-smooth.

So, Mac users and those averse to downloading .zip files can now give Ascent of Kings a try.

Well, I finally made some progress in finishing up all my main chores for the competition.

That being the port to windows and finally uploading my timelapse video. Check out the game page for the windows version and the timelapse.

Oh and as I heard there were some problems with the windows version, please let me know if you also encounter any problems running my game, so I can try to fix it somehow.

DOWNLOAD HERE!

What’s new in this update?

Well, there’s an AWFUL LOT. Thanks to all the people who played, this update is for YOU!

• The entire escape sequence has been fixed to be tons better. Sound isn’t as awful and the enemies still spawn.
• The in-game timer works now, so you can actually do competitive runs through.
• Added a whole hidden new area and fixed one of the hidden guns.
• Tweaked the final boss fight. More fun.
• Fixed a minor thing with the whole map.
• There’s a hidden boss in the hidden area. You can only get to this boss if you haven’t got the spreadshot yet.
• Tweaked difficulty levels to be a more steady challenge and made easy mode not as easy.
• Even a bit more than I’ve listed here. Have fun!

Doh! I thoughtlessly picked one of the stock Unity skydomes, forgetting that this is ART and should therefore be made by ME. Oops.

So “Lonely Fortress” has accordingly been moved to the Jam. Apologies and thanks to all of you who took the time to rate it.

On the plus side, since it’s no longer being judged, I’m uploading a new version with a quick and dirty fix for the bug where you could get stuck with your head inside a block. And I plan to continue developing it into a full game. Gotta keep busy until LD21 rolls around!

Hi, my name is David and i am looking for people interested to be in a small dev team. I am a good programmer in AS3, but i suck at making chiptunes even though i play guitar and know how music works and such. I also am TERRIBLE at spriting/graphic design. So in this dev team of mine would be:

Me: Lead Programmer
?: Chiptune/music developer
?: 8-bit/what ever matches the game artist

if you think you qualify and you are interested feel free to comment or find me on twitter (dsv101). Thanks,

dsv101

Due to several people suggesting it, I made a post-compo version of Take This Penguin that doesn’t start at the title screen each time you die. Link is on the entry page for it. Hope you enjoy it!

Entry Page

Hi,

I heard some reviewers mention, there is a bug in my game Red that freezes the game after the objective is complete.

Please check the game if you have a sec and see if it freezer during the second level.

If the bug does happen, please comment and include the version of flash you have.

You can check here which version you have. Thanks

ER

This post-mortem presented to you as a series of random observations and comments.

My original idea for the game came as a sort of pacifist Zelda. It would be just like the Legend of Zelda game, except you’d never get any of the weapons.

I wasn’t trying to be funny at first. With this post, however, I realized that there was a potential for humor in the plot, and went with it.

Honestly, this wasn't intentionally funny. I just needed an excuse to not give the player the super-weapon yet.

I can’t really point out something that went wrong this time. I suppose I wasted too much time and didn’t get around to implementing a boss fight, so there’s that.

I started seeing someone between the last LD and this one, so I got to dedicate the game to her. That was cool.

The reason for the super-weapon:

SPOILERS BELOW

I wanted to give players a chance to destroy the puzzles and annoyances from previous rooms, a sort of vicarious revenge upon the game. Also, a lot of the people will stop playing the game for a bit so that they can say to me. “MOTHERFUCKIN’ RAINBOW CANNON” or something along those lines.

SPOILERS END

Autotracker-C is AMAZING. USE IT!

Taking part in the community is so beneficial! Getting feedback is helpful, and giving helpful feedback leads to all sorts of warm fuzzies.

My puzzles are so unchallenging! I have no idea how to balance them, since being the one who designed them gives me a bit of an advantage.

Well, let me tell you my foray into game building this time was an interesting one. My goal was to create a dramatic movie experience using just audio and music.

While everyone else in the competition was busy playing with game ideas or throwing together some code for their game infrastructure or perhaps even creating a level editor, I was just trying to fight back writer’s block. I had about 15 pages of narration to write (and that was after cutting the initial scale of my game in half) and initially I had allocated about 6 hours to do it. I was planning on being done by the time I went to bed that night, but when I was too tired to work any longer, I had only a third of the story written!

In the end it took me about 12 hours and it was still unfortunately a pretty rough draft but I had to go with it. The end of the narration definitely suffered compared to the beginning when I was able to add so many extra details, but that’s life in a 48 hour competition. At this point it was 1pm on Sat. and all I had to show for it was a stack of papers.

Luckily I was prepared for the recording session. I had done a test the day before and knew exactly what I wanted to do even though I had never narrated before. Of course, the fact that I didn’t have time to even rehearse the material meant the narrations didn’t come out as well as they could of. And of course it’s harder to narrate than you may think. Sure a paragraph or two is simple, but when you are reading page after page, the mistakes add up and so you end up doing everything several times and then have to go back through all that later and sort out what is good and what is not. There is just a ton of painstaking processing involved with audio.

In order to get the best possible sound, I shut down my pc and got rid of every possible sound in the room. I recorded the audio using logic pro with my mac mini. I recorded through the preamp of my Mackie mixer and through a comp54 compressor (which is an amazing reproduction of a neve compressor). I used a Shure sm7b microphone which was the one that Michael Jackson actually used to record Thriller. It works as well for voice as it does for music. So I was pretty confident that technically the narration would come out well and it did.

So I finished the recording and then that evening (maybe 4pm) I exported everything to my pc and put the chapters together using Cubase 6. Cubase is by far my favorite daw; it really is the best there is if you are using midi and virtual instruments and don’t want to feel limited with what you can do. I had originally planned on scoring the narrations using my prophet 08 analog synth, but I realized there just wasn’t going to be time to do all the tweaking necessary to get the sounds I wanted (I did use it for that intro sound though), so I fell back to using Omnisphere, which is a software synth in a class by itself. I had never scored a narration before (a lot of firsts here). I tried several different techniques during the process of creating the 12 different scores (which is a heck of a lot of music to try to create in such a short time). I think from the first one I did to the last one I definitely improved quite a bit. I hate the first one (chapter 1) and plan on redoing it for the iphone version. My favorite is the helicopter flight score. Well, that and maybe the score of the hive with all of the gross creature sounds. I found my process was getting much more elaborate during these last few scores. I spent the rest of the night working on the scores, maybe to 3am.

Next morning I was on schedule but immediately things went horribly wrong. I had used Unity in the last LD to make a nice little 3d game, but man when I tried to use it for the simple purposes of this game, I was just fighting it the whole time. All I wanted to do was a simple fade, but I was jumping hoop after hoop and things weren’t coming together. It was noon and I had nothing, so I switched immediately over to flashpunk which I had used to make a game last year. Thank god I did. I didn’t even have flashdevelop on my computer, so I had to download it all and follow the flashpunk instructions to get it all working, but that only took about 10 minutes. Almost immediately things were working and I was coding the game. The actual code was about as simple as could be, so I won’t spend much time talking about it.

The final big hurdle I hit when I was all done and testing was that I found that flashpunk (probably flash actually) was very picky about the sample rates of my mp3 files. In order to upload the game to Kongregate I had to get the game under 10MB so I had to make the sounds mono and as low a sample rate as possible. I had done all the final wav files at 96k and I was having a heck of a time getting wavelab to convert the 96k wavs to small mp3 files that flash would actually accept.

I finally ended up creating the mp3 files in Cubase actually, which I think gave me a higher quality sound in the end. I went with mono, 32kb, 11khz and I liked the quality of the output, but ran into a huge problem. It was really affecting the volume levels of the different tracks. I had the music much quieter than the narration and in some cases the output mp3 had actually silenced the music. So at the last minute I had to go through my projects and adjust the volume levels, bringing up the volume of the scores so you could actually hear them in the mp3.

That’s it. Overall, to be honest, I’m just amazed I was able to complete it. There were several times when things weren’t going right that I considered just giving up. But I think I continued because with this project I choose to do the things that I enjoy the most, writing and making music, and so that’s why I was able to persevere. I know a game like this is sure to be rated poorly, I knew that going in and accepted it from the start. Even if my voice was like Orson Welles and my prose like Hemingway I wouldn’t have a chance. And yet I really think there is a niche for this kind of game. Sure it falls more under interactive fiction than game (it is less interactive than dragon’s lair even), but there’s almost limitless potential for the number of epic stories I can tell. I almost see it as a way to bring game-players back into fiction.

If you feel like listening to a good story, check it out. It is a dark, apocalyptic science fiction / survival horror thriller that will depend completely on your imagination. I’m working on a mobile version now that will have some beautiful artwork and a bunch of other features as well (not to mention a re-write or two). I should warn you that there is a ton of profanity so I would say if you don’t like listening to audio books or if strong language or gross imagery disturbs you, then stay very clear of this one.

Change of Heart
http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=258

I’m making good progress on an improved version of my game: thinking of lots of new gameplay elements and drawing lots more Zelda enemies.

Here’s a screenshot showing some of the new things I’ve added:

Entry page here

Tags: post-compo, screenshot

Hectic week, but finally had the chance to toss my timelapse together.

Click to play!

Enjoy and critique!

This was my first Ludum Dare – I went into it feeling completely unprepared, and finished the compo with a game I’m pretty happy with. I’m going to attempt to describe how that happened.

What Went Right

• The Toolchain. I made a rather risky move going into this LD. I decided to use a game engine I’d never tried (Flixel) in a language I haven’t used in years (ActionScript 3) in an IDE that doesn’t run on my OS (FlashDevelop) Crazy, right? Actually, I don’t think it could have gone better. Flixel’s handling of basic motion and collisions is far more intuitive than any physics engine I’ve tried, and the engine as a whole seems perfectly tailored to quickly prototyping games. Due to some of the awesome features in Flixel, I ended up using Photoshop as my map editor, which worked quite well, and is something I’ll be thinking about doing more of in the future.
• The code. The one piece of advice I got before Ludum Dare was to not get caught up in the code. That’s a problem I’ve had in the past (I’ve got a number of game prototypes that are more engine than game, nearly all of the utilities I’ve released have about 3x the functionality that can be shown in their UIs) but with the looming 48 hour deadline, I was able to ignore best practices and just get sh*t done. There’s dead code, unused variables, methods copied from class to class, and not a comment in the entire program. But it works, and ultimately that’s all that matters.
• Music & Sounds. The audio ended up being much less of a hassle than I’d initially thought it would be. For the music, I used Garage Band on iPad which has a feature called “Smart Instruments” – I gave it a couple chords, and it gave me back a groovy baseline. I spent about as much time making the music as I did trying to get the .mp3 to loop properly. For most of the sound effects I just decided to record them myself. I grabbed my iPhone, went in to the quietest room of the house and made zombie noises for a few minutes. It was fun, actually.

What Went Wrong

• The Theme. At least initially, I had no idea what to do with this theme. I didn’t want to wind up with the same idea as everyone else, so the obvious ideas of a zeldaish game or something where you only win if you’re holding the MacGuffin were out. I spent probably 4 hours tearing my hair out and contemplating leaving the competition before scrawling down “you start in a portal like chamber where you don’t get the macguffin, then you fight zombies or something”
• The Graphics. Unlike the code, where I only did what I needed, as I needed it, when it came to the graphics – I didn’t really have a plan. I started the graphics before starting the code, which was a mistake – but the bigger mistake was starting the graphics before I’d nailed down what the game was going to be. I wasted a lot of time on graphics I didn’t end up needing, or which just didn’t look right (all the walk cycles) I’m relatively happy with where the graphics ended up, but it took too long to get there.
• Planning. I didn’t really know what my game was going to be until after I was 3/4 of the way finished, so I didn’t even have a todo list until the last 12 hours. I’m pretty good at flying by the seat of my pants, but I think a little pre-planning would have helped. You know, trying to set a couple milestones, researching the engine I was using a little more, that kind of thing.

And if you read all that, here’s your reward! I’ve uploaded a Timelapse of the development of Super Shotgun Deathrace which you probably shouldn’t watch until after you’ve played the game

Tags: postmortem

Let me tell you about my first ever 48 hour Ludum Dare experience!  I made a top-down puzzle game where you, the player, control the movement of both a green Link-like guy and a kitten at the same time.  It is dangerous to “go” alone! Take this [kitten].  “Go” as in, yes, “going” to the bathroom.  In this puzzle game you have to collect TP for the toilet and litter for the litter box!

Play the game – Click here for my game’s competition entry page.

I’ll go through my experience chronologically as I talk about how my game came together, and then I’ll also tell you about the process of making each of my levels if you don’t mind spoilers.

Part 1 – How 48 Hours Turned Into a Game

Ok, so Friday night the theme was announced. When I saw it, I simultaneously felt like I had to do something Zelda-like, while also not wanting to do anything so literal.  The direct reference to such a classic game put me in a bit of a mental bind.

I started brainstorming ideas. For inspiration, I grabbed from the internet both the Zelda screenshot and the famous meme image. I actually had them up on my screen during the whole contest!

Inspiration: The Dangerous Duo

Some Zelda parody ideas popped into my head right away, but because you can’t reuse existing Zelda graphics for Ludum Dare, my ideas basically amounted to “recreate Zelda,” and that seemed a little impractical in 48 hours. There was one particular moment from the first Zelda that I kept thinking about:

Kittens are made of meat…

For more inspiration, I started to read everybody’s blog entries, and I was amazed by all of the clever interpretations of the theme.  I started to think about each word in the theme individually, and tried to figure out how I could play off of it. It was then on Friday night that playing on the word “go” hit me with an idea: I’d been wanting to do a simple classic top down puzzler for awhile, so what if I did something with needing to “go” to the bathroom.  I figured the player could be a little Link guy like from Zelda, and there could be a kitten companion (like from the meme) at the same time.  Visions of pixel toilets and pixel litter boxes flashed in my head.

But I didn’t stop brainstorming at that idea.  I also looked at past Ludum Dare winners, and how they related to the theme.  Then I looked at the Wikipedia list of video game genres.  Within probably an hour I had a list of maybe 15 ideas.  I was able to down-select based on scope pretty quickly, but I was left with 3 or 4 ideas that I really liked, including the idea that I ended up picking.  I decided to let my unconscious marinate on these ideas for awhile, and I played some Portal 2 with a friend, and then went to bed.

Saturday morning I got up and did my typical Saturday routine.  I walked to get some coffee and a pastry.  I got home, and I setup the shell of a top-down game using the Akihabara HTML5 game engine.  I still hadn’t picked my final idea, so I picked up pencil and paper to do some sketches and explore the ideas a bit more.  I got out a tablet of graph paper and started to doodle thoughts and level diagrams and game elements for my top ideas.

“Look! Doodles! I went to class!”

This ended up making the decision harder, because with pencil-to-paper my unfiltered creativity was creating ideas for these games with too much scope, and then I would get concerned that my ideas were too big and not suitable for the 48 hour time limit, and that it would be very difficult to make enough game content by the deadline.  The pressure of the 48 hour competition hit me a bit at this point, which was late Saturday afternoon by now.  Trying to address my concerns about being able to design enough levels by hand in 48 hours, I burned another hour or more by visiting the procedural generation rabbit hole… I even started to implement the A* search algorithm to help me test the difficulty of procedurally generated level content.  Luckily, I stopped myself from continuing down that path.

I gave myself a break to de-stress and remember that this was fun!  I had a good conversation about my different ideas and the pros and the cons of each with some friends.  Two ideas were left as top contenders, with my friends favoring one idea.  I headed back to the keyboard determined to work on their favorite, and then an odd thing happened: I felt confident about their second favorite idea, my very first idea… the puzzle game about “going” with a Link guy and a kitten.

It was getting to be late Saturday evening at this point, but I started doing sprites for that game.  I burned an hour or so doing some higher polish sprites than what ended up in the game, only to realize that I’d made them without any of the game requirements figured out.

Abandoned tile art.

I totally knew better, but I think I just needed to do something other than program or think conceptually at that point.  I took a step back and thought about what my levels would be like.  I knew that I wanted the whole level to fit onto the screen all at once, so that ended up dictating a certain tile size and sprite size (that was of course much different than the ones I’d already drawn! lulz!).  Having lost some more time, but still feeling like drawing graphics instead of coding, I decided to ratchet down the fidelity of the sprites even lower. I had the idea to go with big, blocky, 16 color graphics of a ZX Spectrum or perhaps CGA flavor.  I googled to get authentic color palettes. I had committed to tile dimensions that would allow for fitting reasonably complex levels all on-screen at once.  I then proceeded to have a very focused session of pushing pixels.  I drew the different wall tiles, the TP, the toilet, the litter, the litter box, the guy, and the kitten.  The guy wasn’t green like Link yet.  At this point, my Saturday was over and I went to bed.

The original tileset.

Sunday I woke up. Coffee. Donut.  It was go time!  Akihabara helped me quickly add basic level map loading, sprite animation, and tile collision.  The first real big game coding hurdle was the movement of the kitten in relation to the guy.  I had actually imagined a game where the kitten followed the guy’s exact path at a delay of four or so tiles behind.  This was going to create its own set of puzzles because the player would have to consider where the kitten would be when the guy was 4 moves ahead.

I started out intending to code this behavior. I began with a basic kitten to go with my basic guy.  The first kitten logic I ended up adding was the same logic as the guy… literally a copy/paste/tweak.  This meant that whatever input the player gave the guy, the kitten got, too.  That behavior is not terribly exciting in an empty level when both guy and kitten just move up or left together in unison, however by luck I was testing the game using a level that had some rooms with walls to run into.  This being the case, I saw that when the guy is up against an obstacle while the kitten is not, or vice versa, the two start to move out of sync — and that’s when the lightbulb went on.  I remembered playing games that felt like this.  It felt right.  I started to get different puzzle ideas around this behavior, and knowing that it was already late Sunday morning, I just went with it.  I decided that this was working, and this was how the kitten would move, and that was that.  And that’s how this guy/kitten control logic ended up in the final game.

The Testing Level

Now it was time to add the puzzle elements.  Besides the guy and the kitten, there would be a roll of TP, a bag of litter, a toilet, and a litter box.  The guy would have to pick up the TP and the bag of litter first, and then only after that the guy would have to make his way to the toilet and the kitten would have to make its way to the litter box.  I’d considered making the rules such that the guy and the kitten would have to reach these goals simultaneously, but I already had puzzles in my mind that would take advantage of this not being the case.  In fact, I made it so that when the guy is locked into the toilet, or the kitten is locked into the litter box, they become an impassible object, which creates its own puzzle possibilities.

At this point, I had the basics worked out, but only had the one test level finished.  Oh, I should mention that I was defining my levels in ASCII using Akihabara’s help.asciiArtToMap() method.  This was a nice, quick visual way to throw levels together for testing that were easy enough to tweak.  I was using TextMate as my editor, and I put it into Overwrite Mode to make editing the ASCII levels even simpler. I did have at least one mix up along the way though… to hilarious effect.

My ASCII level editor!

Oops…

Around this time in my retelling of the story was when I posted to the Ludum Dare site about not being sure I would finish.  However, with the game mechanics in place, I found it was fun to throw some levels together, and I got into the flow! I do wish I had committed to this particular game idea sooner so I would have had another whole day to do levels.  My lesson for my next Ludum Dare might be to just go with my first idea, start building, accept any serendipity, and get the first working level done while minimizing scope as much as possible before adding or expanding anything.  I’d try to do that by the end of Saturday, and leave Sunday for exploration!

So now it was getting late on Sunday.  Besides making the levels that ended up in the competition version of the game, I also worked out a basic intro sequence based on the theme.  In this intro an old man in a cave with fires gave the player the kitten.  Drawing the old man in red, as a nod to Zelda, made me realize that the player’s guy should not also be red… and obviously he should have a green outfit like Link!  I was surprised I hadn’t thought of that before.

Final Competition Tileset (Left) and Jam Tileset (Right)

For the competition version of my game, I used the default dialog functionality from Akihabara, which was a bit off from the Zelda experience.  For the Jam version, I had time to animate the fires, make the dialog more Zelda-like, and even let the guy pick up the kitten and hold it over his head!

In Part 2 I’m going to talk about the levels themselves.  Warning! If you read on there will be level spoilers!  If this is where you leave me, thanks for reading!  I’m thrilled that I participated in Ludum Dare, and I’m really happy with what I managed to accomplish in 48 hours.  I’ve learned some lessons, and I hope to do even more for the next Dare.  If you’d like to play more levels for this game, let me know!  If there is interest, I certainly have ideas for how to continue the game from here.  Also, my tools if you are curious: Akihabara HTML5 game engine, TextMate, Photoshop CS4, CFXR, GarageBand with the magical8bitPlugin, Audacity, graph paper, and a pencil.

Play the game – Click here for my game’s competition entry page.

Part 2 – The Levels

…

HERE BE SPOILERS.

…

HERE BE SPOILERS.

…

HERE BE SPOILERS.

…

HERE BE SPOILERS.

…

My original design for level 1 had no danger, and it also really did not present any logical puzzles to the player.  The player could simply steer both the guy and kitten over to the TP and the Litter, and then drop the guy off at the toilet and the kitten off a the litter box in any order.  It was meant to just teach the player the basic point of the game in a simple way.  I play tested my original level 2 with friends, skipping this simple level 1, and they understood the point of my game just fine!  Level 2 had a tiny puzzle built into it, too, so it was more fun.  I ended up trashing this original Level 1, and making my test level 2 the game’s new level 1.  I’m glad I did this, because the puzzle in that new level 1 taught the player so much more about the rules of the game and how to control the characters.

Very first Level 1… didn’t make the cut.

Specifically, in this new level 1 from the final game, the player learns that the kitten cannot pickup the TP or the bag of litter, and that the guy cannot pass through the kitten.  The player also learns how to separate the guy and the kitten because of this, which is a key lesson for solving the puzzles.

Real Level 1.

Level 2 is the first level to add lava to create some danger for the player.  It’s pretty much the same solution as level 1, but the player has to now pay attention to what the kitten is doing when it is separated from the guy.  I placed the lava somewhat randomly, although I avoided putting lava too close to where the player would probably be trying to separate the kitten from the guy.  I guess I was trying to moderate the challenge in this level, since the player is still learning.  I could have put a long river of lava along the right wall to make this level more difficult.

Level the Second.

Level 3 is the first level where the order that the player solves the puzzle matters.  A kitten in a litter box full of litter, or a guy on the toilet with TP, becomes an impassible obstacle, and the player may learn that the hard way on this level.  I’ve gotten feedback that there’s no way to restart this level when you mess up, however you can simply commit suicide by driving the kitten into the lava.  I agree that there may need be to be a reset for some puzzles, though.  I placed the lava somewhat randomly again, and just play tested the level myself based on my haphazard lava placement to get a feel for how hard it would be to play.  I have more of an intuitive understanding of the lava placement than any sort of hard and fast rules.  I did make some of the lava gaps tight so that navigating would require the player to arrange the guy and kitten in particular ways.

Level #3.

Level 4 probably starts out looking pretty simple to the player.  They have to figure out how to rearrange the guy and kitten from being left-right of each other to being top-bottom from each other, and then it is another puzzle where order matters.  Having the bottom wall and far left wall be solid with no lava makes this level a bit less challenging than it would otherwise be.

Level 4 from my competition entry.

For the Jam version of my game, I made somewhat aesthetic changes to Level 4, but by adding pillars and moving them around I believe I probably made it a little bit more challenging for a first time player to understand how to rearrange the guy and kitten… and they are also a little bit less likely to accidentally get the guy and kitten in the solution order right away when the pillars are moved like this.

Level 4 from my Jam version.

Finally, Level 5, which only appears in the Jam version of the game, really ramps up the difficulty by having the entire left and right sides of the puzzle being lava.  There was originally only two paths through the lava towards the items below, one for the guy and one for the kitten.  I felt that this made the puzzle too much like the others where it was about the player figuring out how to separate the guy and the kitten.  So, I added extra paths through the lava in order to make the player think a bit more about how to solve the puzzle.  I put items in tantalizing places that encourage the player to not pay attention and accidentally plunge the kitten into the lava.  I also put extra TP and bags of litter into this map for the first time as to make identifying the correct paths through the lava less obvious.  At first I had the toilet and litter box goals just out in the open in the bottom part of the map, but then I realized I could move these up into the lava and have the player re-enter different paths from the bottom, which would be less obvious and more fun.

Level 5 from my Jam version.

Each level that I added basically evolved from me understanding a new situation that could be presented to the player based on the basic rules and limitations of the game world.  I was trying to exhaust the possible puzzles I could present to the user with the mechanics I had before adding any new puzzle elements, like other dangers.  I certainly could make a ton of just slightly different maze levels like level 5, but I wanted to understand the different basic ways I could trip a player up, so I’ve have more paint brushes in my level design arsenal.

Thanks for sticking all the way until the end!

Well, that’s all I’m going to ramble on about. Thanks again for reading!  If you’d like to play more levels for this game, let me know!  If you have any questions or criticisms, those are welcome, too.

Play the game – Click here for my game’s competition entry page.

As the title says, the post-compo version of my entry, Torch, is now live on Kongregate. I’ve addressed most of the bugs I found, added sounds and music, some more detail to the tile set, and other miscellaneous things.

http://www.kongregate.com/games/alexlarioza/torch

Neat! Quaintbrush was featured today as a jayisgames.com Weekend Download.

Check it out:

http://jayisgames.com/archives/2011/05/weekend_download_184.php

I never finish my games. There are exceptions of course, but even now, I have urges to let Minions or Champions or whatever I’m calling my LD0 catchup game fall into the past. I managed to finish two games when I was in middle school. Ugly, ugly things. My code for those two games was the most unprofessional thing I have seen to date, and the result wasn’t pretty. I got them sponsored, but I think games were easier to get sponsored back then. After a long break from game making, in 2009, I finished another game. It was pure mediocrity. But it was an improvement.  It’s still sitting on FGL waiting for a sponsor.  But my code was cleaner. And this year (school year; sorry but I go to school and that’s how my perception of time is ordered), I finished my miniLD25 entry, Blind, and my LD20 entry, The Legend of Zelda on Budget Cuts. I consider them to both be successes at least in terms of good coding practices. And in between this all, numerous, various projects have fallen into neglect and died. But this year, it’s not as bad as before.

So the question is: why? What changed? And I think I have the answer: both LDs, I was motivated to sit down and finish the job. In all cases — whether it was working through the night and till the deadline, or … scratch that “or”, I did that both times — I had a specific goal and a specific time period to finish. My other projects almost all got too ambitious. Each of these times, the project was exactly what I expected. Each time, I counted on spending part of the weekend working on the game, and got that exact amount done in practically the whole weekend. But I did get it done.

So I need to motivate myself. I need to set clearer goals and duedates. So I am resolving to take on a medium sized project (I’m not quite ready for major yet), and finish it before the summer is out. I haven’t decided what it is yet, but there are plenty of options. Note that I said project, but not game. I’ll get back to this in a minute.

This school year, I got a lot more serious about programming than I was before. I plan to double up on two CS classes next year. I will be taking the two semester AP compsci course, and the two single semester systems level programming and computer graphics classes. This means that on entering systems and graphics, all my classmates will have taken the AP class and I will have not. In order to be allowed to take the class, I have to learn Java and familiarize myself with all the standard data structures common to most languages. And this must be done by the start of class, so I have the summer to finish. This might be my project.

I also want to learn two (and a half) other languages/programs. I want to learn python, and also Unity in one form or another (most likely using javascript or Boo). The half is that I think mathematica might be worth knowing. Learning one of these properly might be my project.

Of course, I might simply make a rather complex game.

So why am I telling you this? Not because you have to care (though that would be nice) and not because I want to vent about how I never finish anything (though let me tell you, it really sucks), but because there’s no taking it back once someone reads this (assuming the amount I have typed does not scare every prospective reader away). This is it. I’m committing to doing something, and no more needs be said.

—
Mikhail Rudoy

P.S. Someone please remind me how to add the more tag so that I can edit it in and edit this postscript out.

Let me start saying that this is my second LD (previous one was LD17). Before entering to LD20 I watched the keynote and I “almost” cried: It’s great to be part of this.

So let’s start the postmortem of The Last Robot Standing…

Before knowing the theme

I wanted to make an isometric game like the ones I played when I was a child. I still remember the day when I played Knight Lore a game made by Ultimate (aka Rare) in 1984 for the Sinclair ZX Spectrum game.. it was the first “3D” game I had played and the graphics and gameplay were incredible.

The name of the game engine of Knight Lore was Filmation. So my goal was to make a Filmation engine-like game for LD20.

More information here:

http://en.wikipedia.org/wiki/Knight_Lore

http://en.wikipedia.org/wiki/Filmation_engine

My reaction to the theme

At the begginning I didn’t like the theme. I remembered I vote against it. But majority rules

It was hard to think about a game that was original and my first take was to refuse to use the “take this” part of the theme as part of the gameplay.. I wanted to use it for fun only instead of getting an object like a gun or something like that. That proved to be very hard 😉

Tools

I used:

Coding: Game Maker 8.1

Graphics: Paint.net

Music: ChordPulse + GXSCC

Audio: Audacity (I recorded my own voice for “sfx”)

Game development blog

The first day I was working on the engine. I wanted to have a map made of 8×8 isometric rooms, with two height levels made of fixed and movable objects.

I started with a basic 2D map and gameplay:

Then I changed the “draw” methods to make it isometric, I had already experimented with isometric graphics so it wasn’t too hard.

I added then movable objects using the chapter “Pushing boxes” in the book “The Game Maker’s Companion: Game Development: The Journey Continues”

Then I added jumps to the main character and movable boxes stopped working. Also, calculating depht was very hard and it was more like a trial-and-error solution rather than a bullet-proof algorithm.

It took hour to realize the movable objects weren’t solid objects so that was the reason I coudn’t jump over movable objects.

After that I implemented enemies. Enemies were very simple, they have an initial direction and speed and an arm rule (left or right). If they collide they use the arm rule to find a new direction.

After implemented enemies, I broke the movable objects code again I came up with terrible hacks to solve it 😉

I changed to a B&W (actually 4 colors) look and feel, and I added a B&W TV “filter” (actually it’s a transparent sprite). That was the end of day one:

So starting the second day, I had a pretty decent engine but not a theme-related gameplay.

Eventually, like 6 hours before deadline, I decided that the object was going to be a music or mp3 player that the hero would use to listen to music during the game.

In a couple of hours I put together four “songs” using ChordPulse (a relatively unkown “band-in-a-box”-like application) and then I saved the songs as MIDI files and gave them a 8-bit treatment using GXSCC.

A couple of hours before deadline I decided to use the movable blocks to push enemies against mortal blocks (spikes). It was hard to make the enemies instances to remember that they were killed when entering again to the same room, but I could solve it.

One hour before deadline I came up with an idea for the game ending…. so the game now had a story

What went right

The tools: I have become very proficient in Game Maker. It is simple to use. Now with version 8.1 it was easier to edit rooms. For the graphic style Paint.net was great and for music…

The music: I really love ChordPulse and GXSCC. I could put together 5 songs that I’m very proud of. The songs are not great compositions but I think they are simple and add value to the game. This is the “final battle” tune (it’s simple but I really like it):

Final Battle song

The engine: I can’t believe I actually wrote a filmation-like engine… I wish it was 1984 and I would have been rich 😉 Of course the engine is super simple, but I think it’s a good start

The gameplay: I really liked the gameplay.

What went wrong.

The music: I really would have liked to have more time to compose more and better songs.
The graphics: I’m not very good at graphics, I’m mainly a programmer so my graphics are very blocky and geometric
Few game elements: the hero, fixed blocks, movable blocks, mortal blocks and one type of enemy.. but I couldn’t do more in 48 hours
Few rooms – small map… again I couln’t do more in 48 hours.

Conclusions

I really liked this LD, I’m proud of finishing a game in 48 hours and I will continue working in my isometric engine.

I hope you enjoy playing the game as much as I enjoyed making it.

My entry

A gameplay video in spanish

Good luck to all participants

Tags: postmortem

Hello there,
I just found out about LD from Notch (the creator of Minecraft). I think its a great idea, and I’m gonna try to participate in the next event (August?).
Anyhow, does anyone here think its against the rules of the competition to take the Platformer Kit in XNA and heavily modify it (add features, use custom art, etc.) and then submit that as your game? I mean, if you add a story and completely redo the art and stuff, its not the same game at all. I’ve been learning C# for a while, but only made 2 games or so. I find that getting started is the hardest part, but once I’m past that I’m fine.

Thanks,
Varmitharen

So, not being satisfied with the completion rate of my LD entyr, i decided to work on it some more and upload it to a Flash hosting site. I spent waaay mroe time improving it than I intended, and people are still pointing out bugs, which I’m trying to hunt down.

Anyways, I’m pretty much satisfied with what I got now, and I already spammed some flash-hosting services with it.

So, what’s changed:

Level redesign
LD version didn’t even use half of the 128×128 tile grid, the improved version utilises almost all of it.

Graphics upgrade
Added many new tiles, redrawn some enemies, added flickering effect to bullet to distinguish them from other stuff. Also, parallax background (yay!)

Final boss
Added a boss, and a pretty hard one. Actually, it’s the only hard thing. Or…

No future mode
When you beat the game, you have an option to test your skills in ‘no future mode’ (a cake to anyone who figures where this term comes from) IMO it’s unbeatable, but who knows….

Explosions
I aimed at having a lot of explosions in this entry, and all I had was some dust. I fixed this by adding loooooooooooots of explosions.

Plot
Now it has an intro, therefore a plot. It might not be an epic one, but it comes with a twist 😉 Also, I made the character talk. Talking animation was done during the LD, but there was no code to wrap it around.

More weapons
Haha, no, that’s a lie.

Game balance + physics update
I updated the physics a bit, so that you have more control over the character, and balanced the game so it might actually get tough at some point. I took my time to reply the game thousand times to balance it properly.

Music
Actually, music is the very same cause I couldn’t push myself to change it after listening to it so many times, even tho I know it’s shit 😛 But I added intro music (not mine, tho). Ok, I changed the music track due to lots of comments saying it’s shit :P. I spent about 2 minutes making the old track so no wonder 😛 Anyways, the new one should sound much better.

Now let me nag you with this lengthy comparison:

And try it there:

Kongregate

Newgrounds

Original LD entry

Also, it’s awaiting approval on other sites I spammed with it. Wish me luck with that!

Is should note that I’m developing my entry, Against the Wall, into a full game. You can check out my progress on the game’s new site. I’ll post a non-compo webplayer there in the near future.

Now for some self-analysis: On the Friday evening of the competition, I initially tossed around a number of ideas that in retrospect look like the ramblings of a madman. The best one was about a herd of cattle that get telekinetic powers and rampage through a city. Not wanting to do the animation for that, I eventually settled on something simpler: a 3D platformer where the player must climb something by using a special item that forms ledges. I was hoping for something Mirror’s Edge style with the platforming, but the eventual hasty execution of that game mechanic left something to be desired.

I made a bunch of boxes, wrote some C# code that made them react to the player’s input, and limited this input by requiring the acquisition of a special item. What the item was, I had no idea at this point. I was wavering between a tk glove or a magnetic device before calling it a magic wand and moving on.

Saturday began with a texture hunt. I grabbed a digital camera and took pictures of some marble and granite surfaces in a nearby park. Other elements photographed were a blue bath towel, a bookcase, and a random metal box. I applied the stone textures to the boxy models which I created the night before with Blender.

For the procedural world, I bit off more than I could chew. The number of bricks that would exist on even a small chunk of the wall would quickly add up into the thousands, causing my PC to chug. I spent almost all of Saturday on this feature.

Sunday started with mesh creation. I made a model for the quest giver and faced him away from the player’s starting point, so that the player may initially think it was a human silhouette in the distance. I pinned a note to him (that pops-up and goes away far too quickly) that quoted the theme of the competition, and placed the wand in front of him. I crafted the city-ledge high above the player, made fake walls for the unplayable areas, and scripted some code that would trigger the player’s “winning” of the game. Problem is, I didn’t test it. The blocks that I had placed in a gap under the city that were supposed to be movable were prevented from moving due to a glitch. Imagine my surprise when I found out that my compo entry couldn’t be beaten!

The take-away? Primarily, I need to budget my time better. I spent almost all of Saturday on my ambitious procedural generator. Placing the bricks by hand would have been well enough and would have taken less time. I should have focused more on the platforming gameplay and level design. Second, I should have set aside the last few hours of the compo for testing my game. Instead, I left everything to the last moment, resulting some major bugs. Third, I went into an eleventh-hour panic when I couldn’t log into my server and Dropbox was my only alternative, then panicked because I did not load it in the right compression format, then panicked that I didn’t initially put up a webplayer, ending-breaking bug, etc. In other words, I need to chill out.

The competition was a fun challenge, and its constraints forced me to think outside the box and make something unique and interesting. My objective now is to flesh-out the game world with some story, add a variety of gameplay mechanics, and form this mess of hastily assembled code into a game.

Please take the time to play and criticize the compo entry. If you like what you see, you can follow my progress on Against the Wall ‘s site.

This was my second LD and I’ve partaken in numerous Allegro Speedhacks before so I was quite used to the format and knew what I was getting into. I also had the fortune to have a completely empty schedule for the entire dare, so I could go into it 100%.

I choose to go with AS3, because that what I program in daily but I hadn’t used Flixel before. In retrospect it absolutely speeded up my development but  I don’t think I will use it again as it didn’t really match my coding style. All in all I’m pretty happy with the outcome even if it came out a bit too difficult.

You can try out the game here:
clicky

What went wrong
- scope
The original idea had way too many features that of course didn’t make it in the end. I had planned everything from magic weapons to hordes of different enemies but in the end only melee and ranged weapons. In addition to this every little fighter is simulated with too much detail. They have damage levels, different weapon skills, and other preferences that the player never sees. This could all have been removed with out affecting the game, saving a lot of time.

- balancing
When the game eventually was playable I realized that it would be a nightmare to balance. All the little things that controlled the fighters, merchants and soldiers made the inner workings way too complex. Changing on variable had unforeseeable results which in the end kept me from even trying.

- scheduling
I sat working way too many hours without taking any breaks. Not good. This made me very tired and I had difficulties tying everything together in the end. 

What went right
- idea
The idea of running a shop came almost right away and I was quite fond of it. I hoped that the supply idea and the whole balancing act as a weapons supplier would work good enough to build around. It did work out fairly well I think and I think the choices presented to the player are interesting enough with room for improvement. 

- graphics
I aimed pretty low for the graphics and just wanted to have something that was recognizable. I used breaks in coding to spend time on improving the graphics and I think it works well for what it is.

- difficulty
Even if the game is set at ‘developer difficulty’ and it wasn’t really intended, I must say I quite like it that way. It is relentlessly difficult, but still fair enough to the player and it always feels doable to win. At least next time you play.

…
That’s it! As I’m currently reviewing and rating all the entries I’m amazed by the rich and creative spectra. Good work all!

This entry was posted on Monday, May 9th, 2011 at 10:55 am and is filed under LD #20 - It's Dangerous to go Alone! Take This!. 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.

Here is a shiny graph of votes and coolness

It generates itself from the current data so it will be up to date.
It will actually work for some previous competitions too.

Tags: graph, voting

Well, my game didn’t turn out too bad! I’ve received some encouraging comments on it, and hopefully some generous ratings. If you haven’t played it yet, here’s the link and a screenshot to catch your attention:

Take this! (and everything else)

I have to say, making this game in 48 hours was really fun. Hadn’t I been busy after the weekend, I would have pounced on my other project(s), and started working on them like I was on a 48 hour deadline, from all the adrenaline pumped in my veins. I probably had more fun making it than I had playing it! So after hearing the feedback on my game, here’s my own judging of it:

When I was thinking about what my game would be like, I tried to design something that would be easy to implement, easy to learn, but challenging. It worked more or less. It was simple, but because of the time limit, I wasn’t able to make difficulty settings or levels or game modes. This, like I was afraid it would, made the game hard to balance in terms of different player skill. It works if you only play it one or two times, as it becomes “hard” pretty fast. However, once you get the hang of it, when you reach the maximum difficulty (which you will, very fast) all the challenge disappears. I myself got to over 800 points and then stopped because I was so terribly bored. Players who played it once or twice reported between 102 and 60-something, but I’m sure they would have gotten the same score as I did if they kept on playing. I was only able to face this issue by the very end, since I had been making the engine up till then, and I was pretty tired.

So that was the main issue: The game advanced too quickly in the beginning and didn’t advance enough at the end. I think it would have helped to have more than 6 characters (I found that having a lot of items really spiced it up, especially after there were more items that fingers on your hand. Besides that, about the graphics, in terms of prettiness, they are simplistic and overall look like they were made by a child, but in terms of being practical, they’re very informative and really helped the players learn and play the game without becoming confused about what’s happening (one could expect this to become an issue in a timed reflex game about a crowd barging into your home). The sounds and music are non-existent due to the deadline, but like someone noted, it’s “Better than bad sounds”. Like the same person said, “the lack of polish is obvious”. So I’d like to apologize once again for the default Game Maker message box and highscore table. It was added right at the end. It was late, I was tired and realized that I needed something like that. Sorry! But I was very happy with the initial splash screen, which was also added at the very end.

After this very long reflection on an insane weekend of game developing, I’d like to end by saying that I’ll probably be polishing and expanding this game a fair bit after the competition. Hopefully I’ll fix the difficulty issue by adding more characters/levels, add some more gameplay mechanics (restoring health), giving it audio content and polishing it a bit (at least remove the default Game Maker stuff). Maybe I’ll include it as a mini-game in the main game I’m making.

Thanks for reading, thanks for playing and thanks for the feedback!

I’m not that great at post-mortems or recaps or whatever, but I did polish up my game a little bit after the competition ended. It handles different resolutions better now and delivers in-game messages in a less annoying way. It also includes music and a voice-over for the intro, not included in the compo version because I couldn’t/didn’t make them myself.

So, without further ado, Leaving the Vault v0.3.0:

• Windows Version
• Linux Version
• Cross-Platform Python Version

I’m really not likely to make any further additions or improvements to this specific game. I’ve started collecting all the best parts of the code and some other things I made into a framework to use at the next (mini) LD. I suppose I’ll see you all then!

????

What do these mean?

Hups, i planned on uploading the timelapse of making the game the day after the compo but forgot to since i intended to add some gameplay video into a dead period of the timelapse. Never got around to it and instead of just letting it rot on my drive i decided to upload it now as is instead. Better late than never eh?

Timelapse video on vimeo

Tags: timelapse

I’m in for Mini-LD #26.

Here’s what I plan to use for this:

• ActionScript 3 – Programming Language
• FlashPunk – Boilerplate Library
• Flex – AS3 Compiler
• Geany – IDE
• Inkscape – Graphics
• as3sfxr – Sound Generator

I’m not sure what I’ll make just yet. But, I’ve realized that I really do like Flash and I really do like AS3. I shouldn’t fight that love.

Peace, love, and clean code,

— Mr. Dude

Tags: declaration of intent, mini ld

Hey guys!

I wanted to see what you guys think of a little game I have been working on: Solar Quest!

It’s a little 3D space monopoly game based on the board game of the same name. Get it here!

Windows Installer

Let me know what you think!

Yo peeps

It’s not dead, so I can’t really perform a postmortem examination, but let’s take a critical look at my second Ludum Dare entry.

The main thing I wanted to achieve this LD was to make a multiplayer game that was fun to play with my family and mates. After my first LD, I was proud of what I had made but was aware that it wasn’t a whole lot of fun to play, and lacked polish. It’s cool, but I wanted to do better this time. My main focus was to make it fun. I think I have done that.

What went right

Focus on fun – I wanted to make something that I would actually play after the competition was over, and that other people would have fun with. I kept it as simple as I could, and focused on making it fun. I think I succeeded here.

Getting feedback early – I made sure that I got other people to play it before it was done. I think this ended up making a huge difference to the multi player. When my brother played it with me, he wanted a way to kill me himself, and the trailing asteroid turned out to be the most fun way to do this. Getting people to play test it during the competition definitely helps.

What went wrong

I must be looking at this with rose-coloured glasses, because I’m having trouble coming up with something. I guess this means that keeping it simple means a lot less goes wrong. That being said, I’m sure you all will have plenty of constructive criticism to share. Check it out, and let me know what you think I did right and wrong with this game.

Play Take This Convoy

Well, it was my first LD and it was some ride!

Friday:

I already decided before the competition that I would use FlashPunk & FlashDevelop for development, Box2D for physics, MinimalComps for UI and Paint .Net for drawing.

Other than MinimalComps I had already worked with all of the tools to some degree, and felt confident with them, and while I didn’t know MinimalComps I figured it would save me the trouble of drawing my own buttons and such, so it would be worth it…

Saturday:

I woke up at Saturday morning, and went straight away to see the theme.

I then realized how dangerous it is to work alone, so I took this!, and then spent the next ~2 hours coming up with ideas. I tried to think of something simple, that I would be able to make something playable fast with, but which can also be extended after the competition will be over.

Eventually I came up with a bit weird and vague idea, that seemed simple enough to accomplish, and looked fun in my head. What I first imagined (I think) was basically you building your army to stand against your enemies, and then slipping to the next room while everybody is fighting and shooting at each other… Something like a mash-up between Plants vs Zombies and Heroes of Might & Magic (the battlefield part), only with puzzles that combine both tactical thinking and real time co-ordination.

Did I say weird and vague already?

Well, at this part, I obviously concluded that I won’t be needing physics so I ditched Box2D, and decided to go on a tilemap based game. Also, since this idea can still go in plenty of directions, I decided to first try to do some level design before even starting to code, to see if this idea is even feasible.

So I spent the next ~2 hours designing 10 simple levels. I did that with an awesome tool called notepad, it lets you write different characters on screen! I simply wrote all my maps with ASCII characters where each symbol meant a different unit, enemy or obstacle. During the level design I also designed the player’s units, the enemies, the obstacles and the player behavior. I also had to design how each of these interact with each other, which I did, but did not think it through (as will be seen later). For each level I wrote down the layout of the room, and my proposed solution to see that all levels are passable.

When the level designs were done, I actually had to go and visit my father, and then meetup with some friends (earlier engagements). That wasted several important hours, and as soon as I came back I sat down, pulled an all nighter and drew all of the tiles.

These look less than pretty, but that was what I was able to come up with at such short time and with limited skills. In the official version, I hope to partner with an artist and make some super awesome graphics! In fact, if there’s an artist who wishes to join me, feel free to contact me.

I also started scripting the UI, it was then when I realized, that MinimalComps is simple only if you don’t touch it! I just wanted to make the font larger, and discovered that it was not really supported, so I had to hack the code, another waste of time…

Sunday:

Next morning,  unfortunately, I had to go to work. Yes, there are countries in which Sunday is a work day, mine is one of them! Another waste of time…

As soon as I got back, I started frantically coding. The first thing I did was coding a level map reader, so that I could simply put my earlier notepad designs in, and it would layout the level for me. That worked pretty well and saved me some time, and so I started to crank up the first levels. I coded the behaviors of the units and enemies, play-tested it, fixed some issues and continued.

As I reached the more advanced levels, the time was starting to run out, and then I realized that the advanced levels assumed some abilities that I had not coded, and were now pretty complicated to make. For instance, the enemy archers should shoot my player as he runs out if they are not occupied, even if they are not on the same row with it. However, I coded the archers to only shoot at stuff coming on their row, which made them pretty pointless as enemies if they are not in the player’s row, which they weren’t, because I had already put some other stuff in that row…

Since it was already too late, I decided to scratch the last 4 levels, and I quickly designed a single new advanced level which would fit with what I already coded. After that was done, I play-tested the game from start to finish and saw that it’s playable. However, I only play-tested the right solutions, I didn’t try to play-test wrong player behavior due to lack of time.

I had maybe 2 hours left at that point, and I wanted some spare time in case of uploading trouble. The one feature which was obviously missing was a “Restart Level” button for when you die. I really hadn’t planned it in advance, it was an afterthought, and as a result, it only works half the time…

Well, that’s it.

So, to sum up:

What worked-

• I selected in advance tools that I’m familiar with, which made my job easier.
• I chose an idea which I honestly like, and I think has a lot of potential.
• I made the level design first. This gave me insight into the coding.
• I coded the level map reader, which allowed me to easily switch level layouts, and this could expand later on reading output from a full fledged level editor.

What didn’t work-

• The biggest problem was that I didn’t make enough time to work on it properly. I will try to amend this in future LDs.
• I gambled on MinimalComps for UI, which I didn’t really know, and it only partly paid off.
• I didn’t think through the interactions between the components of my game, when I designed the levels.
• The “Restart Level” feature was an afterthought, I should have thought about it in advance. More generally speaking, I should have sat down and decide on what features are a must before starting to code.
• I only play-tested the solutions to the puzzles, and didn’t give much thought to other actions that the players might do.

In the end, despite all the faults, I am pretty satisfied with the fact I have an idea which has potential to become an interesting game, and from the feedback I’ve been given, I’m not the only one to see this (which is a first).

Brass Monkey – Post Mortem
A Treatise on Simian Semantics

What happened…

When I first heard the theme “It’s too dangerous to go alone. Take this!” I sort of shrivelled up and died. I had placed this right at the bottom of my list of preferred themes. It seemed too generic, too clichéd; it simply didn’t grab me.

The irony here being that a tight rigid theme allows more creativity than a vague theme.

I judge a theme by how quickly they evoke images, characters and game play. Many themes like “absorption” and “evolution” gave me instant visions into doors of wondrous possibility, but the final chosen theme gave me nothing – just a mental blank page.

So, being confused by this theme, I desperately wanted to steer clear of anything predictable, and of any concepts already done. (Perhaps I get a point for this… ).

I spent the entire first day thinking, scribbling, walking, and generally procrastinating. I spun yarns in my head about a far future monkey race of beings (a la Planet of the Apes). In this context, the player could then be given an ancient artefact of any design – this idea amused me greatly, and struck me as the crux of “escaping the usual”.

For some reason, a trumpet came to mind.

And of course, what would a monkey know of trumpets? Perhaps it is a hat (which was the original idea, and it is implemented in the game; but it bounces up and down so it’s not really very evident that it’s a hat).

Some idea I had involved Pied-Piper-esque scenarios… a silhouetted monkey dancing across a barren landscape, playing a trumpet, leading a multitude of rat-like post-apocalyptic mutants to their death.

Another idea was a kind of “simple simon” musical challenge, you would have to essentially “jam” with the enemies to defeat them.

After the end of the first 24 hours I was building a civilization in my head. This was fine if I wanted to write a novel, but I was supposed to be making a game.

But I am stickler for cohesion – the back-story of a game is important to me (he says, while typing a blog entry about a monkey playing a psychedelic trumpet).

At the end of the first day I had not written a single line of code.

THIS was a mistake.

Any code, any dirty code, any spaghettified mess of code is required at the end of day 1. Something. Something to get your project moving.

Instead I had done some “asset fishing”; this helps me think, and reflect upon ideas. So I grabbed certain CC/royalty free images that inspired me in some form or another, without really knowing what the final game was going to be.

This sort of random haphazard multi-sensory work flow is fine… unless you’ve only got 48 hours.

I slept on it.

I struggled the next day too, and played with assets – graphics and sound – still without any concrete ideas.

5.00pm on day two, I write my first line of code.

Something came together over those hours. Nothing amazing, but a nice little game that can be expanded upon. The submitted version lacks pace, and “powerups” – easy enough to address.

I’ve always been a great fan of Jeff Minter (a Commodore 64 guru of psychedelic gaming), and I wanted to add some of this flavour to “Brass Monkey”.

A couple of quick words regarding royalty free images… I wasn’t sure of the “legality” of this, it seems the consensus is I am not supposed to use them. I can understand how it’s not really “in the spirit” of the competition.

I remember reading some post where someone offered the general advice: “if it feels like you’re cheating, don’t do it”. I didn’t feel like I was cheating. And the silly thing is, if I were to use a publicly available AS3 library (like “flixel” I think it is) I WOULD feel like I was cheating.

But that’s just me, and it’s a bit silly, and it’s something I shall get over… I need to explore some of these libraries.

I’m from the “olden days” (not TOO old, but technology changes so fast doesn’t it?). Cut my teeth on programming machine language, by “hand” of course, for the 6502 chip on my Vic-20 (no assembler – manual opcode lookup, split addresses into low-byte/high-byte format, poke them into memory, and hope the machine doesn’t crash!). This is in about 1981, I was aged 12. My father is a programmer, so he helped and encouraged.

So, I was around for the excitement of the microcomputer revolution. Progressing from the Vic-20, to the Commodore-64 and then the Amiga (…oh, the Amiga, how I miss thee). So, I’ve always written my own libraries for everything, because computer were much simpler back then.

BUT all that being said…
I highly recommend the LD experience to anyone and everyone!
It IS challenging, but also great fun!
As difficult as I found this one, I still enjoyed the experience!

The one big thing out of the Ludum experience is the COMMUNITY.
It is so inspiring to see the work of others, and read about their experiences and ideas. It’s also amazing to see all the different technologies – for example, I wonder what it would be like to write a game in Python? I’ve no idea… but many out there do.

There is a real sense of comradery and community here!

Cheers,

Yo LD’ers, coders and freakers,

Just sharing the news with a shameless plug…

There will be a juicy two-page-spread editorial about the game “Track King” in June’s edition of “Racing Victoria – Inside Racing” (Australian horse racing magazine).

Stoked!

“Track King” is a game that my friend and business partner created, with additional design and content from me, including flash based applications (RaceVision, Silks, DNA lab etc.). He covers the PHP/HTML bases. We’ve put in countless hours of work since TK was launched late 2007.

It’s a multiplayer online stable management game. We won BBG’s “Best Simulation 2009” award against some pretty tough competition.

www.TrackKing.org

Play Now Vote

In the Beginning
Going into the competition I didn’t really have any direction. After hearing the theme and looking at the kitten meme and the Zelda text I figured I would start off with an elf kid going into a cave and receiving a kitten rather than a weapon, but other that that I had no idea for gameplay or anything. I knew for tools I would use CoffeeScript and the PixieEngine (I have been creating PixieEngine for exactly these kinds of competitions and wanted to put it to the test). If you’re looking to try out a new development environment for easy publication to the web I recommend checking it out. It’s free! It’s still a bit rough around the edges but with your feedback we can make it better.

It was quick to get the initial level and cave in but I wasn’t sure what direction to take the game. I spent several hours on animating the sprites, drawing the kitten from reference of the meme. Art isn’t my strongest suit but spending time on it gave me time to think and I definitely could feel myself improving. After sleeping on the theme the first night I knew that I didn’t want to just have the cat act as a weapon, because that would be pretty plain and boring. I decided that it would be cool if you had to take the cat around to different dungeons and work together to solve puzzles. I had the idea to make the water impassible for the kitten around this time so that the player and kitten would need to work together to access different areas. I also spent some time getting the mew to sound right in SFXR.

I really wanted to focus on the emotional attachment to the kitten and to make it feel like you were helping each other. It is for this reason that the initial cave the kitten goes into narrows symbolizing a feeling of cramped/claustrophobic danger. This culminates when the kitten becomes trapped in a waterfall and the player is required to submit to entering the water and becoming helpless. Then when the kitten floats back out down the stream the player is given control of the elf character and must rescue the helpless kitten. The relevant psychology is that we develop good feelings towards those who we do favors for (similar to Portal’s Weighted Companion Cube). These locations, actions, and even the sound of the mew, were all designed towards the goal of creating an emotional bond.

The bombs were an ok addition, but didn’t have very much depth. It seemed like near the end of the game (especially at the ending) there was plenty of room to create a wide variety of levels and puzzles, but I had just solidified the core mechanic and core emotional experiences and the clock was still ticking down.

My brother was in town and late Saturday or early Sunday, in the course of viewing the game he came up with the idea for the ending. I spent several hours Sunday grossly copy/pasting and hacking the functionality in. This cost me a bit in terms of level design. An additional cost of adding screens was due to some excessive manual steps (like hand coding doors). In the end there were maybe 1.5 dungeons and 1.5 puzzles, but people really enjoyed the ending so I think it was a decent trade-off. As the level editor and game object tools improve it should become easier to add more levels with fewer manual steps.

All in all it went pretty well. I didn’t stay up too late or stress out much, but the time limitations were significant. Next time I should make a stronger effort to discover a fun core mechanic sooner to leave more time for level design. The risk of this is that I may lock down the mechanic too soon, before it is actually fun, but I think that’s the main conflict throughout game design.

The Good
The pixel editor, level editor, and sound editor integration in PixieEngine really helped me get a playable prototype up quickly. I was able to get a guy on the screen and moving around in minutes.

The API for many of the core components was simple to use. If I wanted to play a sound I would create it in the embedded SFXR, then call it by adding Sound.play("mew") at the appropriate place in the code. Similarly for loading sprites.

The engine Object Query Language was great for hacking together quick functionality engine.find "Player", engine.find "Item", engine.find "Cat" all came in handy.

Experience with CoffeeScript and the PixieEngine system was also a big plus. I knew what the strengths and weaknesses of the system were and was familiar with the workarounds (like using git integration to copy files to get around the missing “Save As” feature).

Publishing to the web was immediate and 100% hassle free because the entire engine is online to begin with. I didn’t have to spend anytime thinking about packaging or distribution.

I actually got to make a serious attempt at sprite animation, and some of the two-frame walk cycles actually look decent. Also the things I was drawing basically looked like the things they were supposed to. Still room to improve immensely but so far a personal best.

The Bad
As a home grown engine there were many parts that were still rough around the edges. The tilemaps and game engine had no built in concept of rooms, persistent entities, and transferring state from one room to another, so I had to just hack it in.

The file management was similarly rough: there was no “Save As” (though there is now because it was my #1 issue)

Our animation/model system isn’t as integrated as the sounds/images/tilemaps so I had to hack together my two-frame walk animations by hand.

Still don’t have an integrated music editor. I was able to do all the art and (most) sound effects from within the editor suite, but had no option for music. I really want to make some sort of online Mario Paint Composer style editor, but realize that it would be a pretty big project in its own right.

The lack of a shared “object toolbox” of all the classes of objects was a pretty big negative. This meant that for each screen I had to recreate the tiles by dragging them in, and manually setting their class and data properties. This especially sucked for doors where I needed to hand type the destinationPosition. The good news is that this is the next feature on our list and once it is fixed things are looking great!

The Best

Because I coded in PixieEngine, everyone is free to view the source, fork the game, make alternate levels, and more. (Though the engine is not quite “easy to use”. Your feedback is greatly appreciated!).

Though I wasn’t able to get in all the levels and puzzles I had hoped for this was still a personal best LD for me. I have had a great experience this LD and am looking forward to the ones to come. Additionally, all the feedback was helpful and it was nice to see that people enjoyed the game. If you haven’t yet, please play through and let me know what you think!

Play Now Vote

Hi All,

It’s been almost two weeks since the competition, and I figured I’ll write a bit about my experience in creating Dragon Island.

What went right:

1. Graphics and tile engine: I am quite happy with how the graphics turned out, given the time limitation. Even more so, I am happy with my trusty tile engine which grows from LD to LD – this time I added “depth” sorting to allow for this “3d” look.
2. Music: I really like how the music turned out to be – after writing it I though it reminds me of a part of “Dune 2” music, but that was not intentional (although my sub-conscious probably is to blame…).

What went wrong:

1. Gameplay: I am actually disappointed that my gameplay didn’t go as planned. It is full of bugs, and controls are iffy. This seems to be a common problem with my games, but this time it was the worst – I think next time I will need to prototype the game play MUCH MUCH earlier on in the competition, and make it work first. Pretty graphics and nice music doesn’t help when the gameplay is flawed – we are making GAMES here.
2. Time management: I am not sure what happened this time, but I didn’t really manage my time well this time around – I got to the evening of Sunday with very few working elements, and needed to rush everything – usually I’m better at this.
3. Theme: I didn’t like the theme, and I didn’t even know the reference for it (Zelda, and/or the Meme). Well, I work with what I get – but I don’t like the silly themes, so it would seem.

I think that’s about it – thanks every one for a great competition and be sure to play and vote as much as you can (I am very busy these days, I just hope to rate the assigned games at least…). Go play!

Thanks,

Daniel

Hello everyone, I’ve been meaning to write this, but with reports and project deadlines bearing down on me I kept putting it off.

This was my first time participating in Ludum Dare, the primary goal I had was to finish, and have a game that was at least partial fun. I finished on time, and I’m overall happy with my entry.

What went right:

– The Teleporter concept, worked overall I would have liked to have more complexity to it, and some sort of combination

– Construct, I was able to get the player movement and Teleporters function working within an hour. As well as having a platform to create level layout on visually.

– The tutorial level, it was the first level I created, and I think it did a good job explaining the concepts.

– Sound Effects, I think they worked good, but with the music in the game you could hardly hear them.

What went wrong:

-The art, (kinda sad seeing as I’m a Fine Art major) When I started with the tutorial level, I was thinking of a high contrast game (mostly Black and White) Then the next level I added more textures and it didn’t look right. It also went wrong with a photographed main character, then a drawn enemy (though in my defense I did add the photographed player at the last minute)

-The music, haha shouldn’t have  even attempted it. I haven’t had much experience with LMMS (or music of any kind). The volume was way to loud, and the music looped wrong, in addition to just being a bad song.

-Construct, (yea it was both good and bad) I had troubles with the Minimap (although they are solved now and I should have been able to figure it out before). There is also a crash that stems from the minimap (I believe).

I’m working on an updated version of the game. I’ve already increased the starting speed of the devices, fixed the minimap. I’d like to add some player animations, powerups, more levels, and I’m going to change the overall look of the game back to a high contrast look. I’d also like to see about adding a scoring system.

You can play the compo version here

Hi, I’m proud to introduce you gLapse v0.1, a GUI GNU/Linux tool to make time lapse videos of your Ludum Dare work progress. gLapse allows you to take desktop screenshots at fixed intervals and glue them together in a time lapse video. I developed it because there only were command line tools to make time lapse videos on Linux… until now!

Features

• Take .png screenshots at a custom time interval and with variable quality.
• Make videos from using the saved screenshots with custom FPS.
• Multilanguage: English and Spanish for now (more translations are welcome!).

Installation

gLapse is very easy to install if you use a Debian related Linux distribution like Ubuntu or Linux Mint:

1. Download the .deb package.
2. Install it.
3. You can run gLapse from your applications menu or by typing “glapse”.

If you don’t use a Debian related distribution, these are the needed steps:

1. Download the source package.
2. Decompress it and access the folder using a terminal.
3. sudo make install
4. You can run gLapse from your applications menu or by typing “glapse”.

License

gLapse is licensed under the GPL v3 conditions, its free software and I will happily receive code contributions or new translations :-).

Feedback and more

I’ve intensively tested gLapse but if you ever find any problems, please report them to the issues sections at the Google Code site. It’s quite easy and it would be a great way to contribute.

I would like gLapse to appear in the time lapse tools section, that would be really awesome. I think gLapse could help many Ludum Darers who are not experts using command line tools or simply prefer GUI applications.

Tags: Debian, gLapse, GNU/Linux, Google Code, GPL v3, time lapse, tools

I’m in for the upcoming mini-LD provided I don’t have to roadtrip that week.  I’m waiting to hear back about a possible job opportunity in my area.  If I don’t get the job I’m going to have to drive halfway across the U.S. to stay with relatives.  So as long as I’m in one place, I’d love to participate.  This will be my first Mini-LD and second LD overall.

My tools will (probably) be:

IDE:  FlashDevelop

Codebase:  AS3 + flixel + flixel power tools

Graphics:  Photoshop

Sound:  Sfxr/Bfxr + Audacity

Music:  FLStudio

Tools:  Handheld whiteboard and 8 colored markers; Programming hat of +5 code skill

I have a couple ideas that I hope can fit with the theme.  One is an atmospheric platformer (pretty generic) and the other is an orthagonal (3/4) view puzzle game with a unique means of interaction.  I really hope I get to do the latter.

Excited as always!

Edit: Looks like the 26th is a Thurs.  Since I’ll hopefully be getting a new job I may opt for fri-sat instead. Nvm.  Misread the date.

With only a week left of voting time, I figured it’s high time I get around to writing a post mortem for my game, Elidia.  Elidia is a game of survival, where your goal is to avoid the enemies for as long as possible.  The theme came into play by certain weapons which help you to destroy the enemies.

Click to rate Elidia

What went right:

• Choosing an extremely simple concept.  In the past, I have bitten off a bit more than I can chew in just 48 hours–I have always made something playable, but it hasn’t been for very long.  Elidia is as complete as my original concept.  Obviously it can use some refinement and expansion, but I am very happy with what I got done.  All-in-all, the whole thing really took me about 16 hours of work.
• Having a game that doesn’t need a story.  I’m a big fan of story-driven games, but they’re almost certainly too much work for a Ludum Dare.  I opted to have a game which didn’t need a story to be played.  That being said, I’d like to think that there is a bit of a story told through the narrative.  Speaking of…
• Using audio.  In the past, I have only really ever used SFXR or BFXR to make sound effects.  I opted for a text-to-speech program this time around, since I thought it would work out better than generic “pew pew” sounds.  I also figured I could work a bit of humor into the speech, since it doesn’t really fit anywhere else.

What went wrong:

• Not adding enough variation.  There is only one type of enemy, but ideally there will be many more–each with something different about them.  I will also add a lot more variation to the audio so it will be less repetitive.
• Figuring out the best graphical style.  I wanted the game to be a lot like Geometry Wars, but didn’t want it to be a copy.  While the game play is actually very different, the style is like a very simple version of Geometry Wars.  I plan on coming up with a style which is unique to Elidia, while still keeping its influences.
• Not changing the size of the bounding boxes.  This is easily the most hated part of Elidia.  Each enemy is a triangle, but the bounding box is a square which encompasses the entire triangle–so you can still die even if you’re pretty far away.  I knew this was an issue, but never got around to resolving it before the competition was over.

In the end, this is my most successful Ludum Dare yet.  I managed to complete the game I set out to in the alotted time, and it seems to be getting good feedback.  Obviously I don’t know how it’s doing vote-wise, but it’s still a big success to me.  If you haven’t played it or rated it yet, what’re you waiting for?!  Good luck to everyone in the competition!  

how to be a girl, my LD20 jam entry, has been updated. I suppose I could call it ‘how to be a better girl’ now, or something. I dunno.

The game’s jam page is here. Or you can go straight to the updated version here.

After recovering from LD20 I decided to spend this past week adding to how to be a girl in an attempt to make it feel more complete.  So what did I do?

I added endings. Plural. Not that I expect anyone to put up with the game long enough to see them all (there’s three). I think the main thing I took away from the feedback I got, was the game lacked a sense of closure (it really did). I’m not sure if the endings I’ve added quite do the trick. I could probably do better. One of the endings in the game works pretty well for me, the others possibly less so. Who knows, I may come back to the game in a while and fix them up. Maybe not; they’ll quite possibly stay as they are.

I also added a couple more interruptions for a tiny bit more variety. This is a very minor addition since the interruptions are all functionally the same.

Perhaps the biggest addition, at least in terms of the amount of time it took me, is music. I spent most of the past week recording and editing. I’m quite happy with how the soundtrack turned out, so you download it here, or from the game’s website, if you want (you probably won’t like it). The download includes a couple tracks which did not find a place in the game. I would maybe have used them for a couple of the endings, except their length would have caused a fairly large increase to the game’s (file)size.

If anyone’s wondering, the only program I used in creating the music was Audacity, with a few plug-ins. The music is all thumb piano (played by me) and noise. For the most part all of the noises are recorded sounds that I applied various effects to (the only non-recorded noise is the buzzing crescendo shared by the two tracks that are not in the game).

Give it a play, if you wish, and leave some feedback, if you so desire.

Currently working on a graphical retouch of Quaintbrush.

Right now, I have a really rough 2.5D system set up.

I finally got around to making a little walkthrough of my LD20 entry. So if you had trouble running it or didn’t want to download it, or are just stumped by the staggeringly complexity of the puzzles, then check it out:

Also includes a quick looks at the “Sproxel” voxel editor I used to make the characters and tiles.

Will there be a post-compo version? We’ll see…

This entry was posted on Wednesday, May 18th, 2011 at 4:12 pm and is filed under LD #20 - It's Dangerous to go Alone! Take This!. 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.

My name is Jim Peterman, and I am a video game music composer studying at St. Olaf College. I’ve worked with zillix a couple of times on Ludum Dare projects, and am looking to write more. I can write in a variety of styles, and have a large number of sound resources with which to supply a game. I am used to writing under a time crunch, and generally write a piece of game music in two hours. Check out my portfolio:

http://www.kongregate.com/games/Zillix/endeavor
http://www.kongregate.com/games/Zillix/p-i-g
http://www.kongregate.com/games/Zillix/summit (same music as endeavor)

Hey there, folks.

Over the past couple of days, I’ve been working on a boilerplate library.

I love FlashPunk, but it doesn’t do everything that I need. I need skeletal animation and more complex collision detection and response than FlashPunk can provide.

Therefore, I’ve taken it upon myself to write a boilerplate library of my own.

It will have skeletal animation, a proper entity hierarchy (FlashPunk has none, Flixel’s is purely organization), separating axis collision response (In addition to hitbox collisions, of course), a gui system, and other things that I will add as I need them.

I’m not 100% sure of the name for the library, but I’m leaning toward “SpudTech” because, well, it sounds funny and I like that in a library name.

That being said, you folks can expect me to use my library in further LD efforts. Probably including this month’s Mini-LD.

Peace, love, and buckets of cheese,

— Mr. Dude

Well, ok, it’s the updated version of my game, but all the levels in the original version are in there. (apart from the first, but if you need a walkthrough for that…) This is also proof the last level is possible. 😉

Hey,

I ported my Jam game over to Android !

However, many users have had crashes, etc… if any devs can give it a run and do an “adb logcat” and post the results here, that would be a huge help!

(The game is also available on iOS, PC, Mac, Linux too, if anyone cares to check it out!)

-Phil

UPDATE: Android build is so broken I took it down.

Here’s the last push for a bit of attention to my LD submission, if you have a second and haven’t already done so, please check it out and toss me whatever rating you feel it’s worth.

This whole experience has been absolutely fantastic. Thanks and much love to the organizers and participants for making this such a great ride to be on!

There’s a walk-through video, a time-lapse, and a self-hosted project page if you’re interested.

Here I present the “edited and abridged for LD’ers” version of the post-mortem:

What Went Right

1. Leveraging the Power of Unity Prefabs

All of my past projects up to this one had been done almost exclusively in C#, with almost no special use of the Unity environment. They were done that way to help me come to grips with coding in C#.

For this LD, I threw that mentality out the window and crafted nearly everything in scene, using prefabs. What an amazing difference it makes! Defining game objects, exposing the variables on them, and using drag-and-drop to configure game play is really what Unity is all about, and I’m glad I had this LD to finally realize that.

2. Scripting Tight

Sort of a knock-on effect of switching over to prefabs, code bloat was immediately reduced to a negligible amount. With all the variables explicitly used and exposed on the game objects in scene, it was far easier to manage what was going on and limit the overall messiness of the scripting process. That’s not to say there’s no kludgy-hacky nonsense going on, but there’s far less than there was when I was in pure code mode.

3. Winning the Theme Roulette

This time I followed the theme selection very closely. I hadn’t before because I didn’t want to set my sights on any one theme before the final was announced, and avoid any kind of disappointment. This time I didn’t really fixate on a theme, but I had a very strong feeling that ‘It’s Dangerous…’ was going to be chosen. The night before the compo I dreamed a fully-formed concept for a game that used this theme, so you can imagine my relief when it turned out to be the one that made the cut. Lucky advantage.

What Went Wrong

1. Uneven Production Process

When tackling any long-term project, I tend to break things down into manageable chunks and then assign levels of ‘completeness required for play’ to them. This means there’s a round of building, and producing passable assets so that I can start to see if a game is going to be fun or not.

For Ludum Dare, though, it seems that one thing that makes games stand out and get recognized is the end quality levels of art. I’ve always envied these 2D wizards that can crank out beautiful pixels for their projects that really make them shine. So, I told myself I was going to push it to the limit with the 3D assets this time out. The problem was I focused so much on making the 3D nice that I had little time for audio and controls polish.

It’s always a trade off, a fine balance of managing just how much to produce in the time given.

2. Not Enough Kitties

Apparently this is also an important thing to producing a popular entry, and I’ll endeavor to add more cute meme-cats to my future entries.

3. Not Enough Zelda

Looking back at it now, I probably could have taken the time to insert at least a few nods to the venerable Nintendo classic, but I’m still happy with my interpretation of the theme and glad that it left enough leeway for all the other creative entries that weren’t strictly focused on emulating the Tri-force hunter in one way or another.

It’s really important to note that this LD sparked enough of a creative fire under my butt to finally abandon another project that I wasn’t really having much fun with and shift all of my production over to creating an improved version!

Thanks again and congrats to all that participated in this LD, I’m looking forward to seeing you all and more come the next one.
–
Jack

<click here for Dark Acre Jack’s entry>

Tags: Dark Acre, Jack Nilssen, LD #20 - It's Dangerous to go Alone! Take This!, post-mortem, postmortem, the Child

S-Raid has been an interesting experience for me within Ludum Dare. It’s my second entry into these contests, and hopefully a fair bit better than my previous one. With the ongoing Finals and all kinds of extreme busy business I’ve been busying myself with, It’s been hard to keep track of things at times. I’m glad I’ve managed to make it though.

-GOOD POINTS-
Got music, base code, and basic designs of levels all done within the first day. I felt relieved at this, since my first day consisted of a trip down to the Zoo, basically cutting the time in half.

The Formations seemed to have gone well for the most part, I managed to sneak a level in which was very reliant on good formation control to get through.

-BAD POINTS-

Oh god time. I had half of my first day spent in London, and the last day was also side-tracked by watching the Thor film. If I had this time, I would have managed to fix all the bugs I had for the game such as Sound Effect volumes, Bullets flying through Rangers without being destroyed and having Blasters and Shields for the main ship. Another thing I was hoping for was a definitively final final boss, with some metaphors, mumbo-jumbo, etc thrown into the mix, which got scrapped. Hopefully I can do this for a sequel of sorts if done.

-WHAT I’VE LEARNED-

Time management is a huge deal for these projects. Not only this, but also the fact that, a project needs to be reasonable to complete in a solo effort. Grandiose ideas might be fun for this stuff but some of the ideas I had didn’t make it through the drawing board simply because It would take too long to make it through.

Sleep is for wimps as well. Who needs it when you have Crunch-Time Deadlines?

Final thing I learnt from this experience is that finals and such are very important. Games are too. It’s a tough choice. ¬(‘_’)-

Till later, have fun folks~

http://www.ninjadodo.net/temp/LD19/rosetta_v5.zip

I’ve done some more work on my Hieroglyph deciphering experiment. Added a new page between one and two where you take a look at the actual stone and go through some more steps before arriving at the obelisk puzzle. Plus various tweaks, both visual and functional.

Tags: Egyptian, Hieroglyphs, Rosetta

Hey I wanted to share the fact that I just finished my website! Please let me know what do you think of it! Also, I got this coooool domain name! I feel like a better man now

Visit www.sos.gd

Special thanks to everyone who helped me with that on IRC!

I’ve got my game idea for the Mini-LD.

I’m interpreting the theme as follows:

1. Getting it done is the most important thing
2. The actual “theme” is less important
3. It’s a Mini-LD, so the rules can be bent
4. Therefore: It’s more important to get the thing done, so the actual “theme” can be neglected and it’s not too much of a big deal

That being said, my idea has very little if anything to do with the potential themes. I really love the idea, though, and want to make it happen.

The premise has a wide scope, though, and I’ll only be able to get a subset of it working during the Mini-LD. That’ll be a good push for me, though.

The game is about a fox that has to get eight elemental crystals (Fire, earth, water, air, and four others I’ll figure out) into their respective altar-type places to get the Forces of Nature back into balance before the World is Destroyed. The Mini-LD version will have the first crystal and a “To be continued…” at the end.

The game will be a Metroidvania where the player collects various skills. The Mini-LD version will have at least two of them.

Looking forward to this,

— Mr. Dude

Tags: ideas, mini ld, rule bending, rules

I’ve been meaning to write this postmortem for a while, but keep putting it off because my thoughts on it keep changing. After watching a few people play my game first hand, I think I’ve finally figured out what worked and what didn’t.

If you haven’t played it yet, then please go and play it, going by the number of comments I think that having a game beginning with ‘W’ means most people haven’t tried it. Thanks.

So, what went right and what went wrong?

Right: Animal companions
I knew when I saw the theme that I wanted to do a zelda-like game. I’ve not done one before so it would make for an interesting change, but I thought there’d be a whole bunch of zelda-like games, so I needed a ‘hook’ to make it different. That’s where the companions come from.

Each companion grants you an offensive ability and a puzzle solving ability. For example cats give you area-of-effect fireball bursts which can kill enemies and melt ice barriers. Ice weasels give you line-of-sight ice bolts which can kill enemies and build ice bridges over holes. Snakes cause room-wide earthquakes that can flip switches behind obstacles, and birds let you jump over enemies or objects.

And they all look different too! I spent a lot of time drawing different walking animations and idle animations, so it does genuinely feel like you’ve got a different companions helping you though the world.

Right: World navigation
Originally the game was going to only have single-screen, non-scrolling rooms. However on the first day I decided that would be too limiting, so rooms can actually be any size – if they’re smaller than the screen they’re centered, and if they’re larger then the camera scrolls around with the player.

Transitions are based on early zelda games, and although tricky to get right I really like how they came out. With single-screen rooms and no transitions you don’t really get a sense of walking through the world, but with the transitions you seamlessly go from one room to another so you actually feel like you’re exploring a single giant space.

Right: Graphics
There’s definitely prettier games in this LD, but I’m very pleased with how the graphics came out. Yeah, the low-fi pixely look is pretty over done these days, but it means I could get a lot of pretty decent graphics done very fast and keep everything looking consistent throughout.

This is by far the most art-heavy LD game I’ve done – an animated player character (in four directions!), four unique NPCs, four unique companions (with walking and idle animations), three enemies, plus the environment, gui and effects. In total there’s 120 unique sprites!

Right: Dungeon
There’s two ‘dungeons’ in the final game, the tutorial and the proper dungeon. The tutorial seems to work really well – everyone I watched got though it with only minimal head scratching and it explains everything it needs to.

For the actual dungeon my main goal was to make something non-linear so players would feel like they’re exploring something, rather than just following a long corridor. I think it pulls this off well – in fact I suspect it’s too non-linear, which overwhelmed some players. A smaller, easier dungeon to start would have been good but I didn’t have the time.

Wrong: Setting
Since the original inspiration was The Thing, the ice base theme fitted well when I was trying to think of non-zelda-like settings. However the combination of lack of time and lack of drawing skill meant I ended up with a fairly vague environment that didn’t really look how I wanted it too.

Originally I’d planned on having separate indoor and outdoor sections, but lack of time sunk that idea – I just didn’t have time to draw another set of environment graphics and the required code to hook them in.

Readability was a big factor too, and one area where the low-res look causes issues. Everything is drawn to be obvious as to what it is, and to be visually distinct from each other. Adding in extra environment detail would have made the puzzle elements of the gameplay harder to grasp.

Wrong: Dungeons
Quite simply, I ran out of time. I actually had two full dungeons designed on paper, but it took me over two hours to physically type in the first one (rooms were just text files with Xs and Os to designate walls and buttons, etc.) and make sure it was solveable, so I didn’t have time to add the second one. (Oddly, the one in the actual game is the second one I designed).

Because of this, the one dungeon that is in wasn’t properly playtested. Which brings me to…

Wrong: Balancing
Again, I ran out of time. Two things are pretty obvious now:

1. The player’s walking speed is far too slow. It probably needs to be about twice as fast.

2. The game is far too hard.

The first is a problem because it frustrates players, and means they give up as soon as they die. The second is more tricky to pin down.

Partly it’s because it’s an exploration/puzzle game, and so I obviously know the correct route through the dungeon. I find it really, really easy. But if you don’t know the route, it’s really, really hard. I should probably have made the dungeon more linear (or had a ‘starter’ dungeon). Also, I think being able to die was a bad idea. If you die you have to start the game from the beginning, but to compensate I gave the player lots of health and lots of places to heal themselves. I think instead I should have given them less health (maybe three hearts?), but made ‘dying’ just place them at the start of a room again, with full health.

Conclusion?
So there we go. Overall I’m very happy with it, it’s by far the most polished LD game I’ve managed, with by far the most content. I’ll probably go back and tweek things, and add in the missing dungeon (assuming the judging result doesn’t say that everyone actually hated it).

If you’ve played the game, I’d love to know if you agree/disagree with anything above.

Thanks.

Just a few hours left. Time to post-mortem my game…
Introduction
Take This Triangle is a 2d defense game inspired by vector graphics from the old-school. Spring physics from the new-school, and doobers from the school of Zynga.
TTT was written in C/C++ using SDL and completed in the 48 hour period and is playable on OSX and Windows here. If you want to play it on another platform it should compile just fine.

Figure 1: Estimated Time Usage

1. Vector Graphics

A massive amount of time was freed up by choosing to focus on what I don’t suck at (writing code, play testing games) and dodging what I do suck at (trying to be an artist).

2. Fun Core Mechanic

Dragging a springy things is fun. Clicking on doobers is fun. These two mechanics together worked well.

3. Small Scope

I managed to avoid feature-creeping the game or trying to undertake something too complex for the given time frame. Executing a small idea well is much preferable to a executing a larger, broader, but more rushed idea.

What Went Wrong

1. Starting at Zero

When the competition began I had an IDE and an zero base code. It took a few hours before I could begin writing game code. Preparation is key.

2. Distractions

Staying focused is always hard. I spent a lot of time doing other things (including sleeping) instead of remaining on task. See figure 1.

3. Polishing Too Late

I wish I had started improving  the art and adding particle effects in earlier. A screen shake, glowey lines, more particles, more feedback on the dragging / aiming, more tweaks to the difficulty curve, badass grid effects. Sooo many small things I would have liked to polish.

Conclusion

Over all the process was enjoyable. I am proud of my game, it is one of the few experiments I have made that I find myself returning to in order to kill a few minutes.

Please check it out!!!

As always, LD was a learning experience for me.

Amazing to see so many great ideas executed by so many awesome people. Enthusiasm and skills abound in this little indie community!

Great work everyone.

In anticipation of the upcoming MiniLD, I am hereby announcing the release of my base code, a platform game written in the D programming language.

This time the rules permit the use of unreleased code, but as this game was not written by me alone, I think it’s fairer to release it beforehand as per the usual rules.

And in case you’re wondering, while it’s working code, it’s not a finished game in the sense that we haven’t created any “real” map for it yet. It’s also a source-only release.

Tags: base code, D

I am completely disillusioned with Ludum Dare. I first heard of this competition from a friend telling me to try it out saying how amazing it was. He convinced me to go ahead and enter. Then I burn an entire weekend only to find that in 21 days my entry recieves 22 ratings from 288 submitters (7.639%). Of those ratings, many are blatantly done without reviewing the actual submission. Some were obvious downvoters, others gave undeserved 5’s all around the board, while others just gave random scores, or NO score for categories I KNOW  I had, showing me they didn’t even bother playing the game or looking at my community page.

Then I see other submissions with over 100 ratings making me assume there is some kind of advertising/word of mouth meta-game in play which is always a disheartening thing to see in any competition. While I do agree the games that won top 20 deserve those 20 slots, the games that fell elsewhere were completely lost into the void, with no quality control on their placement. I don’t know how you can improve a rating system that depends on a biased party to make the votes, but as a first time participator, frankly it’s just a joke.

Essentially I am a pretty upset that for a competition that has been running as long as it has; so many submissions have fallen through the cracks, and that I unwittingly set myself up for disappointment by entering.

TL;DR – The rating system brings no incentive to participate again

I like to learn how to make an open world game, I have some great ideas I would like to know how sould the programming look like or are any recommendation on books out there, pleasea tell me whats needed.

So I made this a few days before LD20, to figure out if I can actually accomplish making a game in a short time, and also to finally get this idea out of my head.

There are Hitler-Clones. Go get them.

Go play here.

Also, mini-LD sounds fun. I shall be participating.

-Matthew

Tags: 3dsmax, max, photoshop, unity, unity3d

The Ludum Dares are such nice productivity boosters that I’ll be participating in the upcoming Mini LD too.

I’ll probably try to finish something using the 3D basecode developed based on my entry in the recent Ludum Dare 20, and that I’ve been playing with recently.  Although, going for 3D may not be a good recipe for getting things done on time in general..

Wow, my entry Change of Heart was #1 in audio and #7 in innovation. I would have never expected it.

Thanks guys. I’ve never had a game win an award before.

I should probably stop now and retire but I think I’m going to try to utilize some of these audio skills in a more action oriented interactive type of game. So let the fun continue with the mini this weekend!

Hey, and just to get the party going here, here is a little song I performed the other night (House style dance genre):

SmoothHouse.mp3

I was told to write a post describing why my game is awesome and how did it come to it. I’m going to be pretty shameless, please forgive me 😛 There we go then…

Attack of the Heavenly bats

So, When I finished the LD version, I wasn’t satisfied with it, and thought that it would be a waste of weekend not doing anything about it. I decided to finish, polish and release the game. I spent about a week on that, and started spamming the internets with it, starting on Kongregate, Newgrounds and some random flash sites.

I managed to get a deal on it, but I guess I shouldn’t disclose the details…

And then… I was completely amused with what started to happen… Since I’m pretty new to flash business, I haven’t thought of sitelocking or encrypting the game, and the flahs game sites become flooded with the game, just see for yourselves:

Google search

But! Since Newgrounds has a game name length limit, I got rid of ‘the’, so there’s more to it….

Google search

Also, Some guy on tigsource forums made a 30 minute gameplay video bundle!

Attack of the Heavenly Bats Game Let’s Play EP1
Attack of the Heavenly Bats Game Let’s Play EP2
Attack of the Heavenly Bats Game Let’s Play EP3
Attack of the Heavenly Bats Game Let’s Play EP4
Attack of the Heavenly Bats Game Let’s Play EP5
Attack of the Heavenly Bats Game Let’s Play EP6

And some other guy I don’t know where from, made another three videos!

(1) Let’s Play Blind – Attack of the Heavenly Bats
(2) Let’s Play Blind – Attack of the Heavenly Bats
(3) Let’s Play Blind – Attack of the Heavenly Bats

also, some flash websites took their time to make a +2 trained version!

Hacked version
Another hacked version

But well, they didn’t notice that I actually added a cheatcode there (Hint: Get Psyched!)

Also, the game was featured on Video Game Hot-Dog webcast!

The game was featured on newgrounds frontpage for several days, got ‘Awesome’ rating, and some good reviews. It also got ‘3rd best game today’ award’ when it was released. Moreover, today my 4 medals got accepted!

Anyways, Any minute now the game will top 150,000 plays! For now it’s 149,721 hits, and it’s up for only two weeks! It gets about 6k hits daily!

Hmmm… what about Kongregate then… Well.. as soon as it dropped from the frontpage, it stopped getting hits, and kongregators forgot about it 😛
See for yourself: Kong version
And what about Flash Game Licence? Well, i managed to get a deal without FGL, and on FGL I got 1 buyer view, and he spent 16 seconds playing the game.

My point is, that Kong and FGL are not suitable for every kind of game…

For all I’m pretty much excited and hyped! I was even asked to make a sequel, and I will surely do so! It was hard work to get there, since I have a programming dayjob and needed to do tons of fixes early after the release. But it payed back, and I can shamelessly state, that I made an awesome game 😉

I am going to take part in mini Ludum Dare 26 as I had so much fun with the last one. Unfortunatly people did not like that I used XNA as it required installing the game and I do not blame them.

I have decided thefore to start learning flash and use it for the mini LD. I only started learning on the 21st so don’t expect too much

I will be using FlashDevelop, FlashPunk and Photo Impact 10.

Hey, I’m gonna do the Mini LD. This will not only be my first LD but also my very first game EVER! I got Game Maker about a week ago and have been playing around with that. I’m also going to use Musagi and sfxr. I have no idea what I’m doing here, but I’m super excited and I’m gonna do it anyways. Wish me luck!

You’re awesome.

I was going to post the usual frustrated-about-voting-results post. But I let it sit there for a while and realized it was useless. I just wanted to say thanks for the great LD as usual, and thanks to everyone who commented on my game! And a really big thanks for those of you who gave me a rating for community even though the game didn’t even work for you. The comments are always my favorite part of post-compo fun and I’m thankful for those that I got.

I tried to put all the over-thinking of it and strategics away this round; I Named the game what I wanted to, not something that would show up on top just for the sake of it showing up on top. I didn’t like the theme; I threw it in the gutter and made a game I actually enjoyed. Hell, I wasted an hour making “box art”. I just had fun and I hope y’all did too. I’ll see you at the Mini-LD!

I’d like to let folks know what I’m starting with for this Mini-LD.

I am starting with my engine, SpudTech, having the following features:

• Basic entities (They have collision bodies and graphics)
• Basic scenes
• Graphical classes (Static sprites, canvases, tile maps)
• Tweens (Number, motion, angle) (Not tied to object variables)
• Hit boxes
• Incomplete skeletal animation system

I also have “template” XML files for my game’s data, as well as “list” files for listing the XML data files.

I have no graphical assets or sounds premade, and no game-specific code.

I have a concept lined up that I really like, and I’m ready to get it on!

Peace, love, and all the luck in the world,

— Mr. Dude

Already have some ideas based on all eight given themes, and I’ll likely be using the exact same set of tools as before. Flex, Flixel, Photoshop, Audacity, some variant on SFXR, the DAME map editor, and IntelliJ as my coding IDE.

Let’s see if I can get things done.

First game ever made (by myself and not copying a tutorial) will hopefully be completed for the upcoming MiniLD! I tried to participate in the last LD with the Blender Game Engine but failed with the Library Linking System, so over the past weeks I have taken up the task of learning flixel. And that is what i shall be using for this MiniLD.

So, This is a list of what I should be using:

-flixel

-flash develop (flex)

-Photoshop (graphics)

-sfxr (sound effects)

-LMMS (music, maybe if time permits)

Can’t wait till the topic is posted in the next few hours, and having a good time game making!

-JaydenB

This will be my first mini LD

I’ve done LD19 & 20 so I’m not completely new here.

I’m not 100% sure what I will be using yet, either XNA 3.1 or Java Swing.

It depends on the theme really, I’ve only been teaching myself Java for a few days so if I can’t think up a simple game that matches the theme, then XNA it is.

I’ve discovered a way to allow users to play an xna game without needing to install anything (as that was  a major complaint of my last two entries). So I will be using most of sunday trying to get this to work (assuming I use XNA).

But yeah, I’m in 😀

Good luck to my fellow classmate also participating (vooodooo).

This will be my first Ludum Dare entry, and the first time doing something larger than a few boxes with audio sources in OpenGL/AL in C++. I’ve gotten much farther with Java using JOGL and Java’s sound libraries. So I’m not sure how well it’ll go or if I’ll even finish , but hopefully I’ll be experienced enough by August for LD21! 😀

As for my personal codebase, I recently wrote a quick little resource loader for RAW and WAV files which I’d like to use:
http://pastebin.com/LAjthruu

• Language: C++
• IDE: Eclipse
• Compiler: MinGW
• Codebase: OpenGL+freeglut, OpenAL Soft+alut
• Graphics: Gimp, Flash
• Sound: Sfxr, Audacity
• Music: Tuxguitar, M1 le

Good luck, all!

Title: Therian

The title comes from a word used by some “spiritual” sorts to describe individuals who feel a highly spiritual link to some sort of animal or another.

Description:

It is about a woman with the ability to turn into an animal who has to gather 8 MacGuffins to save the world from an evil demon.

[stextbox id=”info” caption=”What is a MacGuffin?” collapsing=”false” collapsed=”false”]For those who don’t know what a MacGuffin is, it is an item that is used in a plot, but that could be substituted for a similar item without affecting the plot.

For example, an ancient artifact might be substituted for a magical crystal in a fantasy plot without affecting much.

This isn’t a negative term strictly speaking, but is a pattern in fiction.

The term was coined by the website TvTropes, which is a wiki that identifies and defines common patterns in fiction. These patterns are called “tropes” and include such things as types of characters and common sorts of fictional civilizations.[/stextbox]

Mockup:

Here is my mockup:

The finished game won't use stick figures

Definition of “Done”:

I define “done” as follows:

1. Three forms: Human, fox, and rabbit
2. Three world areas
3. One “animal altar” (Where the player gains the ability to turn into a rabbit)
4. Finished hitbox and hitbox grid collisions for SpudTech
5. Animation cycles for running and jumping for all three forms
6. Sprinting animation for rabbit form
7. High-jump animation for fox form

Optionally, I may include the following:

1. Sounds for movement
2. Water and swimming
3. A fourth form: Cougar
4. An altar for the cougar form
5. A scripted widget or two

These are unlikely, though.

That’s pretty much it. I will say this: I am willing to spend part of Monday working toward this if I really need to. I hope I can get this done, but I’m not just dead certain.

I will use the following tools:

• Flex (AMXMLC) (Flex’s AIR compiler)
• Adobe AIR Runtime (Framework for stand-alone AS3 apps)
• Adobe AIR Debugger (For testing)
• Geany (IDE)
• Inkscape (Graphics editor)
• SpudTech (My game engine)
• as3sfxr (Sound, if I get that far)
• Tiled (Level editor)
• Python (Scripting, will use for code generators and data mungers)

Due to the nature of Adobe AIR, my game will require you to install it unless, of course, you have the Adobe AIR Debugger. I figure that I will want to make a larger game out of this, and AIR is good for that. I apologise to anyone who is deterred by that choice. This Mini-LD is more for my own work than for making something that is publishable. Really, I’m entering mostly so that I can work through a standstill that I’ve hit with SpudTech.

Peace, love, and rapid development,

— Mr. Dude

(Edit: I have decided to toss the themes, because I think that the idea of “done” is the core concept and my game idea is nifty enough to warrant tossing the actual “themes”)

This is my first LD, mini or otherwise, and I am very excite! With this game, I hope to incorporate three of the themes in the list: Descend, destroy, and detonate. The intent is to have the player pilot a submarine in search of treasure at the bottom of the ocean. Once found, the treasure must be snatched up and taken to the surface in order to be redeemed for points. Getting to the surface is going to be the hard part, for underwater pirates and other challenges stand in your way.

Mockup:

Done = 3 weapons (torpedoes, remote mines, prox mines), pirate ship enemy, shark enemy, procedurally generated ocean levels, music and sfx

Now for teh codez.

I’m in! I’ll be using the “Dig” theme, and (hopefully) creating a game where you just mine. And mine. For your boss. Because it’s your job. You can also build automatic things that take your minerals to the top. If I can implement it. I’m at the MCMexpo in London for the whole of saturday, but hey! If anyone remembers the game “motherload”, it’ll be like that. Ish.

Name: DIG. (subject to change)

Description: Just mine. And build cool contraptions.

Mockup Image:

Done: If I’m able to implement the basic mining things, money, and a few basic contraptions.

Just in case anyone cares, I’ll be using AS3 with Flashpunk. ^^

Title: DDDDDD
(VVVVVV an obvious inspiration, as I plan to implement as many of the D-themes as I can)

Description: Playing as an adventurous jerboa, you use various methods to dig your way toward the delicious grub buried deep within the ground.

Mockup image:

Goal: At least one level with enemies and the goal, with equippable dynamite and drill items.

If you are on twitter, and you are participating in the Mini LD this weekend – Don’t forget to submit your screenshots and WIP shots to http://www.screenshotsaturday.com

Its easy : Post a link to an image on twitter and use the #screenshotsaturday hashtag to tell the site you want to submit. Thats all!

And take note, you can start submitting and Friday and still submit on Sunday! Its more “around Saturday” , then just saturday.

We are also running a small survey (really small) about the site, if you are interested in giving your 2 cents! http://j.mp/iGNK5e

This is my first MiniLD. The basic idea for the game is a vertical map in which the objective will be to climb to the top. For now it will be a split screen game for 2 players and the second player will also try to go to the top, but with the map inverted so it would be like descending from the perspective of the first one. They will have explosive guns to help themselves to climb, and to stop the adversary advance.

ASCII Mockup Image: (Just because its faster than opening a drawing app)

+-----goal----+-----goal----+
 |2            |          1  |
 |---------    |    ---------|
 |             |             |
 |    ---------|---------    |
 |           1 |  2          |
 +---------------------------+

Done:

The world with split screen working, the characters with guns working, and a winning state for the game.

I’m not used to decide what I will do before I do it, so this is the best I could manage. Probably a lot of things will come and go during development.

Ah, and I will be using C++ with OpenGL.

Or, “Oh no, what am I letting myself in for?”

My themes are the above. Dig dirt, Descend into the ground, Destroy the environment for your own selfish needs. 😛

Title: Dig, Descend, Destroy

Because I cannot think of a name.

Description:

Yet Another Mining Game ™. Dig, admire the not-very-realistic water and rock physics, collect treasure! Probably die horribly.

Mockup:

Definition of Done: (Oh dear, this is the hard bit! I’ve tried to limit myself, which means I might actually achieve ‘done’.)

• Player can run around and destroy terrain.
• Terrain is randomly generated to some extent. Caves, mineral veins, streams, all very basic.
• Water moves around, in a semi-realistic fashion.
• At least one kind of dangerous enemy.
• Animation of some sort. Fairly basic.

The more I look at this list the more minimal it looks! I’d like to try to have:

• Terrain generation that makes sense and isn’t boring.
• Several enemy types
• Terrain be falling-sand like, to some extent. Haven’t fully considered how that would work.
• Sounds! Not that likely and if so, probably sfxr.
• Particles! Ooh, sparkly.
• More player control over the terrain. Buckets, maybe explosives somehow.
• Maybe a shop? That’d make some sense.
• Even more feature creep…

Code-wise, I’ve decided to go with C++ as it’s what I’m most comfortable with, and depending on what convoluted physics models I end-up developing, Flash might not be fast enough.

Art is likely to be done in a mix of Paint and the GIMP, as the latter is better but takes forever to load up.

Sounds will probably be generated in sfxr, should they exist at all.

Music? You must be kidding! 😛

In the next 72 hours I shall create “The Digger” (Working title).

Dig a hole to the center of the earth, while gathering valuables and avoiding HOT MOLTEN LAVA. Behold, the fake screenshot.

Yeah. I’m not really a fan of producing “how it’s supposed to look”-stuff. I’d rather spend the time more productively, like actually working on my game.

“Finished” game shall include
– automated level-generation
– several valuabales and hazards
– highscore-system

-Matthew

Tags: 3dsmax, max, photoshop, unity, unity3d

A: Name of the game – pitdive

B: Description (140 chars) – dive into a never-ending pit of exploration.

C: One mockup image – see below

D: Definition of Done: (Example) 3 levels, 3 enemy types, 1 boss, music track, sfx

Done = 1 “unending” level, enemies, a boss,  weapons, sfx.

Title: Silhouette Skater

Theme: Detonate

Description: The player is a skater who must navigate over oncoming obstacles using a ramp placed by the user using the mouse. When the player reaches the end of the top half of the screen the player will start in the lower half of the screen and continue to complete the level. Once the player has reached the end of the lower screen the level is complete and the player will move on to the next. The player will Detonate if they touch an obstacle.

Mockup image(Very Basic):

Definition of Done: 10 levels, sounds, nice graphics and hopefully fun.

I’ve just realised I’m out literally the whole weekend. Saturday at the MCMexpo in London (if anyone else is going, I’ll be there as Fancy Pants :D) and then Sunday up to a festival… And I had a nice game idea going too

You can play what I managed to do here: http://natpat.hostoi.com/miniLD.html Click to remove the blocks, arrow keys to move. I’m kinda proud of it… kinda :L Be aware it’s very buggy… I didn’t have time to implement ceiling collisions

Screenshot! :D

Name of the game: ‘lotsoflots’

Description: ‘lots and lots of autonomous agents try to bury you alive and you got to Descend/Demolish/Destroy/Detonate/Dig/Dirt/Drill/Dynamite’ your way free but they’re being directed by an advanced learning algorithm so you can not.’

Definition of done: ‘When you can complete the game by escaping the onslaught of many projectiles and its a bit of a challenge.’

name:  Zombie Descent

description: You play a guy who tries to get the treasure from the bottom of a mine full of zombies.

definition of done: 2 Levels, shooting Zombies, collecting items

Title: Glitchin’

Description: A reverse roguelike where you play as a buggy game trying to keep a player from winning.

Done:

• A procedurally created dungeon.
• An opponent “player” that can navigate the dungeon with goals, attempting to find treasure and the exit.
• The true player can cause glitches, destroying parts of the dungeon.
• The opponent can find bombs and picks, allowing them to destroy your dungeon.
• Music and sound effects
• At least two monsters to be used by the player to stop the opponent via glitches.
• At least two environmental effects (lava, gas, so on) that can be used in the same way.
• Some neat ‘glitch’ visuals.

So that’s my concept: A game where you play as the game. Too ambitious? Probably, but I have a handle on most of it. The tricky bits will be the opponent players, since I’ve never done any sort of complex AI. I’ll probably go for a lo-fi NES or DOS game aesthetic. Maybe even use the horrendous CGA palette and rely on interesting glitch effects to carry the visuals.

Mechanically, I want to explore the concept of needing to give up pieces of your dungeon to win the greater battle (you know, the Destroy part of the theme), as well as the idea of toying with players.

My tools:

flixel, flixel power tools, (possibly) TweenLite, Pro Motion, sfxr, FL Studio. I may also find some open source Pixel Bender effects to use.