While I was able to produce something playable this Ludum Dare, it was not one of my favorites. I failed to manage the time and scope of my project. As a result my entry falls far short of my goal.

When the theme was announced I brainstormed three ideas:
1) A 2d platformer where the player shifts between two parallel planes of existence. By touching an enemy the player is either kills it or is killed by it depending on if the player is in the correct plane.
2) A top down tower defense game where monsters appear through portals (to connected worlds). The player needs to survive a set period of time.
3) A 3d platformer where in a surreal floating dream scape. The player would collect journal pages as they explore the 3d level.

I went with the third one, in part because I had been wanting to do a game like this for a while, but also because I would not have to program enemies. The collectable Journal pages would allow me to add some flavor to the world and do some basic tutorial stuff.
After settling on a concept I dreamed up a feature list that included Momentum based air movement, bouncy blocks, moving platforms, and wind patterns. The wind patterns were going to be the main feature of this game, allowing the player to rise on up currents and glide about the level. I spent a lot of time implementing the wind system and the particle effects that the player would use to visualize it.

I spent Friday night programming the movement, platforms, and wind system. I planned on having the core game play done by Saturday morning. Then I could spend all of Saturday afternoon doing art. Sunday would be reserved for making levels. The schedule began to slip when I spent a good chunk of Saturday refining the wind system and making the journal/portal code. I finished up the level art assets Saturday night on schedule. When I awoke Sunday I felt the need to mess around with the code some more. The first real level I had made was behaving oddly, and I had to go back and fix several bugs. I didn’t get to proper level creation until 4 hours before contest end.

Ultimately I managed to make two levels that would instruct the player in how to use the jumping, double jumping and moving platforms. I had wanted to make 1 level for each of the game features. As the player mastered each feature they would be able to explore more of the central hub level and discover more levels and journal entries.

What went Right:
* I used tools I was very familiar with: Unity3D, GIMP, and Blender. I was able to bash out the core of my game play and art in very little time.
* Picked an idea that involved dynamic movement (one of my favorite things to program)
* I kept my art style consistent and did not try and steal textures from google image search.

What Went Wrong:
* Did not allocate enough time for level design.
* Did too much playtesting on a non level.
* Focused too heavily on features that would never be implemented.

Conclusions:
I managed to produce a good prototype for a game concept that has been lurking in the back of my head for ages. For games like this movement dynamics and level design are make or break the experience. I focused too heavily on the first and neglected the second.

During the development period the only person play testing my game was me. Now that I have gotten some feedback I realize that most new players treat the boomerang as a linear projectile weapon that comes back to you. That was not my intention with the game. The boomerang is supposed to orbit around the player killing targets as you dodge out of its path. The goal is to not catch the boomerang. The point system incentives you to kill as many Zombibers in one throw as possible. This is only possible if you keep the boomerang air born between Mobs.
Here is an animated gif of how I meant it to be played:

The boomerang will accelerate towards you and it will also partially turn towards the mouse. By combining mouse and player movement you can direct the boomerang to specific targets. The challenge of this game is not killing Zombibers but getting the most points by killing them with style.

Just finished uploading screen shots and publishing my entry. I have been up for 23 hours strait. I know some of you have been up for longer, I know some of you still have more work to go, but here is where I stop.

Download Link:
http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=4265

For those of you who are still furiously polishing your games and stomping bugs, I wish you the best. For those you who are asleep right now, you have my envy.

I did a lot of sound, score, and level exchange work, I can finally start on level design.

Well I should have saw this one coming. I have been polishing the code that handles the game play, but have completely neglected the level design and sound. Even if I spent the remaining 3 hours hammering out levels, they won’t be complete or very good.  I think I am going to give up on the compo and do the Jam instead. Those extra 12 hours will be useful for making a better game.

I have completed all the artwork I plan on doing for this game, and integrated the animation into the working code. Tomorrow I will make a game out of this.

Working demo online at:
http://www.monkeydev.com/unity/ld28/

Got the boomerang physics, enemy death, and enemy AI working.

The most recent version is here:

http://www.monkeydev.com/unity/ld28/Index.html

Any feedback on the boomerang physics, difficulty, or general feel would be appreciated.

To do:  Make a main character 3d model, animate models, sync movement and play to animation.

Tomorrow will be art day.

So I plan on making a game in Unity 3D that involves a Vorpal Boomerang, The Canadian Wilderness, and a clone army of Justin Biebers. It may not be the most original idea out there but it is a start.

I currently have character movement, camera control, and am using the Unity terrain for background;

Now Working on physics of the boomerang.

My idea for this Ludum dare was to make Puzzle/Stealth game where the player must sneak/fight/bluff their way through guards to get from point A to point B. The 10 seconds would be how long it takes your gun to reload. As an additional dynamic I wanted the enemy AI to recognize they had a gun pointed at them and back off. Thus allowing the player to defend themselves without shooting.

Last night I got the game to a playable state (path finding, user input, line of sight) and I came to the conclusion that it is not fun. While I think I could finish a game with this in the remaining time, that game would also not be very fun. I like theme was but I was too ambitious in my implementation of it.

I also spent way too much time working on 3d models that are too detailed for the distance viewed at:

This is an in game screen shot:

This is a better view taken with the unity camera of what the models actually look like.

On the upside I have a Depth first search path finding algorithm written for unity that I can apply to future projects. I also have a better understanding of the unity animation controller.

For those who are continuing I wish the best of luck. I look forward to seeing your brilliant interpretation of the theme. See you next Ludum Dare.

Having Just learned the new Unity3d Animator state system, I find my self spending way too much time on fancy animations that I can blend together. This is not helping me get the core mechanics done. I blame any failure on my game not being interesting on Unity being too awesome to play around in.

I came to the realization that a 10 second reload is too long for the game play I am going for. 5 seconds is stretching it. So I am giving the user 2 guns each take a total of 5 seconds to reload. At the most the user will be reloading for 10 seconds. Oh here is a screen shot:

I will be making a Zelda style game around a 1 shot pistol that takes 10 seconds to reload. The gun can be used to threaten enemies as well as kill them. The long reload should force the player to think about the ramifications of discharging their weapon, since they will be unable to scare off enemies with an empty pistol. Player will be limited to aiming in the cardinal directions to make combat against melee only enemies more challenging.

Possible features include AI drawn to the sound of a gun shot, path finding, and a plot ooooh…

Last night I started getting into Ludum dare mode. I stocked up on easy to consume foods, cut my hair and nails, and did some warm up code. I learned how to work the new animation system that comes with Unity 4. It seemed very intimidating when I first started, but I feel comfortable enough with it now. There were some kinks with the newest version of Blender, but I downloaded an older version and it works fine. I made a very simple 3d humanoid model, skinned it, rigged it, and gave it two animations. The whole process took three hours.

Ludum dare starts at 8:00pm in my time zone. After work I plan to do some more food shopping, take a nap, cut my nails, and hang with you all on the IRC before the start. Here is to another successful Ludum Dare. (Raises a cup of tea towards the screen).

This Ludum Dare some friends asked if they could help. While they were very motivated they did not have much experience with the development tools I was using. So my main challenge this Ludum Dare was to get the most done towards game development from my friends enthusiasm.

Since the game jam allows you to use a private code base I started making a generic side scrolling beat-em-up engine a few weeks before the contest. Regardless of the theme I figure I could it could be made into a side scrolling beatem up. Its key features would be movement on the XZ plane, the ability to jump and 2 types of attack. I used place holder art to verify my systems worked.

For art assets I wanted to take digital images of my friends against a green background then convert the green to alpha to make sprites. I encouraged my friends to bring what ever costumes they had lying around their homes on the day of the event, and we would try and figure out what we were going to make on the fly.

When the theme was announced the first idea that popped into my head was trying to distill the “Hero’s Journey” into its core components and check off as many of those components over the course of the game. Considering the how much is written academically on the Hero’s Journey I figure it was due for a quick dirty video game treatment.

I cribbed off this page:http://www.mcli.dist.maricopa.edu/smc/journey/ref/summary.html for the main steps in the Hero’s Journey. I formed a loose plot outline consisting of 7 stages: Call to Action, Training, Death of Mentor, Escape from Fort, Meeting Goddess, Climax, Return to normality. Each stage would have a series of enemies and some dialog giving pretty blatant hints about what step in the hero’s journey it was checking off.

I spent Saturday morning cleaning up the side scrolling fighter code so that it would do the game specific tasks like AI mentor, boss battles, and event triggers. Saturday afternoon my friends came over with their costumes and props. We decided that all the bad guys would be T-shirt Ninjas (made by tying a tshirt around our head to look like a ninja mask). The roll of Protagonist and Mentor was foisted off Zach and Crystal because they are the most photogenic of our group, and because they didn’t bring a computer that could do development on.

Saturday night and most of Sunday was spent cleaning up the images and importing them into the game engine as characters. Zach had a great idea of doing the backgrounds on notebook paper to add to the whole minimalist theme. I like the note book aesthetic since it conjures memories of high school day dreams. During this period jimmy did of the image processing. While I created character prefabs from his finished art assets. I also created the basic scene files on which we would build the encounters.

Around 9:00 we were finished with the character prefabs and decided we should actually make the finished levels. Zach was down sick and Crystal had work on Sunday so the task of level design was left to Jimmy and I. We tag teamed each level with one person in front of the computer and the other watching and making suggestion. By midnight we had 4 out of the 7 levels done. Jimmy went home at this point and I soldiered on until 2:00am finishing the last levels. I spent an hour on QA, bundling the application, taking screen shots and going through the submission process. Then went to bed around 3;00 am.

Thanks to “cheating” and using base code written before the event this was one of the more relaxing Ludum Dares I have participated in. I intend on refining the code base and image capture process so that it will be even easier to make games of this type in the future. I wish we had more time to fiddle with the game play variables to make combat more fun, but we spent too much time making sprites.

-Wilson

Instead of a postmortem I wish to provide a journal of my thoughts and actions during this Ludum Dare. One of the things I like about Ludum Dare is watching other people’s creative process in action through their blog entries. Unfortunately I was too involved in my own creative process to blog about it during the event. So I am writing this after the fact, using my best recollection of the events. I felt I had a pretty successful Ludum Dare and want to share what I think made it successful.

Edit I just realized that this post takes up a huge ammount of screen space. Probably because it is an almost hour by hour account of my actions during this Ludum Dare. I have copied the main text to my webpage, here is a link:

http://www.monkeydev.com/unity/ld24/devlog.htm