#5 Problem solving and finding new ideas

If you are an aspiring artist (designer, author, ...) you certainly know these moments when your mind is totally blocked. No matter how hard you try nothing comes to your mind, not even a single approach to solve a problem or a new idea.

Solving a problem often requires time (i.e. incubation). It is similar to a computer which needs time to calculate a complex equation or a constant (e.g. pi). In the meantime it might be best to focus on other tasks. Your brain is doing the job and the solution or a part of it will come to your mind when it is done. Sometimes you need another attempt and go into detail again until you have the final solution. Nevertheless, to focus on solving the problem too much might be counterproductive.

From my experience development in general is a process which evolves over a period of time. You can hardly force yourself to generate new ideas. Ideas are like different parts of a puzzle: you find one part at a time and if you collect them you finally are going to be able to create a the big picture (i.e. your concept). Collecting parts means writing down or sketching the idea the moment it comes to your mind. Afterwards you can take the new part and check if it fits to another part. Therefore, an appropriate knowledge management might be very handy.

If you think "blablabla it still does not help me to find a new idea": You are right! Did you know that innovation often results after combining already existing ideas? Do some research and analyse which approach other writers or developers chose. In addition, sometimes it is helpful to combine ideas or approach from entirely different sources (e.g. something which has nothing to do with designing a game, writing a story or dissertation, ...) and generate something new.

Apart from these points, it is not always required to reinvent the wheel. Keep in mind that "new" not necessarily means "better". Some ideas are innovative but at the same time just rubbish. To prevent this outcome, it might be wise to critical reflect whether the idea is useful / practical, coherent, ..., feels good or appropriate, meaningful and so on.

Transferring these findings to this game: I did some research how camera movement and angles were implemented in other games (e.g. in Skyrim, Valheim, Elite Dangerous,...). I started the game, moved the mouse and asked myself: Is the movement intuitive? Does it feel good or even annoying? Where is the location of the cursor? Which body parts do move? Is it possible to look down on the ground or up to the air? To be honest: I abandoned Elite Dangerous weeks ago because of the (at least for me) painstaking controls. However, I do not intend to implement any flying controls so far.
Focusing on player camera movements (first person): From my point of view the camera movement of Skyrim feels very smooth and intuitive. Moving the camera sidewards results in rotating the whole body. Moving the camera up- and downwards results only in changing the angle of the camera. Furthermore, a centered cursor feels somehow normal. In contrast, it felt annoying to have a cursor which reaches the top / bottom of the screen after moving up-/downwards, especially if the camera can move further up-/downwards. Therefore, I did adjust the camera movement similar to Skyrim.
As you can see in this case I did not reinvent the wheel. Sometimes it does not make sense to develop something new if there is a solid approach. Nevertheless, it is useful to try different things out and check how it works and feels.

#4 Priorities

Indie game development usually goes hand in hand with a lack of resources. There are dozens of ideas but never enough time to implement all of them. Therefore, it is important to set priorities appropriate. 

Every idea contains different tasks and every task requires a specific amount of time to finish. For example, if you want to implement a walking animal you need to design a model, create and add textures, program the code required for the animation of the body parts, add a sound for the movement and so on. Depending on the level of detail you need more or less time. For example, if you want the walking animal to be realistic it is going to be very time consuming (e.g. creating a realistic model and very smooth movements).

Does this mean you should not invest time to polish your game if you are an indie game developer? No, it does not. If your idea is a core feature of your game (i.e. this makes your game unique or if it is essential for the game in general, e.g. controls) invest the necessary time. If it is not a core feature it might be wise to set the idea on the list "nice to have".

Transferring these findings to this game: Most likely I will not be able to implement high end graphics (e.g. no detailed facial expression, no high resolution textures). Nevertheless, I want the game to be visually appealing. When it comes to graphics I will focus on a more abstract and artistic approach. The models will have less polygons and no textures but diverse colours. In addition, real time shadows shall help to create an unique atmosphere.

The following picture shows a part of the game's test environment:

#3 Concept and mechanics

In the last blog post I mentioned the game concept and mechanics. Let us go into detail.

Before starting the project I did some research about do and do not when it comes to game development. Several indie developer emphasised the importance of a good concept. Well fine but what the heck is a concept?

According to my understanding a concept guides you through the process of development. For example it can contain a vision, goals and steps how to reach the goals. This includes the way how the game shall function as well (i.e. game mechanics).

Why is it important to think about all these things early in development? The earlier you know which things are required and how they shall work the less time, effort and money you need to invest in development (this is not limited to games; it is important when it comes to software in general). The further you are in the process the more resources are required to change all the things you already did.

Speaking of concept, a good knowledge management is essential. While progressing in development a concept not only becomes larger but more specific and sometimes more complex. How to organise all these information? Especially more complex information can be tricky to organise (e.g. game mechanics). Tables and charts are great for comparison. However, dependency between elements hardly can be visualised. Quite helpful are network visualisation tools (e.g. relationship visualizer as a free extension for microsoft excel in combination with graphviz).

The following picture shows the game mechanics (e.g. how elements depend on each other) in the current state:

#2 Realistic expectations / game preview

If you are one of these gamers from the last century you might remember the (good) old times when you bought your favourite pc game magazine, including several compact discs (hell, it sounds so old fashioned to spell this word out) with dozens of drivers, videos and patches. That was great but even greater was the demo version of your most and long anticipated game!

Since then, times have changed. Broadband internet made it possible. These days you can stream and download videos, games and patches within minutes. The development of video games has changed too. Many studios shortened their development time and released their games earlier. Early access and co-creation have become popular. There are not many demos left out there but plenty of games with early access (ranging from early unstable alphas till polished betas). Early access is a controversial topic, some love it others hate it. On the one hand, there is big potential because you might even co-determine what is going to be implemented in the final game. On the other hand you might be disappointed when you cannot co-determine or if features are being promised but not implemented. Long ago this was different; you got what you got and in most cases the demo version you played was a small part of the almost final version of the game. There was less to expect because you had less promises and you could not influence the development. There were several game magazines where tests of games with pros, cons and features were published. If you think, nah, that is not totally true that in past less was to expect, you are right. Publisher made false promises back then too and not all the tests and ratings were accurate. In contrast to the past, today on most platforms customers can rate the games after purchase. This is great because it increases transparency. 

Besides the early access, expectations have changed as well. For example 25 years ago big pixels on the screen were just normal, today high resolution textures are often either delivered or expected. Looking back and thinking about all the games which made fun playing, from my point of view few had outstanding graphics. Most of them were and still are brilliant because of their concept and their mechanics. 

To conclude: what remains is the fact that the own expectations and the final game can differ. Early access did not change that fact, nor did the possibility to rate games on platforms (there are plenty of games which were published long time ago and still receive many negative ratings and comments). Being a part of a development process means being a part of a change process. A change sometimes ends like expected. However, there are many examples when things did not turn out like expected.

Transferring these findings to this game: Unfortunately, I do not have the resources to develop the game in an iterative way like most early access games do (i.e. an on-going adjustment of the game based on the ideas of all the players). This does not mean that your ideas are not welcome, not brilliant or not worth implementing. It just means that I want to prevent wrong expectations and false hopes. I hope you are fine with that.

Nevertheless, pictures and videos shall provide an insight into the game and I intend to publish a demo version before lunch.

#1 Let's get the struggle for life started

Hello and welcome to the development blog of [qylor]!
[qylor] is the name of a computer video game series. Its first episode - archetype - is being developed with unity, using blender to model objects and audacity to record and process sound.

The game is currently in a very very early stage of development and the first episode is going to take several years until launch. To be honest: It is not going to be an triple-A title but (hopefully) an unique game experience!

Since I was a child I have been fascinated by survival. For several years I fought dozens of fights... well okay, just with toys (Lego)... but it was great fun! No it is not going to be a Lego game but the idea of survival remains.

Survival as a genre has recently become quite popular when it comes to video games. I enjoyed playing different games of this genre (e.g. bermuda project, s.t.a.l.k.e.r: chernobyl, minecraft, stranded series, ark: survival evolved, rust, the long dark, osiris: new dawn, the black death, raft) and others with some of its elements (e.g. gothic series, elderscroll series, mount and blade: warband, kenshi, freelancer, far cry 3). Of course there are plenty of interesting movies out there too (eg. riddick, 28 days later, cast away, I am legend, into the wild, everest, the martian, u-571) and I guess books as well (I have not read that many, only red planet and the comic series prince valiant).

So how is the game going to be? Well, it was utopian to even think that it will include all the great things of these games, movies, books. However, certainly the development will be inspired by some of its elements.