I made a video about developing my Ludum Dare #22 entry, Omega Men. During the competition I filmed some video diaries, and some footage of the game as it evolved, so hopefully it’ll be an interesting story!

Btw, does anyone know how to embed youtube videos into these pages properly?

Our timelapses are online, yay!

Check them out here:
http://01101101.fr/ld48/

I’ll go write a post mortem now 😉

So this is the first Ludum Dare I made it all the way through, and my second attempt total. I didn’t make it for the compo, but thank god for the extra day allowed by the jam. I had a blast doing it, and I’m very proud of the result, Frosthome:

What went right:

Cutting the design. This is the number one reason I succeeded. The original design called for a series of levels in different settings, with an interesting little mechanic that caused the level to “decay” over time, bits and pieces falling apart and changing the paths through it. Further, it required a set of items to be scattered across these levels, which you’d have to collect to ‘win’. This design was originally called “Scraphunt”.

What I ended up with is a simple 2D parallax platformer with no bells or whistles. But I finished it on time, and I think the design is more elegant because of the features I cut.

TinyXML. It’s an easy to use open-source XML parser designed for simple integration. Thanks to this, I had level saving and loading up and ready first thing.

The art. Thank god for my tablet, but really this can also be attributed to the level editor. 99% of the level is made using two basic image files, rotated and scaled, with some fuzzy-blended patches of the same thing overlaid to hide the edges. It was quick and efficient. The art was the second thing I worked on, and prototyping with real art is a big motivational kick.

The level editor. It’s fairly easy to use, and without it I’d have to design levels by editing the XML file they save to. I still have to do that if I want to introduce an item with a texture not used in the level, but overall it’s simple and efficient. If I want to design a jump, for example, I just play the game, make the jump, swap to editor in mid-air, place a platform below me, and continue on. Easy.

Sleeping. I tried staying up late the first night, but when I was mistaking array[1] for array[i], I realized sleep was essential. After that I made sure to manage 6 hours a night.

What went wrong:

The physics. “It’s a platformer,” I thought. “How hard can it be?”. Well, it turns out that it’s damn hard to do ‘right’. Beyond the generic but annoying stuff like getting the player to follow slopes and preventing collisions with the environment, you’ve got the fun but damn hard stuff: adjusting jump timings, player speeds, air control, and all those other little questions about what makes a game fun. Can the player wall jump? What about one of those mid-air double-jump direction reversals, ala Ghouls and Goblins? Should he slide on the ice? Tweaking these things took time. A lot of time. I spent pretty much the entire second day doing that.

The level editor. I spent real time making it easy to use and intuitive- drawing outlines around selected objects, doing some things (color picking) in a dialog when I could have used straight key-presses. These little bits of polish all ate away at my time.

Real life. I lost about 3 hours a day to various real-world responsibilities, in addition to time spent eating and sleeping. The worst was an appointment I forgot to cancel on the afternoon of the last day, right during crunch-time.

Forgetting to explain double-jumping. This is a big one. After releasing, I had several of my friends tell me that my game was “impossible”. It turns out they weren’t double-jumping. This kind of basic mechanic introduction is key, and I can’t believe I missed it.

Level design. The last hour of time was spent adding the win screen, the kitty achievement, and freezing to death. The last 15 minutes was spent taking my test level and turning it into something playable. I really wish I’d spent time making a longer level. Luckily I hear it’s quite challenging, which makes up a bit for the length.

Audio. I spent some time integrating ogg/vorbis and openAL, and then never got around to using them. Thankfully this was mostly boilerplate stuff, so the time cost wasn’t too big… but I feel keenly the lack of moody music with whistling ice chimes and wind blowing.

So yeah, coding hard, even if slow ( I _HAD_ to sleep during the day, still weak from the sickness ). I managed to implement PNG map loading, character entity, tiles, and “tile cleaning”

PICTURE TIME!

Now to implement, in Gameplay milestone:
-Dying
-Multiple levels
-Time limit
-more tile types
-enemies

Sheesh. I guess I’ll be doing 3 days. Stupid sickness.

Also, I noticed that I’m making the game about a goblin that’s alone on his birthday. It’s my birthday, I’m alone in my bed, far from any friends ( in a foreign country ), coding. Not so different after all, eh? Maybe I’ll change the game ending from one I wanted to have to happier one. At least my Gobos will have a happy birthday 😉

Here is our double timelapse for Braille:

Tags: CSharp, LD #22, timelapse, xna

I’ve known about LD for a few years, but have never participated before. On Friday I asked Steve if he would be interested in being sleep deprived for the entire weekend and he was! Once we decided to join we anxiously awaiting for the theme to be announce and couldn’t focus on much else.

We added an extra layer of challenge beyond building a game in 72 hours. We wanted to try and build a lite version of a game that we could submit to the App Store. Going into it we knew it was a crazy and foolish idea, but we wanted to push our abilities and focus to their limits.

Process

Even though 72 hours is technically 3 days, the schedule below is broken into the 4 “days” or awake periods between naps.

Day 1

Setup

Normally Steve and I work remotely, but we live close enough together that face to face meetings are possible. We decided to setup a joint office for weekend so we could brainstorm efficiently and motivate each other. I setup a folding table next to my desk and he lugged all of his stuff over.

Steve worked on OSX using Flash, Photoshop, and a Wacom tablet. He sketched out a lot of art on paper prior to working in Flash to make sure we nailed the look. I worked on OSX as well using XCode 4, Texture Packer, Particle Designer, Audacity, GIMP. We were targeting iOS so I worked with cocos2d-iphone and chipmunk. We were both very familiar with the tools and frameworks that we were using so we didn’t waste a lot of time learning our tools.

The Reveal

Every LD has a theme and this year it was “Alone”. We were ready to shout out ideas but when we saw the theme all we heard was crickets. “Alone” was one of the themes we were interested in but we knew it would be tricky coming up with a good game. Luckily the silence soon ended and we started brainstorming.

Brainstorming

Everyone started throwing out ideas and Steve scribbled them down. Whenever we would get stuck we would read through the list and try to go further with an existing idea or try to take it in another direction. We initially approached the process by trying to come up with a story or situation that fit the theme. This generated a lot of ideas but it was hard to come up with a game mechanic out of many of them. Here are some of the ideas we had:

• Ghost who wants to be alone and tries to evict the living
• A mute and deaf person (possibly blind?) who is alone in the world and needs to find a way to communicate
• Stuck in space
• Stuck at sea
• Buried alive
• Post-apocalyptic survival
• Famous and trying to buy friend

The Idea

We ended up expanding on the idea of someone who wants to be alone and can’t seem to get away. We decided that our protagonist would be a rockstar who was being chased by a horde or adoring fans and the player would guide them along a platformer-esque level to the tour bus.

The rockstars would be members of the four person pop group The Four Hats. Their debut album Hat Tricks is also introduced in the game.

The Four Hats in “Room to Roam”: Rockstars have it hard. Millions of adoring fans, mountains of cash, and no alone time. How is a musician supposed to write new music when chased by the paparazzi or the hordes of adoring fans? In order to find the solitude that you crave and unlock your inner muse, you must outrun fans and make your way to the studio. Don’t get caught by the paparazzi on your way there or your creative energy will be sapped dry.

The initial idea included having all of the members of the band as playable characters with different abilities that would allow you to navigate the levels in unique ways. The levels would take the band through multiple eras of music to provide variety. Clearly that was biting off a bit more than we could chew in the time that we had.

Why rockstars and music? We had at our disposible a very talentled musician who has written music for our other projects. We wanted to work on a project that showcased his strengths as well as ours. He could easily do the creepy music that would accompany the ghost story or the stifling silence of being buried alive, but who doesn’t want to be a rockstar for a weekend.

Flesh on the Bones

Next we started to flesh out the idea. We worked on the sound, did sketches to get the look, settled on the mood, and worked out the details of the mechanics. Once we were on the same page and understood what we were making we each started working on our own parts.

Getting the style and animation of the first character to match what we were aiming for brought Steve to our first nap break. During that time I got a basic prototype working of some platforms, and obstacles, the controls, and a horde chasing you.

Day 2

On Day 2 we started adding actual art assets into the game. I had put together a basic animation system on top of the existing system in cocos2d while Steve finsihed up the animations. We had also settled on a naming convention and system of organization to simplify the code and avoid rework.

Once we had the character in game, Steve moved on to background elements, obstacles, and other art assets. At this point our pace matched up really well. Art and code were never too far ahead of each other.

As the day drew to a close we had all of the basic gameplay in place with art assets and an awesome instrumental version of the music. We did some playtesting and identified the pain points to work on the next day. One of the issue we had was that the obstacles weren’t interesting enough to make the game varied and interesting. We had a few ideas for “traps” or “enemies”, but hadn’t added them into the actual game yet.

Day 3

Sunday was a busy day and by the end of it we had a game. Even though we were not in the 48 hours contest, it still felt good to have a complete game by the 48 hour mark.

A few things that we worked on:

• Everything else: menus, icons, etc
• Level loading, gameplay tweaks, enemies
• Writing and recording vocals
• Writing and recording menu music
• Playtesting

Up until this point we had been randomly generating levels, which worked for testing purposes, but it led to uninteresting levels. We decided to switch over to hand built levels.

The best part of the day was that we had the final cut of our main gameplay music. “Room to Roam” is a track written, produced, and performed by The Four Hats. You can check it out on soundcloud:

01 Room To Roam by The Four Hats

If you need music for your game, we can put you in touch with negapixel (or The Four Hats) as he is available for contract work.

Day 4

Level Building

Building the level was a lot of fun. It also gave me a lot of time to play test the game and burn off a lot of warts. Building the level by hand gave the game a good pacing and slowly introduced elements in a balanced way. Since we didn’t have time to build level selection screens, or other elements that would create a polished multi-level game, we made sure the level was decently long and ended with more challenging play.

Building and playtesting the level took a lot of time. I had been storing the level config in a plist, which is not at all visual, and definitely added some friction to the process. After reading other LD post-mortems I realized we should have been using a pixel map. It would have been a quick way to implement a simple visual level editor. It is definitely a technique that I will be using in the future.

Polish / Cleanup

We finished the basic game and added a lot of polish ahead of schedule. We knew we didn’t have time to add additional characters or levels so we focused on wart removal and polish. We spent time putting together sound effects, button states, an intro cutscene, and particle effects.

Playtesting

In the final hours of the competition we were as ready to submit we were going to be. We continued to playtest the game because we were addicted. It was a great feeling to realize that we were no longer playing to test, but because it was fun.

What Went Well

• Came up with a fun concept that excited us
• Balanced work, sleep, and breaks to stay productive
• Familiarity with cocos2d and tools
• Great teamwork
• Music, art, and gameplay meshed together into a consistent experience
• Had time to add a lot of the polish we hoped for
• Reduced scope to make schedule realistic and focus on quality
• Time constraints focused the project
• Lots of testing

What Didn’t Go Well

• First time building a platformer. Learned that realistic physics didn’t equal fun.
• Took a bit longer than expected to get gameplay feeling right
• Took too long to build level
  • Didn’t choose a good format for level editing
  • Wasn’t familiar with any existing level editors
  • Should have used a pixel map
• Took longer to animate initial character than expected
• Had to redraw some frames a few times to make the action smooth
• Had to reduce the scope of the game
• The kittens we rented ended up mostly causing a distraction when we didn’t need them for the theme
• A few minor bugs slipped through (expected given the time restraints)
• Building an iOS game for LD has caused fewer people to be able to play than if we built a flash game

What Next?

We are going to submit Four Hats to the App Store after Apple’s holiday break and will continue development on additional levels and characters if people enjoy the game. We originally pictured a much bigger game, but the 72 hour time limit restricted what we could build. In the full version we pictured:

• Four playable characters each with a special ability
• Switch between characters to work through levels
• Multiple eras of music by the Four Hats with levels to match
• An EPIC sound track

Prior to submitting the free version we will fix a few minor bugs that we missed in our initial testing. This should only be another hour or so of work.

Conclusion

Ludum Dare is awesome! We would definitely do it again. We are happy with what we managed to build in a weekend.

It would be great if there was an iOS focused version of the contest. I am not sure how to solve the distribution issue, but if all the participants had iDevices it would expand the audience.

Building a polished app in a weekend is extremely difficult. We already knew this going into the process, but we wanted to challenge ourselves. What we found is that it is possible to build a fairly well polished prototype or lite version of a game, but adding in the extra content required for a full featured game takes a lot of time.

See art, video, and photos from the project on our live blog post from the event.

Check out our page for Four Hats here.

Cross posted on our blog.

I missed ludum dare? D:

aww :(((

Cross-posted from my blog:

• http://www.gavpugh.com/2011/12/21/ludum-dare-22-postmortem-journal-and-timelapse/

So, this past weekend I participated in the 22nd Ludum Dare competition. You have just 48 hours over the weekend in which to create a game. The crux of the competition is that you create all code and content within that 48 hour period. No re-used assets at all. Only engine/middleware/framework code is permitted to be prepared beforehand.

I wrote my game with Unity. It’s the first project I’ve ever undertaken in Unity, and I had very little experience of it. I came out of the other side with a very positive impression, I really liked using it. As much as I love C/C++; given the time constraints, it seemed a good idea to go with Unity. The other big upside is that you can deploy the game to be played via a web browser. This was definitely what I wanted. I didn’t want people to have to go to the hassle of a download-and-install, just to play the little toy game I made over a weekend.

I wrote a turn-based strategy RPG game. My inspiration was the “Shining Force” series of games. The theme of Ludum Dare this time was “Alone”; every game submitted had to follow this theme. This obviously doesn’t fit the team-based gameplay of Shining Force, but mine has a twist. You just play as a single character. It just takes the combat part of those RPG games, there’s no walking around and talking to villagers. There is a shop to purchase and sell items between battles, but that’s it.

The Game

Here’s a link to play the finished game:

“Adventures of One”

I was disappointed with what I ended up with, mostly due to how much work I had to squeeze into the time. In my eyes the game had two major failings:

• A lack of polish. The art is my placeholder art, and the GUI is the default-Unity GUI.

• Little game balancing. The first world is decently balanced, but after that it gets way too easy. The game is completely procedurally-generated. I just didn’t have the time to playtest it.

The biggest achievement though was:

• I wrote a game in 48 hours, that’s actually playable; and a little bit fun!

That’s my introduction out of the way. Now, onto the postmortem…

What Went Right?

• Choosing an idea which I’d see through to the end. I actually lost most of the first two hours to thinking over what type of game I’d do. The theme ‘Alone’ was tricky for me, as most of the ideas I had before it was announced didn’t fit it. I ended up taking one of those ideas and simplified it. In retrospect doing a full-blown party of player characters would have been ridiculously hard to do in 48 hours. But yeah, I was excited by the idea and that helped me keep my motivation.
• Using a higher level language like C#. Considering the game didn’t make too much use of Unity-specific ‘scene’ features, and was mostly generated in code; I could have had similar results using something like XNA instead. Either way, this sort of rapid development lends itself to something higher-level like C#. Out of habit, I think I would have been too anal about my code if I wrote it in C++. C# just lets you throw caution to the wind that little bit easier!
• Enemy AI. Pretty close to “Shining Force”’s enemy AI. It slotted in well to the turn system I had set up; so it followed the same rules and states the player had. The turn system I wrote had its positives and negatives, but since I left the AI to pretty late on, I’m happy I spent the time earlier making the turn system generic.
• The UI. I left it to pretty late on. I hate coding UI. I’m glad though I just used the stock Unity functions and didn’t try any fancy rendering techniques. I went for the basics, and that was the right decision. I’d hoped I’d get the chance at the end during the polish phase to ‘skin’ it, but I had no polish phase.
• Save and load. Lost close to an hour implementing it, but it’s a pretty cool feature. It autosaves after each battle (Unity stores web-app info on your hard-drive, so it’s transparent). I also got in a crude Base64 load/save screen, to bring your save to other computers.
• Bug free? Well, it seems to be for me. I kept it in a pretty stable condition, considering the game’s complexity and reliance on procedural generation, and AI.
• Food, drink, and breaks. I think I was sensible with what I ate and drank. I took pretty regular short breaks. Even if it was to just chill on the sofa with a notepad for five minutes, and plan out my next coding session. I’m not a coffee or energy-drink guy, so just cups of tea kept me going. I’m unsure how I wasn’t totally fatigued by the end, I’m guessing it was adrenaline.
• The ‘all nighter’. It saved me from not finishing. I’m an optimist when it comes to scheduling time. Re-reading my journal log, I hardly meet any of my set goals (but to be honest I did surprise myself with getting ‘unscheduled’ stuff done really quickly). If I’d had lost say, another five hours to a second nap, there is no way I’d have had a functional game come submission time.
• Placeholder work. Crappy art, blocks instead of characters, a checkerboard playing area for 90% of development. These sorts of things meant I had systems playable sooner. This helps my motivation, there’s nothing worse than building up to a point, where you’ve seen nothing on screen and hoping ‘everything will work out at the end’…. And then it inevitably doesn’t. My longest blind-coding run without actually seeing anything on the screen working, was about half an hour; for the turn system. Everything was short and sweet to rapidly iterate on.
• The audio. I think it went well. I dropped in the sound effects just after the halfway point, which provided good battling feedback, with the lack of particles/visual effects. The music I also procedurally generated. I lucked out with some good classical piano pieces which fit the style of game well. The voiceovers by the wife I threw in at the last minute. They worked out well, but I’d have liked to try and fix the audio balance between her and the music a bit more.
• Not caring about the code quality. It’s awful. Terribly hacked-about stuff that reminds me of the sort of thing I’d have written in college. I however still coded pretty defensively though. I just didn’t worry about things like commenting, and whitespace/indentation being off. Fix something ‘properly’, or throw in a sure-fire hack? A no brainer. I also committed many cardinal sins with global static singletons, instead of jumping through Unity’s component hoops. My typing fingers thanked me!
• Stand-up desk. I have an IKEA Jerker desk. It’s not adjustable, but I have a high stool which I use when I need a rest. Being able to constantly switch between two was awesome. When I’d feel lethargic in the chair, I could stand. When my feet got tired of the standing, I’d be able to take a load off and sit. I probably was about 50/50 in each position, time-wise.
• No internet distractions. I know some people who do these completions regularly like to use Twitter and IRC extensively during the dev time. I’m a bit of a procrastinator; those sorts of things can be a big timesink. I told myself I would just check my emails on my cellphone, and do nothing more than that. It worked out well. I’m real surprised that I didn’t feed my Chaos Engine addiction, throughout the whole 48 hours!

What Went Wrong?

• I left some important features until way near the end. In particular the attack logic I rushed through, such that it doesn’t scale into later battles. Enemy placement and the map terrain generation I did with less than two hours to go. I should have had all the procedural-generation stuff done very early, and other risky things like the battle logic calculations too. Instead I did the bread-and-butter stuff that’s hard to get wrong first, and did the risky stuff later.
• Very little playtesting. It’s a slow game to play through to test leveling into later battles. I should have made leveling stats deterministic and had some way of starting myself off in the later, harder battles to test balancing.
• Graphics/art. I spent hardly any time at all on the graphics. I can’t draw for shit, but I can usually fudge things to look very aesthetically pleasing despite that lack of talent. I didn’t even get any time to try that.
• A lack of preparation. I’d planned each day during the week prior to “look at Unity tonight”. I hadn’t got around to it. So I had to learn as I went. Some aspects like hooking up audio took a little longer than they would have, if I knew how to do it beforehand. I also found myself dropping in and out of the ‘component’ model that Unity has for objects, because it didn’t ‘click’ for me until a few hours in. I think I would have likely pen-and-paper planned out my components to be better organized, than the ad-hoc mess they ended up as.
• AOE (area-of-effect) magic; stuff that affects more than one tile. Probably lost a couple of hours spread over the whole period, to implementing it, and dealing with fallout from it. I envisioned it as being useful in later battles when there are tons of enemies; which drove me to add it in the first place. It’s a shame later battles are such a walkover, which kind of renders it just a time-saving device.
• I started working at about 11am on the Saturday, after about five hours of sleep. I took it easy in the morning, and watched some football as I coded. That time was actually pretty productive. I then carried on for well over 24 hours and worked up to the 6pm deadline the next day. I really didn’t feel too tired, but my productivity certainly slowed. I didn’t have many bugs to fix, but one in particular was niggling in the last four hours. I only fixed it shortly before submission. I think with a fresher head, I’d probably have not caused the bug in the first place.
• UI and state machines. I hate coding UI. I hate coding state machines. This game had plenty of both. I’m surprised it didn’t demotivate me. State machines always seem such a chore. So much code for what has very simple intentions. Scripting languages can make this a lot easier with their micro-threading capabilities. I remember reading something about C# and the ‘yield’ statement lending itself well to state machines, but it’s a little less straightforward to grok. I should have probably checked that out again.
• The scope. Too big. Too ambitious. Given my lack of preparation too, it was silly to think I could do the idea justice in less than 48 hours. I had a good stab at it, though.

“Picasso” – Look at that work of art!

My TODO List At The End

I had to prioritize the last few tasks, so I inevitably had some on the cutting room floor. Here are the features I really wanted to add:

• Particle effects on attacks. I’d seen some demos of particles in Unity, and they looked really simple to set up. A good bang-for-buck. Didn’t even give it a slight look.
• More/better character graphics. I also rushed through naming and giving stats to the enemies that did make it in. The art in the game isn’t good, and I don’t think I’d have made it that much better; but I’d have liked to added more varied enemies for sure. I think I probably spent a grand total of about twenty minutes the whole project (if that), making art.
• I had functionality to ‘slow’ the player movement over harsh terrain, and collision for impassable squares. I always planned to procedurally generate the terrain, but I didn’t get the chance to hook this stuff up. Impassable squares would have been tricky, in order to avoid blocking the player out of areas. ‘Slow’ terrain though wouldn’t have been much work.
• Healing spells for enemies. ‘Buff’ and ‘debuff’ spells for the hero player, as well as the enemies. Similar ‘buff’ and ‘debuff’ items to use as well. Some of the turn-logic for this sort of thing was in place; it would have probably taken less than an hour to add these.
• A better looking GUI. I’d have liked to try changing the font and colour used. I did Google search at one point, but it looked pretty involved, and would require me to go through all my UI code and hookup references to a ‘GUISkin’. Probably not much time to do at all, but every minute counted at this stage.

Of course, all of these things still fall way below ‘fixing the balancing’, and some other things mentioned in the “What went wrong” section. The Perlin-noise, colored and textured terrain was actually a wishlist item for me originally. I wonder if I’d have left that on the wishlist, I would have been able to fix the balancing?

Final Thoughts

In all, I enjoyed the experience. I was disappointed that the game I was intending to be challenging and provide seemingly ‘endless hours’ of battling, only holds up for about ten minutes. But I had fun coding something that quickly under a time pressure. Sure, the code looks absolutely horrible, but it’s a thrilling experience just churning out stuff at that speed, and having it all come together.

I would consider doing another Ludum Dare in future, but I’d definitely want to do more preparation. I’d also certainly scope my idea much better. I think a shorter, tighter game is the way to go. Something that would be doable with two ‘sleeps’ in there as well. I’d like to get a good twelve hours of sleep next time, instead of five!

My Journal Log

You’ll notice the log ends at about 2pm, four hours before my 6pm deadline. That last four hours was just a whirlwind, the time flew by ridiculously fast!

log.txt

I found it pretty useful to keep this log. It helped with motivation, and helped me focus on what I should be doing next.

I also have half a dozen mini-notepads full of ramblings about movement, AI, and the turn system. Taking a break from the computer and sitting down with a pad and paper is pretty valuable. Just gives you time to refocus, so you don’t just sit there coding down a blind alley.

My Time-lapse Video

~38 hours in ~4 minutes:

Ludum Dare #22 – Adventures of One

The first session was about 10 hours; the second session was about 28.

Tags: postmortem, timelapse

Spoiler Warning : Contains full play through. 

Tags: Playthrough Video Unity

I added forums to my google site now you can talk about stuff going on there

Hello all, I guess the cool thing to do is a postmortem, so here is mine. First off, here is my game, I would love to hear some more feedback.

This is my first Ludum Dare so I really just wanted to see what it is all about. I didn’t push myself to create something amazing. I didn’t do any cool time-lapses and I didn’t try to ‘market’ my game at all. For the next LD I will try harder at these.

What I did right –

• I’m proud of my game. Even though I didn’t push myself in its creation I still put a lot of myself into the game. I
• I created what I had in mind. My final product is what I had envisioned from the beginning. Granted I did need to cut some content out but I sorta expected that.
• I finished! I didn’t give up or get discouraged!
• I didn’t kill myself while making the game. I ate well, and I slept well.

• My game doesn’t have enough game in it. My game feels a lot like your on rails the whole time. It feels like there is only one way to go, and one thing to do. Sure there are some small physics puzzles along the way but I wish I could have made them more integral to the game.
• I didn’t prepare. This is partly because I had no idea what to expect. Next LD I will probably go through the themes and brainstorm some.
• My game takes FOREVER to load. I’m not sure why this is, but I shall do some research and figure it out. Maybe its because I’m using dropbox. Hrm.

Play the game here.

This is the time lapse of the full 48 hours of development, trimmed slightly so you don’t have to wait 30 seconds while I’m sleeping.

I like the concept of a timelapse, it makes it look like I know what I’m doing when I code something, as opposed to making it up as I go.

And again, if you could please play and rate my game, as well as leave any constructive criticisms, that would be greatly appreciated.  Thanks

The entry page.

Tags: LD22, timelapse

A while Back me and a Friend started making a small Command Prompt Application Called BatchChat after a while we got Bored and stopped developing it However I have decided to Release the source code here and If anyone wishes to expand Upon it feel free to do so

Click Here to View the source Code

Click Here to View the forums Source Code

Click Here to View the Prototype of what was Eventually Programmed Into the Forums as Polls

I Hope you people Like it

Espectadores en el clima frío los eventos tienen más de un problema de los atletas. Cruz condados carreras de esquí se han disputado a temperaturas cercanas al menos a 30 grados F sin problemas para los atletas – no así para los funcionarios de carrera y los espectadores. Artículo recomendado por Roja Directa

My entry for LD22 (ISOLATED ASSAULT) was somewhat of a wave survival game, getting harder with each death, until you reach the goal, the escape chopper.

I had a lot of fun, and, after being my first time, I will most definitely do this again.

Here’s the “Proper” Post-Mortem:

How I Spent My Time

Timelapse here if you want to take a look.

Basically I came up with an idea while I was making the game. I had already pretty decided it would be first person. And also I had pretty much decided the enemies would be cubes. (Just to make it easier on myself)

I didn’t particularly like the theme, alone, but it was better than kittens. 😛

Mainly I worked on getting the character movement to be as smooth as possible, that’s where most people messed up, to make the game fun and re-playable. I tried to make the sword animations as hectic as possible, just to make it look a little more stylish. I made the wall and floor textures 8 bit and repeatable. I made the music overdone, with a lot of instruments (using garageband) and very complicated. I did this because I remembered all those 2d games with catchy music but terrible graphics.

I implemented the theme by having enemies appear if you put on sunglasses, but disappear if you take them off. The catch was that in the sunlight, without sunglasses, you burned. So you had to find shaded “safe” areas to take off your sunglasses and regenerate health, while the enemies disappeared.

The sound effects were done in CFXR (I especially like the enemy death noises). The language I used was Javascript. The game engine was Unity Indie. The 3d modeling software was Blender. This cannot get any simpler.

I chose these programs because, well, they were free, and also because they’re proper towards making an indie game.

What I Learned

• The smoother the gameplay and character movement, the better
• Sound is a very important part of game development
• Don’t over-complicate things, keep your main code in as few scripts as possible
• Particle effects make the game seem more complete

What Went Right

• The music was mostly catchy and was repeatable
• The gameplay was smooth and the sword attacks blended together well
• The implementation to the theme (being alone, only when your glasses are on)
• The sound design was okay, especially with the enemy deaths

What Went Wrong

• There should have been more enemies
• The enemies should have been easier to fight
• There should have been more things blocking your path
• There should have been better GUI controls and being able to change the mouse sensitivity
• The level design should have been worked on better
• The game should have been longer

All in all, I think I did an okay job, maybe not the best, but it was fun enough to please my friends, and good considering the amount of time I had. (Less then 48 hours, more like 30, I had to go to some places)

Try it out here.

Tags: blender, post-mortem, unity3d

When I first submitted my project, it depended on the VS2010 Runtime Environment. I then re-submitted it using a static compilation (before the deadline), but that caused it to crash on many PCs. So, I am reverting it to the old version that required the VS2010 Runtime Environment so more people can actually play it. I hope this is OK.

I came into this Ludum Dare with one clear objective; to develop a game using HTML5 to evaluate the Impact Game Engine (it passed with flying colors, tho I’m still hoping that someone ports Flixel to JavaScript). Besides that, I had no further plans, so when I saw the theme, I was a bit troubled, how can I make a game about being Alone?

So I decided to think about job occupations that lead you to loneliness, and while I went through the list the weirdest one was “Lighthouse Keeper”. So I scoured the web searching for a Lighthouse with a cool name, but I found none that I liked, so I decided to create a fictional one, that somehow made this idea pop into my mind:

Yes my notepad is rainbow colored

“You are the Lighthouse Keeper at Styx River, your job is to persecute souls trying to escape hell, it can get lonely, but jumping on ghosts sure is fun and it’s pretty comfy.”

For some reason, I saw the tarot card “The Tower” and I felt that it was fitting, so I dropped the idea of being the Keeper, and the player became the Lighthouse itself. For the mechanics I concieved Space Invaders meets Hop & Bop platformers. Sounded pretty easy at first, but the execution proved difficult and it does need a lot of playtesting to get right.

What went right:

a.- The Music: As usual I took a public domain music score (Danse macabre, Op. 40, by French composer Camille Saint-Saëns.), recorded some sound effects (cards shuffling and hitting the table), and a public domain fireplace sample that I looped. I was very pleased with the final product, I think it properly represents the core concepts: We are all alone and the same in death (Danse Macabre), We all share the same destiny(Tarot), and the fires of hell that served as setting. Once again I used Audacity, Aria Maestosa and GXSCC.

b.- The Framework: Impact Game Engine was pretty intuitive to use and extend, even for a first time user, I only missed per pixel collision.

c.- The Concept: The idea is great, I’ll keep working on it.

d.- The Art: I loved the Art. I drew on paper, then took a picture with my webcam and painted in Photoshop, it went smooth as silk but…

What went wrong:

a.- The Art: Spent too much time on Art creation. Last time I think that no one realized that my Art style was Atari-like on purpose (I even implemented a Pixel Bender shader to simulate screen ghosting after the screen flashes), so this time I decided to go for a painterly style, that also happened to be more labor intensive. In the end I could have used a couple more hours on coding.

b.- The IDE: I was too stressed out to properly install and configure Eclipse, I was stuck with Komodo Edit.

c.- Server Stuff: Spent too much time trying to configure PHP on my laptop to run some tools.

d.- Platform: HTML5 audio support is not there *yet*, had to implement a quick hack with SoundManager 2.

e.- Language: I had no prior game dev experience with JavaScript, I was left wondering how to implement a global variable registry. Also, I got to find an IDE with proper code completion, Komodo did not autocomplete variables I had declared on the same *.js file.

f.- Execution: The concept was hard to execute successfully, I should have playtested more, and also I should have investigated prior implementations. Now I have homework: Why does Mario bounce off enemies the way he does?

Phares, Jam Entry

Tags: Phares, postmortem

Para evitar problemas, asegúrese de que cualquier vacío de la piscina tiene una cesta de la hoja en línea, o eliminar manualmente las hojas de la piscina con una embolsadora de red o de la hoja que se conecta a una manguera de jardín antes de aspirar a la piscina, entonces usted está aspirando sólo la suciedad. También, asegúrese de que todas las cestas de filtro en la piscina están en buena forma y no tiene fisuras. Esto incluye la bomba, el skimmer y las cestas de la hoja en línea. Artículo recomendado por Cubiertas de Piscinas

It’s not really a post mortem, well it sort of is, but not for the game I made this Ludum Dare. That’ll come in  a while after I sort out my thoughts on it. I might do a technical post mortem first.

Anyway

It’s about my previous ld game(again, sort of), which has been my first proper contact with game-making after a long long time. As if I put it (making games) on a shelf and forgot about it for many years and let it collect dust and cobwebs. It’s something I can do that makes me happy regardless of the end result. It’s something I can do that takes nothing and time and makes something, and at the end of the day I can sit back and look at something which wasn’t there before.

And you guys are to blame for me finding it on that shelf.

People liked this game of mine for some reason(the ones that understood it) and some made a point to tell me in IRC they remembered and liked if from all the way back then which blew me out of the water. Days later I still can’t believe that happened. So now that said game is on the android market and the ubuntu software center and desura and such I feel that I should give something back to the people who inspired me to keep going.

So what I’ll do is post a bunch of desura keys for that game of mine every day till Chritmas.

Let’s start with 2 for now and see where that takes us:

R42VR-VIU5B-ZBR2T-EL8BD-RIZIK

PUOJQ-X0BD5-I2QG2-E26MQ-KZCQC

I refuse to call it a postmortem for the end of the dare is not the end of the game , Due to how much i like the idea and the game-play i will continue Chronoflux. now to get down to the meat of the post.

What went right:

-Sound creation was a breeze with sfxr and Greasemonkey’s Autotracker-bu it took all of 5 seconds to add some sound to the game;

-Art creation though its not a work of art by any stretch I made art that make your eyes bleed and it take too much time.

-Infinite Coffee who needs sleep anyway

-Made a map editor as clunky and painful as my (sort of unreleased) map editor it is much better then if i tried hard coding it

What went wrong:

-Lack of outside testers caused me issues such as the slowdown on level two (caused by poor collision detection) and the difficulty of some puzzles(end of level 2 for example)

-Lack of sleep to be honest i slept a total of 2 hours during the dare, as much time as i gained not sleeping i lost much more from being tired… i may have started mumbling to myself and rocking back and forth one hour… but thats besides the point…

-Infinite coffee without it i would have passed out, it would have been for the better

-Lack of time i lost many hours from my madness cause by lack of sleep so i lost time to add features such as past npcs, animations and a proper tutorial.

All and all if you get anything from this. code +fuel = game. sleep = fuel. coffee != fuel

by the way you should play my game