Archive for the ‘LD #23’ Category
And I’m done! have fun playing “Freedom” a prequel to my LD#23 game Predicament :
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.
Zephyr, my game from LD 23 is now available on the iTunes App Store.
When I originally created the game a few people commented on how well it work with a touch screen, so I’m happy to finally have a version that runs on iPad and iPad mini.
I’m keeping the game free until after LD 26, so get it while it’s fresh if you want to try it out.
I participated in my first Ludum Dare almost a year ago, for #23 “Tiny World” and made Humphrey’s Tiny Adventure. It was my first game jam and I had a great time, but the game I made had a long ways to go — despite being technically “complete” it didn’t have any audio and a lot of things were unclear due to the fact that I hadn’t done any testing for feedback before I released.
So…yeah. That’s all I’ve got to say. Go play it!
I’m remaking my first LD entry, World Panic, wich you can play here:
I’m using Unity3D. It’s gonna be finished soon with the same original levels and I’ll add some more. I’ll release for Android and Web (and Windows maybe).
I just compiled all of the songs from my various Ludum Dare entries into a single soundtrack. You can download it for free HERE !
Timelapse video (speed: 10x) – Work on my Virtual Machine and work on my new microgame Tiny World Adventure developed inside this new VM.
My LD23 entry: Tiny World Adventure. Consider to provide constructive criticism.
We’ve just released our game for this year’s October Challenge.
It began as our entry for Ludum Dare 23 but has been polished up since then.
It is available now for PC and will soon be available for Xbox Live Indie Games.
This time around I saw a lot of good games with a lot of great art styles! Unfortunately I didn’t see much use of distinct music in a lot of games, but they were still nice.
Some things I noticed were:
ABSOLUTELY NO FIRST PERSON UNITY GAMES HAD A PAUSE SCREEN EXCEPT FOR MINE!!!
(with the exception of Accidental Rebel’s Complexivity )
I ALWAYS have a pause screen in my games and for some that I played, it wasn’t even possible to quit without Force Quiting the App.
Please people think about BASICS in a first person game.
However most people nailed the graphics style, and that was nice.
Anyways thats me rambling, play my game HERE and happy gaming! <3
While every one was preparing and working on their LD #24 entry, I’ve cleaned up the entry I submitted for the last LD #23. It’s now available on Kongregate.
I’ve mostly shaved of the raw edges:
- Added a bunch of free sprites instead of my own “artwork”
- swapped the sound effects for something halfway descent (still no music though)
- it now has 30 levels, there is some progression in difficulty, but since I didn’t add any gameplay, it does get a little boring in the second half
Given the fairly positive comments, I’ve used the weekend to draw up some new ideas to make the gameplay a little more interesting. I’m either going to add more settings or add extra options, I’m currently thinking of some tower defense inspired units. It’s still unclear, but I am excited with this progress
Took us (a team of 5) 4 hours to come up with an idea. The concept art you see here doesn’t make any sense, ignore it.
I took Chevy Ray‘s code that he released as part of his keynote for LD23 and put it up on github. It is written for his FlashPunk engine. I used it to make my LD23 entry Seeds of Destruction and it worked out really well for me.
PS Chevy if you happen to see this, I’ll happily transfer the repository to you.
Third time entering. Hoping to do better than last time. When I got completely distracted by bad timing due to a friend coming to town.
I’ll be using
Pickle or graphics gale
and Bfxr and audacity for sound.
I just wanted to share with everyone the stats from my last game (LD23). I used Google Analytics to record events from within my Flash game. It was very easy to set up – it only took a few minutes – and while the numbers are not very impressive, I think it was worth it to see how my game was being played. For example, I see that only about 10% of players clicked the restart button and that each level of difficulty had about half as many completions as the previous. For a throwaway game like this, this info is not really important, but for a real game in the wild, this can be very valuable. I would encourage everyone to add some kind of tracking code to your game even if it’s only for the practice!
I’m sure nobody cares it, but i’m in in this competition. For the first time.
Using pure Flash AS3. For the second time.
It’s been a while! Back in the judging period of LD23, I promised I would make a post-compo version of Recluse – one with sound and bug fixes – but I was too busy with college back then. Well, I finally manged to work on the game, and here it is!
You can download the new version in the entry page – in the same links as usual. (I’ve included the original compo versions inside the RAR files, so that shouldn’t be a problem)
To make up for the long time without any update, I also decided to include a whole new game mode for those who are bad enough dudes to find all secret collectibles in the game. This should be enough reason for people who have already played Recluse to download it again, and in case you still haven’t, this is also a great opportunity to try it out for the first time.
Changes in the new game:
- A new game mode, activated when you collect all secrets and finish the game.
- Adjustments on the difficulty and controls.
- Some new animations where it was needed.
- 4 hidden collectibles instead or 3.
- Bug fixes.
Unfortunately, the screen flashing (which is not intentional) was the only bug that couldn’t be solved. On the other hand, I managed to change the color of those flashes from white to purple, which made them less intense.
Well, I hope you enjoy it!
While my game didn’t do terribly well in LD 23, it got overall average scores, I did get quite a bit of plays and a lot of good feedback on it. I decided why not, take it and expand it out further. Well this has taken FAR longer than expected and I ended up developing a full cross-platform 2d game engine/library that supports Android NDK/Linux/Windows/Mac in the process, but as of last night the extended edition of my LD23 game “Tiny Defenders” Is available on google play
First off, a link to the free version:
And a link to the compo page!
But that’s not the primary purpose of this post! I wish i had though of it sooner and done more in between but i’ve started doing video logs of my development so following this sentence i’ll have a few videos, starting with a video of the competition version, showing how the game evolved as i tried new things and added on to what I already had. I actually think it’s kinda interesting to see how something starts from a tiny little ludum dare game and evolves into a full game.
Click the link to view the rest of this post! i’m hiding it under a “more” tag otherwise it’ll eat up the entire front page….it’s huge!
A few months ago, I proposed a quite vague idea about a new “cartography” module for the upcoming LD23. Web Cartography is more and more used because of its curiously innovative and interesting aspect.
Now you may ask: “What’s the damn connection with Ludum Dare” ?
With the increasing popularity of the event, we see more and more game proposed for each LD session. Also, the initial idea was to realize a cartography of the submitted games.
To have a better visualization of the whole game submissions. Take a look to statistics in an original and interactive way.
- Which games are available for a specific platform? Multi-platform?
- Which games have more votes, coolness? (main nodes) => Imagine a visual helping tool for voting.
…and numerous other possibilities. (Why not something more realtime-oriented based on database snapshots?)
Proof of concept:
Using available public data and python scripts, I extracted and classified data concerning each game entries of a given Ludum Dare composition (platforms, ratings, creators,votes…). I’ve written a small web application displaying large directed graphs, generated from these data sets.
You can find my work over here: http://cboissiere.com/projects/ldviz/
Don’t be afraid by the messy aspect of those graphs, it’s mainly because of the huge size of the data sets. And don’t forget it’s still experimental =)
And of course, the source code is over here: https://github.com/cboissie/LD_Viz
Tell me more:
It’s basically two kind of graphs:
- WordCloud: We extract each words from all game titles. The words used together in a same title are linked to each other. For instance, if you click on the “TINY” node, you will see all the words that were used conjointly (like “WORLD”, or “PLANET”). The size of the node is proportional to the word occurrence.
- MultiPlatform: In this graph, games and their respective platforms are linked (Windows, OSX etc…). The size of a platform node is proportional to the number of game ported on this platform.
- You can change anytime the dataSet (between LD21,22 and 23) and the graph type.
- Zoom with the mouse wheel.
- Click on a node to see its immediate neighbors.
- The “Start algorithm” button apply a “Force Atlas 2″ algorithm to the current graph (see http://en.wikipedia.org/wiki/Force-based_algorithms_(graph_drawing)). You can stop the execution of the algorithm by clicking again on the same button. This algorithm will place the nodes in a more convenient way, give it a try!
Here’s a quick web app prototype for visualizing interactive graphs of game entries from old Ludum Dare compos. You can see two kind of graphs: Word cloud (most used words for a specific theme) and Multi-Platform (Game names associated with their respective platform(s)). http://cboissiere.com/projects/ldviz/
Feel free to contact me at clemzbox[at]gmail[dot]com or via Twitter.