[My name is Carlos Leituga and I’m a junior Game Designer / Implementer in a Portuguese company, where I’m working on a Hidden Object Adventure for a year and a half now. So here I am again, creating a game in 72 hours with the Make A Game team for Ludum Dare #22. ]

As we were packing our stuff after making Eggscape, someone said something in the lines of “Let’s do this again in December!”, and since that day in August we’ve been talking about participating once more in Ludum Dare.

As the final week till LD #22 began, we followed the theme voting closely, coordinated our votes and shared the possibilities of each theme that interested us. Having learnt a lot with LD #21, we were confident that this time everything would work out better, even with two fewer members.

 The whiteboard calls the shots

The Idea

Something that we might never get the hang of it is figuring when in our timezone will the theme be announced. Finally, at 2 of the morning, “alone” was crowned the winner. After fumbling around with multiple ideas, it was about 5am and only Manuel, the other designer, and I were still awake while the others slept.

We started talking about a game where you played a kleptomaniac at his girlfriend’s house, having dinner with her parents, and stealing stuff when they weren’t looking. This sounded fun, but there wasn’t much variation, and we suspected it would require a lot of scripting to be interesting.

The best part about that idea was picturing the main character trying to conceal every item beneath his clothes, so that evolved into a shady guy wearing a trenchcoat on a museum, that would stray away from his tour group to steal paintings. You couldn’t remain alone for too long or the guide would start searching for you, but this was dismissed since it could limit the player’s movement too much.

Always great when the artist nails it better than we do

We then settled with a lone shady character walking around a museum, stealing art when he was alone and no one was looking. His trenchcoat would get as large as the concealed art, preventing him from navigating through narrow doorways. If the painting you were carrying was blocking your progress, you could swap it for a smaller one to proceed. There would be security guards on a constant patrol, and visitors walking around and stopping to admire the art, but running away and warning the guards if they spotted you snatching something.

The tour group made a brief comeback, as a moving hiding spot for the player, much like the monk groups in Assassin’s Creed, but that was cut earlier due to time constraints and issues that where delaying the development of more important non-playable characters.

Not even the size of his desk could constrain our artist’s talent

What went right

- An environment that nurtures creativity™

This time everyone was in the same place. There was no design or art by proxy, which made things much easier, specially since the extra hand in art determined the quality of our entry.

There was constant communication between everyone, and when there wasn’t, we quickly rectified that, which help maintain a good mood throughout the development process. If someone started sighing or getting upset, we asked what the problem was and tried to figure out solutions together.

The whole project gained a perfect harmony pretty quickly: the art style match our vision from concept to execution, and our sound choices were on the spot. All this thanks to communication™.

Image soon to be available on all of your favorite stock photo sites

- Good “marketing”

We wanted our game to be different. For that, we decided to keep an eye on the other participants. We didn’t want to steal other’s ideas, we wanted to avoid them, so we set up our Twitter clients to follow #LD hashtags. Eventually we started talking with other ludum darers, giving support and sharing links.

This lead to mutual interest and hype between projects. We can’t be certain of this, but hopefully they remembered to rate our entry as we did theirs.

Our updates at the Ludum Dare blog were also well spaced between to avoid spamming people and getting pushed by other posts. The Tumblr blog we made last time wasn’t forgotten, and we tried to use Facebook and Twitter in a controlled manner. Tried.

And then everything was about notch’s game

- A team of fast learners

For the second time competing in Ludum Dare, there were some amazing first times.

Manuel was in charge of level design, which he never once worked on before. We needed content, a lot of it, and we didn’t have time to prepare the game for multiple levels, so we all though that a huge museum was best. Though we now realize we were wrong, the map he made is still cleverly challenging. He even added color coding for areas that were the most far away from the exit and contain the most valuable art.

To avoid pulling the programmers from their tasks, we decided to use the DAME map editor to build our level. Learning how to use it was surprisingly easy for me but there was still the issue of exporting it to Flixel. We were exporting our map in LUA, but Flixel wouldn’t identify entities like the paintings, so when everything was rendered, it appeared as a solo background. So basically, Pedro, our engine programmer, spent one hour learning the motherf@#% basics of LUA to write an interpreter! Just wow!

Teamwork!

- Adding value

To encourage exploration and add value to the game, we made the Gallery one of our top priorities. This Gallery is accessed through the main menu and contains all of the paintings the player steals. Having classic, well known paintings wasn’t funny enough, so we made our “own”.

We have in total 72 unique paintings in the game, all of them are scattered in the museum, and each have a title on them. Most are nods to other games, while others are Internet jokes.

fArts

What went wrong

- Again with the framework

Last time we had problems with our tools, so this time the programmers decided to research in advance for something that suited their needs the most, and found they Flixel. Unfortunately, this engine turned out to have it’s own brand of headaches.

We had problems swapping animations, changing and rotating the guards’ cone of vision, setting up spatial sound and developing better pathfinding than just by points and that avoided getting stuck in objects. Most of these features had to be dropped to meet the deadline.

But worst of all, it was picky with our sound files. Some wouldn’t play completely, others wouldn’t embed when compiling the SWF file, giving multiple errors when trying to stream external audio files. We nearly missed the submission window because of that, forcing us to release the game without sound. Only on the following morning, after the Jam had ended, that we figured out that the problem was related to file size, so we got back to work and solved some minor bugs.

At least this time we were able to test a prototype early in development

What’s missing

We made our best effort to make this game rich on content. From all the features we had to cut due to unforeseen problems with the engine, the quantity of paintings and the gallery menu were elements that we had to deliver. Though we should have spent some time looking up how to save the player’s progress.

The guards took so long to implement that we had to drop the visitors and change the setting to a museum at night. The placeholder circle around the guards, used to test their cone of vision that we didn’t finish, stayed in the game with a different color and opacity, and we gave a flashlight to the sprite to pretend it was a circle of light.

There’s a lot of art missing from the level, mostly museum props used either as decoration or obstacles, because not everything was exported from DAME.

And after these 17 days of voting, we read your comments about the game and completely agree that it should have had a smaller map or multiple exits.

See? It’s not that big!

Conclusion

Although we had our share of problems, everything worked out better than last time. We took our time planning who would do what and how.

Manuel worked on the game design with me, designed the level and made additional art (paintings and props). Fred took care of the AI and sound. Tiago made all the characters and animations. Pedro and Daniela programmed the gameplay mechanics and menus. And I translated the level into the editor, while also making mockups and acting bossy.

We prepared in advance, setting up a local SVN server instead of using Assembla like last time. We forced ourselves to be original by identifying the theme’s common patterns and avoiding them. We tried to sleep at least 6 hours per day and were well stocked up on food.

There was a lot of stress in the final minutes of the Jam, but it was a great experience nevertheless!

Regarding future Ludum Dare events, we’re talking about of at least finishing Eggscape before competing again, but we also have other side projects up our sleeve. So we can’t decide on Make A Game’s fate just yet. I mean, third time’s the charm, right?

You can play “alone I art” at Ludum Dare or at http://makeaga.me/aloneIart/.

Don’t forget to rate.

Update!

Here’s a video of Banksy that Manuel showed us when we thought of the trenchcoat guy and swaping art. Totally had forgotten about it!

Tools Used

FlashDevelop, Flixel engine, DAME map editor, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.

It’s very short, but I thought it was pretty cool. Good production quality. I spent most of the time on the art and physics, I did it all from scratch.

Written in C++ using SFML2.

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

Check it out, play it please, let me know what you think

That doesn’t necessarily mean I won’t use jMonkeyEngine for 2D though. Its integration with external libraries on the scene graph is phenomenal and I’d like to find a way to utilize, say, Bullet nodes/controllers in a 2D environment. Plus, I find wrangling with LibGDX to be un-fun and rewriting boilerplate code for Slick again is not in my sights. I spent way too much time on simple crap like entity management on the Discovery game from LD19.

I’m guessing using jMonkeyEngine for 2D stuff the hacky way would be switching the camera to Orthographic view and just using objects with lots of volume in the Z axis, since I am terrible with physics.

In addition, there are a few new tools I may use:

• Tile Studio
• The Games Factory/Multimedia Fusion (total last resort, if I’m just not feeling up to speed)
• PXTone definitely, though I mentioned FamiTracker earlier I absolutely loath tracker interfaces and PXTone is like a really, really simple FL Studio to me.

There was some talk between my friends and I about doing the Jam instead, but one of them may be having travel conflicts that’ll prevent them from participating. Oh well. Dare it is.

Tomorrow I’ll finish off the game’s lost and won screens and add in more enemies – I promise!

What went right

I spent some time coming up with a couple of interesting(ish) ideas, but ended up throwing them out before settling on what became Cosmic Heist. When I designed the game that actually ended up being made, I actually cut out tons of things, and cut even more as I developed it. This is one area that I really want to improve (I, like many others, am horrible at the “cutting things until it’s right” part), and I feel I made some good progress during this compo. I was able to reject tons of ideas, some good, some bad, but all non-essential.

I had a decent personal code base to start from, and already knew all about the language, libraries, and tools I used beforehand, so I was able to jump right in.

I left some time for play-testing and bug fixing/tweaking near the end, but ended up not needing very much of it. The game was small and simple enough that it wasn’t too buggy by the end, and my wife and I tested it some as I worked on it anyway. However, I would definitely leave this buffer time again anyway, because it really kept things stress-free.

The menus ended up looking/working/sounding great, and I added a cool animated menu background near the end that I really liked. I’ll probably use some of the work that went into that stuff off into the future in other projects.

The music turned out to not suck as much as I thought it would. That was actually my highest-scoring area in the competition, and I am still somewhat unsure what to make of that. This was my first time really making any music, and I don’t really have experience playing/reading/etc. music either. But it doesn’t sound too bad, so I am counting that as a nice success.

The controls are really fluid, and are my favorite part of the whole thing by far. The way you control the ship is great, and I’m really happy with how it turned out. I actually didn’t spend much time tweaking that, and by implementing everything I needed for it, I had a whole system for various enemy ship movements, too.

What went wrong

The player’s ship is a bit oddly shaped. This makes it hard to see where you are going. I didn’t realize this at all (duh! isn’t it obvious! the ship points in the direction I drew it to point!) until people began commenting on it. Certainly something that would need to be fixed.

Some people kept looking for the shoot button. I didn’t make it very obvious (at all) that there is no shooting in the game. You just pilot your ship, and enemy ships try to plow into you.

There were a couple of features I wanted to get in, but had to cut due to time constraints. I wanted enemy ships to shoot at you, and every level was supposed to start at a shipyard, from which you had just stolen a ship.

There might be a problem with the Linux build of the game, as one person mentioned they couldn’t get it to run. Unfortunately, it runs fine for me, but I only have two machines to test it on, and they are both almost identical in both hardware and software. If anyone has or can test the game on Linux and tell me if it a) explodes, b)doesn’t run at all, or c) runs fine, I would greatly appreciate it.

Conclusion

All in all, as I said, I was very pleased with the outcome, and I even got some people to play my game, so that was really exciting. I hadn’t ever participated or followed LD until now, so I didn’t have any idea what to expect. I honestly didn’t think anyone would even see my game! Thanks to everyone who rated mine. One thing that I regret is that I didn’t have time to rate any games myself. I did play a few, and they were all great. Next time, I want to set aside some time to rate a good number of games.

Links

Ludum Dare entry

Cosmic Heist on Cheese and Bacon (my website)

Cosmic Heist on Google Project Hosting (MIT License)

It was around 11pm when I left my house with a 1 hour trip ahead until I met the yet to be named Make A Game team. Having memorized half of the list of possible themes, I spent the little I could of brain waves keeping my car on the road, and tried to think of quick game mechanics suited for a 72 hour game development.

I was the last of the team to arrive; I met some new faces and joined in on the ready up ritual. There were still 3 hours until the official LD #21 theme to be revealed, so we started throwing ideas around, writing them down on our white boards and linking them to similar themes.

 Look busy guys…

The awaited hour finally came, and the Escape theme was victorious. We quickly (and sleepily) gathered around one whiteboard and started discussing our previous ideas, along with new ones. Among them, the Survival Tetris game was highly praised. For some dumb reason, I went to my computer and searched if someone already had done such a thing. It existed, and in two quite different forms. In one you only controlled a stick figure, and in the other you controlled both pieces and a round character. We were bummed out.

We tried multiple approaches

It was late, our two hours of brainstorming didn’t end with a winning idea, as we decided to go to sleep at 5am.

As each of us woke up, we agreed that we needed to go forward with one of our ideas. We were wasting too much time thinking of a game to make rather than making one. Our most solid idea was our twist on the Tetris game. We didn’t know it yet, but we would have a lot of fun developing it.

The Idea

Our game isn’t Tetris. It might look like it, and use some of its rules, but you wouldn’t play it like Tetris. Actually it would be a bad idea if you managed to complete and erase lines, because it would be a setback from your objective, which was to save a non playable character from something dangerous at bottom of the screen. You’d be making steps with Tetris pieces so that character can climb to its safety.

Initially we took inspiration from the idol scene in Indiana Jones, the game’s character would be in the central chamber of some ancient temple, and removing said treasure from its pedestal would trigger a huge spiked cylinder that would try and crush you from below. The whole temple would start to crumble, and the character would use the falling debris to escape being grinded to death.

Eventually we started thinking on different treasures and dangers, even on a feature to allow custom tilesets. Though we weren’t glad with the default spiked cylinder danger, it would be easily animated but lacked something, like personality. The dinosaur mommy came into form, as did its egg. Our character changed from an Indy/Spelunker lookalike to a something akin of the great animal taunter Steve Irwin.

Goodnight Sweet Prince

What went right

- Great references

We wanted a quick and fun arcade experience, and for that we had to make the player to play it fast. There had to be a rhythm that could match the speed the loop of which the pieces would appear on screen and drop down.

Every time we had some doubts on how to replicate that feeling, we’d turn to the current best example of a fast paced arcade game: Pacman CE DX. That game has so many small but important details that can be easily overlooked, from the music to the gameplay feedback. And we used it as our way to resolve impasses.

For the art style, we were constantly leaning over the shoulder of Spelunky. We loved the way Derek Yu can mask the mosaic nature of tilesets and we tried to apply what we learned from his work on that game.

- Knowing our priorities

By the end of the second day, we knew we were late on schedule. We didn’t have any prototype for some hands on and we had to start deciding what needed to be done versus what we wanted to have in the game.

Listing all of our features and deciding the importance of each helped us to, well, deliver an actual playable game. Leaving out stuff can be heartbreaking, especially on bigger projects, but we knew our challenge, and we knew we’d add all the stuff later.

One of the few annotations that weren’t in moonspeak

What went wrong

- No Streaming

It was a shame, but we had spent some time setting up our SVN and getting our game idea together that we didn’t bother with getting any kind of desktop video stream. We also had a camcorder but lacked a proper tripod to have it up high filming the whole process.

- Lack of planning

This was everyone’s first time working with Flash to code a game. That alone made us lose valuable time when we decided to ditch Stencyl for FlashPunk, because the prior was having conflicts with our SVN. Basically, when the XML files that Stencyl saved were submitted to the SVN, they appeared differently to each user, with a modified structure or a bunch of errors that weren’t supposed to be there.

But what hurt our time the most was the lack of planning before getting started with the code. Each was tasked with a particular job, and there was no discussion on how to approach their tasks. This lead to some late changes that kept us from moving forward with development and having a proper prototype of the gameplay we aimed for.

What’s missing

For this Ludum Dare build, we only have two modes available: Survival and Time Trial. We were planning two more modes – Altitude Attack and Score Sprint – as well as multiple goal values for each mode.

The difficulty would also do much more than define how many lives you start with.

We had plans for a startup countdown before the game would begin proper, where a little cutscene would play out with the game’s character picking the egg and crapping his pants when everything started collapsing.

We wanted that the Score was a combination of remaining lives, height climbed and treasures collected. One thing that got in the build was the score multiplier that doubles your points each consecutive step climbed. But you probably didn’t notice it because we didn’t have time to put points coming out of the character’s head when he was climbing.

But worst than everything, we didn’t have time to include a splash screen with our team’s name!

Screen mockups are your best friend

Conclusion

In one year working on a game studio, I’ve learn that game developers can’t get too obsessed with their projects. There has to be a time when a game needs to be finished and released, with or without implementing all of the planned features. A finished game has much more value than a game that’s been in development for years, without a release date.

Though we are finishing the game after the competition, this is a lesson that Ludum Dare has taught our team. In this industry, every project has milestones that need to be met. We had a lot of setbacks and what we delivered wasn’t accomplished without staying up until a couple of sunrises, but concentrating on what we could finish instead of hanging to what we could add helped us reach the finish line.

It feels good to finish something.

You can play Eggscape at Ludum Dare or at http://makeaga.me/eggscape.

Tools Used

FlashDevelop (IDE), FlashPunk, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.

No more art to do ; _ ;

With all the art done, we turned our attention to the team’s logo while the programmers keep churning out code.

We are near completion of what we can do with our 72 + 4 hour time limit.

Setbacks in the second day kept us from having the game done within the original schedule but we are really proud of our overall progress.

Some stuff won’t make it to our submission build, but we’re keen on finishing this amazing project.

You can check out our Day 2 recap at http://makeaga.me. We won’t be doing a Day 3 post or Post Mortem for a couple of days.

WATCH OUT, IT’S A CODERS’ BLOCK!

]]> http://www.ludumdare.com/compo/2011/08/22/eggscape-update/feed/ 0 http://www.ludumdare.com/compo/2011/08/21/timelapse-of-city-runner/ http://www.ludumdare.com/compo/2011/08/21/timelapse-of-city-runner/#comments Sun, 21 Aug 2011 20:49:56 +0000 Warrozo http://www.ludumdare.com/compo/?p=67343 (Can’t get embedding to work…)

Here’s the link!

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

I’ve submitted my game to Ludum Dare. If you want to check it out, here’s the link. Screenshots:

Anyway, my game is submitted, but not done. I’m sure there will be code that needs fixing, which I’ll do during the last few hours. I’ll post my post-mortem after the 48 hours is done.

This is the first Ludum Dare I’ve actually completed with a game that resembles finished. Ah, that first time feeling Technically, I did attempt LD 20, but that failed miserably.

After the 48 hours is up, I’ll call my game finished. Until then, I’ve got everything covered so can spend the last 8 hours with the code. And maybe some caffeinated drinks.

I was planning to do the Jam this time round, but my team are all over the country right now on holiday

See you on the other side of the 48 hours.

The Second one i may redo… Hm.

IT’S NOT STEALING! IT BELONGS IN A MUSEUM!

“Oh, I didn’t see you there, crushing my path for survival and my dreams of becoming a famous paleontologist.

Do you know how hard it was to find this egg? And how lucky I am that these debris are falling in such a coincidental position that I can climb some of them? It’s like someone is throwing them with exact precision. But I don’t have time to think about it, actually I can’t do much more than panic and run around, waiting for more debris to fall.”

We’re Make A Game and Eggscape is our entry for Ludum Dare 21′s Jam. You can read our Day One Update at http://makeaga.me!

Onward to Day 2! It starts right now!

Hmm, I just decided that I would scan some of my note/sketches. I’m putting it through the automatic document feeder to not waste time, so it might look a little washed out. — GAH, nevermind, the auto doc feeder is a POS. It always fucks up.

• Graphics Engine / Game Engine / Libraries: Allegro 5
• Sound: SFXR
• Graphics: GIMP

I hope the this ludum dare will be a lots of fun and good games
See you after a good sleep, and Good Luck Everyone!!

I’m developing for iOS in Xcode 4. I’ll be using the terminal screenshot script that was posted today. I actually used it in the last Mini LD; and it works reasonably well, especially considering you don’t need to install any extra software, which is nice.

I have my own small library for iOS games, which is the accumulation of what I’ve learned until now. There are still some glaring holes, like that fact that I have no idea how to build/import any kind of map haha! But I’m sure I’ll figure something out. Last Mini LD, I figured out collision detection on my own.

Hmmm, since a lot of entries include photos and stuff, maybe I should do the same. I’m at work, so I won’t be taking pictures of my messy house, however, I started dicking around on some music last night, warming up for this weekend’s challenge (don’t worry! I won’t actually use it. And my “song” really sucks anyway, haha). So I included a few screenshots of that.

Wee!

I figure as rules demand I should really (re)present myself and intentions. It’s my first time doing Ludum Dare and it’ll be interesting to see just how much gameplay I can cram into a piece of code within the allotted time – if any.

The game will be Flash-based. I would have considered Flashpunk but I don’t have enough experience with the framework just yet. Instead I’ll be using a custom-fitted version of Flixel which I’ve used with some hibernating projects lying around Github (https://github.com/tellus). While none of them will likely be a basis for the game (actually, I intend on it not to), I’ll most likely draw on a few supporting routines and procedures from the modified Flixel and my support lib tellusLibsAs. As should be obvious by now, all of the code is freely available from Github. Flashdevelop will be the IDE of choice (I’ve fallen in love with that piece of software, delicious) as well as Paint.NET for graphical purposes (I’m spartan… very spartan… basically Spartacus-spartan) and if… when… eventually… sound may be a necessary evil element of the game I think I’ll fall back to something quirky through Audacity. Open-source and freeware throughout.

I’m rooting for a few particularly interesting themes myself (one cannot help but visualise possible ideas already) but let’s see where things head.

Good luck to all and cheers for a great weekend!

I plan on using a SDL-based sprite framework that I’ve been working on lately… right now it’s in an unusable state though (being moved from using SDL blitting to sprites as textures in OpenGL).  Assuming it’s fixed in time for the competition, I’ll post the code somewhere for y’all so that I’m within the rules and whatnot.

Uuuhh… yup!  Nice to meet you all!  Let’s have us some fun!

EDIT:  Aaand… that SDL->OpenGL conversion I mentioned?  I think I’ gonna abort it and instead move to SFML.  I’ve been reading about it some today and it really seems like the way to go.  There’re benefits to working with SDL and learning how things like blitting work, of course, but if the API for SFML is as much better than SDL as people are making it seem, it would really speed things up for me… in addition to saving me from having to link in extra libraries for some of the stuff I’m doing.  I’m pretty sure this is one of the useful things someone told me about last night on IRC, but I never managed to get around to looking at it at the time because I was too busy playing with bfxr!  I should have listened to y’all better!  Belated thanks!

I have found the idea, the music kind, the mechanics… I just hope it’ll be the “Title of your game must be a year” theme, ’cause otherwise I’ll have to shoehorn my idea or something… So far it’s a 2D game, topdown, about a firefighter rescuing people in a very specific moment in history… More on that later!

I’ll be using AS3 and FlashBuilder (the Flixel framework, most probably), Photoshop, musagi, sfxr, and chronolapse! Also, I’ll be using a SVN system to reduce the “undoable catastrophe” damage ratio, if ever there is one. I hope everyone uses a version control system of some kind.

During the compo I’ll be blog my ideas and how I expect to expand them, and how everything goes.

Aaaaaaaaannndd I will also be updating my personal blog over here : clicky

KICKASS WEEKEND, ENGAGE!

http://download.thenet.sk/images/out/NiribuX.swf

Still got lots of stuff todo, but Im happy with the graphics so far. Next up: Loot!

Click here to try!