Estarei em Palmas, Tocantins, nesta segunda para falar sobre desenvolvimento de jogos.
I decided I needed a more informal place to write and make unpretentious (and even unprofessional) statements. So I made this blog, which is also a HUB for all my virtual persona figments. Let’s just hope I can bring myself to update it often.
Well, over than one month after Oniken’s release, I guess we are in a good position for discussing what went right and what went wrong at launch. But, before I start, I’d like to note this is a plan for a indie game launch. Really, really indie. This means, we had the total amount of zero dollars to use for communication even though we recognize communication is one of the most important things in any game launch. As such, all strategies used on Oniken were thought to maximize our coverage in all ways possible counting on press only, since no dime could be expend on ads [I´m including paid reviews on ads sections since there is not much difference in the financial point-of-view].
The right time is of the essence
First of all, I’d like to point out Oniken is a two year and three months project (it began around March of 2010), which most of the this time was of development in silence. Of course, the project was discussed between friends and in some internet forums, however the total number of people who knew about the project was probably around 15, at best. On May of 2011, more than a year before starting the project, Danilo set a dev blog on Blogger [now oniken.net ], where he posted about Oniken’s development. This blog was, for a long time, one of the most important thing your game will need at its early communication stage: a landing page, where anyone on the interwebs can gather relevant information about your game.
But even setting something simple as the landing page involves a tricky thing: timing. I believe one of the most important things on Oniken’s development is the exact timing of the creation of this land page and I’d like to suggest it to any indie and small developers around. No one knew about Oniken when it was alpha and that very important for the first stages of the development of a game because, during this period, many things change and devs need to move on fast. If tour game already have a big commotion around it, changing anything can make many fans upset. This, by its turn, can lead to other two dreadful things: or you will get attached to features that won´t add up to [and might even harm it!] the final game just to not disappoint some fans or you might change those things and gain some haters. And boy, those guys can hate your game and tell everyone about it.
Something equally important at this stage: no, the press is not interested in showing up something that doesn’t even have a face yet. I see some some young folks sometimes with nothing more polished than an prototype going nuts after game journalists, trying to publish their stories by all means. Don’t be this guy. New game projects are started all the time, but not all of them have developers that can take the project until its final stages, and journalists know that. They write about good stories that have any future and, with all the respect, a prototype is not a good story yet. It can be, if you put enough effort into it, but if the journalist says it can´t write about your game yet, don´t push the line: you are not only making him not write about your game now, but probably also making him not write about it for ever.
When Danilo set up the blog, Oniken was more than a year old; it:
- had all main mechanics and plot set up;
- was half-way done;
- had its all art direction and style defined, even though not all of it was done.
So, it was a pretty mature project, on its perfect stage to be known. So, please, write this up in your bathroom mirror and read it every day: Don’t show your game to the world until it is ready for it.
Ok, so in May of 2011 we had a working game, Danilo and Pedro were developing Mission 4 and we had a free beta (I´m not discussing betas and demos here for the lack of time, but they are really important to let people know how your game feels; don’t underestimate them). Good time to let let everybody in press know about it, right?
With Oniken we were really luck to know someone in Brazil’s Kotaku. Marcus wrote this lovely post about Oniken on July, about two months after Danilo created the blog. Marcus post literally put Oniken on the map of brazilian indie development, but everybody knows home market is not enough to any indie game: indie games already gather not so much interest as AAA, restrict it to on country is like building your Minecraft cowshed all around one cow: not very productive. Luckily, IndieGames.com also posted this great piece on Oniken about the same period. These two posts enough to multiply by 10 our monthly views.
After all this exposure, we knew we had to keep Oniken on people minds, but we also knew we had, at least, six months more of development and not many “pressable” things to announce expect for Oniken´s main feature: its 8-bit aesthetic and fell. So, we slowed down contacting press people, but we actually never stopped doing it also. Here are some noteworthy posts of Oniken during this period.
- PixelProspector on July
- PCWorld about Oniken’s beta on August
- IndieGameMag and Destructoid on September
This is how Oniken’s dev blog views stats was like:
So, we have already talked about the basic rules on Sky Castle: the economic progression based on levels, the cooldown time influence and also about other limiters, as food and space. Now we can finally discuss a bit more about the essential thing on the game: its rooms. But before we talk about the rooms themselves, let´s just remember what is SkyCastle´s narrative background.
Player takes role of the surrogate king/queen of almost broke castle. Actually, that´s no ordinary castle, its built on the top of a flying island. So, the main theme around the game is a fantastic medieval setting, which is visible not only on room´s design, but also on characters clothing and on the choice of words used and rooms characteristics, as we will see. However, we didn´t want to take this setting too serious, and instead we mixed references from both medieval periods and modern times. For instance, if you take a close look to the Ballrom or the Mask Shop designs, you will get what I mean.
It´s very important to determinate the game atmosphere and that all the creative is in the same page about it. As I have stated, SkyCastle had a fantastic medieval setting but didn´t took historic context too serious [for Thor sake, it was a flying castle!] and that says a lot about the game atmosphere. We also wanted to keep a lighthearted space, so one of the narrative/art priorities was to also have humorous bits. This atmosphere must be reinforced on every element possible in the game, as on its looks, characters, interface and even game mechanics. We will talk more about how atmosphere influenced other design parts later, so let´s get back to the rooms.
I started with a list of 10~15 rooms the previous designer had imagined, however they had no data except by their name. From this list [which was converted to a spreadsheet right away] , I could add more variables [as price, cooldown time and rent, which we already discussed] and started brweing more and more rooms. It´s important to state that I didn´t get to the present numer of rooms all at once; it was a natural and slow development that took the period of weeks and, as I don´t have the previous records of the spreed sheet, here it is on its final state, with almost 70 rooms.
Below, there is a preview of the rooms info, fresh from the game itself [if the spreadsheet doesn´t show, please refresh the page or click here].
Type column represent with of the four kinds of room that was, being red food, green hotel/residence, purple commerce and blue were functional rooms that changed/improved gameplay our produced items. ID was the name that the room was saved on our game, its system name, while Room column represented its visible name to the player. Lvl column stated in which level the rooms would be available for player to buy it [though it was already visible some levels beforehand]. Both goldprice and manaprice stated rooms´ price, however some rooms costed gold while others were available only through mana, depending on which column had a value. Descrip. was the visible description of the room player would have when clicking for more information before buying it and time stated the cooldown time before collecting next rent [please not that not all rooms produced rent]. All columns below Requires cell (reqRoom, reqItem, quest, place) are requirements for building that room, being reqItem and place consumable while reqRoom and quest were not. NeedFood is the food allocation that rooms would use as active (in the case the room was sold, its allocated food was free again, as we discussed on our previous post). XP was the experience resulted in buying the room, goldgain was the rent it generated, manaChance was its possibility of generating mana every time it produced rent. We will talk more about research and allow columns later, givenFood was the food that the rooms could make available [only food rooms] . All other columns were reference data, so not very useful for our research here.
Almost everything we previously study culminated in this spreadsheet. For instance, the economical progression is visible on rooms price, while the result of this progression processed by cooldown times is the main determinant factor of rooms rent. There is a small smoothing based on room´s size, for instance a bigger room must me more lucrative than a smaller room in the same level while not being much more expensive, since it occupies more space slots and player had a limited amount of those. Even though player could get more space, those were bought, and not very cheap, so even not paying much more for a bigger room itself, its implied costs were bigger.