“Alien Super Mega Blaster” in play test  and can be downloaded and installed on your XBOX for those of you with an XNA Creators Club account.

http://tinyurl.com/23h3cr6

Same gameplay as LD18 submission, just changed a couple classes to allow the game to  be controlled via a game pad and added a splash screen for selection of the active controller.  The last remaining change was to tweak the rendering to allow the 800 by 480 resolution to be displayed centrally on a TV screen.

The windows compo version is still here  and appreciate all the feedback: http://www.ludumdare.com/compo/ludum-dare-18/?action=preview&uid=1516

Indiegames.com, ByteJacker and more. Hit the jump to see what the rest of the internet thinks about how you spent your weekend.

(more…)

Just wanted to let people know that the source code for every single compo entry has been verified and is available for download.

That’s 172 games, all with source code, for your learning pleasure.

I’d like to request that if you did a jam entry to consider uploading the source as well, if you can, because it is just cool to do so.

Hey everybody,

Judging is in full force now, and hopefully you’ve been playing competition games (nudge nudge wink wink). Now that we’ve all had a couple days to rest, it’s time for the question:

Did you like the new Ludum Dare (Competition AND Jam)?

Share your thoughts in the comments.

My timelapse is uploaded!

http://www.youtube.com/watch?v=GiHW9Kum49I

Hey guys
We made an Jam-Game, so our game is not in the list to be rated, so it would be very nice if you try out our game and leave some comments. This would help us to improve our games and our iteration.

Here is a link to our game: LINK

Thanks a lot
glethien for BazingaProductions

Now that I don’t have to rush to get everything done, I’m going through and redrawing everything in Fromulus.  Everyone seems to think it’s got good art (and I do, too), but it could certainly be better.  I was definitely rushed to get it all done in time, so now that I no longer have the pressing time constraint, I can do things the proper way.

The obvious first place to start is with the character graphics.  Fromulus in the old version was in a profile view, which was certainly easier to draw in a short time, but not as good to look at as a 3/4 view.  The enemies are already drawn in 3/4, so it makes even less sense for him to be in profile.

Here is a comparison shot of Fromulus’ old casting animation versus his new one:

The most important difference is that I increased his saturation quite a lot.  On top of this, I got rid of his single-color border and used darker versions of the color being outlined.

So, what do you think?

Time for a post-mortem. Even though they are apparently totally useless: after 8 years of Ludum Dare I still make the exact same mistakes every time.

I thought the theme was really nice at first but then when trying to actually think of something original it wasn’t so great after all. In fact, there seems to be lots of games with a similar concept to mine.

1st mistake: My first idea is always something unrealistic and it’s never clearly defined. I can never think of something clear and simple at first.

2nd mistake: As a result, I either start working randomly on things that I don’t use in my final game or procrastinate. (or both… v__v) I only got really started on my final idea at 11pm on Saturday when the compo started at 4am local time. Almost a full day wasted.

3rd mistake: Trying to make a puzzle game and ending up with an “action-platformish” game. This happens almost every time. Seriously my ideas are often based on solving puzzles but somewhere along the way I have to change it when it doesn’t work as intended. For example, I spent some time extracting code from the enemy class to allow the player to move in the same tile by tile way as the robots… and had to change that back to my initial platformer controls…

4th mistake: Making the playable levels at the last minute leaving no time to test and adjust the gameplay. Another classic, I don’t have all the gameplay elements so I leave the levels for the end and I have to try to think of ideas for levels using the only gameplay mechanism that was actually implemented. This time it was particularly bad as I realized that the robots not firing at the same time made it almost impossible for them to destroy each others on some levels. When I tried to fix that it was worse, it broke all the other levels and I had to improvise a solution that would work with both types of levels.

5th mistake: Lack of polish. I haven’t made a game with a title screen since LD #5. I never have the time to do that kind of things. This time the deadline came as I had just opened Reason to try to make some kind of pseudo-music. Too late :/

On the positive side, this time I was able to make an animated main character. That wouldn’t have been possible if I had not tested how to create and export animations from C4D to Unity during the RPGDX compo the week before so at least I wasn’t completely unprepared this time.

Anyway, I still had a lot of fun making my game and I’m looking forward to repeating all those mistakes next time.

I’ve updated my LD final entry page, but I wanted to let you know that I finally created a Stop That Hero! Windows port (2.2MB)!

Now you have no excuse not to play! Well, assuming you don’t use a Mac. Or some other OS. Then you have an excuse.

@ LoneStranger

“Is that a Lego setup on the left shelf? Is it a battle or some kind of scene?”

Yes it is! Allow me to get kiddy for a second or two. That is actually my main sci-fi base. On the right top shelf is my custom Jedi temple (which is partially covered by plastic trash. On the farther LEFT, out of the picture, is my castle fortress. In the center, behind the laptop, is a slightly trashed town set up.

@Spiridion and Osgeld

No, it’s more of a time thing. I go to church on sunday mornings and evenings. So that means get up 9-ish, church for 2+ hours,  dinner, nap, dishes (maybe), bout an hour left, then church again. So I really had no time at all left. Also, any bad programmer art is better then my bad pixel art.

@alistair aitcheson and madk

Thanks for the suggestions! Although, if I’d use a starfield again, I’d probably just go with one color. Maybe white. Though pink does sound lovely.

@everyone else who posted on the quitting thread

Thank you! It’s nice to see this sort of encouragement. I’m gonna really gun for it in december and try and make a game in time. Thanks again!

My f****** internet died just when i was about to see the theme. And i’m still connection-less. Im in a cibercafé =(

I would cry if i werent in public.

Well… that was my third attempt… you can “not win”, but some times you also “EPIC FAIL”.

Bye, i gonna get a chansaw to kill Arnet. =P

I’ve taken a few days of a break, and now I’m ready to come back and write a post-mortem!

Play illumynate here

This was my first LD, and I didn’t really know what to expect. I’ve only ever finished and released one game before, so I was pretty worried about what I would get done in 2 days.

My goals, before the competition:
-I wanted to make a game that I would want to play
-I wanted to make a game that I would enjoy making
-I wanted to finish a game
I’m happy to announce that I was able to achieve all 3 of those!

The preparation

I decided I would enter the competition about 4 days before it started. I knew for certain that there was no way that I would be able to design a game engine as well as a game in the time allotted, so I really wanted to try to learn a framework that would do some of the engine stuff for me, namely flixel, since I have a soft spot for pixelly games. Getting flixel + flashdevelop installed and working, as well as going through the tutorials, were unquestionably the best uses of my pre-compo time. I also learned how to use some accessory programs, like sfxr, Mappy, and GraphicsGale, which I would end up using. By the time the theme was announced, I was comfortable with using these tools the way I would need to during the competition.

The idea

I’ll admit, some of the idea of my came was conceived before the theme was announced. I had two ideas for games, each which could be tweaked to accommodate several themes. My first idea was a tower defense game where the player couldn’t place turrets; they had to control a little guy with a gun, and use the impact of the shots to push the creeps into tiles that would convert them into towers (enemies as weapons), and pushing more creeps into the same tile would slightly change the turret depending on the type of the creep (evolution). My second idea was a cave crawler, where the player had two weapons- a flashlight and a gun, fighting trolls, which would encompass darkness, claustrophobia, hidden depths, and anachronism.

Basically, the theme was announced, and I realized that I really didn’t want to make the tower defense game. The cave game sounded much more atmospheric and interesting, so I went with that. I threw away the gun from the design, and put in different types of enemies who reacted differently, that the player had to use as tools.
The story of the game was one of the last things I came up with. What would be at the end of the cave? A damsel in distress? A rare artifact? Nothing? Once I decided to use notes as a storytelling technique, however, the current idea (and ending) just jumped into my head, and I liked it.

Making the Game

The actual creation of the game went pretty smoothly. I created the player, the fog/flashlight, then the enemies, and by the end of the 24hrs I had pretty much every class I would need finished. The second day was designated to finishing the details- the story, the level design, and the art. I got plenty of sleep each night, (5-7 hours), but I made up for it by taking very few breaks- even at meals I had a notebook with me, doodling and scribbling ideas. The only notable break was when I went out with my family to the Renaissance Festival, which did a brilliant job of clearing my mind.

I spent a lot of time on optimization, which ended up being overkill, since the .swf ran ~2.5x as fast once ran it outside of flashdevelop.

As the time counted down, I still had a ways to go. Eventually I only had 5 hours to finish everything up, and it wasn’t very polished. It wasn’t until 2 hours from the deadline that I had someone else test my game, which was a terrible mistake- I learned I had to fix a ton of bugs, make a bunch of tweaks, and clarify a lot of the gameplay, with not much time to do it.

I didn’t spend much time evaluating the gameplay. In all honesty, before I submitted my game, no one had even played it from beginning to end. As a result, I wasn’t sure if the game was any fun. I’m still not sure of that. But whatever, it was a great experience making it.
I plan on tuning gameplay a bit based off of feedback, fixing some bugs, and adding sound/music, after which I’ll release a final version of it somewhere!

What I learned

-I can make a game in 48 hours
-Have someone else playtest for bugs as early as possible
-Frameworks help a lot
-Autotiling is awesome
-Breaks and sleep are important
-Test early and often to fine-tune gameplay

Thanks to everyone who played my game, especially to those who gave me feedback in the comments!

Since this was my first Ludum Dare, making the game Alpha Channel, I didn’t make an effort to post my progress as it happened. However, through the magic of git, I’ve pulled some old versions up and seen how things developed. Interesting to see how the game progressed and if you have git you could also look at the progress made throughout the development via the repository at github.com (if you were very bored, of course).

I’m using my local time, not that of the competition, in the entries.

(more…)

So its been a couple of days since my game went up, and I thought it was high time I did a post-mortem. To give a bit of background: this is my 2nd flash game ever (number 3 is in the works), and was my first time doing a Ludum Dare, so I’m fairly new to the whole experience. Overall (spoiler alert!) it was an awesome experience that I’m looking forward to repeating(end spoiler).

The game can be found here – I’m looking to polish it up and do a re-release, so any suggestions are more than welcome.

Now, onto the experience:

Part 1: Brainstorming

My brainstorming session involved me, a whiteboard (pictured below), and Google. The first thing I did was to break down the theme into its two important points: Enemies, and Weapons. Ultimately, the idea of enemies proved to be the more interesting of the two.

Brainstorming!

Then I looked up google for sayings about enemies and weapons, and noted the most interesting down. The two that stuck were ‘Know your enemy’ and ‘The enemy of my enemy is my friend’. The first implied a game where you turned your enemies into weapons, but you had to figure out who your enemies actually were. The latter made this more interesting by suggesting a complicated web of alliances which.

These two basic ideas are what informed ‘The enemy of my enemy is my heat-seeking missile’. Essentially, the idea is that you find out who your enemies are, find out who their enemies are, and turn them into heat-seeking missiles so they kill your enemies.

At first, I wanted to use a mechanic of asking people questions to find out their allegiances, but this struck me as way too complicated and messy for a 48 hour game. This lead to the idea of using a colour-based detector for allegiances, and so the ‘allegiometer’ was born.

I’m pretty happy with the basic ideas that came out of this initial brainstorming stage, though they may have been slightly too complex to explore in terms of level design and balancing (the programming aspect turned out to be fine). Which leads us to the next stage:

Part 2: Coding and all things new and shiny…

I should probably mention at this stage that this is my first game that required any level design or sprite animation (I’ve done the graphics programmatically in the past). At this stage, I was putting off the graphics, but one of my first steps was to find a decent level design program and test it. I ended up using Ogmo, and am ridiculously happy with it as a level editing tool.

I got a framework together (using flashpunk as a base) that would read in the map, place the player and the bad guys in and have them interact. I’m really happy with my collision and basic movement code – I simply got it working in a way I hadn’t really done before.

At about hour 10 I hit a bit of a brick wall. First, there was a few dodgy dependency-based bugs (the kind of ‘include’ loops you expect in C or C++, not in Actionscript), and secondly, there was trig. At this stage, I have to emphasise how much I hate trigonometry. I’m not bad at maths, and really enjoy most math-based aspects of game programming. Trigonometry is not one of them, and it seems to come up every god-damn time. There’s too many cases that I never seem to get right the first time, and it often degenerates into guesswork as I get more and more frustrated.

In this game, the trig problem was the angle to point the missiles at as they were rising (so they’re pointing at the target at the top). Ultimately, I got it working if the target was below them but not above, but it took so long that I needed to just leave it and move on.

Overall, I’m pretty happy with the code base I made. There’s some real dodginess in the scoring screens (magic numbers galore), as they were done really late, but otherwise it’s a fairly elegant system.

Part 3: Graphics, (aka why there are Summersaulting Robot Ninjas)

At about hour 13, I started working on the graphics. I first tried to do silhouetted stick figures, but without a tablet (hell, with a tablet might not have helped) I suck at drawing, so Robots it was!

Robots were easy, and I’m pretty damn happy with how they look in the end, considering the timeframe and my ability. One or two frames in the transformation into missiles were a bit dodgy, and there’s a lack of a jump animation.

The lack of tilesets was probably a good move given the timeframe, but the simplistic nature of the graphics did hurt the game a little. It’s something I’ll definitely look into in the future.

I’m particularly proud of the summersaulting ninja robots that emerge from the terrain (this was half animation, half programming)…

Part 4: Level Design

This is the part that probably suffered the most due to the short time frame. I managed to create 20 levels, which was great, but without any playtesting, the difficulty curve was way off and the explanations of mechanics untested. In addition, any playtesting I did was kinda defunct, as I knew what the allegiances of all the robots were (as I had just placed them). So yeah: no playtesting = bad.

I think the levels I came up with demonstrated a decent range of the ideas that could be explored with the mechanic, but often I erred on the side of too easy (apart from a few of the later levels, which go the other way) or on the side of too guess-like. The mechanics of the game can make it easy for levels to devolve into guesswork, and that’s something that I worked to avoid, sometimes more successfully than others.

Part 5: Mechanics/Conclusions

In terms of the overall mechanics of the game, the problems are more in omissions than in alterations: a ‘duck’ feature would be good, and different types of robots would allow me to better emphasise types of gameplay.

One thing I didn’t really get to explore was the idea of the colour wheel. The colours used are the primary and secondary painting colours (not digital colours), and a colour will befriend colours that are next to it, and be enemies with all the others. Even though this was never really used in the game, the decision to do this allowed me to have a pretty nice choice of relationships within levels without ever giving up on consistency.

Another issue is probably the ease of simply killing the evil robots, and the rigidity of the win conditions. Sometimes I should have made it so that the level ends after the timer counts down, and other times it should have put a loss condition of when certain required resources were destroyed.

Overall, I was really happy with this game as a 48 hour attempt. I’m really interested in feedback so I can fix it up (particularly anything on particular levels and their difficulty), so let me know if you have any.

I didn’t quite have enough time to finish even with the extra jam day.  I am still working on it and I hope to bring it to completion relatively soon. In the meantime, enjoy this timelapse video of me working on the game.  It covers 32 hours worth of work over a span of three days.  More information is provided in the YouTube video description.

Link to ArmchairArmada’s LD18 timelapse video

I’ve just gone through the pain of booting an old WinXP box that would want to upgrade (and so, with some reason, I’m sure there is a reason, would eat up all my RAM and start swapping like hell) without asking me, installing python, PySFML and cx_Freeze (well, I agree, that’s more complicated than “aptitude install python2.6 python-sfml”, but hell, is that so hard? I mean, when your system isn’t responsive because of Windows Update…).

As a result, you have a Windows build! (and a Linux static build since I wanted to make sure everything was ok before attempting to build the Windows version)

http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=2432

Okay, first off, I’m going to say this shouldn’t really be a postmortem as such. Why? Because I’m going to develop my game from here into something much better! So it’s not really dead yet

Mind Control Monster Madness

Anyway, the final game, in my opinion, was pretty ropey. Mostly the controls were horrible, with the camera zooming off from here to there whenever you click on something. But also the game lacked a lot of clarity. The gameplay isn’t explained very well at all, and it’s very hard to tell when you’re clicking on a monster and when you’re clicking on land. This is all stuff I fixed up for the Jam version, as best as I could. I still think it’s hooribly awkward to play though.

I thought it was a disaster when I submitted it on Monday morning (or Sunday night depending on where you are!), but playing it again now I can see a lot of value in it. The rock-paper-scissors mechanic on the monsters works a treat, and because they differ in other attributes (most notably speed), it makes it weighted in a way that’s quite interesting to play.

For example, dragons are the fastest monsters, so you normally want to get them first. You can use them to beat up the Godzillas. But you need a certain number of Godzillas on your side to beat up the turtles, otherwise you’ll get screwed by turtles. You can’t mind-control every enemy fast enough, so you need to start fights to defent your control tower. This means that you need to think on your feet at all times, and judge what’s the most pressing issue on the fly.

That, to me, is nice gameplay, and it’s a shame the concept doesn’t really shine through because of all the other issues with the game. That’s why I’m going to work on it more and make a decent game out of it.

So what went wrong?

Time. Time is the enemy of us all! I think I suffered a dent to my productivity due to travel. I spent 8 hours travelling on the Saturday, to Cambridge and back, to spend time with the Cambridge Friendship Club, who were jamming for the weekend. And, of course, while I was there, I spent a lot of time chinwagging. But I do not regret that at all! It was great to meet everyone, I had good fun getting to know other developers, and it was motivating to be in the same place as a bunch of other people working on their own projects. Without other people around to chat to I would have gone stale very quickly!

The train journey wasn’t too bad. Instead of starting programming right away, I planned out my ideas on the train, thinking through each aspect until I was happy with my ideas. But other than that it is hard to program while on a train or metro. I managed a bit, but didn’t really get stuck into it.

Was I too ambitious? To be honest, I don’t think this was a massively ambitious project. It was fairly simple, and there weren’t many gameplay elements to consider. The problem is the indirect control style. You don’t move your guy by pressing a button and he moves. You have to choose a monster monster, and click on something to tell him to do some command, and he’ll work out the rest himself. All the elements, the user interface, the AI, the camera controls, and so forth, were very much intertwined. If I’d made a platformer and the enemies’ pathfinding didn’t work it would be fine, but if the pathfinding were bust in this game then the whole thing would be unplayable.

The pathfinding, simple as it was, was buggered for so much of development, mostly because of silly typos of single forgotten lines.

So I think in that respect, I wasn’t overambitious on the amount of content required, but having so many elements that needed to intertwine and work together meant that it was only very late on when I had some thing that was playable at all. I spent a lot of time wrestling with some nasty bugs, some of them caused by tiny little things (like forgetting to put a “break” in a “switch” condition), and by the time it all came together I was too tired to really make it all user-friendly, making the whole game look awful.

But I don’t regret doing it like that, because at the end of the day, had it all come together then it would have been great fun. Maybe I just needed a couple more hours earlier in the day, or maybe a shorter train journey. But ultimately I took a gamble. I knew I was making a game that would either work great or not work at all. The gameplay was self-generating and didn’t need a lot of content (graphics, dialogue trees etc.) to make it work. And this time it didn’t work. The game was fine, but the interface makes the whole thing a struggle to play.

I’m glad I gambled, because now I have a game that could be developed into something really cool. Looking back I’m much happier than I was about it when I submitted it. I thought it was complete tosh and was actually quite depressed about it! I’m glad I don’t feel that way about it now

The game was a failure, sure, but a failure I’m very happy with, because it was so close to being a resounding success.

Grabman Walkthrough

Grabman Submission Page

Did you find Grabman too difficult? If you weren’t sure how to win the level, here’s a video walkthrough by me that might inspire you to have another go at it.

Hi folks- I’ve been refining my Ludum Dare 18 game since the competition ended, and I’m ready to release another build. This is still an early version. The game will see some major changes before it’s done. Changes in this build include:

• lots of tuning
• wider field of view
• circular view
• indicators which display the direction to castles
• improved notification when our castle is attacked
• improved animation for the tiny creatures (the ones that come out of the creature pumps)
• pulsating bubbles
• green enemy bubbles
• carried castle pieces now form a train behind our character
• transition animations for castle building

http://vacuumflowers.com/temp/bubble_tag_current

The next step is a major one- I’m going to alter the flow of the game so castle upgrades are rarer and more significant, and also focus on making sure there’s more of a swing between offense and defense. To accomplish this, I’m currently thinking I’ll add destructible protective walls around castles. These walls would bear the brunt of most attacks, protecting vulnerable turrets and other components. Walls could be repaired by expending resources, which would be collected during exploration. More builds soon!

My game has been moved to a different server with plenty of bandwidth.
Now hosted here