About Gareth Jenkins (twitter: @garethjenkins)
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Gareth Jenkins's Trophies
Archive for the ‘LD #23’ Category
Note: I originally posted this on my own blog at garethjenkins.com, but as it’s directly applicable to Ludum Dare past and present, I wanted to share it here as well. I guess this is also my “I’m in!” post… looking forward to the weekend
In April last year (2012) I participated in the 10-year anniversary Ludum Dare game jam and built a 48-hour competition game called Mineral Cities, for the community-selected theme “Tiny World”. Nearly 12 months later, I launched a Kickstarter campaign to raise funds for building a game based on that prototype — also called Mineral Cities.
That campaign ends in a couple of days, and at 75% of the funding goal reached I’m hopeful that it is going to make it. In an effort to drum up some further support and close that final gap and in the run up to Ludum Dare #26 this weekend (which I’ll also be participating in — my fifth now), I thought I’d share some of the things I did in taking Mineral Cities from a game jam prototype to a fundable game — especially one I could enthusiastically get behind and convince others to share in my vision.
If you’ve not backed Mineral Cities already, I’d really appreciate you checking out the campaign page over on Kickstarter. You can even sign up to get access to the alpha, which I’ll be distributing when the campaign ends.
So, in no particular order, here’s a bunch of things I did…
#1 Figured out a point at which I was happy telling people how good it was
This was super important early on. I had an idea for the feel of the game as I was building the Ludum Dare version, but I wasn’t necessarily expecting other people to “get it” right away (they did, I got some great comments on the original). The Ludum Dare version was limited in replayability and somewhat obtuse in UI and instruction (as a lot of great LD games are), but I knew how I wanted to fix both. Problem was that I didn’t want to end up breaking the feel of that original version. I only wanted to make this game (and ask others to help me fund it if I had confidence in it) The solution I came up with was relatively simple…
#2 Built an alpha, essentially for myself
I didn’t do this right away (in fact I didn’t start this until February 2013), but I decided early on that this would be my measure of readiness for launching a Kickstarter campaign or, in fact, continuing any further with the development of the game. I effectively identified (and wrote down) what I wanted the game to play like (not how) and what its core mechanics should feel like in use. Building a new version of the game that included a better control system and mechanics that would support a full game that satisfied those criteria became my immediate objective.
#3 Came up with a visual design that I felt embodied the feel of the game when played
This was slightly tricky in that I liked the visual design of the original Ludum Dare game — it was sufficiently simple and articulated game state in a way that provided variety and an evolving aesthetic that mapped well to the game’s progression. However, it demonstrated nothing about what the game was — unless you’d read the description of the mechanics, the appearance of arbitrarily-coloured columns on a sphere didn’t give much away. I set about coming up with something that manifest both the simplicity and compound, emerging nature of building on the planet as well as the function of the gameplay components themselves. Simple things I did early on, like making terrain (mountains, hills etc) a different colour from the planet’s surface, led me to the decision to make colour a foundational part of understanding and differentiating the game’s mechanics and level configuration.
#4 Came up with a visual design that gave me the flexibility to build the game
I didn’t so much make this decision as I knew I had to live with it. I wanted to work on this alone and I didn’t want to (nor was I able to) spend a significant amount of time modelling or manually tweaking art. Ultimately, for the alpha (which is what you see in the campaign video) I went through two iterations of the building models and 3 or 4 planet types, all of which were ultimately merged to the test planet I’ve been using throughout. All of this was done over a couple of evenings and a couple of bottles of wine.
#5 Kept things that were not broken
I’m really fucking picky about music. I’d put together a little electronic riff for the Ludum Dare game using Propellerhead’s Figure, which, whilst it’s way too short and it has a couple of things I’m not entirely happy with, it totally nails the feel of the game for me. So I kept it. I need to expand on it at some point, but right now it fits.
#6 Iterated on the core design… a lot
Before I revisited the code for the game (which I didn’t in the end, I started from scratch) I spent about 3-4 months going over and over the core mechanics of the game. In the end I boiled this down to 3 sets of ideas, and a couple of variations. My final iteration was actually written as a vocabulary of events in the game, which I worked back from to an implicit set of mechanics. This took by far the single largest chunk of time yet spent on the game, but overall had the least impact (it was done over a serious of long and repetitive journeys over the course of a couple of months).
#7 Worked out what worked, then started again
Somewhat a subset of the above, but it’s important to note (/for me to remember) that pretty much every design concept or change I came up with I tested against my original assumptions for how the game should work, then against the Ludum Dare prototype and then against my other design ideas. Often this resulted in not-quite-workable ideas that I then had to go over again. For those who’ve played the original and seen the alpha, the inclusion of “gems” was central to a lot of these decisions. And I didn’t finally decide on them until relatively late in that design process.
#8 Identified a reasonable (time and resource) budget
To some extent this is more of a campaign/business issue around budgeting for the game’s development — but in the end it actually factored quite significantly into what I decided should be in the alpha and how some of the game’s systems should — or could — work. Knowing that I was looking at an alpha + campaign setup of about 2 months and a final game build time of between 4 and 6 months (which I knew wouldn’t be full time — my “day job” is running a consulting business building games for other people) meant that there were certain things I needed to exclude, at least in the first version. This included AI, procedural generation and excessive tech tree balancing (interestingly I ended up moving my design work away from any kind of tech tree and focussing on the core interplay of a relatively small set of building types).
#9 I wrote (mostly coherent) descriptions of the game
I’ve ended up describing Mineral Cities as a “minimalist RTS / city-buidler hybrid”… which, while it’s technically correct, I’m still not happy with and hope to find something better. I did this (write descriptions) a lot though — normally without reference or consideration, I just kept writing them down. I’ve reused some of that in the lengthier descriptions of the game, but, while they’re all okay, I’m still not really happy with any of them. I love the name though, I’m keeping that
#10 Worked out how to add variety and longevity
I knew that once I had the core mechanics in place and control and presentation issues resolved, extrapolating out to various objectives, level configurations and gameplay modes would be relatively easy. It was. Being able to play a version of the game that was functionally complete allowed me to test a variety of game modes very quickly. Subtle changes such as visibility and adjusted mineral replenishment make a massive difference to how the player approaches planning in the game. Really this was evident as soon as I had the core mechanical designs in place — being able to test those assumptions while playing the basic mode of the game just reinforced the longevity and value of those systems.
#11 Made room for essential UI, but nothing else
At the core of the game is the presumption that the (interested) player will develop their understanding of the interplay of the game’s systems as they experience the game itself. The game is the UI and vice versa. The only actual “UI” I built was for objective tracking, building selection and level completion. What surprised me is that while I started with that as a minimum required for an alpha to be usable, I’ve actually ended up with most of the required UI for the finished game — validating my original intentions for the user’s interface with gameplay systems.
#12 Listened to all of the feedback
I got some fantastic feedback on the original Ludum Dare game. If it wasn’t for that I wouldn’t have taken it any further and I wouldn’t be writing this now. That there were players that identified with the feel of the game was what led to me making that core to its ongoing design.
#13 Ignored all of the feedback
I knew from the outset that this game wasn’t for everyone. I embraced that and ignored feedback of the “wuh?” variety.
#14 I took a break
I didn’t so much decide to do this as I was forced to. I didn’t have time to do speculative work on making the game (which is what it would have been if I hadn’t gone through the lengthy design phase I ended up with), but I did have time to think about it. Over the course of the 10 months between Ludum Dare #23 and February just gone I effectively took a break from the game. I didn’t play it for 8 of those months. It was all in my head for all that time though, and the majority of the design was done there as well. I made extensive notes at various stages, but very few of them ended up being part of what I ultimately wrote down in February as a “this is Mineral Cities” document. If it wasn’t for that forced period of contemplation, the game wouldn’t be anything like as good as it is now. I’m happy to report that I’m in the contemplation phase with a number of other projects — I’ll tell you about those in a few years I guess
If you’re interested in the game, obviously go check out the Kickstarter campaign page for Mineral Cities. The updates I’ve posted there articulate some of the output of the design process I’ve discussed above. It’d be great if you could back the project and/or spread the word about it.
Okay, so I’ve got some pretty solid gameplay. Almost as originally anticipated, though introduced minerals as primary driver/progress.
Few things remaining — achievements (these are kind of like levels / secondary driver) and a title. Probably tidy up a few other loose ends as well if I get time.
Concerned about how obvious the math is — game developer’s conundrum I guess. Right, more children, more regular work and then achievements and such later. Might revisit the music and sound as well.
I’m working on a sim-/civ-/me2-like-planet-scraper like resource management thing.
Cursors & WASD rotate the tiny world, num keys place objects. The objects all have different resource dependecies on eachother. On a cooldown, they produce “resource” based on their modifiers. E.g. grass needs water, water needs hills, cities need water + grass. Also have crazy ideas for city expansion and conflict. Probably out of scope for this weekend though.
Building things costs resource. Also would like to implement some production depletion/deterioration over time, such that there’s no incentive to leave it there ticking over. Game objectives are likely to be a list of achievements — e.g. “build a city”, “earn more than x”, “have y resources”, “cover the world” etc.
Happy with first pass at input, manipulation and some rendered affect. There’s a local collision loop in there as well so placed objects don’t get too close. I’m at the point of having each object calculate it’s resource output, but all outputs are 0 currently.
Thought it was a good time to put an update up. Later I’ll get some math into the resource calculation and consider how to do depletion over time.