Archive for the ‘LD #20 – It’s Dangerous to go Alone! Take This!’ Category
So I look at my game when the results come back, and see results I was expecting. This game was a test, so I am not suprised that it got mostly 2 and 3 overalls. But what’s this? columns of 1′s? My game surely wasn’t that horrible! Even if they didn’t like the humor or the graphics etc, I know I did some community work. What were they expecting, an essay?
Well after mild frustration but a little bit of self pity, I went on and looked at other games I found to be quite polished. What? More columns of ones? Are these people crazy?
I guess these people don’t have enough time to play or something, even then they shouldn’t be voting but instead leaving it all alone.
It’s been a long 3 weeks for some, but Ludum Dare 20 has finally ended.
Here are your results:
Top 20 Competition Games
You can check out the top 20 competition games here (including ties):
Winners are decided by the Overall category. To see the complete list, hit the “Show All Entries” link at the bottom.
Categorical Top 5′s
Here at Ludum Dare, being the best game isn’t the only way to win. Games are rated in 7 additional categories, with a special “Coolness” category highlighting people that went above and beyond to be sure you got a vote.
*NOTE*: You can click on the titles of the categories for Top 20 style lists per category.
More Great Games from the Jam!
The Jam is huge – simple as that. With 64 games this time, the Jam is now larger than some of the earlier Ludum Dare events. I regret that we still don’t do more for the jammers, but don’t fret, we are thinking of you. We’d like to encourage everyone to check out the Jam games, and leave a comment. Here are four to get you started:
Again, this is just a taste of some of the great games to be found in the Jam.
See them all here:
Seriously, go check them out!
More Ludum Dare 20 links
IndieGames.com’s 250 Indie Games You Must Play
Editor of IndieGames.com Michael Rose has recently released his new book “250 Indie Games You Must Play”. I know we’re a pretty significant source of great freebies and not-so-freebies (see the featured games in the sidebar), so I fired off a question last night: Did any Ludum Dare games make the book?
Mike had this to say:
Yep, quite a number [of times] actually
We here at Ludum Dare love talking about ourselves, and though we may not have coffee tables to prominently show a book on, coffee is a significant source of caffeine, so I’m sold.
Visit your favorite Amazon and pick it up.
Ludum Dare breaks 2000 on Twitter!
As the organizers, Phil and I tend to amuse ourselves each event with little statistics to gauge the growth of the community. One I’ve been keeping a close eye on for LD20 is our twitter follower count. Early this morning, the @ludumdare twitter account finally broke 2000 followers! Wow!
We use the twitter account as a way to share little updates. Reminders, press coverage, and the occasional amusing quip we catch in the Twitterverse or on IRC. If you’re in to that sort of thing, and do the twitter thang, follow us!
Also if you haven’t already, sign up for the mailing list. Even if you do hound twitter reading each and every post, we make an effort to get the most important news to you via e-mail too.
Ludum Dare 21 – Coming August 2011!!
May Mini LD #26, hosted by drZool
I agree, August is quite a ways away. How about this weekend then? Yes, tune in Friday for a brand new MiniLD event hosted by drZool. He’s been teasing with D’s all month… I wonder what he’s up to?
If you have any suggestions for us (website, observations, etc), we continue to collect them in the comments here:
Thanks everyone for coming out and making Ludum Dare 20 such a big success! We’ll see you again in August!
- Mike Kasprzak (PoV)
Just a few hours left. Time to post-mortem my game…
Take This Triangle is a 2d defense game inspired by vector graphics from the old-school. Spring physics from the new-school, and doobers from the school of Zynga.
TTT was written in C/C++ using SDL and completed in the 48 hour period and is playable on OSX and Windows here. If you want to play it on another platform it should compile just fine.
Figure 1: Estimated Time Usage
1. Vector Graphics
A massive amount of time was freed up by choosing to focus on what I don’t suck at (writing code, play testing games) and dodging what I do suck at (trying to be an artist).
2. Fun Core Mechanic
Dragging a springy things is fun. Clicking on doobers is fun. These two mechanics together worked well.
3. Small Scope
I managed to avoid feature-creeping the game or trying to undertake something too complex for the given time frame. Executing a small idea well is much preferable to a executing a larger, broader, but more rushed idea.
What Went Wrong
1. Starting at Zero
When the competition began I had an IDE and an zero base code. It took a few hours before I could begin writing game code. Preparation is key.
Staying focused is always hard. I spent a lot of time doing other things (including sleeping) instead of remaining on task. See figure 1.
3. Polishing Too Late
I wish I had started improving the art and adding particle effects in earlier. A screen shake, glowey lines, more particles, more feedback on the dragging / aiming, more tweaks to the difficulty curve, badass grid effects. Sooo many small things I would have liked to polish.
Over all the process was enjoyable. I am proud of my game, it is one of the few experiments I have made that I find myself returning to in order to kill a few minutes.
As always, LD was a learning experience for me.
Amazing to see so many great ideas executed by so many awesome people. Enthusiasm and skills abound in this little indie community!
Great work everyone.
I’ve been meaning to write this postmortem for a while, but keep putting it off because my thoughts on it keep changing. After watching a few people play my game first hand, I think I’ve finally figured out what worked and what didn’t.
If you haven’t played it yet, then please go and play it, going by the number of comments I think that having a game beginning with ‘W’ means most people haven’t tried it. Thanks.
So, what went right and what went wrong?
Right: Animal companions
I knew when I saw the theme that I wanted to do a zelda-like game. I’ve not done one before so it would make for an interesting change, but I thought there’d be a whole bunch of zelda-like games, so I needed a ‘hook’ to make it different. That’s where the companions come from.
Each companion grants you an offensive ability and a puzzle solving ability. For example cats give you area-of-effect fireball bursts which can kill enemies and melt ice barriers. Ice weasels give you line-of-sight ice bolts which can kill enemies and build ice bridges over holes. Snakes cause room-wide earthquakes that can flip switches behind obstacles, and birds let you jump over enemies or objects.
And they all look different too! I spent a lot of time drawing different walking animations and idle animations, so it does genuinely feel like you’ve got a different companions helping you though the world.
Right: World navigation
Originally the game was going to only have single-screen, non-scrolling rooms. However on the first day I decided that would be too limiting, so rooms can actually be any size – if they’re smaller than the screen they’re centered, and if they’re larger then the camera scrolls around with the player.
Transitions are based on early zelda games, and although tricky to get right I really like how they came out. With single-screen rooms and no transitions you don’t really get a sense of walking through the world, but with the transitions you seamlessly go from one room to another so you actually feel like you’re exploring a single giant space.
There’s definitely prettier games in this LD, but I’m very pleased with how the graphics came out. Yeah, the low-fi pixely look is pretty over done these days, but it means I could get a lot of pretty decent graphics done very fast and keep everything looking consistent throughout.
This is by far the most art-heavy LD game I’ve done – an animated player character (in four directions!), four unique NPCs, four unique companions (with walking and idle animations), three enemies, plus the environment, gui and effects. In total there’s 120 unique sprites!
There’s two ‘dungeons’ in the final game, the tutorial and the proper dungeon. The tutorial seems to work really well – everyone I watched got though it with only minimal head scratching and it explains everything it needs to.
For the actual dungeon my main goal was to make something non-linear so players would feel like they’re exploring something, rather than just following a long corridor. I think it pulls this off well – in fact I suspect it’s too non-linear, which overwhelmed some players. A smaller, easier dungeon to start would have been good but I didn’t have the time.
Since the original inspiration was The Thing, the ice base theme fitted well when I was trying to think of non-zelda-like settings. However the combination of lack of time and lack of drawing skill meant I ended up with a fairly vague environment that didn’t really look how I wanted it too.
Originally I’d planned on having separate indoor and outdoor sections, but lack of time sunk that idea – I just didn’t have time to draw another set of environment graphics and the required code to hook them in.
Readability was a big factor too, and one area where the low-res look causes issues. Everything is drawn to be obvious as to what it is, and to be visually distinct from each other. Adding in extra environment detail would have made the puzzle elements of the gameplay harder to grasp.
Quite simply, I ran out of time. I actually had two full dungeons designed on paper, but it took me over two hours to physically type in the first one (rooms were just text files with Xs and Os to designate walls and buttons, etc.) and make sure it was solveable, so I didn’t have time to add the second one. (Oddly, the one in the actual game is the second one I designed).
Because of this, the one dungeon that is in wasn’t properly playtested. Which brings me to…
Again, I ran out of time. Two things are pretty obvious now:
1. The player’s walking speed is far too slow. It probably needs to be about twice as fast.
2. The game is far too hard.
The first is a problem because it frustrates players, and means they give up as soon as they die. The second is more tricky to pin down.
Partly it’s because it’s an exploration/puzzle game, and so I obviously know the correct route through the dungeon. I find it really, really easy. But if you don’t know the route, it’s really, really hard. I should probably have made the dungeon more linear (or had a ‘starter’ dungeon). Also, I think being able to die was a bad idea. If you die you have to start the game from the beginning, but to compensate I gave the player lots of health and lots of places to heal themselves. I think instead I should have given them less health (maybe three hearts?), but made ‘dying’ just place them at the start of a room again, with full health.
So there we go. Overall I’m very happy with it, it’s by far the most polished LD game I’ve managed, with by far the most content. I’ll probably go back and tweek things, and add in the missing dungeon (assuming the judging result doesn’t say that everyone actually hated it).
If you’ve played the game, I’d love to know if you agree/disagree with anything above.
Hey I wanted to share the fact that I just finished my website! Please let me know what do you think of it! Also, I got this coooool domain name! I feel like a better man now
Special thanks to everyone who helped me with that on IRC!
I’ve got my game idea for the Mini-LD.
I’m interpreting the theme as follows:
- Getting it done is the most important thing
- The actual “theme” is less important
- It’s a Mini-LD, so the rules can be bent
- Therefore: It’s more important to get the thing done, so the actual “theme” can be neglected and it’s not too much of a big deal
That being said, my idea has very little if anything to do with the potential themes. I really love the idea, though, and want to make it happen.
The premise has a wide scope, though, and I’ll only be able to get a subset of it working during the Mini-LD. That’ll be a good push for me, though.
The game is about a fox that has to get eight elemental crystals (Fire, earth, water, air, and four others I’ll figure out) into their respective altar-type places to get the Forces of Nature back into balance before the World is Destroyed. The Mini-LD version will have the first crystal and a “To be continued…” at the end.
The game will be a Metroidvania where the player collects various skills. The Mini-LD version will have at least two of them.
Looking forward to this,
— Mr. Dude
S-Raid has been an interesting experience for me within Ludum Dare. It’s my second entry into these contests, and hopefully a fair bit better than my previous one. With the ongoing Finals and all kinds of extreme busy business I’ve been busying myself with, It’s been hard to keep track of things at times. I’m glad I’ve managed to make it though.
Got music, base code, and basic designs of levels all done within the first day. I felt relieved at this, since my first day consisted of a trip down to the Zoo, basically cutting the time in half.
The Formations seemed to have gone well for the most part, I managed to sneak a level in which was very reliant on good formation control to get through.
Oh god time. I had half of my first day spent in London, and the last day was also side-tracked by watching the Thor film. If I had this time, I would have managed to fix all the bugs I had for the game such as Sound Effect volumes, Bullets flying through Rangers without being destroyed and having Blasters and Shields for the main ship. Another thing I was hoping for was a definitively final final boss, with some metaphors, mumbo-jumbo, etc thrown into the mix, which got scrapped. Hopefully I can do this for a sequel of sorts if done.
-WHAT I’VE LEARNED-
Time management is a huge deal for these projects. Not only this, but also the fact that, a project needs to be reasonable to complete in a solo effort. Grandiose ideas might be fun for this stuff but some of the ideas I had didn’t make it through the drawing board simply because It would take too long to make it through.
Sleep is for wimps as well. Who needs it when you have Crunch-Time Deadlines?
Final thing I learnt from this experience is that finals and such are very important. Games are too. It’s a tough choice. ¬(‘_’)-
Till later, have fun folks~
Here’s the last push for a bit of attention to my LD submission, if you have a second and haven’t already done so, please check it out and toss me whatever rating you feel it’s worth.
This whole experience has been absolutely fantastic. Thanks and much love to the organizers and participants for making this such a great ride to be on!
Here I present the “edited and abridged for LD’ers” version of the post-mortem:
What Went Right
1. Leveraging the Power of Unity Prefabs
All of my past projects up to this one had been done almost exclusively in C#, with almost no special use of the Unity environment. They were done that way to help me come to grips with coding in C#.
For this LD, I threw that mentality out the window and crafted nearly everything in scene, using prefabs. What an amazing difference it makes! Defining game objects, exposing the variables on them, and using drag-and-drop to configure game play is really what Unity is all about, and I’m glad I had this LD to finally realize that.
2. Scripting Tight
Sort of a knock-on effect of switching over to prefabs, code bloat was immediately reduced to a negligible amount. With all the variables explicitly used and exposed on the game objects in scene, it was far easier to manage what was going on and limit the overall messiness of the scripting process. That’s not to say there’s no kludgy-hacky nonsense going on, but there’s far less than there was when I was in pure code mode.
3. Winning the Theme Roulette
This time I followed the theme selection very closely. I hadn’t before because I didn’t want to set my sights on any one theme before the final was announced, and avoid any kind of disappointment. This time I didn’t really fixate on a theme, but I had a very strong feeling that ‘It’s Dangerous…’ was going to be chosen. The night before the compo I dreamed a fully-formed concept for a game that used this theme, so you can imagine my relief when it turned out to be the one that made the cut. Lucky advantage.
What Went Wrong
1. Uneven Production Process
When tackling any long-term project, I tend to break things down into manageable chunks and then assign levels of ‘completeness required for play’ to them. This means there’s a round of building, and producing passable assets so that I can start to see if a game is going to be fun or not.
For Ludum Dare, though, it seems that one thing that makes games stand out and get recognized is the end quality levels of art. I’ve always envied these 2D wizards that can crank out beautiful pixels for their projects that really make them shine. So, I told myself I was going to push it to the limit with the 3D assets this time out. The problem was I focused so much on making the 3D nice that I had little time for audio and controls polish.
It’s always a trade off, a fine balance of managing just how much to produce in the time given.
2. Not Enough Kitties
Apparently this is also an important thing to producing a popular entry, and I’ll endeavor to add more cute meme-cats to my future entries.
3. Not Enough Zelda
Looking back at it now, I probably could have taken the time to insert at least a few nods to the venerable Nintendo classic, but I’m still happy with my interpretation of the theme and glad that it left enough leeway for all the other creative entries that weren’t strictly focused on emulating the Tri-force hunter in one way or another.
It’s really important to note that this LD sparked enough of a creative fire under my butt to finally abandon another project that I wasn’t really having much fun with and shift all of my production over to creating an improved version!
Thanks again and congrats to all that participated in this LD, I’m looking forward to seeing you all and more come the next one.
<click here for Dark Acre Jack’s entry>
I ported my Jam game over to Android !
However, many users have had crashes, etc… if any devs can give it a run and do an “adb logcat” and post the results here, that would be a huge help!
(The game is also available on iOS, PC, Mac, Linux too, if anyone cares to check it out!)
UPDATE: Android build is so broken I took it down.
Well, ok, it’s the updated version of my game, but all the levels in the original version are in there. (apart from the first, but if you need a walkthrough for that…) This is also proof the last level is possible.
Hey there, folks.
Over the past couple of days, I’ve been working on a boilerplate library.
I love FlashPunk, but it doesn’t do everything that I need. I need skeletal animation and more complex collision detection and response than FlashPunk can provide.
Therefore, I’ve taken it upon myself to write a boilerplate library of my own.
It will have skeletal animation, a proper entity hierarchy (FlashPunk has none, Flixel’s is purely organization), separating axis collision response (In addition to hitbox collisions, of course), a gui system, and other things that I will add as I need them.
I’m not 100% sure of the name for the library, but I’m leaning toward “SpudTech” because, well, it sounds funny and I like that in a library name.
That being said, you folks can expect me to use my library in further LD efforts. Probably including this month’s Mini-LD.
Peace, love, and buckets of cheese,
— Mr. Dude
My name is Jim Peterman, and I am a video game music composer studying at St. Olaf College. I’ve worked with zillix a couple of times on Ludum Dare projects, and am looking to write more. I can write in a variety of styles, and have a large number of sound resources with which to supply a game. I am used to writing under a time crunch, and generally write a piece of game music in two hours. Check out my portfolio:
I finally got around to making a little walkthrough of my LD20 entry. So if you had trouble running it or didn’t want to download it, or are just stumped by the staggeringly complexity of the puzzles, then check it out:
Also includes a quick looks at the “Sproxel” voxel editor I used to make the characters and tiles.
Will there be a post-compo version? We’ll see…
After recovering from LD20 I decided to spend this past week adding to how to be a girl in an attempt to make it feel more complete. So what did I do?
I added endings. Plural. Not that I expect anyone to put up with the game long enough to see them all (there’s three). I think the main thing I took away from the feedback I got, was the game lacked a sense of closure (it really did). I’m not sure if the endings I’ve added quite do the trick. I could probably do better. One of the endings in the game works pretty well for me, the others possibly less so. Who knows, I may come back to the game in a while and fix them up. Maybe not; they’ll quite possibly stay as they are.
I also added a couple more interruptions for a tiny bit more variety. This is a very minor addition since the interruptions are all functionally the same.
Perhaps the biggest addition, at least in terms of the amount of time it took me, is music. I spent most of the past week recording and editing. I’m quite happy with how the soundtrack turned out, so you download it here, or from the game’s website, if you want (you probably won’t like it). The download includes a couple tracks which did not find a place in the game. I would maybe have used them for a couple of the endings, except their length would have caused a fairly large increase to the game’s (file)size.
If anyone’s wondering, the only program I used in creating the music was Audacity, with a few plug-ins. The music is all thumb piano (played by me) and noise. For the most part all of the noises are recorded sounds that I applied various effects to (the only non-recorded noise is the buzzing crescendo shared by the two tracks that are not in the game).
Give it a play, if you wish, and leave some feedback, if you so desire.
updated on May 18th
thanks to Draknek who pointed me to this page which doesn’t require signing in and have more comprehensive stats. i have updated the script and now there is no need to provide a password. page fetching part was rewritten using only built-in ruby methods so mechanize gem isn’t needed as well.
some examples to demonstrate how it works:
get this script on github: https://gist.github.com/975928
With only a week left of voting time, I figured it’s high time I get around to writing a post mortem for my game, Elidia. Elidia is a game of survival, where your goal is to avoid the enemies for as long as possible. The theme came into play by certain weapons which help you to destroy the enemies.
What went right:
- Choosing an extremely simple concept. In the past, I have bitten off a bit more than I can chew in just 48 hours–I have always made something playable, but it hasn’t been for very long. Elidia is as complete as my original concept. Obviously it can use some refinement and expansion, but I am very happy with what I got done. All-in-all, the whole thing really took me about 16 hours of work.
- Having a game that doesn’t need a story. I’m a big fan of story-driven games, but they’re almost certainly too much work for a Ludum Dare. I opted to have a game which didn’t need a story to be played. That being said, I’d like to think that there is a bit of a story told through the narrative. Speaking of…
- Using audio. In the past, I have only really ever used SFXR or BFXR to make sound effects. I opted for a text-to-speech program this time around, since I thought it would work out better than generic “pew pew” sounds. I also figured I could work a bit of humor into the speech, since it doesn’t really fit anywhere else.
What went wrong:
- Not adding enough variation. There is only one type of enemy, but ideally there will be many more–each with something different about them. I will also add a lot more variation to the audio so it will be less repetitive.
- Figuring out the best graphical style. I wanted the game to be a lot like Geometry Wars, but didn’t want it to be a copy. While the game play is actually very different, the style is like a very simple version of Geometry Wars. I plan on coming up with a style which is unique to Elidia, while still keeping its influences.
- Not changing the size of the bounding boxes. This is easily the most hated part of Elidia. Each enemy is a triangle, but the bounding box is a square which encompasses the entire triangle–so you can still die even if you’re pretty far away. I knew this was an issue, but never got around to resolving it before the competition was over.
In the end, this is my most successful Ludum Dare yet. I managed to complete the game I set out to in the alotted time, and it seems to be getting good feedback. Obviously I don’t know how it’s doing vote-wise, but it’s still a big success to me. If you haven’t played it or rated it yet, what’re you waiting for?! Good luck to everyone in the competition! :)
Hello everyone, I’ve been meaning to write this, but with reports and project deadlines bearing down on me I kept putting it off.
This was my first time participating in Ludum Dare, the primary goal I had was to finish, and have a game that was at least partial fun. I finished on time, and I’m overall happy with my entry.
What went right:
- The Teleporter concept, worked overall I would have liked to have more complexity to it, and some sort of combination
- Construct, I was able to get the player movement and Teleporters function working within an hour. As well as having a platform to create level layout on visually.
- The tutorial level, it was the first level I created, and I think it did a good job explaining the concepts.
- Sound Effects, I think they worked good, but with the music in the game you could hardly hear them.
What went wrong:
-The art, (kinda sad seeing as I’m a Fine Art major) When I started with the tutorial level, I was thinking of a high contrast game (mostly Black and White) Then the next level I added more textures and it didn’t look right. It also went wrong with a photographed main character, then a drawn enemy (though in my defense I did add the photographed player at the last minute)
-The music, haha shouldn’t have even attempted it. I haven’t had much experience with LMMS (or music of any kind). The volume was way to loud, and the music looped wrong, in addition to just being a bad song.
-Construct, (yea it was both good and bad) I had troubles with the Minimap (although they are solved now and I should have been able to figure it out before). There is also a crash that stems from the minimap (I believe).
I’m working on an updated version of the game. I’ve already increased the starting speed of the devices, fixed the minimap. I’d like to add some player animations, powerups, more levels, and I’m going to change the overall look of the game back to a high contrast look. I’d also like to see about adding a scoring system.
You can play the compo version here
It’s been almost two weeks since the competition, and I figured I’ll write a bit about my experience in creating Dragon Island.
What went right:
- Graphics and tile engine: I am quite happy with how the graphics turned out, given the time limitation. Even more so, I am happy with my trusty tile engine which grows from LD to LD – this time I added “depth” sorting to allow for this “3d” look.
- Music: I really like how the music turned out to be – after writing it I though it reminds me of a part of “Dune 2″ music, but that was not intentional (although my sub-conscious probably is to blame…).
What went wrong:
- Gameplay: I am actually disappointed that my gameplay didn’t go as planned. It is full of bugs, and controls are iffy. This seems to be a common problem with my games, but this time it was the worst – I think next time I will need to prototype the game play MUCH MUCH earlier on in the competition, and make it work first. Pretty graphics and nice music doesn’t help when the gameplay is flawed – we are making GAMES here.
- Time management: I am not sure what happened this time, but I didn’t really manage my time well this time around – I got to the evening of Sunday with very few working elements, and needed to rush everything – usually I’m better at this.
- Theme: I didn’t like the theme, and I didn’t even know the reference for it (Zelda, and/or the Meme). Well, I work with what I get – but I don’t like the silly themes, so it would seem.
I think that’s about it – thanks every one for a great competition and be sure to play and vote as much as you can (I am very busy these days, I just hope to rate the assigned games at least…). Go play!
In the Beginning
Going into the competition I didn’t really have any direction. After hearing the theme and looking at the kitten meme and the Zelda text I figured I would start off with an elf kid going into a cave and receiving a kitten rather than a weapon, but other that that I had no idea for gameplay or anything. I knew for tools I would use CoffeeScript and the PixieEngine (I have been creating PixieEngine for exactly these kinds of competitions and wanted to put it to the test). If you’re looking to try out a new development environment for easy publication to the web I recommend checking it out. It’s free! It’s still a bit rough around the edges but with your feedback we can make it better.
It was quick to get the initial level and cave in but I wasn’t sure what direction to take the game. I spent several hours on animating the sprites, drawing the kitten from reference of the meme. Art isn’t my strongest suit but spending time on it gave me time to think and I definitely could feel myself improving. After sleeping on the theme the first night I knew that I didn’t want to just have the cat act as a weapon, because that would be pretty plain and boring. I decided that it would be cool if you had to take the cat around to different dungeons and work together to solve puzzles. I had the idea to make the water impassible for the kitten around this time so that the player and kitten would need to work together to access different areas. I also spent some time getting the mew to sound right in SFXR.
I really wanted to focus on the emotional attachment to the kitten and to make it feel like you were helping each other. It is for this reason that the initial cave the kitten goes into narrows symbolizing a feeling of cramped/claustrophobic danger. This culminates when the kitten becomes trapped in a waterfall and the player is required to submit to entering the water and becoming helpless. Then when the kitten floats back out down the stream the player is given control of the elf character and must rescue the helpless kitten. The relevant psychology is that we develop good feelings towards those who we do favors for (similar to Portal’s Weighted Companion Cube). These locations, actions, and even the sound of the mew, were all designed towards the goal of creating an emotional bond.
The bombs were an ok addition, but didn’t have very much depth. It seemed like near the end of the game (especially at the ending) there was plenty of room to create a wide variety of levels and puzzles, but I had just solidified the core mechanic and core emotional experiences and the clock was still ticking down.
My brother was in town and late Saturday or early Sunday, in the course of viewing the game he came up with the idea for the ending. I spent several hours Sunday grossly copy/pasting and hacking the functionality in. This cost me a bit in terms of level design. An additional cost of adding screens was due to some excessive manual steps (like hand coding doors). In the end there were maybe 1.5 dungeons and 1.5 puzzles, but people really enjoyed the ending so I think it was a decent trade-off. As the level editor and game object tools improve it should become easier to add more levels with fewer manual steps.
All in all it went pretty well. I didn’t stay up too late or stress out much, but the time limitations were significant. Next time I should make a stronger effort to discover a fun core mechanic sooner to leave more time for level design. The risk of this is that I may lock down the mechanic too soon, before it is actually fun, but I think that’s the main conflict throughout game design.
The pixel editor, level editor, and sound editor integration in PixieEngine really helped me get a playable prototype up quickly. I was able to get a guy on the screen and moving around in minutes.
The API for many of the core components was simple to use. If I wanted to play a sound I would create it in the embedded SFXR, then call it by adding
Sound.play("mew") at the appropriate place in the code. Similarly for loading sprites.
The engine Object Query Language was great for hacking together quick functionality
engine.find "Cat" all came in handy.
Experience with CoffeeScript and the PixieEngine system was also a big plus. I knew what the strengths and weaknesses of the system were and was familiar with the workarounds (like using git integration to copy files to get around the missing “Save As” feature).
Publishing to the web was immediate and 100% hassle free because the entire engine is online to begin with. I didn’t have to spend anytime thinking about packaging or distribution.
I actually got to make a serious attempt at sprite animation, and some of the two-frame walk cycles actually look decent. Also the things I was drawing basically looked like the things they were supposed to. Still room to improve immensely but so far a personal best.
As a home grown engine there were many parts that were still rough around the edges. The tilemaps and game engine had no built in concept of rooms, persistent entities, and transferring state from one room to another, so I had to just hack it in.
The file management was similarly rough: there was no “Save As” (though there is now because it was my #1 issue)
Our animation/model system isn’t as integrated as the sounds/images/tilemaps so I had to hack together my two-frame walk animations by hand.
Still don’t have an integrated music editor. I was able to do all the art and (most) sound effects from within the editor suite, but had no option for music. I really want to make some sort of online Mario Paint Composer style editor, but realize that it would be a pretty big project in its own right.
The lack of a shared “object toolbox” of all the classes of objects was a pretty big negative. This meant that for each screen I had to recreate the tiles by dragging them in, and manually setting their class and data properties. This especially sucked for doors where I needed to hand type the
destinationPosition. The good news is that this is the next feature on our list and once it is fixed things are looking great!
Because I coded in PixieEngine, everyone is free to view the source, fork the game, make alternate levels, and more. (Though the engine is not quite “easy to use”. Your feedback is greatly appreciated!).
Though I wasn’t able to get in all the levels and puzzles I had hoped for this was still a personal best LD for me. I have had a great experience this LD and am looking forward to the ones to come. Additionally, all the feedback was helpful and it was nice to see that people enjoyed the game. If you haven’t yet, please play through and let me know what you think!