Found a bug in the game, it’s still the submission hour so I’m putting up an update!  Is that cool?  Really I was just noting this here because I’m doing that behind the scenes as it were, with no change to the entry page – just a swapped file on the server!  Thought folks should know.

It’s complete. I’m not satisfied with the balance or the feel, but Hot Potato is finished and submitted.

Oh. I should rebuild it on my Debian system since other people tend to have problems playing my game when I build a project on my Ubuntu system I might make a Windows port soon, but after 72 hours, I’m beat. I’ll update this post when I get those two things done.

Updated! I created the Windows port, and I rebuilt the game on my Debian system so that a wider variety of Linux-based systems should just work out of the box.

You can download it for:
- GNU/Linux (1.6MB tar.gz)
- Windows (3.12MB .zip)

Well, this is disappointing… I suppose I should have guessed that I really wouldn’t get very far with the extra day. Even though I originally was going to submit this game for the compo, almost nothing visible has changed with it in the last day; it’s been mostly code cleanup, a few new features (not readily visible), and a bit of story. Oh, and I now have install instructions that should work on Windows and Mac OS X as well, since I had a couple of other people try it out, and spent some time fixing the issues they were having. Other than that, most of the day was spent at work (you know, actual work I get paid for) so I sadly haven’t had much time to devote to the game.

Well, what I currently have is going to be my Jam entry. Congratulations to all compo contestants for getting your games in on time, and cheers to my fellow Jam participants… I look forward to playing all the games! Now, I only wish these things were held more often.

I’ll be posting my game on the site in a few minutes.

…but hit the jam.

Entry is here.

I have no idea why I ever thought it possible to get this done in the first 48 hours. I have got to stop trying to make games that use a whole ton of unique art assets for competitions. That’s always where most of my time ends up going.

Would like to add music, and a bit more variety to the events. It depends on how I feel about it tomorrow, post-jam.

I said I was going to make ‘it’s dangerous to go alone, take this: the girl game’. So I did. But I ended up focusing more on the girl game theme I think.

I just submitted my first ever “complete” game! I had originally planned to stick to the 48 hour competition, but in alot of ways I’m glad I didn’t. The extra 24 hours was sorely needed, as I was able to squash some game stopping bugs and even add in a boss level. It was my first real experience with Unity and despite some strange bugs that arose during development it was a good experience. There are still lots of small bugs, but at some point I had to just call it done. I want to thank everyone who posted updates during the competition, seeing all the great games being made gave for a good drive to finish mine. All in all it was a great experience participating, I can’t wait for the next one, maybe next time I’ll finish the competition. I wish I had posted updates over the weekend, but there’s always next time. I’ll post a post-mortem tomorrow. You can view my entry at Zombieland Entry

I was way to busy this weekend so I couldn,t push out a game…. ;(

… Wow… My entry sucks!

But feel free to check it out HERE: My entry: Matt’s Trial Dungeon

It’s unfortunate that I didn’t get to compete this time around. I was really looking forward to LD20, considering it’s a milestone number for the event. Oh well.

I had AP exams to study for, a couple projects to finish and some plans with friends that prevented me from competing. I’m sad I didn’t get to exploit the newfound power of my Ubuntu installation.

Best of luck to those who competed, and may the best game win!

I just finished porting my XNA compo submission to silverlight.  So it now runs on the web!  It’s currently identical to the downloadable version that several people have commented on having trouble with (likely due to missing XNA redist).  Try it by visiting: http://sugarpillstudios.com/games/zomkeybotcalypse.html

So this is my first post, as I joined especially for LD#20 “It’s Dangerous To Go Alone, Take This!” I’ve just finished Mary’s Awesome Adventure, which I wanted to submit to the Compo, but I guess it’ll just go into the Jam section now.

Title screen for LD#20 It's Dangerous To Go Alone

(more…)

It’s time to gather all the moments of the last two days in a short yet interesting post mortem. So much happened in these days that it’s kinda hard to decide which are worth mentioning the most. I better start with quick reconstruction of both days.

Ludum Dare – Day 1

Competition started at 4:00AM (here in Slovenia). I fell to sleep at 1:00 AM and woke up at 3:30 AM then I’ve prepared some coffee and soon after that, theme was announced! “It’s Dangerous to go alone! Take this”…what to do now. Idea shouldn’t be too complex yet fun and I took my cup with a coffee and lit a cigarete. While I was watching the trees in the dark that crazy idea got over me – Darkness, light, creepy, item, old man = Lead a character trough a dark place and let him have a torch from an old man. That’s it, plan was made and ready to be excecuted!

First I drew my humble design document with character vizuality, hud elements, goals, plans, how will the map look like and that kind of stuff. All that on a single page to keep it simple, and I was ready.

Development in order (1st day):
- Map editor (drawing, loading and saving maps)
- Game engine (loading maps and support sidescrolling)
- Player (red dot on start)
- Collision detection
- Some graphics
- Particle system
- Lighting (which wasn’t successful on the first day)
- More graphics

Lunch: Pasta with tuna
Dinner: Pizza with pepperoni
Coffee drank: 4 – 6 cups

Day was over and I went to bed around 1:00 AM planning to wake up at 6:00 AM. At that time I went over the day at myself and there was satisfaction because I made a lot of things. So I fell asleep…

Ludum Dare – Day 2

Plans didn’t work out. I overslept  from 6:00 AM to 9:00 PM and I got nervous and went back into action with cup of coffee next to me. I’ve made a quick ToDo list for more organized work and clocked started to run like crazy – it didn’t stop.

Development in order (2nd day):
- Flame system (flame bar getting lower and coal refuellig the torch)
- Lighting (I still had problems but it was implemented afterall)
- Character animations
- Enemies and their fear before the flame
- More tiles
- Death/victory condition
- Main menu and level selection
- Making maps
- Story dialogs (for beginning and ending)
- Adding 1 single SFX for picking up coal and lame repeating music (I can’t do music, don’t judge!)
- Entry was submitted 30 seconds before the end.

Lunch: Pasta again
Dinner: Toasts with cheese, tuna and pomodori
Coffee drank: 4 – 6 cups

Clock pointer said “It’s over” and I made a toast to the victory! It was over, I was among other strong souls that have made it to the end. I did something like that for the first time, game in 48 hours even if I had some doubts on start. I believed in my game concept and at the end, I had that realized even if it didn’t include all features. Ludum Dare chat was full of joy and I stayed around for a bit more and went to bed later at the dawn.

What went well

First of all, I’m glad that idea was born few minutes after the announcment which was huge advantage. Trough the competition I wasn’t distracted much and I just kept doing my work. Experience from the past helped me a lot because few things took me less time than I predicted. Overall, I think two main factors were idea at the start and experience from the past.

What went wrong

First problem that I’ve encountered were lights. I’ve never done fake lighting in 2D world before and so I was trying different stuff and functions without success. I’ve lost nearly 4 hours at that part if not more – I’ll have to concentrate on that part now. Maybe I did set my goals too high because some features were cut off and those that are in the game right now are bugged or poorly done (or at least some of them). Music is another weak factor. I’m artist and programmer but I can’t do music so I’ve tried to make something with Inudge but I’ve encountered problem to record from my speakers (records were too silent) and so the lame piece of music was born! (If you try the game out, you’ll know what I’m talking about). Next time I have to prepare my framework properly to save some time and I shouldn’t be learning new stuff at the competition.

Conclusion

It was first “Make a game” competition for me and it was exciting, especialy when I saw all the people working on their projects and in the same time together as a community. It’s obvious that we’re not here to win but to participate and have fun at what we like to do the most in our lifes.

I invite you to try my game out and rank it if you will
[ RATE GAME |  DOWNLOAD GAME ]

We submited !

Only a proof of concept is available for now.

CHECK IT HERE

We’re quite happy for a first try at the LD jam, considering the  full RealLife© working day that removed this whole monday from the dev time.

We will release a (more complete) post compo version as soon as possible

Thanks everyone for the motivation.

So I finally got my timelapse for Throwbots up. It’s on YouTube right now! Just click the link below to watch it.

http://www.youtube.com/watch?v=-QpwoeDswoE

I know that’s not particularly interesting a post, but it’s taken me literally all day to kajigger it into working. Couldn’t even get music into it, had to use the YouTube audio swapping thing (which isn’t in effect yet as of this post). Unfortunate, but I wanted it up for people to see it. Post-mortem for the game should be up by tomorrow or by the end of this week at the very latest.

This was my first Ludum Dare competition and I managed to make a submission. I’m really looking forward to taking part again next time.

I can’t say I’m proud of the fun factor/end user experience in my game. In retrospect, I should have spent a bit more time on front facing features (making the world scrollable to enlarge the game world, more varied artwork, sounds). But in hindsight, I’m extremely happy that I was able to get an RPG prototype running in 48 hours.

My submission for LD20 can be found here.

What Went Well

• Python and Pygame was an amazing choice. It’s great for rapid prototyping and shines in LD. But be warned, vanilla pygame doesn’t have menu support.

  My code should be multi-platform as well, which is an added bonus and gave me more time to think about the game ahead of me. I never would have made it this far this quickly using C/C++.

• I took breaks and got away from the computer. While away I would think about the progress made in the game and try to think of features or solutions to problems I encountered. In a few cases I found some good solutions, but I also brainstormed ideas on other areas of the game.
• Test Driven Development: I’d write some code and fire up the game to try it out. I would often start with a class skeleton that would balloon as I added features to it. Often I would start from scratch or extend from an existing class, but on a few occasions I found good opportunities for refactoring. As a smaller project I could stay on top of a lot of the test cases and quickly go through them as I worked on a feature.
• Platform testing. When I compiled the game using Py2Exe I set aside some time to test on a freshly formatted WinXP virtual machine. This is where I discovered Py2Exe depends on Visual C++ 2008 runtimes and I was able to include this in the readme.

  Testing also revealed issues with Py2Exe and buttons in WinXP, and the confirmation that my code worked with Python 2.6 and the official version of pygame (as pygame for 2.7 isn’t available on the main site yet). I didn’t spend much time looking into the issues once I found out the game runs fine when running from source due to lack of time.

• Artwork. Going into the competition, I remembered I was going to have to make my own artwork. I am no artist and my initial posts show the programmer art I came up with. I spent a few hours on Sunday learning how to draw character sprites and managed to create something that was quite presentable.
• Motivation/Attitude. Participating in LD made me forget about pessimism when it came to brainstorming feature work. This made me very productive and kept me motivated throughout the competition. Hopefully I can keep this mentality in mind going forward.

What Could Be Improved

• Gameplay. I had a great idea to tie in the theme with no time to implement the features to support it. As a result I more or less threw the game onto the existing features in the final hours and I think it’s fairly noticeable. Ideally I wanted the player to travel through the world with a mix of enemies, without being able to identity friend from foe when it came to people NPC’s (this would be the tie in to the theme). But without a larger map and non-human enemies this concept is missed.
• Linux: I have a linux VM but I didn’t get a chance to confirm my game worked on it, perhaps after this post.
• Game type: Turn based RPG might be a bit too ambitious for a solo competition, especially when you include graphics and sound. An action RPG may have been a better choice.
• Sound: Sound was also thrown together in the final hours and I’ve never really worked with it before. I also delay button clicks in the battle screen until sounds stop playing. This delay makes the game feel like it’s lagging if the player clicks through menus quickly.
• Combat formulas: Prototyping this at 2 or 3am for an hour in Excel is rushing it a little bit
• NPC speech: Again, something I should have looked at sooner rather than the end.

Well, that’s that. Try out my game and let me know what you like/don’t like. It can be difficult to get third-party feedback outside of competitions like Ludum Dare.

Forgot to make game / had an AP. Will try next time.

You play a leather-clad woman who has to survive, alone, against hordes of dangerous kittens.  Luckily, she has an assault rifle.

I’m quite pleased with it!  It’s crazy looking.  You can’t see it from the screen-shot so well, but it has fog-of-war, which I compute with ray-tracing.  That really enhances the fear!

The kittens have little bum-holes too!

It’s written in plain C.  Was good fun to write.  The most C I’ve ever written in 72 hours, for sure!

I’ve only tested it on Windows 7 and Gentoo Linux.  It runs okay for me!  I’d love if people would try it, if you find bugs let me know

I’m going to get some sleep, and then later play a bunch of Ludum Dare games.  Woohoo!

Windows .zip

Source code

Check out the entry here

We’re kind of sorry not beeing able to submit in 48h, we had to polish it a little, but here we are.

It’s been a great experience beeing able to work with me good chumps abe and Aries in this ludum dare.
We’ve loved the ludum spirit, thank you all for this great human experience.

See you next time, maybe in the comp !

if your fancy, you could “rate” it too, we would be happy to have your feedback.

The submition is here. (with decided to give the full Code/GFX/sound sources if you want to take a look)

Product
Overall, I think my product was very good for a first try. While it might not have been polished, it was fairly fun. I was quite critical of myself throughout the entire process – looking at everyone else’s blogs, I noted how much better their graphics were than mine, but I didn’t think quite long enough about that to realize that that didn’t tell me anything about gameplay. I doubt I’ve created a winner, but I think, at the least, I’ve been able to bring a little joy to the people who play my game, which is a good first step. Certainly, it was very gratifying to receive the first few comments, at which point, I knew I’d done something far better than my own views on it (maybe it’s less fun when you’ve played it for hours on end, trying to debug it). The Ludum Dare is certainly more difficult to complete than one would imagine, and it was pretty much intense coding for 48 hours even to get what I got.

Process: Write Once, Debug Forever
On Friday, at 10:00 EST, the theme was announced. Bet you didn’t see that coming. I thought of ideas for about 30 minutes, and then I generated a list of ideas that I had thought of. Really, my two favorites were having the item be duct tape (because who doesn’t love duct tape?) or acid. At the time, I envisioned both being played on a world made of lines (this thought proved to be perhaps the worst thought I had in the entire contest), so the technical challenges of each were very similar. However, I assumed that duct tape would be a fairly popular idea, since if you ask anyone sensible what the single most useful item to have is, they would say duct tape. Also, I think that the acid idea had more potential, although I wasn’t sure.
I spent from then until midnight working on getting circle-line intersections done well. I probably used a bit more wolfram alpha than was necessary, because solving for x in x^2 + (mx+b)^2 = r^2 is not the hardest thing in the world. I also failed to realize that that equation existed originally, and tried using trigonometry to get the answer, to no avail. Looking back, though, I definitely could have done it with trig, so that was a bit of time wasted. I think I also created my character sprites that day. You can really tell that they took me more than 10 seconds to complete.
The next day I worked almost entirely on getting the movement system working. As a programmer, this actually turned out to be my first encounter with numerical stability (or lack thereof). Since everything had to be working on a line, all x-velocities had to be multiplied by m to get the y-velocity, and all y-velocities had to be divided by m to get the x-velocity, and there was some sort of weighting that had to happen so that gravity on a nearly flat line wouldn’t accelerate you 1 m/s downwards, and 100000 m/s to the right. Dividing by m proved to be very troublesome, because it sometimes caused massive numbers to result, and that wasn’t good. I still have such a step in my current implementation, but I also have special cases for everything that could go wrong (almost everything). Once I had finally gotten that working, I had to write the collision code. The code’s algorithm was basically to make the smallest move possible (which would mean that if you crashed into the bottom of a line, you didn’t come out on top – which was a bug that I had frequently very early on) that didn’t upset any other constraints (specifically, it rechecked every other collision box each time a collision moved you, and it made sure that if you were already on a line, and weren’t transferring to the new line, it kept you on the line). This was surprisingly difficult, although I eventually got it with some more math. I also added all the graphics and UI that were used in the game, excluding the title screen & introduction cinematic.
As is evident from the blog, this code DID NOT WORK. It worked sometimes. Not much though. I spent so much time debugging it – it’s a miracle I was using Xcode instead of Code::Blocks, because I really needed a good interface to the debugger. I deleted the code that handled moving around lines twice, and the code that checked collisions once. While it might not seem too bad, each line of code you delete is time wasted. It becomes the LD47, then LD46, and pretty soon, you’re out of time to kill. Also, I had difficulty with OpenGL & SFML, because I couldn’t figure out how to make a texture that had transparent places in it.
The next day, I worked on MORE debugging (let’s face it: the movement code was full of murderous bugs), and added the red line feature. I think that this was a very good decision, because it made the game interesting. It gave the game an obstacle – time. If you don’t destroy the floor quickly, the red stuff will fall, and you’ll die and fail. I also created my level creation tool, which I didn’t release because it’s buggy and unintuitive. I also implemented the system that let me show pictures before a level started (e.g. the instructions presented to you before the first two levels) and let you go to the next level. Most of the day was spent debugging, and I ironed out about 3 major bugs in the movement system (ARGHHHH!!!), and created the system for the title screen & introduction cinematic (which makes it relevant to the contest! XD). Those went without any trouble. I created all 5 levels that day as well. I compiled it on my Windows machine that day as well, and submitted it.

Good Things (Do More of These)

• I stayed motivated throughout the 48 hours. Often I hit an obstacle that seemed insurmountable (See: Movement), and thought about giving up, but I could never put down my computer for more than a minute before I thought to myself, How awesome would it be to succeed on my first Ludum Dare? (Answer: Really awesome)
• Even though I am a very algorithmic programmer, I gave a lot of thought to graphics and audio. Of course, thought doesn’t make it happen, but if I were making a game with a bigger time constraint, they would have gotten done.
• My code was moderately neat! I didn’t really get to use the OOP I love so much beyond having it as syntax sugar (storing two variables, xPos & yPos is uglier than storing 1 variable, pos with pos.x & pos.y), but I got my code roughly organized in a tree, with no cyclic dependencies.
• Stayed focused. It’s so tempting to try being on a forum, twitter, and what have you, while still coding. During these 48 hours, I was either programming, creating content, eating, playing soccer, sleeping, or blogging about programming (okay, I tweeted about blogging about programming a few times as well). I programmed for long stretches of time with no interruptions, and never was doing more than one thing.
• I created a game. Rather than taking my good ideas, and arduously journeying 90% of the way up a mountain, being confronted by an obstacle, and dumping them into a pit of doom, I took a decent idea, and reached the summit.

Bad Things (Do Less of These)

• I chose to use a complex system instead of a simple one. While I could have used a system based on blocks to create my worlds, I chose to use a system based on lines instead. I use the word “chose” lightly, though. I didn’t realize that I could use the simpler system, because it never occurred to me. I need to think more next time.
• I screwed up my timelapse. Yes, it takes a special kind of idiot to do that. Idiot, thy name is Milo Brandt! Oh well.
• I had no audio. This was mostly a time constraint, considering that I was coding up until the moment that I had to stop.
• My graphics were slightly ugly. This probably was also mostly a time constraint issue, but it also stems from my relative unfamiliarity with OpenGL. My relationship with OpenGL is… complicated. I keep dumping it, only to realize that I love it, and to come crawling back.

The Future
Certainly, I stole a lot of experience from the Ludum Dare, as discussed above, but I think that I generated some very interesting concepts during the contest that might be worth pursuing in the future. While the acid idea would probably, at most, yield me a pretty cool flash game (if I ever bothered getting good with flash), I think that the duct tape idea could create a very interesting game, and could also be extended to be a 3D puzzle game, like Portal. While I definitely have ideas I want to pursue more at the moment, I would certainly be interested to see how such a game would turn out. Also, I look forwards to future Ludum Dares! Bring it on!

Get the flock out!

So yeah, first LD.  and I survived!  Woo!  48h to create a game is certainly even a bit more intense than I expected.

What went right:

I finished a game – more or less.  I certainly wanted lots more stuff to go into the game, but given the time constraint, I felt like I was able to prioritize.

Monocle is a pretty great framework.  It simplifies a lot of the grunt work of building a game, but doesn’t get in your way.  The abstractions are natural and flexible.  The documentation is still very in progress or missing, but the code is easy to read, and the examples do a great job of documenting how to use the framework as well as some basic game algorithms.

C++ didn’t kill me.  This was some of the first coding in C++ (or any statically typed language) that I’ve done in years and years, and it really wasn’t that bad.

Saturday night, I was figuring out how to go from “toy” to “game.”  I had some game ideas together, but I just wasn’t feeling good about the game.  In a non-crunch environment, it was the kind of feeling that would make drop the project and go watch Doctor Who.  I stepped back and thought about what piece of my game idea I liked – the ridiculous personality of the sheep – and focused on that.  It let me do informed design and better prioritize what do do with the remaining time.

Recording your friends making sheep noises is fun.

Playtesting!  I actually got to watch a person or 2 play the game.  It really helps you realize when things are unpolished and really need to be fixed.

What went wrong:

Bugs.  A few bugs definitely made it into the final version that I maybe could have caught if I’d been able to play the game more than once in its final form.  Not bad for a first run though.

Do it the simple way.  It’s way too easy for me to want to tackle a difficult design challenge.  Early on, I implemented a boids-style wander algorithm for the sheep.  It took a couple hours to get working and integrated, and it looked awful.  Sheep don’t move like birds.  Late Saturday, I tried to integrate entity spawners into Monocle’s XML-based map system by overloading some map loading code.  Although there could be some merit to that approach, this was way too complicated for a weekend competition and required way too much understanding of a complex system for being sleep deprived.

Environment.  LD seemed like a fun excuse to have an “art party.”  I was in a space with people designing a puppet theater piece, sewing a cartoon quilt, making monsters out of old sweaters, and building an accordion.  While this was fun, it was not very helpful for deep thought for code and game design.

Lessons for next time:

No really, sleep.  I wasted probably 4 hours early Sunday morning trying to work on things and definitely making things worse.  I would have been way better off going to sleep and being fresher on Sunday.

So yeah.  Thanks for a great weekend, all.

Ludum Dare 20 was my first. You never forget your first I’m told.

I didn’t get around to posting on my progress during the competition so I thought a quick post mortem to make up for it. At the end of the competition I was pretty upset about how the final hours went, but having slept on it and after getting some good feedback I’m now really glad I did it and with the end result.

Along with the post mortem, I’m thinking of doing a discussion of the game development (How I did feature X, Why I did it that way, Problems found along the way). If people are interested in that let me know, or it will probably just stay on my TODO: list.

Also, If you’ve not played my entry yet, go play it please, its here http://www.ludumdare.com/compo/ludum-dare-20/?action=preview&uid=3842

What Went Well

Tiled:

Tiled is a free 2D level editor that someone pointed out to me some time back. I had never used it before the competition but it looked good. It turned out to be brilliant, its very quick to knock a up level with. Its object system was essental to my game and the ability to add any kind of property to an object allowed me to do some really cool things (but these never made it into the final submission more on that later). It save format is xml which is well laid out and simple to parse. It also handles tile sets very well. If I was to do another 2D game (professional or hobby) tiled would be the first tool I’d download.

GIMP and Graphics Tablet:

Despite being employed as a professional programmer, I did once do an A-level in art. However, I’ve never got along with computer art tools. That changed over the competition. The art work I thought would take the longest to make, but after 30 mins of using GIMP I was flying  and knocking out textures. I’m really happy with a couple of the assets I made. The angry ball makes me smile every time I see it. I enjoyed using my new tablet so much I’m tempted to use drawing to relax.

C++:

I’ve seen some people posting something along the lines of “going old school and using C++”. While I agree that C++ is a pain to work with (a lot of the time)  its the language I work with every day. I was tempted to use a newer language like Python but in hindsight I think I may have stumbled on the language details. In C++, when something goes wrong its rare that I have no idea about the cause. In the end I had very few bugs during development of the game and I think this comes from knowing the pitfalls before hand (Sadly, with C++ there are lots!)

What Went Wrong/Didn’t Work:

DirectX:

As I started from scratch, I had a choice between Direct3D or OpenGL. I, somewhat, regret using Direct3D for two reasons. 1) Can’t easily port the game to other OS’s 2) Direct3D is a ball ache to get up and running. The amount of set up needed to get a triangle on screen is a lot. This is not always a bad thing, but for a 48 hour game making competition it wasn’t a wise choice. Maybe for the next Ludum Dare I should find an alternative (SDL? XNA? Unity?)

Didn’t Focus On Sound:

If you didn’t notice, there’s only one sound in my game. I wrote the code to play sound, it worked and I had a tool to generate sound in a couple of clicks. But I was stupid and left it to the very last moment to do and as an end result the game is lacking some character. I think the lesson here is to make an effort to get most sound in as place holder within the first 24 hours. Once its in it should be easy to swap out old sounds for new ones.

Wasted Time On Feature I Threw Away:

I said before that Tiled rules. It very powerful and in the 48 hours I created a basic system that could link physics objects to others via physics joints. These in turn would link to switches in the level. The idea behind it all was to have things like sea-saw puzzles or joints that could be broken to create domino effects i.e. a switch in level would set off a chain reaction in the physics that opened another door. However, the idea was just too big for the time frame and 7 hours from the deadline I had to drop it all. That was time spent I could have spent on sound . Lesson: Don’t think too big(?)