Ludum Dare 27
Ludum Dare 26
Ludum Dare 24
Ludum Dare 24 Warmup
I think the most learning from this jam came from a 1 hour postmortem we did with another team who also submitted an entry. We got together and discussed things like technology choices, how long we planned and most importantly what we felt went wrong. Of course many of the problems existed in past jams as well. It is hard to truly learn from your mistakes being creatures of habit. But we keep trying and eventually we’ll get it right.
Our entry was T1me Twist0r, a game of 10s mini-games. Our triumph was to ensure that the mini-games work together seamlessly in a clock like manner and to this end we succeeded. We also added quite a bit of custom audio and some funny effects. We also felt this went over well. Don’t want to spoil too much, so if you haven’t played and voted on the game do that before you continue.
So how did things play out?
For hosting we used Windows Azure. Generally this works out really well. We got one complaint of slow load times for the game. We traced that down to what looked like a really slow outgoing bandwidth amount and not related to latency or server load of any sort. In the future, it might be good to use CDN services for larger files especially media components like audio or large sprite strips.
Visual Studio 2012 + Visual Studio Tools for GIT + GitHub + Azure…
This worked out way better than we thought. The VS 2012 to GitHub connection was seamless. We had a single merging problem that we were able to resolve by going to the command line. Other than that we had 2 developers partying on master and no other conflicts. We pushed directly to master and had Azure listen to and deploy the site directly from there. Turnaround times were seconds in the single digits.
There was some confusion around a .deployment file to pick which project to deploy, but that was easily configured. In the end we also need to branch the jam version from the post compo version so we created a branch and built a second website that pointed to the jam submission. We still had the ability to push game breaking bug fixes this way. Again, branching and building out a second site was also a seamless experience.
Not having issue tracking built into VS is a big issue, but with 2 developers we didn’t even notice. Sticky notes are where its at. In the future it would be nice to have GitHub Issues as a window inside of Visual Studio, which is actually quite doable using the Web Browser window and just pointing it at your GitHub repository.
We planned all of Friday. At least 4 hours of planning before we wrote the first line of code. We did have the source control already set up so we weren’t worried that our technology wouldn’t work for us starting Saturday morning. At the last hour on Friday we pushed some basic sprite framework code up in preparation for Saturday.
I will probably never do a Ludum Dare again where I don’t plan this hard. We had so many ideas and were able to think on them all night while we slept and have a really good feel for the best ideas in the morning. Had we started coding the previous night on some major features it would have been a big mistake.
Our failure in planning was in establishing the later task list. We knew what we were going to do, but we didn’t have a task list. Previously in our jams we had done more much task list creation and that allowed us to scale out to more people. Somehow having fewer people we didn’t see the point and it hurt us in the end. Every now and then I’d poke my head up, say I had checked something in, would grunt for a few seconds, and then proclaim my next conquest. Not very good if you want to maximize your working time, but great fun.
What Went Wrong:
It starts with a capital P and ends with a laytest. We needed more of it. Earlier. We needed playable aspects of our game done earlier to facilitate it. Reality check. Your first choice is not your best choice, instead without playtesting it becomes your ONLY choice. Doesn’t sound as good when you call it your ONLY choice does it? We would have fixed 2 or 3 very minor coding issues that affected our released game without having to have all of our initial players experience it. Better initial experiences would certainly lead to better scores in the Jam.
The second thing starts with a capital P and ends with a laytest… Wait, I see what you did there… Some of our mini-games didn’t work quite as expected in all scenarios. Trackpad users are slower to mouse around for instance and so found the games more challenging than touch users or mouse users. This was unfortunate. We also had a game where it wasn’t obvious that your taps were actually doing anything. Too much filtering and noise added to the results was making it sometimes do nothing when it should have been giving the user solid visual feedback that they were doing the right thing.
Never underestimate user frustration with waiting. The challenge is 10seconds, but if they finish faster, give them something for it. We initially gave nothing and had to gamify the left-over time. We actually had some of this in our planning, but wait, we didn’t write down a task list and so it got easily forgotten in the time crunch. Always give the user positive feedback. When they do something fast, give them bonus points whether or not they have to wait.
Finally at one point in the game we had some issues around the transitions. As a result we coded in a little countdown timer to the next level. This actually made the game play way too slow and after we had fixed all of the transition issues we never removed the countdown. When we implemented that countdown “Brilliance”, but when we failed to see it lacked further use in the final game, “Idiocy!” Really think about how each of your temporary decisions are impacting the game and make sure you revisit short term decisions to see if they can be made better.
We hope everyone can learn from some of our insights. With just under 2 months to go for the October Jam we are already thinking of ways to improve one of our existing games to ship quality. I sure hope we apply everything we learned from this Jam and finish a truly stunning submission. See you in October!
So we are live with our game, Natural Selection – You vs the World.
The premise is simple, fly around an infinitely scrolling canvas and shoot through the ghosts of everyone who has ever played. The gameplay will evolve as people last and live longer and as people develop different flying strategies and techniques. When a lot of people die at a specific distance, expect a wall of enemies at that point in the future. When you die, see the names of your killer and hope it isn’t yourself from a previous run.
Direct Link: http://naturalselectiongame.azurewebsites.net/
The client side portion of our game is almost done. Here are the code stats and list of retired tasks.
So we are doing an HTML 5 based game targetting canvas. Only minor math and sprite libraries we previously generated have been used. So far here are the check-in stats:
5 developers, 7085 LOC, one of the devs is pumping out 257 LOC per hour worked on the project.
Completed list of items (not in any particular order):
Canvas Sprite Engine
Parallax Tree to enable a star field
Multi-level star field
Collidable Obstacles with special properties for bullets
Single Screen State Manager (we didn’t want screens or transitions, everything flows based on a single screen state)
Collision Detection Engine (a multi-layer collision detection engine for handling enemies, bullets, etc…)
Over 80 custom sprites and graphics
Multiple Ship Designs
Full interactive in game credits
Multiple Input Modes
Konami Code Support
Ghost Replay Mechanism
Windows Azure Server setup for Leaderboards and some Secret Sauce
Interactive Game Over and Replay
A Highly Optimized Bullet System for optimum Performance
Its fully playable now and we are incorporating our core evolution concept now. Should be fun!