About Gareth Jenkins (twitter: @garethjenkins)

Entries

 
Ludum Dare 33
 
Ludum Dare 32
 
Ludum Dare 31
 
Ludum Dare 30
 
Ludum Dare 29
 
Ludum Dare 28
 
Ludum Dare 26
 
Ludum Dare 25
 
Ludum Dare 24
 
Ludum Dare 23
 
Ludum Dare 22

Gareth Jenkins's Trophies

Gareth Jenkins's Archive

One Spear Arena, my #LD28 game, is now free on iOS & Android

Posted by (twitter: @garethjenkins)
Friday, August 22nd, 2014 3:23 am

Hey — so to celebrate #LD30 the game I made for “You only get one” / #LD28, One Spear Arena, is now free on iOS and Android.

One Spear Arena on iOS

One Spear Arena on Android

screenshot1-iphone5

 

Watch out for news on the desktop multiplayer version in the coming weeks.

One Spear — take #1 / early mechanics preview

Posted by (twitter: @garethjenkins)
Saturday, December 14th, 2013 8:16 pm

Core mechanics in place — next up some AI refinement & increased difficulty/spawning, game over state and then polish/juice.

onespear-gif1

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.

Super Evil Machine — playable

Posted by (twitter: @garethjenkins)
Sunday, December 16th, 2012 12:19 pm

Okay, so it’s playable… few (many) things left to do though, see list at the bottom.

Some notes along the way.

Screen Shot 2012-12-16 at 19.09.15

These “Things” spawn on platforms, walking somewhat randomly. You need to get them into the Evil Machine to replenish your evil energy.

Screen Shot 2012-12-16 at 19.10.33

You control them (a bit) by flipping the platforms, and making them fall through.

Screen Shot 2012-12-16 at 19.10.27

You can also push them along the top of the machine using the “Pusher”.

Screen Shot 2012-12-16 at 19.09.36

If the Things get away from you, they’ll jump onto new platforms and new rows of platforms get created as they jump. You can scroll up and down the platforms using the wheel / touch scrolling.

Remaining as essential:

– game over / restart & in-game restart

– bigger hitboxes & rotate in direction of side pressed

– occasional spawn on top rop

– evil meter as bar that falls

– bonus for multiple kills

– bounds on camera scroll

– prevent more than one press on pusher, calibrate pusher

– instructions screen / start / restart screens

– attach gui to screen edges not from centre

– sort out double accelaration post jump or fall

 

Some things to do to play with the playability (a few of the above will affect it though):

– speed of evil decrement

– speed of things

– spawn rate of things

– flip walk direction when catapulted — e.g. if direction of body changes, face to it through rotation

 

And some polish stuff that I almost certainly won’t get time for:

– machine mechanics and evil meter

— play an single tween everytime something dies?

– offscreen indicators

– click and drag controls

– use pfx / liquid / something for evil meter

– scoring == evil energy accumulated (energy depletes, but score is totalled)

— deaths

— missed opportunities

— “score” — multiplier (no missed opportunities) * deaths * amount squashed at a time

Super Evil Machine — design mockup

Posted by (twitter: @garethjenkins)
Saturday, December 15th, 2012 6:06 am

So, I have a machine of evil… a Super Evil Machine!

Have to do regular work now — but will be getting stuck into constructing this thing-squashing monstrosity in a few hours.

Super Evil Machine -- mockup

 

Super Evil Machine -- instructions mockup

 

Update — critical detail missed from those above… score!

Super Evil Machine -- Deaths!

An Unnatural Selection / Trinity Labs — day 1.5

Posted by (twitter: @garethjenkins)
Sunday, August 26th, 2012 1:01 pm

Okay — so got testable play & level prototype earlier:

And have since been working on systems, some of which can be seen here:

Taking a short break now, then it’s on to level progression / load; score increments; general juiciness (inc some more sfx & music), and, er; some basic levels.

G.

An Unnatural Selection / Trinity Labs — Day 1.25 update

Posted by (twitter: @garethjenkins)
Sunday, August 26th, 2012 7:05 am

Okay, has gameplay. Pretty much.

You can match things up and they create other things.

In fact, you can match up a lot of things.

Possibly too many things. At the moment, chaos is a feature and nothing’s certain. Quite fitting 😉

Also got some basic sfx in. Need and better a gorilla and a two more models. Then onto establishing some objectives. Haven’t decided on the mutants yet, might just go for gene variety, reproduction and, well… a surprise at the end.

G.

An Unnatural Selection / Trinity Labs — day 0.5 pics

Posted by (twitter: @garethjenkins)
Saturday, August 25th, 2012 10:12 am

Okee… very little time today and off out for dinner and festivities this evening, so thought I’d post a quick update of where I’m at…

Some food to get started

An early playtest

Current screenshot

It’s something of an evolutionary match 3 — with fucking and mutation. Got 2d mouse>3d object movement in place. Logic’s in for the petri dish’s triggers and associativity. Next step is to get some alternate “things” in (they’re supposed to be dinosaurs — there are monkeys, babies and robots to come) and then start the match/spawn stuff. At that point (hopefully early tomorrow) I can start to play around with some mechanics and hopefully engineer a useful ruleset.

G.

Act 2 — gameplay done, need a title and some achievements

Posted by (twitter: @garethjenkins)
Sunday, April 22nd, 2012 9:37 am

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.

Act 1 done — ready for some mechanic/math

Posted by (twitter: @garethjenkins)
Saturday, April 21st, 2012 10:36 am

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.

[cache: storing page]