The gameplay video for the first level of Doctor Spandex. I did it with alarm on and off.

You can play the game here: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=10554

It’s been almost a week since we started Ludum Dare, and have had a bit of a time to cool off since then.  Our team of three were able to put out a reasonably fun game for the Jam.  Some things went wrong, but I think we made a fun little game and the whole thing was an overwhelmingly positive experience.

What Went Wrong

Thematic Squabbling – We spent a lot of time on this. The theme was weird, we wanted to take ‘villain’ to mean ‘antagonist’, but we couldn’t really make it into something that worked or would have been fun. Eventually we just ran with the ‘badguy’ idea, but it would have been better to have something that was a little more clear cut.

Lack of Practice and Setup – Before this Ludum Dare, I was very rusty with unity, I hadn’t worked in it in almost a year now. Our other programmer had only a passing familiarity with it, and our artist wasn’t so much an artist as he was simply the most artistic of our group. We also didn’t set up any of our tools prior, which lost us a bunch of time.

The maths – We got stuck for a good while to make the angles work. The game relies heavily on knowing the angle between the player and other actors, in relation to their current heading, but we spent and unreasonable amount of time just figuring out how to make it all work.

What Went Right

Simple Setting – We chose to have the game take place in space. Space is a great setting, since there’s absolutely nothing there. It saves us the time from having to do pathfinding, collisions, or obstacles. The trick is to keep it looking empty and to make it feel like you’re moving, but I think we handled those well. It might feel like a bit of a cop-out, but

Build and Refine – Our primary goal was to have a working game as early as possible. I think we had a semi-working game with a player (an untextured cube at the time) and an enemy by the end of the first night (about 5 hours after start). At each step we would play it, think of what we could do to improve it, and work from there. While such a lack of direction might be considered a detriment to a bigger project, the fact that we had something working so early on meant that it was less directionless and more of a non-stop polishing process. If a feature looked complicated, we wouldn’t add it.

Relaxed – We never felt rushed by our pace, we took regular breaks, slept normal hours, and even took time to watch some anime.  We also ended our jam after 48 hours, so it wouldn’t cut into our Monday. The fact that we had a fairly solid, playable game without suffering from burnout when we went in to work on Monday was a good thing, and probably resulted in a better game.

Randomly Interesting Technical Bits

– The background is just a plane that faces the camera, that is movement locked with the player. There are two materials applied to it, which have their texture offset adjusted to a multiple of it’s x/y coordinates, to give the impression that you’re moving through space, with the stars move slowly, and the dust moves much faster.

– All the ships are actually cubes, because we had pains making the planes face the camera properly, and never went back to fix it.

– If you look at the above picture, you’ll see lines pointing from the police ships to a point near the player. What’s actually happening is the police ships actually lead the player by a random amount. It’s not really obvious in the final game because the shots are way too random to see it, which is a shame. When I first started testing, the enemy ships would all clump up when chasing you since they all had the same parameters and target, so I made the actual target random as well as randomized speed and turning rate.

– The message box was originally going to be used for communications, as we were going to have both civilian and police ships send messages, but as the game pace increased, it ended up being difficult to follow while things were going on. Originally, we had messages simply flash at the top of the screen, but it became fairly annoying as a new message would appear every 5-10 seconds.

– Collision detection doesn’t work at all if the player or target ship isn’t moving at all. I have no idea why this is, and it drove me insane while working on it, but since there’s no way to actually come to a stop after you start it’s not actually huge issue. Maybe it has to do with the way unity handles triggers. If you have any idea, I’d love to know.

– The arrows that point to each entity, probably one of my favorite features, was one of the easiest to code, taking maybe 30 minutes to do. Unity is kind of sexy that way, that it’s so easy to make such a thing. Check out that code.

– The AI on the swat cruiser tries to fly along beside you and shoot at you from the side. It also cheats a lot, if it’s off screen it’s speed and turning ability is greatly increased, and if it can’t get to the player for long enough it basically is launched high speed towards the player. I had thought the arrows would make it obvious it’s cheating, but it seems fairly natural from your point of view aside from the odd “wtf how did he get there”. Or maybe you don’t notice cause you’re trying too hard to not explode.

– I’m especially proud of the taxi behavior. The taxi groups all start parented to a group object that moves on its own with the taxi’s inside. When the group object detects a projectile nearby, it transfers the current direction and velocity to each of it’s children and removes itself as the parent, at which point each of the ships starts moving independently.

Timelapse

A timelapse video from my computer perspective. 1 frame every 5 seconds, at 30fps. I should have used a dark theme for visual studio, don’t watch if you dislike flashing images.

The game

Give our game a shot!

Thanks for reading!

Tags: ld25, postmortem, unity

I have been putting off writing this because I don’t really want to think about this game anymore, but I guess It has to happen some time.

Tiny sprites 😛

I started out the compo with 3 hours away from the computer. On one hand, this was good for coming up with ideas, but in the end I switched again about 6 hours in. My first programming sesh was good, I got a lot done as far as player movement went, and I really solidified what I wanted the gameplay to look like in my mind.

I really hit a speed bump at about hour 16. Even after getting some sleep, I was struggling to concentrate. I started coding boss combat, which was fine, but everything began to fall apart when I did enemy combat. This is where I really began to regret having such sloppy code. Usually, I am meticulous about storing variables in the right place and such, but at this point I was just creating new ones instead of trying to deal with the ones I already made.

After a whole day of code, around hour 28, I decided to go to bed again, and promptly forgot to set my alarm. 10 hours later, I was well rested, but in a very bad place as far as time went. I finished enemy combat, and worked on unit placement, which became another big pain. I simply didn’t have enough time to test my game much, and by the time hour 48 rolled around, I was only able to submit a terrible game, that honestly did not work.

But I did not give up! I took on the challenge, and kept working on the game. Long story short, by the time the Jam competition was ending, I was able to submit a working version of the game (more or less). It had different hero types, different enemy upgrades, and sound! Much better than what I had for the compo, though still kind of buggy. In the end, I was happy that I had a working game at all! This was the first game that I had ever finished, and I am so glad I had the opportunity to participate in Ludum Dare.

10/10 Would do again.

What went right:

Interesting idea, pretty good art, sound, distribution.

What went wrong:

Sloppy code, BUGS, cut features, slow combat, stress.
Play it here: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=18930

Guardian Angel Devil is a solo jam game Play it here

The original game idea popped in my head when I saw the theme “Guardian” during voting, and when “You are the Villain” ended up the winner it came up again with a nice twist at the end. The idea is a take on the “chosen one” trope, as in the hero, Blake, is a young farm boy and he is the only one who can retrieve this evil artifact from the dungeon. Since you, a small demon,  are the villain, of course, you pretend to help him since he’s clueless, because you want to take the artifact for yourself after he retrieves it. You have cards you can play to provide various effects on the battlefield and Blake does all the dirty work of fighting.

The Good

JSIL:

I wanted to make a web game, and was about to use silverlight again when I heard about JSIL. It meant I could code in XNA but then export it to Javascript. I spent some time porting my silverlight tile engine to XNA that played nice with JSIL, which wasn’t too hard as long as I found workarounds for the methods that JSIL hadn’t implemented yet (Particularly having to read xml tile maps with an xmlReader because XDocument and XmlDocument weren’t implemented.)

Juicyness:

This came from a video that someone posted before the compo. Even though I didn’t manage to animate combat attacks, a simple particle effect and sound effect worked pretty well to make the game feel more finished, and took far less time than animating each frame.

Gameplay:

There are three different ways to finish, and all are possible. Plus it plays out a bit differently each time depending on which cards you get.

The Bad

Use of time:

By the end of the compo I only had a fairly generic RPG with the villain walking around and the hero equipping items and attacking, so I ended up entering the jam. I think I may have been able to squeak by on compo time  if I had planned a little more efficiently. I plotted my time out fairly in depth to see where I was using it and this is what happened:

Ideas: 2 hours  compo

Art: 4.5 hours  compo (about 2 hours thrown out)

UI Programming: 4 hours compo

Level Design and programming: 7 hours compo/1 hour jam (Some of this was unused)

Programming walking around the map: 2 hours compo/ 1 hour jam due to JSIL issue

Programming combat: 4.5 hours compo/ 1 hour jam

Programming items and equipment: 2 hours compo

Programming/Drawing cards: 4.5 hours jam

Sound: 1.5 hours compo (very good bang for the buck)

Conversations: .5 hour jam

If I could do it again I could have saved some time on art by deciding my style better in the planning stage. I also could have shaved some time off level design by only implementing things in the maps as I went. There was a bunch of tile flags in the final room that went unused because I didn’t have enough time to implement the cutscene I was planning. I also wouldn’t have bothered making JSIL builds until after the compo ended because it was really just a port. I lost a bit of time implementing something and then finding out I’d have to do it a different way to appease JSIL.

Bugs:

There are a pile of gameplay bugs (Not breaking and most of them work in the player’s favor) mostly due to the rush at the end to get 23 different card types working.  I think some of them might only be in the JSIL port but I haven’t had a chance to look into them.

GUI:

This game had quite a bit of GUI work and not very good base code for it (I intend to rectify that in my library before the next LD). And I didn’t have time to code proper window backgrounds so the text is a bit hard to read at times.

If you haven’t done so yet, Play it here

Today I had a go at some more features and bug fixes on a post-LD variant:

• Tried reducing memory usage by using CopyOnWriteArrayList. I had been copying the gamestate object array to avoid concurrentmodificationexceptions. I’m going to try modify this to reuse objects instead, but it needs to be threadsafe anyway.
• Made the arrows into an arrow shape and rendered with gradient fills that dont show up at that pixel depth.. For kicks, I made the arrows enlarge as they go up into the air, maybe it looks odd?
• Increased volume of dragon screams. (Why? Why was I created to feel pain?)
• Reduced space between joints to make the dragon less jointy. Neck segment 2 needs scaling slightly.
• Made dragon faster.. This makes the game ridiculously hard at the moment.
• Experimented with tail takes no damage. This lets you hide behind tail to deflect damage then bust through and kill some dudes. Slightly overpowered, but wouldnt be if you were surrounded on all sides.. Needs more art peices and a redone title screen for that though.

Things that are really bugging me:

• Archers need to have bows, though now I’ve got an idea to draw the bows pointing in different directions! When I do this, I will probably change the warrior cloak to be red, and keep the archer in ranger colours, though add some random texturing.

Ideas:

• I had the idea that multi-hits could result in a powerup drop, so two hits within 2 seconds gives you something good.
• Thinking about rendering spent arrows and scene damage into the ground. I created some decent scorchmarks at one time.
• Thinking about making the dragon dart and open its mouth to feed.
• Thinking about making guys explode into gibs you can eat later (maybe).
• Had some Hobbit related ideas about Grandelf and his glitched mare shadowhaxx. Also thought of having a cutscene of the dwarves, with Hobblin’, Dabblin’, Tiffin, and Dave (who comes from a semi-detached house in the suburbs) “What do you mean your name doesnt rhyme with your second cousin’s auntie’s goat?”.

I’ve just finished uploading a new build of my LD25 compo entry, “The Hubris of the Bone Lord”. Features/changes include:

-Pause/Unpause now makes sound

-Menu navigation now makes sound

-There’s actual menus for selecting difficulty etc instead of just pressing the corresponding key on the keyboard

-XBox 360 gamepad support added

-The intro story crawl can be skipped with the pause button

-The quit button will always return to the title screen if in-game, and quit the game otherwise

-On Game Over, the player has the option to retry from the current stage instead of getting completely kicked to the title screen

To avoid any confusion, I’ve uploaded the updated build exclusively to my website. It is nowhere to be seen on the LD website so that it won’t accidentally be judged as part of the compo entry.

Post-poning making it into a fully realized game until later.

The new version can be found on my website here: http://beardedpixel.net/hotbl/ (re-iterating: do not judge this as part of the compo)

1. New “fear” animation for person running away from Bad Puppy if you bark at them enough.
2. Fixed bug in highscore detection so that tweet prompt only happens when you really do have the local highscore.

I’m still looking forward to seeing my first high score tweet from a player.  It will make me feel really happy when I finally see that

Tags: Bad Puppy, csanyk, ld25, post-compo

Well, I think I did okay this time around. Better than LD24 (my first LD)

This time I made a game called Lord of Corruption

Play it here

Anyway:

What went right

I was more experienced. I have now been programming for almost 1 year. Which means I have 1.5 times as much experience as LD24.
No school. Last time school got in the way and I lost all Monday morning (timezone offset means I finish the compo on moday afternoon).
Had a simple GUI framework. Last time I tried implementing my own GUI system and wasted half of Sunday morning.
Focused on fun even if my interpretation of the theme was just… simple. Result: It’s fun, so no-one cares about the theme.
I did so well that I submitted 1 hour before the end because I was done that early.
I had just started developing a platformer engine a few days before the compo, so I was able to rewrite that, and as a result, I now have an even better engine to use for bigger projects.

What went not-so-right

No music/sound. I should try to get this going next LD.
It was too hard for some people to win.
There were a few problems with enemies bunching up at the side of the world and insta-killing you whenever you respawned.

Overall, I think it went well. ;D

I had a lot of fun this Ludum Dare, and I think that of all of my submissions the one I submitted this time is the best.

Here is a link to my submission: Link
There is also a post-compo version available, with more items and levels (as well as a smarter AI).

When I first saw the theme, I wasn’t sure if I should participate. But, I came up with an idea that tied in with some AI research I was doing. The game uses neural networks, which is pretty uncommon. But, it really is the only way to do it in this case. Path-finding and other methods are far too rigid to be able to adapt to arbitrary environments. Also, it is difficult to create a character control system that can predict how to move in the air in order to land on a platform. Path-finding can be complementary to the neural network, but I left it out since it is too processing intensive. I instead just made all levels pretty linear (the AI always moves to the right).

When I started out writing the game, I was pretty sure that the AI would fail miserably. But I at least wanted to try it out. To my surprise, however, it almost immediately (usually in less than 10 generations) was able to comprehend how to jump from platform to platform. However, by the time I got it working, I squandered too much time on YouTube to be able to submit it for the 48 hour compo. So I submitted it for the Jam.

I started out the AI with 25 inputs, arranged in a rectangular grid around the hero. These inputs were set to the corresponding tile values. This acts as vision.
I later added the signed x and y distances of the player from the goal (princess), so it could learn the map better and not be fooled by structures that look the same from its point of view in different locations.

In the post-compo version, I also added the x and y velocities, which improved the behavior significantly.

The outputs of the network are arrow-key controls (left, right, up). To test the physics, I started by having the controls respond to keys, and I then later let the AI control it. If a output is greater than 0.5, then the key was activated. Otherwise, it was left inactive.

The neural network is recurrent, and is evolved using the NEAT (Neuro-Evolution of Augmenting Topologies) technique to evolve connection weights as well as network structure simultaneously. I had the NEAT algorithm coded prior to the competition. It comes with a visualizer, which uses another genetic algorithm to produce images of the networks. Check it out here: Link

The NEAT algorithm itself is very generic, feel free to use it in any of your own projects. The visualizer uses SFML, but you can leave it out if you don’t want it.

Here is an example of what the NEAT visualizer shows. In this image, it learned a XOR gate.

Other than the AI, the game is nothing special.

What went right:

– AI was able to beat levels as intended.
– The training process ran at an acceptable rate.
– The map editing interface was relatively easy to use.
– Sounds were indicative of events (thanks to BFXR).

What went wrong:

– The menu system (there is none).
– The graphics. It was an ugly grid with rectangles with legs as characters. Also, some people got black screens. This was fixed, but perhaps too late.
– The items. There were only 3, which made puzzles repetitive.
– The levels. They were mostly too easy, I ran out of time when making them. Also, there were not enough of them.
– No music.

I might make a post-post-compo version. I kind of like designing puzzles for this game.

So I decided to take upon myself a challenge today: make my old Warmup game, Castle-Castle, multiplayer co-op.

Download it here

Play the original here

type yolo or oompa in the chat

This is my first Ludum Dare and I’m glad to know I’ve been able to finish a game, strange, but at least, a game.

To be honest I was uncomfortable with the winner theme. I think I was not the only one that thought: “omg!” I have preferred other, probably more simple or more conceptual. After all I think that this issue isn’t important. Instead I think it’s a challenge that forces us to be more creative to find a nice idea to start to develop the game.

The first important choice I took was to do a remake. In fact, I think that’s all we do when we’re trying to make a game: we search for a clue or inspiration from the lots of games we played before. I decided to do something similar to Terry Cavanagh’s “Don’t look back”. I thought this will be a good starting point to, after a while, modify the characters, the game plot and graphics. But it was no possible in the end and I feel like I was haunted by the feel of DLB.

Ok, I’m also stuck with the no-end of the game :)

Play and rate it

What went right:

• Incredibly funny experience.
• Working with Game Studio Pro is ok. I have a six months experience with it and I feel I improved my skills in GML. I think that Game Studio is a good tool for developing games in a fast way. This makes me to think that GM is a right tool for make prototypes, sketches or mockups and platform games as well.
• The ambience and the atmosphere of the game.
• The rain effect.

What went wrong:

• There’s no a clear plot. Well, in fact I love games without a plot and left the player to imagine a plot by himself while he’s playing the game.
• There’s no ending. This is the big fail of the game. I was in a mess trying to work out a perfect end but I failed miserably. This is the first issue I want to fix this holidays
• No audio effects like footsteps. Only the rain sound as background.
•  No enemies to kill/avoid or puzzles to solve.
• No web port of the game. This question I think it’s crucial. As a player while I was rating games I find myself more comfortable playing the web port than Windows/OSX/Linux version. This issue makes me think that I need to learn HTML5 or Haxe + NME soon

It’s been a week already. Time flies! So I suppose it’s time for my game’s post mortem.

What went right

• The theme. While I didn’t have any pre-planned ideas, coming up with an idea was pretty easy. An AI that decides people should die. While the end product differed a little from the ideas I had initially, I think it made the game more enjoyable by making you actively involved in the brutal murders of death.
• The tools. By now I know pretty much all I need to know to make a game in 48 hours with Visual Studio and XNA. I ran into zero problems related to my tools or knowledge of them, making the development easy and smooth. I only ran into a few small roadblocks regarding implementing some features, but they were nothing no dirty hack couldn’t fix in a few minutes. While I really should move away from XNA at some point in the future, I just can’t yet as it’s so easy to work with. 😀
• A built-in level editor. It was the first thing I made, and while it’s a horrible thing for any purpose other than LD, it got the job done and made it possible to create complete levels in minutes. I will seriously consider making this the #1 task for any future LD game I’m gonna work on.
• The AI. I’m very happy with what ended up being AI controlled. The humans react to doors closing on them and other shenanigans you might be doing to them, resulting in some sort of realism. Of course, they look like shit, so it’s not that realistic, but still!
• The features. I almost completed all the things I wanted done before the deadline. The only things that didn’t make it are in the post-compo version, which took a few additional hours to create. While I’m sad they didn’t make it in, it doesn’t change the fact that there are many ways to kill people, lots of achievements, and a bunch of playable levels. Probably the most I’ve ever done in 48 hours so far.

What went wrong

• The graphics. There’s no way around that fact. My game looks like shit. It’s 3D, which is the only positive point, but the walls are ugly and exactly the same, the entities are ugly boxes that don’t rotate and have a single texture for all 6 sides, and there are no animations at all. I really wanted to add better graphics, but my main focus was on gameplay elements, and halfway through day 2 my code was so ugly that it was pretty much impossible to replace the cubes or the single-texture geometry.
• No goat. I wanted to add a killer goat that was locked up somewhere inside the base, and it would seek out humans and eat their face etc. But adding that would be too much work. My pathfinding was slow and static (very inefficient BFS, or at least I think that’s what I ended up with) making it hard to find humans, and I could only make a cube goat anyway.
• Collision detection. Mostly a problem when you have a human grabbed and you want to make a turn in a small corridor. So frustrating! 😀
• The controls. Always make the controls as smooth and easy as possible. I didn’t do that. I imagined that if you are an AI and you control all those things, then you do that indirectly. So I made the indirect button panel, which works, but it’s pretty crap. The first-person view added movement keys, which was a huge improvement already, but I did not make a ‘move backwards’ option. I should have, but I ignored that as I learned to deal with it while devving. But it’s horrible, unintuitive, and it makes the game much less enjoyable imo. But that’s just hindsight, so it’s a lesson learned for next time: If something doesn’t feel right during development, don’t learn to deal with it, but fix it immediately.

Overall I’m very happy with what I ended up with. It’s pretty much a complete prototype. If you have the chance, give the post-compo version a try as well for the super fun camera features. I recommend playing the two dark maps then, as you have to rely on the cameras for your human awareness. The second dark map is especially hard to not screw up on.

I won’t continue working on my entry, though. While the concept is nice, the code isn’t. A massive refactoring is needed before adding anything non-trivial or related to graphics, it would be much easier to start over from scratch and to do things right instead of quickly. It would be interesting to see an implementation of this in UDK or something, with realistic graphics. Imagine the scientists discussing things with each other while they are at work, and then you shut down the doors, grab them with robots, and force them into incinerators while they are pleading for their life, only to throw their crispy remains against their co-workers as they are banging on the doors and screaming for help. Horrible! 😀

You can view my entry here

Tags: post-mortem

Hello, I’m a person and this is my second Ludum Dare.

Things that can seem right by a certain point of view:

-My game has graphics! Fantastic graphics made with a broken pen! Yeah, I’m a great artist, I know…

-I managed to make a lot of contents in little time and this is important.

Things that can seem wrong by a certain point of view:

-Stencyl did random things that I’m still not able to understand, it made me lose 2-3 hours.

-I had to see “The Hobbit”. This was a huge nerd duty that I couldn’t avoid.

-Many other random things that made me lose time.

-In the end I made my entry in 9 hours but it’s ok because I managed to partecipate.

Here it is the link to my entry:http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=16077

P.S.: My game can be frustrating but, hey, it’s not my fault. It’s yours, you are the villain!

P.P.S.: Merry Christmas to you all!

Click to go to the game page

 What went right

» Tools: I was familiar with all tools I was using

» Art: I’m addicted to working with the NES style graphics, so this was no problem. From the sprites to the font and title screen, it was all fun to work on.

» Sound is my weak point. Luckily a day before someone suggested me a website with free music, and there I got all music I needed. I also used sounds from freesound.or instead of the usual bfxr

What went wrong

» Time: Couldn’t join the compo because I wasn’t going to be home on sunday, but this is hardly a problem, as I still had 2 whole days to work.

» Planning: I didn’t plan the game properly. I never got to that point where you say “ok, the game is about this“. It was all over the place, and because of that near the end I had to spend a great deal of time just to figure out if the concept actually worked.

» Had to cut many features off, like a more in-depth interface with more helpful information, and a loot system that was supposed to add more depth to the game.

And then

After submitting the game, I added a statistics system to it, and submitted it to Kongregate. It’s pretty fun to see how many people are playing it.

Not my best game by far, but this is what Ludum Dare is all about: learning. Next time I will plan things better and actually have a fixed idea of what the game will be.

Tags: ld25, postmortem, timelapse

LD #25 was significant for me.  Not only did I submit my first entry to the compo, it is the first time that I have created a game and put it up for anyone in the world to play.  The feedback in the comments has been fantastic, and I’m kicking myself for not having participated sooner.

Take a minute and try Goombah! here.

The first thing that came to mind when I saw the theme announcement was to focus on a grand villain – Darth Vader, Genghis Khan, Kane, etc.  The second thing I thought of was stupid and funny.  I went with that.

It’s hard out there for a goomba.  He sits on a little platform, waiting patiently for the plumber to show up, at which time mr. goomba either gets stepped on or walks off a ledge.  I didn’t want to make the game quite that boring, so I took out the ledges and provided an endless stream of jumping men to avoid.  The goomba’s chances of survival are still slim, but at least it is interesting!

What went well

• Kept it simple – I had a simple design that was not too difficult to implement in a few hours.  I considered adding game play features, but focused instead on making everything look nice and by the time I could have come back to changing game play it was time to submit.
• Flashpunk – The only exposure I had to flash development before the compo was running through the flashpunk tutorial.  For me it was a great place to start, and that engine is a snap to use!
• Draw first – I am not what you would call an artistically gifted man.  I spent the first hour or two in GIMP drawing out the sprites for the game, so that I knew they were done and did not have to worry about the art while I was working on the code.  If I had done it the other way around, I’m not sure my placeholder art (colored squares) would have ever been replaced.
• Submit early – I submitted the game early on Sunday because I had other obligations, and at that time only a few dozen games total had been submitted.  I know they don’t count for scoring, but almost 50 people had played my game before the end of the day.  That’s just cool.

What could be better

• Levels – One thing I would have liked would be to add some variety to the game by having different platform configurations to mix up the game play.  The game works, but does get boring pretty quickly.
• Interface – An actual menu, instructions screen, and game over screen would be nice to have in there.  The text elements up top were a last minute addition, and while I think they do the job it could be better.
• Frame based motion – I would much rather have implemented motion based on actual elapsed time, but started the game by implementing motion based on number of frames passed.  Around hour 5 I realized that this could be an issue, but never managed to go back and rework it.  Next time, I’ll start the right way.

Having actually made a game in a weekend, and then having so many people play and comment on that game has been a great experience.  And to everyone who has played and commented on my entry, thank you!

Tags: compo, flashpunk, ld25, postmortem

I’ve been a big fan of Ludum Dare for a few years, but this is only my 2nd time entering.  Here’s what I ended up with:

Play/Rate it

What went right:

• The Tool – I used Construct2, just like my first entry.  Both times, I considered using GameMaker/GML, but I wanted an easy way to post to the web, and more so, Construct2 lets you rapidly produce something that’s playable.
• The Story – I thought the “you are the villain” theme could really make an interesting story arc in the game.  I spent a good amount of time the first day just thinking of how to implement the theme into the story.  I’m happy with how it turned out.
• The Music – With only about 45 minutes left, I finally turned my attention to sounds/music.  There wasn’t enough time for me to create anything that wouldn’t have been boring or repetitive, so I turned to the Wolfram Tones to generate some background music for me.  Out of the 60 or so tracks I listened to, I had found 3 that I thought would add to the ambiance of the game.
• The Gameplay – It ended up being a simplified zelda dungeon.  You acquire 4 powers along the way, and use them to open doors to get farther into the dungeon.  The powers were fun to create, and worked reasonably well.  Unfortunately, there were also a number of problems with the gameplay (see what went wrong).
• The game felt complete – By “complete”, I  mean there is a definitive beginning and end, assuming you could make it to the end (see “bugs”).

What went wrong:

• I tried to do WAY too much – I chose a relatively complex game to make in 48 hours.  A number of  gameplay aspects suffered to have something complete by the deadline.  Also, virtually nothing felt polished, and there are a number of bugs.  Fortunately, there was only 1 bug that stopped the player from finishing the game, and that’s been fixed.
• The text speed – There are a few “cut scenes” in the game where all controls are suspended to show dialog important to the controls or story.  This wouldn’t be so bad, but I made this dialog unskippable, which left the player frustrated, having to wait for the dialog to finish before they could resume playing.  I had planned to add the ability to move through the dialog via a keyboard button, but ran out of time.
• Lack of planning – I had a conceptual idea, and just went with it, making many things up as I went along.  This ended up being a very poor choice.  If I had planned things out a bit more in the beginning, I would have had more time in the end to polish the game.

For next time:

• Plan as much as possible before creating.
• Start with a simple gameplay mechanic, and expand if there is time.
• Wrap it up with a definitive beginning and end.

See you all in LD26.

Hi everyone! I’m glad to say that I’m constantly visiting the web over and over, and I’m trying to play all of the games that I think that are good of the last LD.

I’ve met with Ludum Dare at the page of Evoland (a game of LD24) at Shio Games. I really liked the game at that moment and in the info said something about the site, and when I got in the first time, there was 1 week ’till this LD started!

I’m living in Argentina, and I talk Spanish here, so sorry if I mistake some letters 😛

I’m 14 years old, and I currently know nothing of programming, but I’m looking forward to learn something and make some useful program/game/whatever in any language. I was interested since last year (I think) and I wanted to learn BASIC first, but as long as I get some progress I’ll be happy about it.

If anyone is can/wants to teach me something, I’ll be glad.

See ya everyone!

Tags: hello, presentation

Get Your Goat – Game

I entered into this compo very nearly at the last minute. I lucked out with five days remaining before the event and was able to get the time off of work. As I missed LD#22 due to life, #23 due to work, and dropped out of #24 due to a six hour power outage on Saturday, I was extremely excited to be able to participate in this one.

My goal of this jam was simple: Improve upon my LD#21 entry. For LD#21, I started with zero base code, used Flash CS4 as an IDE, did not have any sprite or sound tools set up or had any knowledge on how to use them prior to the jam. I was not well prepared, but still managed to finish. My entry was very unpolished and was not really play tested. Thus, the goal of my LD#25 entry was create a more polished and fine tuned game that I considered better than my first.

Unfortunately, I do not believe I fully succeeded in my goal. Time-wise, I was ahead of where my previous entry was and some parts of the game were better polished. However, I still ended up performing the 3 hour-remaining crunch to knock out all my art and sound assets. This game uses about two to three times the amount of art and sound over my LD#21 entry. As a result, my art assets were half-done, sound is half-done and one major bug and game balance issues were present in my submission.

This Ludum Dare was a great learning experience, even better than my previous one. I now know exactly what skills I need to improve on in between jams and what I need to focus more on while jamming.

What went right

• My pipeline– Much improved over LD#21. I was able to produce more assets at a much quicker rate.
• Adaptation– Midway through the compo, I discovered that my path finding had a non-trivial bug on top of generating paths too slowly. I was faced with the choice: Stop all development to fix the bug and optimize the code, or redesign the game so I would never encounter the bug or have to generate more than one path. I chose the latter. I feel that if I had tried to debug and optimize, I may not have finished the compo on time.
• Fixed some things from my first jam– Trying to not be too hard on myself, I did end up fixing some of the problems and issues I encountered in my first jam.
  

What went wrong

• Scope– Once again, scope popped up to bite me in the butt. This time it wasn’t gameplay related but it was simply that I shouldn’t have attempted a rts style game. Although, I now have some code I can clean up and port to the next Ludum Dare for another rts game.
• Dealing with distractions– On Saturday, I had some work distractions pop up. I wasn’t able to concentrate fully for a few hours and lost some of my most productive time.
• I’m awful at making sprites– Put simply, I am incredibly bad at making quality sprites in a decent amount of time. This is something I will need to practice between now and the next Ludum Dare if I hope to produce a better quality game. I sort of know what I want things to look like in a general sense. For the life of me, I cannot translate that onto a sprite.

I’ve added some more levels. Along with some more elements to play with. Enjoy

Here

Tags: post-compo

Play / Rate | Timelapse | Demo | Postcompo version (progression)

LD#25 was my second participation, and the second game I created. Before participating at the 24th Ludum Dare, I couldn’t just go and make a game. I am terrible at drawing, and always wanted to find a graphist before starting to code any game.

Ludum Dare forced me to be a graphist, and even a compositor. I learned that I was in fact capable of creating my own games without any help. And now that I have my new computer, I’ll be able to start making more games soon, with Haxe instead of HTML5 (the only thing my previous computer could run..).

You can find the timelapse here:

What went right

Time management.
Unlike LD#24, this time I was able to have a finished game before the compo deadline. I spent way less time procrastinating, something like < 5% (40% for LD#24). I avoided spending too much time on a bug, by fixing it the easy/quick way.

Playable at any time.
I rushed over a playable version the 4 first hours of this LD, so that I had a game to submit at any time after that. Using git gave me that opportunity. I could then add content without worries, even 1 hour before the deadline.

Kept it simple.
I am no graphist nor compositor, so I kept both simple to be able to have a fair amount of content in the end. The background took me a few minutes (The Gimp), vectorial shapes were made easily with Inkscape, and sfx + music took me less than 15 minutes in total (besides the two computer crashes). And in the end, I’m quite satisfied with the result =)

Focus & Health.
Although I have headaches every day lately, I haven’t had any problem during this Ludum Dare. I was able to focus the whole weekend, without starving (couldn’t buy snacks for LD#24), with no exhaustion while not sleeping much, with sugar (candies *o*) and with cigarettes to help me fight my hyperactivity (didn’t have any for LD#24). Those helped a lot against procrastination.

What went wrong

Theme.
Less catastrophic than LD#24, but I had no good ideas. I had some, but too risky (involving good IAs) or not that great (the one I chose). I needed some drawings and more story telling to make this one really fit the theme, but couldn’t do it.

Chronolapse.
I forgot to launch chronolapse for the first hours, lost some more hours of screenshots with ffmpeg later, and forgot again to launch it after sleeping.. My timelapse could have been exhaustive, but well.. I’ll be more cautious next time x)

Computer performances.
My computer gave me a hard time again. Poor performances implied creating a game without knowing how it would really run on a decent computer, and resulted in a game a little speedy. I had a crash while trying to make the music (when my timelapse ends), and a second one while trying again. I ended up with only my test music (I was trying the instruments), and I used it in the submitted game. It was funny to see that it pleased some players xD

Play / Rate game:

Demo (first 5 levels):

Tags: ld25, ld48, postmortem