New website, post-portem, Indie Buskers

Welcome to the Rat King's shiny new website! The old one was pretty worn-out, and it was made in a time when we didn't have much projects to show. After a year and three months, and after several game jams and two iPhone games, this has changed! So the front page now is dedicated to the games we made, and eye-candy is everywhere to be found. Enjoy!

In other news, Friedrich wrote a post-mortem about our Seven-Day-Roguelike Challenge entry, Me Against The Mutants. The game was made for the challenge AND the Pitman Birthday week, so a review of the game's creation was just mandatory.

Last, but not least, some of you may heard that we are part of the Indie Buskers!

The Buskers are a group of indie game developers who happen to have a thing for game jams:

They also are not very rich. So they decided to make a public game jam where they create games based on suggestions they got from people all over the world, and accept donations while this game jam happens. The Busking is set for the midst of this month, so visit us on April 14th to 15th!

Me Against The Mutants: post-mortem

Before we began to create "Me Against The Mutants" we had other ideas for our 7-Day-Roguelike Challenge entry. All a roguelike needs is a turnbased gameplay with a walking player and some enemies – and then you add things. Things like different zones, the ability to break walls, end-bosses, etc.

So our first real idea was about a prince who has to be protected by several amazons. You would play the whole group, and while amazons are good at fighting, collecting items and other stuff, the prince would be a whiny weakling with no skills at all. But as soon as he dies your mission fails, so you'd have to use the amazons as his wardens.

We liked this idea very much, but unfortunately it transformed into a full 7-day-roguelike and even beyond, and we had to plan for something with a much smaller scope.

We knew we wouldn't have much time during that week, so after some rethinking we scratched the concept and went for a simpler approach: the player is in a world full of radioactively contamined mutants and has to use "infinity fields" in order to reach places and get rid of enemies. Why was that easier? Because it means focusing on a single gameplay mechanic (the infinity), which we invented a year or two ago but never used it for anything. This way, we could concentrate on the basic mechanic of roguelikes not just by making a simple clone, but rather by adding something new to the genre which hopefully doesn't need so much work.

Of course, it was much work and there still were problems. No matter how small the focus of a game is, the whole thing at least needs some time to become an actual game. However, the technical hurdles of "Me Against The Mutants" were bigger than anticipated. Even though I already tried the infinity mechanics via smaller prototypes, I never implemented it with entities other than the player. When all the tile-based movement of the player finally functioned inside an infinity zone, it became clear that the current implementation would not work with the enemies. A big modification of the code was necessary, and for some hours I even lost all hope to get it to work again as error followed error every time I tried to compile the project.

In the end the whole thing was worth it, although it cost me a whole day – not only the player could create infinities and enter them now, but also the world and its inhabitants were able to do so. Thus the idea of the radioactive zones was born, and now the player had to be careful not to walk into a "natural" infinity field unprepared.

One decision we reached very early was to make the game realtime instead of turnbased, i.e. NPCs and monsters can move and act all the time. We are still not entirely sure if this was a good decision (as it is a downer for many fans of roguelikes), but somehow it makes the game more dangerous and it complements the infinity fields.

As "Me Against The Mutants" is very small in focus, there is not much variety; in my opinion realtime helps to tighten the gameplay in this case. Would it have been turnbased, people would get bored of the pretty obvious AI very fast.

Learning from our first 7DRL "Pitman", balancing issues were less crass this year. I will never make a game again were a fight could go on for hours because both parties are too weak and too agile so one combatant would never hit the other (which happens in "Pitman" quite often). Hence the mutants all have their basic damage and the player has his basic damage, and both cannot be zero (only very low). There are also much less stats – and in hindsight even with six important values only (Attack, Defense, Speed, Health, Mana, Stamina) not all of them make sense ...

For instance, a varying speed of the player isn't much of an issue for the gameplay – even though having different speed for every character was one of the reasons we wanted to have realtime gameplay!

It's also essential that the self-created infinity fields don't exist forever, so a tactical course of action is desirable; but I was never quite content with the approach of using mana. If it drains too fast, the infinity isn't much fun; but when it drains too slow, it doesn't make much sense in the first place. Either way, automatic mana regaining was needed – which made the mana refill containers I placed in the world useless in the end.

The differently coloured slimes are another part of the balancing act. As the game has no concept of the player's progression level (it is far too short for that), we invented another way of changing the player's various skills: slimes. In the beginning, when we thought we could add much more things to the game, the slimes would be large radioactive pools and change everybody around them. They would have been the real reason for normal creatures suddenly being mutants. As we never really had a plan how exactly that would happen and also not the time for elaborate mutations, the slimes became the simple, but double-edged swords they are now. They can boost the player or make him weaker or both – the effects are random, but don't change per colour, so every red slime in the world does the same. Of course, sometimes the God Of Randomness decides that every slime colour has to have mostly negative effects, so this gameplay mechanic really could benefit from a little bit more thinking.

The slimes are also one of the reasons why there are bunnies outside the contamined building. The little rabbits were planned as creatures not yet mutated but with the possibility to do so. As the game progressed only slowly over the week, it was clear that they would regress to decoration.

But they also serve as a tutorial – the player can approach the bunnies, hit them and even backstab them without having to fear them to counteract. In fact, the whole outer region, the grassland with the forests, was planned to be a dangerous zone but instead it is now an interesting contrast to the mutant-infested building. Somehow, it promises some kind of peace and happiness this way.

On the other hand, our roguelike is missing handholding at the beginning, and some people were really not sure what the game was about and how to control it. Sure, they could have read the instructions at the start of the game or below the embedded SWF, but never one never should expect something like this. Nonetheless we like that the game is even more about exploration this way, and the first "Aha!" moment when you get into the building is really fulfilling.

 

About the graphics: pixel art was an unconquered field for us. We mostly dabble in the third dimension, so concentrating on single dots instead of polygons was a small challenge for Jana's skills as an artist. Nonetheless we were eager to try it, and it also convinced us to make a full game with pixel graphics some day, as they are neat and have an abstract style which can make forget the lack of detail. And even though retro pixel graphics already are widely used in the indie gamedev scene, the pure form of the pixel still can produce novel looks and an interesting atmosphere.

Conclusion

What went right?

  • learned a lot about 2D pixel graphics
  • game was finished within time
  • interesting gameplay mechanic, even worked as intented
  • small scope, lots of fun
  • used Flash, which works on all desktop computers
  • sound and music!
  • featured on freeindiegam.es and rockpapershotgun.com, woah

And what went wrong?

  • stupid coding problems
  • not much time
  • balancing still an issue
  • very sparse in content and variation
  • some people are confused about what to do and how to do it in the game

Indie Distribution Platforms that are not Steam

(The original posting is in German, on Indie-Inside.)

Foreword - Sale Week

Last week (March 10th to 18th) the annual 7-Day-Roguelike Challenge took place – the event for which Pitman was developed last year. That's why our yellow dwarf celebrated his birthday that week, and because the 7DRL Challenge always gets some attention, we decided to link it together to a sale.

Our roguelike is available at four PC distribution platforms: Indievania, IndieCity, LittleIndie and Desura (+ the AppStore). So we reduced the price to $0.95 / €0.79 every day at one or two sites for three days each. We also offered a few goodies or articles on our website daily.

In retrospect this sale was not only a good marketing campaign, but also very helpful to find out about the strengths and weaknesses of our four platforms.

Of course it would have been great to have self-distribution on our own website additionally (as it was indeed the place we referenced most times in our sale), but unfortunately this is planned for our web relaunch in the near future and wasn't available yet.

Indie Distribution

The four platforms are characterized mainly by low barriers for an entry; i.e. you send in a game, it gets checked and reviewed, and often it goes straight to the market with no major problems (except for Desura, where we had minor troubles with the file upload).

So if the splendid Steam Store is denied to you or you like to put smaller titles (e.g. jam games) outside of your own website or offer your product indie-compatible – you hit the right spot here.

Of course, Steam is the largest provider and has the advantage of a high number of users. However, most indie platforms – like many indie developers as well – often only have other developers or the not-so-big indie scene as players and multiplicators. Platform owners often expect that the developers bring the players (aka buyers) already with them and thereby keep the cash flowing. Thus, the scene just fertilizes itself and the few larger indie platforms remain hidden from the "normal" players.

Desura might be known by linking up with the Indie Royale bundles, since you can load their games with Desura keys. But for most games Steam keys are also available ...

In the future it would be nice other platforms having a chance next to Steam, as in my eyes monopolies are never positive. While Steam guarantees a high quality, the reviewing process is too opaque for many developers. Desura or IndieCity for example also allow the presentation of a different kind of games that would get (even) less attention.

Okay, enough about my plea to not only promote Steam, but to aim for at least another platform. However, you have to be aware that the effort you put into marketing for a platform does not always bring about the expected profit.

I was wondering what is used by other developers and what platforms do not work (anymore)?

E.g. Play Greenhouse by Penny Arcade has folded, unfortunately: "Apologies for the inconvenience, but Greenhouse is temporarily offline for some ... upgrades. We'll be back soon! " – the last Twitter entry is from 2010.

Indie distribution compared

Little Indie

little indie screen

- since August 2011
- 13 games + 3 new releases soon
- wide price range and very different genres
- DRM or DRM-free / client
- Little Indie highly values achievements
- Cloud-functions, matchmaking, multiplayer, lobbying (direct server selection) are planned
- regular news on Facebook and Twitter about new features on the client and current titles and sales
- bank transfer, Paypal

- from the review of the game until the start: a few days
- contract
- upload via SVN / SSH
- demo on the platform
- sales and updates are set by operator
- revenue share is negotiable
- payout: quarterly from € 20

Pros:

- close contact with the operator, responds quickly
- you don't go down in the masses of games yet
- individual compilation, bundles, Alpha Funding, Keys
- Forums, blogs are available
- Support Center (client-> developers) for bugs / problems

Cons:

- very low popularity
- the project, images, demos, page texts can not be adjusted by oneself via an interface
- Windows-only
- only rudimentary backend for developers (sales / hits)

little indie backend

Indie City

indie city screen

- in planning since 2010, started publicly since 2011
- >140 Games
- most expensive game: Cardinal Quest € 10.00
- very different, small, cheap games
- DRM / client
- regular news on Facebook and Twitter about new features on the client and current titles and sales (a Twitter account for players and developers each)

- there is no payout yet (tax law issues are being resolved)
- revenue share: 25% to platform (currently); with integration of achievements / leaderboard system only 15%

Pros:

- adaptive recommendation system in the client
- very good support, chat (IRC) and forums
- edit everything through the backend: project settings, updates, pricing, etc.
- do occasional promotions for developers (marketing week, pimp-up-your-media week)
- Tweeting and blogging very often
- relatively simple upload system: upload one EXE file together with game data in a ZIP, gets automatically wrapped into an installer
- Demo upload possible

Cons:

- many features are still in beta or not available at all (but marked with some yellow post-its)
- low popularity
- Windows-only
- payment via Credit Card only
- Annoying limitation of size (and number) of the images when setting up the project
- very simple statistics, no breakdown

indie city backend

Indievania

indievania screen

- since 2011
- >250 Games
- extremely diverse genres, quality and prices
- DRM-free / direct download
- regular news on Facebook and Twitter about current titles and sales
- payment via PayPal

- authorization of the game: only a few days
- upload through Amazon S3, no restriction on upload format
- money is transferred immediately after purchasing to the developer (no platform costs)
- responded late to the announcement of the sales, but then we were listed in“featured” and “specials”

Pros:

- download games without client
- Very good back-end, relatively detailed statistics
- customers may pay more; pledge, pay-what-you-want
- bundles, keys
- sale section for special sales in the backend + Twitter announcement (at least in the case of Pitman)
- Windows / Mac / Linux / Android / PSP / keys for Steam

Cons:

- relatively low level of publicity (during our sales week we got some more buyers, though)
- Paypal costs way too much for cheap games, when the micropayment option isn't used / cannot be used
- no demo upload to the platform

Desura

desura screen

- since 2009
- from very cheap to expensive higher-quality games
- DRM / client
- regular news on Facebook and Twitter on current titles and sales
- Paypal, Visa, MasterCard

- transfer from €500 (minus fees)
- platform fee: 30%
- sales must be requested

Pros:

- substantial increased sales opportunities by IndieDB connection
- biggest indie sales platform (after Steam)
- very good connection to the devlog system IndieDB and modding counterpart ModDB
- linked to Indie Royale
- Alpha funding possible, in own category
- Demo can be uploaded
- Windows / Mac (limited) / Linux
- very detailed backend, with very good statistics
- referrer bonus as soon as buyers come from your own website

Cons:

- 30% share / payout with minimum of €500 is a hurdle for smaller games
- relatively complicated upload system for Mac and Windows: Windows / Mac / demo must be uploaded in two versions (I.e. 6 different files that need to be uploaded when doing an update of the game); purchase link in the demo must lead to Desura

desura backend