It has been approximately 2 months since we released our puzzle game Fabric. So while probably it’s too soon to write-up a postmortem, there are certain issues I’d like to talk about. I’ve been aware them during development, but I think calling a product ‘finished’ makes its issues much more eligible to be discussed.
For those who are like “Fabric? wut?”, it is a first person puzzle game on Steam, which also happens to be first (game) project I’ve ever completed.
Using Visual Studio when working with Unity is awesome and Visual Studio Tools for Unity takes the comfort even further. Since Unity’s 5.2 upgrade, VSTU comes integrated with VS. Though with this integration, the developers took away some of the flexibility.
For instance, I would like my VS to have a very clean view. VSTU’s relaying Unity’s Debug.Log’s to VS’s console spoiles this neatness a considerable amount, since it opens and re-opens console window without my permission, as log prints keep coming. Before 5.2 integration, it used to have a nice configuration menu wihtin Unity, where one could toggle this feature. Now, appearently, there is not.
(EDIT): There is now with version 2.3. The code below is unneeded now.
When I asked, the developer was kind to give the answer, which is an editor script that toggles console redirection:
In many Unity projects I’ve worked on, I’ve encountered those green spikes seen in the profiler, under the name Gfx.WaitForPresent, which chops framerate down to hell. This basically means that CPU’s waiting time for GPU to finish its job, in other words, that spike you see is not the problem itself. I guess it probably indicates that some rendering.. thing.. is horribly conflicting with another, and my googling failed to give me a definite answer of reason why. I’ll mention some options to try, mostly compiled from here, for not having to look at the same inconclusive forum threads again and again. Some of them doesn’t make any sense initially, or may be fixed in time, but lack of definite solutions made me keeping them here anyway:
OK, this is sort of a more personal entry where I blabber without reaching any kind of conclusion.
When you work for some company, your primary concern probably becomes money. Of course, you might like the people, the work you do, the game you are making. But you need money, and you are working on that game for money. If you aren’t making that game, you will be starving. On top of that, you have resource limitations, like time, money and people. Eventually, the game takes shape around those resource limitations; features added or cut, parts of story being cut, some parts of the game itself being cut, voice-overs being cut etc. Even with all the initial planning and designing, you witness a great deal of sacrifices for the game to be released, and, you guessed it right, to make it bring money.
When you go and think about creating a game, you try to define the experience and visualize things in your mind. There is a scenery which you try to achieve through the development process, a scenery in which you want to make the player… sense the experience you designed. You design all the components of the game pointing in this direction. There is a reason for each.. thing in the game to exist, a reason given by you. Everything that you put in the game together form that experience.
From what I understand, this first “Oh my! That’s totally gonna be so cool!” design, is somewhat personal. People usually fail to deliver this enthusiasm to people around them, so they get the game done by themselves. Or if they are not alone, they get to decide on important matters. The “other” team members are of course contributing to the project, but mostly by doing the tasks given to them.