GREENLIGHT IS A PATH, NOT AN OBSTACLE.

A lot has been said about Greenlight recently, most of it very negative, and with Broforce being greenlit, I wanted to share some of my experiences and thoughts to perhaps present a more balanced picture of the challenges a developer faces while trying to get greenlit.

For those that don’t know, Broforce is a 2D action platformer where players take on the role of every action hero from the 80s and 90s to defeat satanic terrorists that you can play for free right now.

The first part of this article is essentially a post-mortem of our successful Greenlight campaign. I hope that my experiences with the system can lend some insight to those planning their Greenlight campaigns.

In the second part I try to counter some of the criticisms that have been leveled at Greenlight. It is not my belief that everyone who dislikes Greenlight does so because they adhere to these criticisms, but some developers have made these particular claims without any public debate from the game development community as to their validity (that I am aware of). I hope my perspective can start a more constructive discussion about Steam’s Greenlight process.

Lastly I make an argument for why Greenlight can be a powerful tool within a game developers arsenal, rather than an obstacle in their path.

This article makes certain assumptions. One assumption is that Steam heavily curating their marketplace is a good thing, and that a more open marketplace, like the AppStore, would make Steam less effective as a distribution/marketing platform. A debate about whether Steam should be more open in the future, and how it should achieve that in order to benefit everyone, is not within the scope of this article.  I also don’t think Greenlight is perfect, but in order to not derail the article we’re not going to go into our ideas for how to improve the service. You can view some of Gabe Newell’s ideas for the future here.

Broforce’s summit of Mount Greenlight

I joined Free Lives at about the same time Greenlight launched. Broforce was put onto Greenlight in the first few days of the system going public. At that stage Broforce had nowhere near the level of polish it has today: most of the artwork was still from the original Ludum Dare entry, enemies were very limited, bro's did not even have their own special abilities. We got a little bit of attention then, mostly thanks to Greenlight itself being new & novel and attracting a lot of visitors. We also gained a couple of fans who have stayed loyal throughout, but for the most part the internet forgot about Broforce.

Our core strategy for Greenlight was simply to maintain a version of our game at all times that anyone can play, and that prompts you to vote for it on Greenlight. We're not a well known studio, we don't have any powerful journalist friends, we simply have a game that (we think) is fun to play and we've let people play it.

One of the interesting things to observe from our time on Greenlight is how well votes corresponded to the quality of the game. At the start of our campaign the game was quite rough and we didn't get very many daily votes:



We had a spike or two where we got some early articles/youtube videos (including two really kickass ones by EatMyDiction), but our average daily vote always quickly plummeted. In February we started attacking greenlight in earnest: We hired a person to manage marketing and press relations and started launching more frequent, high quality updates to Broforce and you can clearly see our average daily rate improve.

We were sitting on about 20-50 votes a day as baseline before February. From February to April we were seldom getting below 50, and from April (after a Cyprien Squeezie video with 700,000 views) until late June we were seldom dropping below 100.

In May we launched one of the biggest updates for the brototype which included much better enemy variation and a boss.  We also launched a trailer (the one at the start of this article) that reflected the updated quality of the game, and which had a request for people to vote for the game on Greenlight. I think it is critical that the request for Greenlight voting was in the video itself (not in the description) so that people still see it when watching the trailer as embedded video, and the request should be as succinct as possible and at the end of the video. We also intentionally put the line "Link in description" in the video itself so that embedders were forced to link our greenlight campaign. This is what our greenlight graph looks like from then until now:



As the quality of the game improved and people spread it to friends our fanbase increased. In the month of May Broforce got over 100,000 unique players, and the little bit of buzz around our game was enough for it to generate a constant stream of attention from youtube channels.

On June 25 we were at about #40 on Greenlight. We released an updated trailer for Broforce that day, which received coverage in most major American indie game press websites, as well two Markiplier videos. From that day onwards we didn’t receive fewer than 350 votes in a day and climbed rapidly through the ranks.



On the 12th July, we were sitting at #16 with 40000 votes. 12 days later, after a Jesse Cox and two Yogscast videos, we got greenlit. At that point we were at #2 with 82000 votes.



All of this seems quite counter to what greenlight detractors typically say: We were not popular to begin with. Our game doesn't have the words "zombie", "craft", "simulator" or "slender" in the title.  While we did get a lot of help from various sources, we did not have ties to any publisher or big names in the Indie space with the kind of popularity that could push thousands of voters to Greenlight.

We had no magic bullet with which to conquer Greenlight, instead we worked hard to make an appealing game, we put some effort into making videos of the game that helped it get noticed, and we made it as easy as possible for people to play it and share it (and then asked them nicely to vote for us). We saw early on the impact of Let’s Play videos and tried to ensure that our game would work well under those conditions.

These were very much the sorts of development practices that we would have (hopefully) followed anyway. We found that in the case of Broforce the Greenlight system rewarded us for developing the game openly. And open development in turn ensured that we had a lot of feedback with which to test and improve the game, which fed back into tangible results on Greenlight.

This isn’t necessarily a method that fits all games, but I think that Broforce’s success on Greenlight does contradict some of the more wayward Greenlight criticisms. I’d like to offer some responses to other criticisms that Greenlight receives, with some of our thoughts and conclusions from our campaign:

Criticism Rebuttal #1: Greenlight screws niche games.

“Niche” games are a tricky subject. A lot of developers who struggle on Greenlight claim that niche games who do not pander can not get through greenlight, yet 'weird' games like McPixel, Papers Please and Shelter have managed to gather enough attention quite easily. It seems to be that people assume because their game is unpopular it is automatically niche when the game being mediocre is far more often the case.  With the amount of games being made, competition in the Indie space is intense and your title needs to stand out somehow.  Frankly, being niche is in many cases more likely to be an advantage than a disadvantage.

Criticism Rebuttal #2: Greenlight items should receive more traffic from within Steam.

Greenlight detractors have suggested that it would be preferable if more Steam users were being sent to vote on Greenlight items. I don’t see how this would benefit the system at all, if your game receives more random visitors then so would every other game on Greenlight.  I suspect users would fatigue of the greenlight queue very quickly if they were more heavily incentivised to vote (in fact their fatigue with unappealing Greenlight campaigns is certainly the main reason the vote counts aren’t higher).

Broforce received the vast majority of its votes from traffic from outside Steam. There was never a chance that a pixel art 2D platform shooter was going to get a high enough “Yes” vote ratio that random visitors alone would vote the game onto Steam, so we worked at driving traffic onto Greenlight from the start. Some players did discover Broforce via Greenlight, but not a significant number.

A system where the vast majority of votes on Greenlight items come from outside Steam is a far better measure of quality than a system where all or most of the votes came from random Steam users. In a random user “yes/no” voting system there would be no measure of passion, so the games with the broadest possible appeal would be favoured and it would be genuinely bad for niche games.

Criticism Rebuttal #3: Publishers should be allowed to pluck games out of Greenlight and put them on Steam.

Turning Greenlight into a game shopping tool for publishers doesn’t really benefit anyone except publishers. It is safe to assume that even a mediocre game would garner sales on Steam and a predatory publisher may choose to find failing games with desperate developers on the Greenlight queue and push them through onto Steam in return for an unscrupulous cut of the revenue.

If this were to happen the Steam store would lose some of its trust as weaker games that cannot compete on Greenlight are placed on sale. Consumers would have bad experiences playing possibly inferior games. And other developers receive fewer sales as consumers view the Steam store more skeptically.

Steam Greenlight is a system designed to enable better access to self publishing to indie developers, and in Broforce’s case it did just that. There is zero chance that at this stage of development we would have been able to secure a distribution deal on Steam without a publishing arrangement if Greenlight did not exist..

Criticism Rebuttal #4: Good games with plenty of votes aren’t being greenlit.

Chasm is a game that has been touted as being at the centre of Greenlight injustice.  Disregarding the fact that the game has actually now been greenlit, I struggle to see how they were suffering an injustice before. The game was still a long ways off from being finished, and Valve had stated explicitly that Greenlight releases were focusing on finished games. I don’t know of any cases where a finished, releasable game has been stuck in the top 10 for longer than a month or two.  Even if that is the case, in the old system they would likely have been even more in the dark as it is impossible for Valve to give detailed responses to all applicants, and also impossible for Valve to release every game as it is finished. At the very least, having a good ranking on Greenlight lets you know that your game is under serious consideration for Steam distribution.

Success on Greenlight is actually a damn good barometer for the overall success you can expect from a game.  Doing OK on Greenlight initially has allowed us to feel comfortable with allocating all our resources to Broforce's development, and the transparency of Greenlight has given us useful information about the competitiveness of our product in the PC marketplace.

Criticism Rebuttal #5: Some games without a ton of votes get greenlit, therefore the system is broken.

This is only a good thing. It means that if you have a game Valve feel strongly should be on Steam then your game will get on Steam. This is especially good if your game isn’t a game well suited to getting to the top of Greenlight.

Closing thoughts

Deciding which games to publish on Steam, considering the limited bandwidth that a quality service would inevitably have, is undoubtedly a difficult job and I am not insinuating that Greenlight is perfect.  I do think it’s the fairest system there is, and Valve have certainly been taking steps to improve it and it will improve in (valve) time.

Greenlight gave us a rallying point to motivate press articles, and even some Youtube videos. It also gave us useful statistics from which to evaluate the effects of our actions and be able to draw comparisons with other campaigns that would have been impossible otherwise. It’s hard to overstate how valuable that has been for us especially because we’re operating from relative isolation in South Africa.

It also allowed players and viewers a soft support option, i.e. clicking “yes” on a button. This provided for us a means to convert fans to supporters. It’s a subtle boundary to cross, but each person who has crossed that boundary will now be slightly more likely to advocate Broforce in the future. That is hugely valuable to us, and perhaps part of the reason why dealing with our players has been such a pleasure throughout Broforce’s development..

Without Greenlight it would have been impossible that Broforce, at this stage of development, would have secured distribution on Steam without publisher assistance. Being able to get that kind of certainty early on as a self-publisher is golden.

As I see it, the biggest difference between our experience on Greenlight and those of detractors has been our attitude. We always saw Greenlight as an opportunity to get on Steam, build a fanbase and gauge interest before release. Most others seem to see it purely as an obstacle to overcome before getting a distribution deal and raking in cash.  Making games is hard, doing so professionally and successfully is even harder.  If you enter this sphere and want to compete you can’t expect that others will make it easy for you.

(This article was cowritten by Ruan Rothmann and Evan Greenwood)

Victory!

Damn! So would have thought, we actually won OUYA create!  I had expected and hoped we'd do well, and perhaps win one of the subcategories, but considering how we felt after finishing the game, I didn't think we'd win (my personal pick, from only seeing the trailers, was Sky Arena). I'd like to take this opportunity to thank the organisers and judges.

It's kind of a weird position to be in, the day after hand-in we were quite bleak and we had a discussion on what we'd done wrong and what we'd do differently in the future to prevent making these mistakes again.  I think a lot of the negative sentiments were amplified due to the jam not ending well for us, with me breaking our repository in the last hours, and some bugs and flow issues not getting sorted out until the last minute.  In the post-mortem I talk a lot about having too much ambition for our game but I guess it paid off.  Perhaps a side effect of having high ambitions and standards are never quite being happy with your work?

Looking back at the game now, however, I do think it is really strong and impressive for 2 weeks' work.  Although it doesn't quite match up to what we'd had in mind at the start, the prototype does demonstrate the potential of our concept quite well, and it is quite fun.  We have some time now to fix and improve the things that had bothered us and to get the game to where we want it to be. Whether we'll actually finish it and release it as a paid title is hard to say, though.  All things considered I still consider Broforce to be the better game, and it is closer to release than Murder Island is, so we'll continue working on that for the time being.  I do feel we owe it to the Ouya and organisers to at least finish what we'd wanted to do for the prototype, and to have a rounded, more stable version that we can put online would be nice.

Post Mortem: Ore Chasm

I've been meaning to do a post mortem on our Ludum Dare game, Ore Chasm, for a while now, and I thought I might as well do it now before it completely fades from memory.

Background

We are currently working on a game called BroForce for which we need to, at some point, implement networked multiplayer.  No one in our team has any experience in implementing multiplayer, so we did a game called Deathsmashers in a for-fun private jam.  That turned out pretty well, but with it being a co-op FPS I felt that we didn't really answer many of the questions that we needed answering.  It is usually a good idea to have some sort of plan for what you will be doing in a jam, and I requested that we do a fast paced platformer with networking and lots of terrain destruction.

Design

Our lead designer came up with the idea of doing a mining game in the vein (heh) of MotherLoad.  This suited what I wanted to try technically very well, and could be worked to incorporate the theme of 'You are the villain' pretty easily - everybody loves mining conglomerates, right?  We didn't quite manage to foster the feeling that you are destroying the entire planet as well as we could have, though.

The game's design is focused around a very simple but effective loop: go down, get ore, try to make it back up, upgrade your gear. Keeping the loop focused and simple really worked for us and it turned out to be highly compelling.  Subtle changes in the game world as you get deeper, along with one or two things to discover also added a lot to the feeling of progression (besides being able to smash terrain near the surface with the more powerful late game lasers).  

The idea for the mining laser as implemented in the game was partly inspired by No Time To Explain's recoil-movement mechanic and works really well in making the weapon feel powerful.  I'd initially wanted to make the starting laser much weaker, with limited range and movement capabilities - but wisely we opted for the design as is.  Having the initial laser nerfed would have made it less effective at teaching the game's mechanics, besides unnecessarily limiting the player.

Some things we had planned did not make it in: We had planned to have creatures underground as you get deeper (although there may or may not be a mysterious and majestic sandworm in certain builds of the game).  A greater variety of weapons and some sort of metagame would also have helped a lot with replayability of the game. Upgrades and scaling are also hard to test when you don't have a lot of time and so the progression and cost of items are not as balanced as they could be.  Still, I think we did a good job of balancing in the limited time we had to make the game.

Tech

As usual we used the Unity engine. One of the technical challenges we faced was managing such a large game world with so many game objects - the map is 350x1024 blocks large, with each block being a game object in itself. We handled this by only spawning onscreen blocks, and despawning those that go offscreen and asset pooling them. We used a "lazy mans's asset pooling" system that I wrote earlier which worked very easily and painlessly for us.

We use a standard perlin noise map to generate the map - 4 layers of perlin noise combined with depth determine a block's state.  The master client determines a random seed and keeps track of all damaged/destroyed blocks. When a client joins, the seed is sent and the client can generate the exact same map. Afterwards a list of all dirty blocks' state is sent.

Networking

We used the Photon library and cloud hosting for the multiplayer portion of the game.  Although I sometimes like to complain about Photon a lot, it is a brilliant library and service and I would recommend it to anyone looking for a quick-and-easy way to get their games networked and hosted on a cloud.

One thing I learnt about networking is that it doesn't necessarily need to be as exact as I'd expected: Player and beam locations are often not the same on different clients, but damage is determined locally and then distributed.  Ore isn't synchronised at all! When a block is destroyed, its ore drop is determined locally. It is theoretically possible (but hard) for two players to pick up the same piece of ore.  Fortunately the nature of the game is quite suited to this relatively low level of synchronisation.

Visuals

We went for a low-res pixel art style, which (with a talented artist) looks good and works well in the context of a jam.  The surface world look was achieved by having some parallax elements on a seperate camera with bloom. Lots of camera shake and a distortion/wobble effects on explosions help with the juiciness of the game and really adds to the feel.

Closing Thoughts

This was quite a successful jam for us, considering that we won 1st place overall in the jam :). Besides that, we had a lot of fun and learnt a fair amount about networking.  Unfortunately not all the lessons are highly applicable to Broforce, where the players are far more dependent on each other than in Ore Chasm.  It did take a lot of hard work, and we had 3 programmers - doing a networked game isn't really a good idea for a jam unless you have good reason to do so.

I'm trying to develop my blog and skills as a writer - if you have any questions or feel there's some important aspect of the game I neglected - please leave a comment!

Post Mortem

So! The jam finished about a week ago, which has given some time for the dust to settle and for us to collect our thoughts.  This was a really tough jam, a lot of things went wrong and we didn't quite get where we wanted to with the game, but we still had a blast and made a prototype which I hope shows a lot of promise.

Before I start I should say that all opinions are my own and do not necessarily reflect the views of the rest of our team!

What Went Wrong

In short... a lot!

Ambition

We were ridiculously ambitious for our game. Shortly before this jam we'd done really well in Ludum Dare, winning the "Overall" category in the jam with our game Ore Chasm. 12 days seem like a really long time, we have a good idea for how much we can get done in a weekend's time for a typical jam timespan but the longer time threw us out a bit and we set our sights too high.  Doing a 3D game is almost always a terrible idea for a jam, and we wanted a 3D game with different mechanics per level, a strong narrative, unlocks and a metagame, dinosaurs and time travel! Which lead to the next issue...

Spreading ourselves too thin

Working on so many different scenes and mechanics meant we never could give enough attention to any one aspect.  In retrospect we should have cut down on story elements, and probably done either only the driving sections or shooting sections, and fleshed out/polished either.  We spent a lot of time on content that didn't make it into the game at all.  It is common jam advice to work bottom up - make something small and improve on it - but we worked from with a top-down methodology.

The Ouya/Dev environment

As is to be expected from a product in such an early phase of development, we had a number of issues with the ouya itself.  The first and most significant being that our Ouya dev kit didn't work out of the box at all! We were lucky to know a nearby developer who also had an Ouya that we could use to test our game on. Still, this meant we had far less time to test our game on-device than optimal.  Building the game for Ouya and deploying also took up a fair amount of time - compounded by the fact that I had never built a game for the Android environment.  The support given by Ouya staff and resources available on their forums were great though, and we managed without too many troubles.

We also overestimated the power of the device, especially on the video side.  Luckily the visual style of our game suits it being run in ridiculously low res (I think in the end we settled for 270p), but even that in addition to a fair amount of optimisation was not enough to stop the framerate from chugging at certain parts of our game.  Another reason we should have made a 2D game!

Finally, the Ouya controller is kind of... bad. The ouya devs have since responded and are improving the controls so I trust this won't be an issue on launch - but the large input delay and inaccurate axis readings made that our game doesn't play nearly as nice with an ouya controller as it does with an Xbox controller.  In the end we opted for a deadzone of about 0.4! We tried to compensate for the problems by adding in a lot of autoaim, which helps, but does not solve the problem altogether.  By carefully watching the youtube videos of other entries it seems evident that other devs were facing the same issues. Again, I don't think these are massive problems for a product in its infancy and the ouya devs are aware so I'm sure these issues will be solved before launch.

Playtesting

As a result of the previously mentioned problems, we did not spend nearly enough time actually just playing our game.  The controls aren't as intuitive as they should be, the difficulty is a bit haphazard and there are a fair number of bugs present.  

I'm stupid

Yep, I'm stupid.  Only a few hours before submission, I accidentally our whole Mercurial repository by committing stuff with the LargeFiles extension, which bitbucket does not support. This meant that the frantic bugfixing which always happens a few hours before submission in a jam could only be done on one machine. If I had more time I could probably have fixed my repo, or worked out a different setup for our mercurial, but there was no time.

What went right

Concept

I think our concept for the game - having lots of different, semi-repeating scenes getting weirder and more difficult a-la Amazing Wagon Adventure is really strong and if fully realised would have made for a really fun, whacky, replayable and unique experience, while allowing us to do pretty much what we want gameplay wise.  Doing something more narrative driven was also a nice change for us, and we learnt some valuable lessons there.

Aesthetics

As per usual our (one man) art team did a kickass job and produced more content than we could even use.  I really like the visual style of the game. On top of that we had some cool terrain tech that allows us to have rippling terrain and marks on ground, making the game quite 'juicy'.

Mood

Even though it does not come across nearly as strongly as I hoped, I still think we somewhat succeeded at establishing the mood we intended - of survivors on an island encountering increasingly weird scenarios.  We did have a whole story planned out - which would have explained what exactly is going on on the island and tied everything together - but we didn't have time to implement it all.  I think the story screen also works quite well - although the writing itself didn't have time to be iterated upon, and I'm not a particularly good writer.

Gameplay

Although again not nearly where we wanted it to be - I think the game sections are quite fun.  Shooting could certainly have been improved by a lot, but there are a lot of different ways of playing the game, and killing mooks by throwing guns at them is quite fun.

Vehicle section

The vehicle section is probably the strongest part of the game - everybody seems to have liked our laser-breathing T-Rex. It's also a lot of fun to play with a friend, and can be quite chaotic (in a good way!).

Final Thoughts

So, our jam didn't go nearly as well as I'd hoped, and I'm not quite sure of our chances of winning. But still think we have an outside chance, and I think at least our trailer is one of the better ones.  Despite this we learnt a lot in this jam and still had a good time, and we might take the game further if we get a good response.  Doing an extended jam (with prizes!) was a great change and I hope there are more of these in the future - we'd definitely like to compete again. It was great being part of something new and exciting and I'm looking forward to the future of the Ouya.  

Thanks for reading!

Strange Happenings

More progress! Little over 48 hours left to go in the jam, and things are starting to come together. We have enough sections for there to be a feeling of progression, and although we've encountered a few technical limitations we've managed to find workarounds for most of them so that our game plays nice and smooth on the Ouya. We've also come up with a tentative title for our game: Strange happenings on Murder Isle. It might still change last moment but for now I think it suits the game perfectly.  Due to the intense development we've not had as much time to test gameplay as I would have liked but it I do think the game is quite fun and should lend itself really well to some coop chaos.

Here is a photo of the team, hard at work:

And here is a screenshot of our intrepid hero coming tantalisingly close to unraveling the mystery of Murder Isle:

Why is this high tech facility built inside an active volcano on a seemingly deserted island? What the hell is wrong with the warthogs? Why are the mysterious gunmen so intent on murdering innocent castaways? Why is nothing as it seems and most bafflingly, where the hell did the T-Rex come from? Strange happenings indeed...

Turkeys and technicalities

Damn, seems like it's been a few days since I've updated. In the passing days we've gotten round to setting our game up on ouya - only to find out that our ouya is a bit broken out of the box.  Luckily there is another developer nearby that also preordered a ouya and we were able to use that one to test.  Getting everything to work was a bit painful but considering that it's a completely new system, and that I've never deployed an app to any mobile platform, it didn't go too badly. Still, it's never nice to lose time in a jam to technical issues.

Other than that we're finally getting some gameplay together.  We're doing some turkey hunting as part of the tutorial:

Delicious jam

So another day, another scene... sortof. Our car chase scene is starting to come together, it should be a nice change of pace from the rest of the game. Our ideas for the story are also coming together and it should be at least mildly amusing if not good, if we can get it to be anywhere near coherent. Screenshot!

We've been jamming really hard for several days straight now so we are at the point where sanity is starting to waiver, but fully in jam mode so the creative juices are flowing. It's also been cool to see some updates of the other people participating. There are some cool projects by some talented studios so competition will be stiff but I am still confident that we'll have a good chance at winning.  I find it odd that some people actually have booked domains, set up a twitter/facebook/youtube account for their game after the first day, but don't have any screenshots or other signs of progress. But you gotta market the socials, I guess.

In the meantime I'm trying to get the game to actually run on the OUYA.  Having to go through app manifests, downloading and installing SDKs and general technical tomfoolery has reminded me how lucky I am to be able to work with Unity for PC most of the time.

15 Jan progress

Yeah, so I've given up counting days.  A lot of things tend to fall by the wayside in the blur and frenzy of a jam.  One thing that, fortunately, has not fallen by the wayside is progress. We're starting to get the building blocks of story together, our character is almost finished being animated and we have a lot of art content to work with.  Enough for a screenshot:

You can see hints of some of our planned features in this (note kickass explosions, terrain scorch marks and deformation).

Yeah. Explosions.

Day...4?

So we've been working semi-hard over the weekend, progress has been good but not amazing.  The visual side is coming together slowly - we have a model or two, lots of terrain art, buildings, vegetation and other odds and ends. We want a high amount of content and polish for this game so we're doing a low-poly 3d look similar to what we did for Death Smashers.

Programming wise, I've implemented some basic enemy AI that I hope will be interesting to play against - enemies take cover and try to move to safety as much as they can, but occasionally charge the player. The idea is to have something that appears to be more intelligent than it actually is - and it looks like I've succeeded in that. We've also worked on effects and overall juiciness; marks on the floor (along with a weird terrain wobble effect, pretty cool), rippling water and Death Smashers explosions. Tomorrow we should have animated player characters, when that has been integrated along with the destructible buildings we should have our first chance to have a good feel for what the game plays like.

Day 1/2

The jam snuck up on us: on Monday I was still really keen to make good progress on Broforce.  The wording for the competition is quite vague and initially we'd hoped we might be able to enter the new version of Broforce. Understandably though that is somewhat against the spirit of a gamejam and we were denied.  We had some discussion on Tuesday, a jam with prizes such as this one is really hard to resist for us and we decided to go ahead. The catch being that if we participate, we HAVE to win at least one of the prizes (preferably the main prize) to make up for the development time lost on broforce. A big risk, but we are confident. Time will tell...

We had some discussions on gameplay and theme: We want to do a fast-paced top down twin stick shooter, with a strong emphasis on coop gameplay and narrative. Gameplay references are, well, any twin stick shooter, cannon fodder and broforce. Thematic references include Cadillacs and Dinosaurs and The Amazing Wagon Adventure.  The organisers of the competition encourages people to start working immediately, and considering the stakes we went right ahead. While our artist is pumping out concepts, we got some base systems in place: basic twin stick movement, some pathfinding for enemies and projectiles. We have a lot of code that we share between projects that had to be converted from 2d to 3d as well.

CREATE GameJam

Hi, I'm Ruan, and I work as a game programmer at Free Lives (www.freelives.net). We have decided to take part in the CREATE gamejam hosted by Killscreen and Ouya and I want to chronicle our progress as the jam progresses. The closing date for entries is on the 23rd of January, hopefully I will be posting more-or-less daily updates on our progress.