Posts Tagged ‘SuccessStory’
My goal for the October Challenge was to successfully Kickstart my game Another Castle. Well, it took a bit longer than expected, but it just reached it’s $12,000 goal on Kickstarter!
I’m glad I took more time to work on my pitch, as I was able to make the prototype much nicer, and I even got approved as a Nintendo developer so the game’s coming to the Wii U! I know Kickstarting a game isn’t quite making a full game for the challenge, but I’ve been wanting to work on a much more ambitious project, and Kickstarter has been a fantastic way to give me the freedom to do so. The Kickstarter’s still going on for about a week, so check it out!
Back in October 2012 I had the bold idea of taking part in Ludum Dare’s October Challenge. Having done game engine and game development projects in the past I knew what kind of huge challenge this was going to be. Nonetheless I still knew I wanted to do it.
Already being in a game idea research phase, after having completed the circle of my last game Pop Corny, I comforted myself by thinking that this was a cool way to take one of the many ideas in my head and really try it out. The worst thing that could happen was to add one more idea to the “crappy game ideas bin”.
What I had was a game idea and a custom game engine. I arranged a meeting with his majesty Thanasis Lightbridge (the mastermind behind the Dol Ammad and Dol Theeta bands), and convinced him to take on the graphics, music and sound design of the game. How little he knew of the horror and torture I was going to put him through for the next 30 days!
With no time to lose I described the idea of a sandbox type game, where you can freely combine simple gadgets to create elaborate flying machines. Before the day was over and through a crazy brainstorming session we were able to find a theme to dress this concept, and that was how Mr. Herbie, the male ladybug, was born. We were going to make a game for a lazy, chubby, ladybug that is too bored to fly with its own wings. Perfect…
Having high standards and only one month is never a good combination when making a game. What most people don’t understand is that games are not created in a linear fashion. You don’t start with an exact game design in your mind, you write it down, split it up in tasks, make a list, start checking out entries on it, and when all are checked publish your game. Game designing is more of a tree building that a list building. You start with an idea and from there you have a number of separate ways to go on. Each one of these ideas then give you more ways. So this way you build a huge tree with branches about every aspect of how the game can be. If we had infinite time, it would be possible to go down every single different path in that tree and actually find the game that works best for us. That is never the case in the real world, and definitely not the case when you only have one month to do it. It is obvious that the key to success in such cases is having a good “greedy algorithm” (as it is called in computer science) that will decide early which way down the tree is not worth going -and be mostly right about it so you don’t miss the next big thing in games-, and being quick to iterate implementing ideas. This is important since you will have to go down to branches only to find out that it will not work. You should be able to quickly backup and try another branch. Yes, the games you play are what is left after you distill all the ideas that don’t work.
That was exactly what I did. I chopped ideas as early on as possible. When an idea seemed worth trying out, I did a quick prototype of and tuned it until it was good enough. If it felt wrong it was dropped and I back tracked to other ideas. The chopping of ideas is mostly a craft and I can’t really tell you how its done. Its mostly about experience that is gained the hard way. The quick iterations on the other hand are a combination of discipline and having the right tools.
Discipline is about being able to focus on what you really want make, not being distracted and being ready to dispose hard work when things don’t turn out as fun as intended. And that is harder that it seems, because as humans we have a tendency of thinking better of things we worked for. It takes great discipline to also cut the feature you think is uber awesome but you probably can’t make it in time and you will have to cut down other features of the game, resulting in a grand total that is less of what it would be without the uber awesome feature.
Having the right tools is greatly important. How can you quickly iterate when your processes take hours? You need to find ways to make iterations as efficient as possible. I live in a different city that Thanasis, so what would happen if every change had to be transmitted by email? You easily solve that with dropbox for example. But we can do better than that. For example I had build a system that was constantly deploying (incrementally) the game through dropbox to any number of computers. The game engine also supported hot loading of game assets and scripts. I could actually press save on the script editor and the change was effective immediately on all testing devices running… anywhere in the world. Action games require a lot of “tuning” to achieve the maximum fun effect, and doing it through a build-run-test cycle is not going to work. You will either not tune it, or it will take you enormous amounts of time. Both bad.
Doing this really allowed to save time for the artwork to get prepared and to try out lots of things. It wasn’t until the last 10 days that the game was exactly as I wanted it to be for a months project. All the fun parts of creating your flying machines and crashing them to the ground was there. In the last 10 days we had all the stuff around that made. The leaderboards, the settings, the menus, the gameover screens, item unlocking and progression, etc. Artwork finalization also took place during that period, along with the final sound effects.
The final weekend to the release was crazy. I probably slept for 2-3 hours, fixing the final bugs and glitches. It was then that I had to cut one of what I considered a major feature of the game. The flight replay. It was a long shot because determinism is a delicate thing, and requires paying a lot of attention while developing the system, which was clearly not an option during one month. The system was not 100% correct at that point, and I had to cut it during that phase. It was stressful. Lots of work had gone into it and I had to cut it. Thankfully not completely as I was going to revisit it after the original release when there was time. So I did and now flight replay is supported and you can even share replays with friends.
The development was done on a BlackBerry PlayBook at the time, as I needed a very stable platform. I knew I didn’t have the luxury of trying out different screen resolutions etc. The PlayBook was ideal as it was a very specific system with an app store and many users willing to buy a good game. Don’t forget that the October Challenge requires that you make a buck out of your game!
Also during that last days I prepared the ground for the coming of FlyCraft. I setup a website announcing the release and setup a mailing list for those interested. I created a teaser video and made a post about it on Ludum Dare website. People seemed intrigued…
The game was submitted for review and got available on the BlackBerry World on October 30th, where it sold about 700 copies at $1.99 that single day. Users really loved it, and 5 star reviews were hitting the store constantly. The game being a BlackBerry exclusive also got the attention of BlackBerry oriented press that covered the event as something extraordinary, bringing in more traffic and sales. It even managed to be voted “Best new game” in Crackberry’s Readers Choice Awards for 2012. The October Challenge 2012 was a success for FlyCraft! But things didn’t stop there, as fate had more for Herbie. FlyCraft was mentioned in BlackBerry’s Developer Conference in Amsterdam during the keynote. I think that this was the biggest highlight of FlyCraft’s path. Alec Saunders in the keynote stood up in front of a huge video wall with FlyCraft on it and he talked about the game and the story behind it. I honestly don’t know how I am going to top that in the future!
Looking back at the challenge and the events that followed, I often try to fully grasp the benefits of this competition. I now believe that learning to self constrain yourself is one of the major powers you can harness for getting better and achieving your goals. Ludum Dare teaches you exactly that. I really believe that without the mental goal of the challenge FlyCraft would have taken longer to complete (if ever) and it would be a lesser game. Big part of FlyCraft’s excellence comes from its simplicity and focused execution. That would surely be missing without the challenge.
[This post was also posted on my blog here]
The title pretty much says it all. I’m very excited about this, more so than I can convey in a post like this!
I finished up Mr Wizard for my January #1GAM game, releasing with 3 difficulty levels and an endless mode. Please, check it out here: http://www.indievania.com/games/mr-wizard-vs-world
It’s pay-what-you-want ($1 minimum). If you can’t afford it, or just aren’t interested in that type of game, please just spread the word! I’d really appreciate anything: tweets, reviews, complaints, anything.
Thank you for taking time to read this. Long live the Ludum Dare community!
Today I released MidBoss (v0.5 beta), because stuff might still change and/or break) as a feature complete game. It’s an overhauled, rebalanced version of my LD25 game, and my January entry for One Game a Month.
MidBoss is a game about possessing your defeated enemies in order to become stronger. You play the weakest of the dungeon denizens, an imp with no ability other than possessing other creatures. Your goal is to defeat and possess increasingly stronger creatures, unlocking their abilities for yourself and becoming stronger as you go along, and eventually defeat and become the dungeon’s ultimate endboss.
Features now include:
- Possess your enemy and gain their strengths and skills
- Dynamic music system with more frenetic music to accompany action
- Line of sight and fog of war systems
- A total of 15 monsters to defeat and 10 skills to unlock
- Randomly generated dungeon floors
- Single-file save and resume
- Permanent death, if you die your save is gone (save-scumming is available)
- Full options menu including key rebinding
It’s here! After a lot of hard work, I’ve turned my Ludum Dare 25 entry into January’s One Game A Month, and released it for sale!
Check out the page on my blog here for more information, as well as a link to purchase it. Among other new features is an endless mode in which, quite fittingly, you must defeat heroes endlessly until you are defeated. Go for a new record!
I have two codes, each for 33% off!
As this was my first Ludum Dare, I only had two goals: to finish a game, and to make sure I was able to sleep both nights.
I met both goals (yay), but I was truly blown away by the judging results: my humble game placed 7th overall, and highly in other categories, too. Thanks to everyone who rated my game, and kudos to everyone else who submitted one! It was really great to meet a few of you on IRC.
What Went Well
- I finished! It may seem obvious, but this is really the primary challenge of any game jam. The beauty of the 48-hour format is that it forces me to lower my expectations — in a good way.
- Development strategy. My goal was to budget the first 50% of the time to getting the game fully playable (feature complete), then spend the rest of the time on polish (graphics, sound, tweaking gameplay, etc.). Although I fell slightly behind schedule, having a plan made it much easier to get a full night’s sleep both nights, knowing that a playable, submittable game was within reach.
- Simple gameplay. Although the theme inspired a lot of ambitious, complex ideas, I chose the simplest one that I felt would make a fun game. In fact, I initially wanted to make a one-button game, but I added steering once I decided to do a driving game. It was easy to prototype and tweak because it was so simple.
- Graphics. At first, I struggled to get a look that I liked. Luckily, things eventually felt right and the graphics came together rather quickly.
- Audio. I had trouble figuring out how to synthesize a convincing engine sound. At the last second, I managed to create decent loops from an actual recording of a Ferrari F355.
- Testing. I played the game a lot during development. Not only did this help me iron out some bugs and refine the gameplay, it helped reassure me that there was actually some replay value to the game.
- The community. On the evening of the deadline, the IRC channel was full of other participants who were eager to play each others’ games. It was a very friendly, constructive atmosphere.
What To Improve
- Make sure the game includes instructions. I planned to create a title/instruction screen as part of the polish phase, but I ran out of time. It really should’ve been included with the “core” game functionality. That way, it won’t be missing if (that is, when) I run out of time.
- Ask others to test — early and often. Although the importance of instructions seems obvious in hindsight, I totally overlooked it because I was so focused on other details. If I had asked others to playtest the game before it was ready for submission, I would’ve realized it sooner.
- Stick to familiar tech. I started out with Flixel, which I had only toyed prior to the competition, and quickly found myself frustrated and unproductive. I wasted several hours before starting over from scratch with Love2D.
- Build a web version. It’s hard to overstate the value of instant gratification. Games that are playable in the browser are much more likely to be played than other ones, which is why I initially wanted to use Flixel. I did try the Love2D WebPlayer, but there were just too many unsupported features and little issues.
- Keep my weekend clear. Easier said than done, of course.
I was stunned to see that how well my game scored out of all 1,327 games (wow!). It was rated 7th best overall, 9th best in fun, and 17th best in graphics!
Of course, positive feedback is always nice, but the real reward is finally participating in Ludum Dare after procrastinating for so long. Up to the last minute, I couldn’t decide whether I was going to join in or not — but I’m so glad that I did.
I’m definitely hooked now … see you all next time!
Hello everyone! I am here today to share with you a game that was born here, in the Ludum Dare, as a warmup game, and now I completed it as a fully playable game with everything a real game needs; Achievements, story, infinite mode, unlockable weapons, highscores, etcetera, etcetera!
The original game, formerly ‘Earth Defenders’ was a crappy minigame I made as a warmup for my first Ludum Dare, under an interesting mechanic: A 360º Space invaders twisted clone. at the moment with my little game design skills and motivation it ended up being fun, but not fun nough, and definately not as pleasant!
So, three months ago and three years after that initial minigame I decided to completely remake it from scratch, I dumped every bit of that old minigame and started writing this new, enhanced version of it, with High definition graphics, a touch-screen friendly interface, and cross-platform. The result was Earth Defenders HD, and it is now complete
You can obviously play it on Google Play for free here:
Enjoy it and dont forget to share it with your friends, thanks everyone!
This is the postmortem for my game Trina of the Depths ( play it! ).
::: Development Notes :::
I worked alone on this one, because I couldn’t find a coder to partner with.
It’s the first game I ever made myself. I’m an illustrator by trade, and have never been (and probably will never be) a hardcore coder.
It was very hard work, since Saturday morning through Monday evening, I slept about 10 hours total.
I used Construct 2, FL studio, Photoshop and Flash.
About the theme: I couldn’t top my last LD submission, which was about an evil dungeon lord trying to destroy a hero, using traps. So I thought I’d go with my second idea, controlling an evil octopus. So this whole RPG/metroidvania idea developed in my head, about Trina, daughter of the evil Sea King and the secret of her birthright. And it really worked for me, to the point that I’m going to make it an actual game.
:::How I spent the time:::
I really wanted a control scheme that captured the feel of an octopus slicing through water. Therefore I spent some 8 hours developing the control scheme.
Trina, the heroine, is controlled via cursor keys, in a unique way. Pressing a direction doesn’t move Trina, instead it charges her corresponding vector, horizontal, vertical or both. Movement occurs after the release of the cursor key(s), and the muscle meter on the bottom left is accordingly drained by the effort.
Since Trina seemed to be falling too fast (she is in the sea, and this just wouldn’t do), I also implemented some resistance to gravity, not in the form of passive Lift, but in the form of a last strain of her muscles/parachute action. For 30msecs after finishing her ‘jump’, trina will try to stay afloat, giving the muscle meter time to recharge.
This simulates a movement that requires judgement and thinking-ahead, like an octopus might plan. After you’ve made your mind about your target, you jump towards it. The result is a very exact, very elegant control scheme, that most players so far hated?? Wait, what? More on that later.
When I was satisfied with the control scheme, I added an enemy, a cute fish, which naturally hurts (and annoys) evil Trina. I struggled with its behavior, AI and patrolling patterns, and in the end managed to only get one to spawn…
Music-writing sessions were interspersed throughout Days 2 and 3, to ensure maximum inspiration, and time to go back and re-do things. I ended up with three themes, a main tune, an encounter scherzo and a battle theme , using old soundfonts and a sampled gameboy Bass sound.
Day 3 was about damage control (since I hadn’t succeeded in properly implementing enemies) and level design. I also made rapidly prototyped level blocks. For this I took one giant background and start painting directly on it, taking care that assets do not overlap, so I can lasso them and export them later. This way I work super-fast without overthinking everything, I have a good idea of what my assets will look like when overlaid on the game background, and I don’t have to worry about layers and CPU performance at all. It’s the technique I’ve used since my first LD#23 and I wholly recommend it.
Here’s a screenshot of my almost final assets file:
And what my final stage looks like:
:::What went right:::
- my first ever solo game!
- the control scheme: having extensively playtested the game, I find that Trina moves in a much more refined, much more interesting way than if I had used plain 8 direction movement or mouseclick-to-move. After getting the first power-up, Trina controls like a charm, cutting through water like the evil princess she is.
- animation/character design. It’s as fluid as I envisioned. Like all animators, I was mimicking an octopus in the mirror the whole time.
- the music: I thoroughly enjoyed taking a soundfont of women singing “ooohs” and another of women singing “aaahs” and writing parts for them to sing, so that they sound like one chorus that sings both. I loved the battle theme, which I injected a sample of a rhino snorting into. I think it makes the mood more intense.
- the backstory and foundations for expanding this into a proper game. I couldn’t help daydreaming and scribbling notes about how I want the game to be, after LD is over
:::What went wrong:::
- the control scheme! From what I see in my comments section, many people don’t get it at all, can’t maneuver, and/or believe gravity to be too harsh. In my opinion, it may actually be too lenient; it’s a platformer, and you can (with some effort) ‘fly’ to wherever you want to. How is this harsh? Ok, it’s not Owlboy, but it’s not supposed to be. That having been said, I’ve been convinced that up-front giving Trina the powerup that nobody bothers to get will do its part in coaxing new players into playing, and is a good game design move.
- coding. I’m not a coder, and even though the Construct 2 forums are full of good FAQ and solutions (thank you, community!) , I seriously messed up the code that spawns new enemies, and even though I finally managed to pinpoint the cause, this left my game with only one enemy
- time: because of my coding set-backs, I didn’t implement the larger level I had in mind, the metroidvania “get the item and go back to unlock a new area” portion of the game, and the boss battle. I decided to make it as fun to play as possible with the assets at my disposal.
- backstory/dialogues. It’s not apparent why Trina is a villain. She hates all people (fish) in this part of the world, where she was brought unwillingly, and will scheme and plot against Good King Triton. All this is lost, since I didn’t want to cheapen the mood by inserting plain text using a plain font (Construct 2 doesn’t support embedding, and using webfonts was a big risk)
And that was my entry. I hope you enjoyed it
So! I, like the thousand-odd other people who’ve slid their games under the door at the last moment, just participated in Ludum Dare. No kidding! It’s not like I’d be writing a post on this site for any other reason! But it’s still true. This was my first Ludum Dare, but not my first GameJam in general. I’ve been doing them all year, so I’m pretty gosh-darned familiar with the whole idea of making a game in 48 hours.
Not so familiar with the whole idea of do it all yourself, though! I’ve had artists, musicians, and sometimes other programmers, working with me on every GameJam I’ve done so far. So…this time was a little nerve-wracking! Combine that with the fact that I was out at a family get together for the first six or so hours of LD, and I was feeling pretty friggin nervous when I started!
But it all came together in the end
I did it! My first LD entry has been submitted. It is a game in which you try to win, but not by too much. As an Evil Overlord, you don’t want the Hero to ruin your plans, but you don’t want him to die either, because that would spoil the fun! More on the submission page.
That was most intense coding I remember ever having done. Towards the end I had to start heavily cutting corners. There are so many global variables and redundant checks, and so much duplicated code that I don’t ever want to look at the code again
I had some time to spare but was too exhausted to start implementing anything – testing my game is pretty tedious. So there’s no sound, no starting screen, and most placeholder art is better than what you see in the game. Still, I completed what I set out to do – to create a game with many AI controlled agents and player only having global control over their behavior.
I feel I was very lucky with the theme, planning the game took only about 15 minutes. And I even managed to include a goat!
If he didn’t have a cute (but deadly) pet goat, he wouldn’t be an Evil Overlord. On the left, you can see Igor and Dmitri, trusted associates of the Evil Overlord.
The game is controlled by giving orders to your minions by choosing one of three available random choices. There are three levels, at the end of each level there are special choices.
See you in next LD!
The Charity Game Jam was a huge success. Our initial fundraising goal was $250 and as you can see, we destroyed it! Mission accomplished. Achievement unlocked. Boss battle won. Princess saved. THANK YOU VERY MUCH, EVERYONE! I’m humbled and grateful for all your enthusiasm, hard work, and generosity. Should we do this again next year?
Play The Games Here! | Keynote Video | Announcement Post
22 days into October challenge, and here is an update on the current version of Vox. Version v0.19 has just been released on Desura and IndieDB, so I thought I would share a post on here to list some of the new features and updates to Vox.
Here are the newest features:
- More Enemies in the world.
- Flying enemies.
- Skeleton archers shoot you from a distance.
- Skelebobs chase you and try to kill your with their deadly swords.
- King Slime boss spawns when you kill too many of his little slime buddies.
- Interactable NPCs.
- NPC movement behaviours – waypoints, world navigation and player follow.
- Questing system.
- Treasure chests.
- Particle editor in the game.
- Particle effects can be added to character parts. i.e head, body, feet, etc.
- particle effects can be added to created weapons and items.
- Undo feature added to creation mode.
- Much better character creation screen in front-end menu.
- Ore deposits that can be mined for ore.
- Collectable items (hearts, coins, ore).
- Damage text popups.
- Improved HUD graphics.
- Experience bar and leveling up.
- Gradient background and better sky rendering.
- Better intro animation.
- New custom frontend music and game music.
- Smoother mouse controls.
- X360 gamepad support.
Here are some recent videos demonstrating new gameplay:
There is a free version to download and test and I would really appreciate it if people would be willing to try this and maybe provide some feedback. As always I am really curious to hear peoples opinions and suggestions. I really like player feedback and love to hear what people’s opinions are (Unless of course they are just the 500th person to state that Vox looks similar to Minecraft or CW ).
So after just over two years of development, a beta of my continued expansion of one of my LD entries from nearly three years ago was finally released for sale (buy now, get it cheaper and updates and a copy when it’s done) It’s been such a long time! Here’s a few screenshots from the game:
And some video:
It’s been a long process, with a bunch of stuff detailed in my blog (http://magicbane.tumblr.com/) and I’ll be happy when the game is completed and I have all the experiences associated with developing and releasing my own game
That, and the fact TWL has been in development since the first October Challenge, I guess third time really is the charm
If you want to purchase the preview, you can get it via my Sellbox link!
I can’t believe that in the first LD, and the second game I’ve ever written I managed to make it into the top 10 for a category! Not only any category but theme, from the looks of things it is an area that a majority of people work very hard to make a game that fits the theme. I was also please my result of 100th for innovation and for other areas it was what I expected around the 200 mark (there were 400 entries into the jam so they were very average scores) .
I’ve had a fantastic time, learning a new language, object orientation and how to quickly generate an achievable if ambitious goal. I am very please with the community and the mature approach to constructive criticism. I’ve had great fun playing, rating and reviewing games (I made sure to comment on each and every rating I made).
I’ve learnt a lot, pleased to have actually taken part at last, even more pleased by my results. I’ll see you all in December!
Rusty Moyher here. I’ve participated before in Ludum Dare, but Super Clew Land is my first experience entering the Jam or working with Shaun Inman and Matt Grimm. After this roller coaster weekend, I know I’ll be doing both again.
A week before Ludum Dare, I asked Shaun if he wanted to make a Jam game. He was interested, but concerned how we’d break up responsibilities. Shaun and I are do-it-all guys, so we didn’t know of a good way to split the work. We decided to sleep on it. (Which actually meant not making a decision until the last minute.)
We met up on Skype an hour before the jam to finalize plans and workflow. Before splitting responsibilities we’d wait to hear the theme. Shaun had worked with Matt before and we sent him a Twitter DM in hopes he’d join us.
At 9pm EST we received the theme: Evolution. We came up with a dozen bizarre ideas including a colored vine puzzle game that the player would grow through to proceed. After four hours of brainstorming both of us were wearing thin. We almost slept on it (again), but finally chose the idea we’d spent the most time fleshing out: an evolving Metroidvanian puzzle double-game.
Imagine a split-screen or Nintendo DS double view. Players would encounter a platforming world above and unlock new abilities in a top-down gene sorting game below. Even as we shrunk the gene sorting into a HUD minigame, the idea seemed ambitious for 72 hours.
To make the creation manageable, we made a last minute framework switch. Shaun and I were both eager to try out Futile, a new 2D Unity framework. But the scope of our idea required tile map support. Rather than trying to roll our own for Futile, we chose a framework more familiar: Flixel.
We also (finally) decided on the responsibility split. Shaun would design and I would develop, but we’d switch things up as needed. We heard back from Matt too. He would do music and sound. 8-bit Voltron was formed.
I woke up to find over a dozen animations in our shared Dropbox folder.
Hizzah! Clew was real.
I started building the “Protein Puck” minigame as Shaun drew food and enemies. Shaun and I communicated almost entirely through FaceTime on our iPads. (He found it useful during a previous collaboration.) This made it easy to bounce new ideas around while working. By using our iPads as dedicated video devices, we never had to manage a floating iChat window. It was so helpful we left the stream open throughout the entire jam.
By the end of the day we had most of the character animations done, a pretty-much-working minigame and an fun retro soundtrack from Matt.
All three of us live in different timeszones, but by the second day this seemed like a plus:
Working with a dev in another timezone is awesome. Go to bed with an idea, wake up to a working implementation. Could get used to this.
As Shaun finished up animations and wrote the Flixel animation timing, I started implementing the player, food and enemies. Halfway through the day Shaun switched to code and implemented autotiling to make world building faster. About this time I started adding Matt’s sound effects.
When the autotiling was ready, Shaun started building the world in Tiled. The pieces were coming together, but a mountain of polish remained. As the day grew long we came to an unspoken understanding: there would be no sleep tonight.
Day 3 (I think)
While the sun rose, I squeezed in a few good playtest sessions. Shaun programmed the enemy pathing behavior and then kicked level design into high gear. Matt had to leave for his day job, but was able to write a few final sound effects in his off hours.
Nearing the end of the Jam, we we’re all exhausted. At some point I took a shower to try to clear my head. Picking the game’s name took near an hour, but this was mainly due to our exhaustion. In the last thirty minutes we added a title, an ending, and Matt’s final piece of music. And….submit!
Working with Shaun and Matt was a blast. Each Ludum Dare I’ve participated in has been more rewarding than the last. I’m not sure I can stop now.
We’re all pretty happy with what we pulled off in three days. If you haven’t checked out Super Clew Land yet, what are you waiting for? Go play it now!
Play it HERE!
Zeik here, the code half of Cake&Code. This being our second Ludum Dare I had a vague idea of the kind of stuff we’d run into and knew that time was going to be unforgiving yet again. This time we did not do a warm-up game but I was messing around in flash days in advance to get back into fighting spirit!
What went right:
- I knew I was going to use Flash and had FlashDevelop all ready to go with a vanilla copy of FlashPunk at hand
- This time around I downloaded Chronolapse and it worked flawlessly to document the days
- We knew that we wanted some more unique music so we had a library of tools available before starting the jam this time
- Despite having work on Monday, we managed to finish at around 5:30am that morning
- Within the first hour or two we had a vision for a game, that vision became AvRvE
- Creating the isometric engine was not as difficult as it might have been, everything seemed to fall into place as I wrote it and extending it was easy enough
What went wrong:
- Though we learned last time that sounds take a lot of time to find/make/integrate we still ran out of time to find well-suited sounds to fill in the gaps in the game
- No tutorial level meant that the levels themselves had to ease players into the gameplay, this turned out to be a bigger challenge than I expected
- The preloader turned out to be a huge problem until I realized that by assigning a value to one of my main class’s static variables from inside the preloader code I was forcing the load of all the assets before the preloader could display, after removing that assignment everything worked flawlessly
- Feature creep, as always, seemed to come from every direction; I built an overly robust level loading system, an interaction halting animation scheme, and was even planning on adding more items
What I learned:
- Sounds still take us forever to do, there have been no revolutionary advances since LD23
- Music is fun to edit, but takes forever just like sound editing does
- A weekend game jam is not the time to implement every feature that comes to mind
- Layering sprites for proper render order is not something to procrastinate on, get it done right and get it done as early as possible
Finally, I just wanted to extend a congratulations to all the participants! We’ve been rating your games and even though we’ve only scratched the surface it’s already been a wild ride, full of great experiences. Pat yourselves on the back, then give each other high-fives! Hope to see you all next LD.
Wow, FINALLY Zeik and I have the time to sit down and write our post-mortems. To be honest, it’s been a crazy whirlwind of activity for me since LD#24 wrapped up, so neither of us have had the time to really sit down and work out our thoughts on AvRvE. Well now that I had a little more time to mull about it, I think it’s about time I crunched out these thoughts!
What Went Right?
- I struggled to find the right art direction for this game. The initial mockups for the game looked a lot like Pow! Pow! Pow! until I decided to just go all out dark. It was colorful and had great visual impact, just as I intended it to.
- I’m a designer by nature, not a digital artist. This time around I actually had to sit down and draw all of our species out, as well as our character from different perspectives. For someone who typically doesnt do digital illustrations, I think I did alright.
- Having the multiple endings was fun! And I’m glad we went with a puzzle route this time around.
- I ate a lot better this weekend than I did the first LD we did. Granted, it still wasn’t GOOD, but I went out of my way to actually prepare food more often than not. I snacked a bit much though.
What Went Wrong?
- I had company over for a chunk of the weekend. It really decreased my producitivity and I found myself having to multitask working, communicating with Zeik, and keeping my friend occupied.
- Despite the fact I’m really happy with out the game’s aesthetic and look came out, I feel like it lacked the kind of detailing that Pow! Pow! Pow! had.
- Level designing was something I was already not great at. But designing puzzle levels? Yeesh. :\ Zeik took a hold of it for the most part.
- SCHOOL!!! Ludum Dare happened on the weekend right after school started. Seems like it’d be an easy workload right? NOPE. Grad school is kicking me in the butt and threw a lot of work my way. So I was even more busy that weekend than I wanted to be.
Things I Learned for the next LD:
- FREE UP MY WEEKEND. Make sure I don’t have any work in the way and that I don’t have any unexpected guests.
- Get BETTER food. I ate well this time, but there was a lot more room for healthier and energy-packed snacks. Also…less coffee plz.
- Do more art research and experiment with styles. I don’t want to look like a one-tricky pony, so I’m going to experiment with more in-depth illustration styles.
And of course, congrats to those that finished!
Introduction and special thanks
This was my first LD, and I came here fully expecting to faceplant from over-ambition or poor time management. But I submitted my puzzle game, ‘Additive’, polished and complete with hours to spare. It’s the first complete game I’ve ever done, and it’s gotten more positive feedback than I had dared to dream, and the process of making it shoulder-to-shoulder with all you other fine people (especially on IRC) was awesome.
Before I start the post-mortem, I want to thank ‘Cake’ from IRC for giving me a quick pep talk around six hours into the compo, when I was feeling particularly unprepared. I also want to thank all of the IRCers who complained that my first release candidate was too cryptic, and especially ‘Tau’, who played through the entire thing and deliberately found ways to break it. My game would be half of what it is without such playtesting. On with the post-mortem!
Part 1: The pre-feedback post-mortem
This is actually the second post-mortem I’ve written for Additive. The first one, written immediately after submission and before voting opened, can be found here. Its salient points are:
What went great
- I knew my strengths and weaknesses at the start of the competition, and this guided me towards reasonable ideas and goals.
- Making a puzzle game was a great decision because the very nature of a puzzle game works against feature creep.
- I used a notebook to organise myself and work through problems.
- I set some time aside to brainstorm ideas.
- I developed a quick way to make levels, which was more efficient and accessible than building the game board in Unity’s editor.
- I avoided crashes by limiting sugar and caffeine intake.
What went poorly
- It was very difficult to design puzzles.
- The game is not colorblind-friendly because I had a hard time letting go of the aesthetic I had developed. This is not the kind of developer I want to be!
- I didn’t have enough time to deepen the game’s mechanics.
Part 2: The post-feedback post-mortem
More things that went great
- I decided on a feature lock after the first day. By the end of the first day I had a working game. The second day was dedicated solely to polish and level creation: no gameplay changes allowed.
- I did early testing. Sticking the game up on my Facebook delivered exactly zero constructive criticism. Posting the game on IRC for fellow devs to play got me immediate blow-by-blow feedback, and my time budgeting on Day 2 allowed me to work on every single one of the issues that were raised.
- I put a lot of effort into visual player feedback. I changed the buttons on the main menu at the last minute to make them look more buttony and clickable. There’s a nice marker to indicate the selected block. The marker and the selected block pulse with color. Blocks animate towards their new positions instead of just teleporting over.
- I spent even more time on aural feedback. When you click on a block, it makes a sound. Deselecting a block makes a different sound. You get a different sound again when you try to make an invalid move. When blocks combine, the sound they make depends on the outcome. Sound makes a game feel alive and reactive. Skimp on graphics before you skimp on sound.
- I think I picked a fairly cohesive style. The game is an exercise in minimalism (like I said in Part 1, I knew I was bad at art). Its presentation was informed by the effect of parenting a spotlight to the camera and tilting the camera 45° towards a plane. I felt that an understated look deserved an understated and elegant sound, so I used single piano notes in GarageBand iOS for sound effects. The game would have been a dissonant mess if I had used SFXr.
- Having the tutorial levels was a good idea. It gave me the opportunity to dress the game up with prose, and it also communicated the essence of the game efficiently and enjoyably. It became even better when I added explicit instructions on suggestion from the IRC testers.
The only other thing I can think of that went poorly
- The black squares imbalanced the game. It was intentional that you’d be able to walk the black squares around in the last level, gobbling everything up with wild abandon. I didn’t know that this was possible in the other levels, and the game’s difficulty suffered as a result. Some of the levels have black squares adjacent to each other because I was actively trying to avoid this exploit. If you poke through my timelapse and my source code, you’ll see that I actually did have other ideas for color combinations and win conditions (some of them were actually suggested by players in the game’s comments), but I knew that the game was already pretty good with black squares as they are, and I had no time to change the mechanic and playtest it to my satisfaction.
In all, I’m incredibly proud of what I made. It turned out far better than I expected, and the experience is invaluable. I am already feeling the itch for some rapid prototyping, so you know I’m going to be back in December. Thanks for reading, and don’t forget to play Additive if you haven’t already!
A surprise for you, dearest reader!
I’ve uploaded pictures of the dev notebook entries I made during LD24 to Additive‘s page on my website. It starts the day before LD, and ends with the list of things I wanted to address in this post-mortem.
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:
Just wanted to let you know that I have put Vox on the Steam Greenlight process.
What was originally started as an entry into the Ludum Dare competition a number of months ago, during the april competition, is now being made into a full ambitious game!
Would really appreciate it if you could visit the game page and hopefully show your support (favorite and rate up) and this would make me very very happy indeed, and I would be forever indebted to you!
As always if you want to follow my voxel engine tutorials or articles, they can still be found at the site:
I am happy to hear any feedback you guys have, or answer any questions you might want to ask.