Tag «Tri»

#04 – TRI – Play-testing and a dogma

Just 1.5 weeks and the TRI pre-alpha plus demo will be out! This means testing, testing, testing. This article is about what makes TRI so special and which problems it breeds, too.


Typical pre-alpha problems

We decided to make TRI as early available as possible. Not only to fund our development, but also to get feedback for game design decisions we made. To provide a smooth pre-alpha experience in this early state of development, we tested as much as possible.

Here are some thoughts I had on game design elements and a certain dogma we developed over the time.

1. "What is the goal of this game?"

The biggest problem we faced in our pre-alpha was motivation and a clear main goal, which is mostly the same thing. The main goal is some kind of McGuffin which triggers the player, like “Rescue the princess!”. It is not really necessary, but with it you can build a chain of suspense – as soon as the player reaches one spot, lead him to the next one ("Your princess is in another castle!", haha). This could be the motivation.
But more important for me is the flow that happens when you fully become one with the gameplay. Which was enough for us playing around, as we knew what the game is about. We had a story in mind, but totally focused on gameplay. Because of that at some point the testers wondered what the game is about and what they're doing.
Our early testers started without knowing who they are in the game, where they were and what they should do. Amnesia? Shouldn't that be enough to just find out what's going on and explore? … no!
Although the starting area is linear and very streamlined, people need a certain motivation – where they are heading to and why. Some kind of progress bar with story.

Although gameplay alone should be enjoyable, you might give the players some starting mission/quest/task to let them know where they are heading to. This keeps up motivation and helps finding a way through dead ends (and even recognizing those dead ends).

Character reading scroll

2. Feedback and rewards

Implementing sounds is very often the most neglected thing about games. Just adding walk-sounds give the player the impression she really is 'in' the game, first of all in a game where you can't see the character you are playing.
But there are also feedback sounds that are really needed because of our puzzles. Switches, doors, laser beams and little ghosts (Kami) appear repeatedly. Without sounds people often don't recognize that there is something happening at all. Or that a certain element changes its status (from open to closed, activated to deactivated).
Even if the sounds you have at the beginning seem shitty, you should implement them to help your players.

Another feedback is light or markers. In our game we have special switches to open doors: you have to assemble crystal holders with a crystal to guide light rays through them. Which means they have three different phases of activation: 1. The crystal is just lying around (no light). 2 The crystal gets a bit illuminated after combining it with the holder. 3. After sending a ray through it, a sparkling particle effect appears.
In the early tests players put the crystals into the holders, expecting that this was enough. But we want more from them - activation through the light rays!
Those mechanics enable some fun puzzles, but also needed proper feedback in the game to tell the player that there still is something to do: there is an empty pedestal – find a crystal and put it on the pedestal – AND activate the crystal via a light beam by deflecting it – only then a door opens or so.

Give objects as much feedback effects as possible. Sounds don't just add atmosphere, they are often necessary to communicate progress. Of course, without stupid flying cameras showing the goal or pop ups informing you about your next target.



3. Design of game objects

As you might have read, our game is mainly inspired by games like Portal (puzzles, first-person mechanics), Thief (level design) and Zelda (puzzles). Although TRI uses typical game elements like levers, doors, switches – things to activate and deactivate, we have the entitlement to integrate these game elements as naturally as possible. Which means that they shouldn't blink spastically or permanently rotate around themselves, but players still should immediately recognize which elements are those to interact with.
This was and still is a great task for us. Portal, for example, used huge switches on the floor plus stripes that lead to the doors they activate. Those game helpers are extremely clever, but also very clumsy. (You can get away with it, though, when you call your levels “test chambers”.)
It is always a challenge for game designers to combine a reality the game tries to create with game objects that convey rules.
Modern games disappoint me, primarily the photo-realistic ones, which try to re-build reality with floating weapons waiting for you to grab them and huge arrows darting in the direction you have to take. Less seems to be never enough, sadly, but it is our duty to find out what is enough for players, before using clumsy out-of-the-world game objects like giant arrows.

crystal holder
4. Non-linear versus linear

Something that most of our games have in common is a certain non-linearity. This means that our level design or decisions a gamer is able to make will always be as free as possible. We hate invisible colliders, tube-like levels and decisions that unnecessarily limit your creativity. This sounds cool, but is also very ambitious and hard to convert into gameplay. Particularly when gamers these day start loving their tubes.
With TRI we try to master the balance act of free choice and leading level design. How accessible do we want the game to be? How many elements should get activated automatically?
We decided that creating your own platforms wherever and whenever you want should be enough non-linearity, at least at the beginning of the game. Because it is important to understand the game and its basic elements without too much distractions, the layout of the first few levels is still fairly linear.

The look of game objects and the decision whether a game is linear or not, is determined by your choice of target audience. Casual players with not too much time and experience – or people that love to dig deeper to explore a game? I would love to see the players start the game and explore on their own, find out what is possible and search around. But players today are spoiled; most games are extremely streamlined and guide you through some interactive scenes without the need to think. With TRI we hope to be able go into the opposite direction.

TRI Demo level

Any other difficulties?

Making a 3D game that uses physics leads to problems which you might consider before deciding whether to use a physics engine in your game or not: Often, physics are great. It always means lots of fun and more interaction possibilities. People love dragging crates and barrels around. It's a sandbox game of its own.
But physics always need more time and effort to implement: every physicalized object demands special adjustments, like mass and drag, or the rock over there doesn't feel heavy enough to be really a rock. Yet there might be collision and performance issues. In our case, the combination of physics with the triangle creating feature (the 'TRIs') multiplied these problems.
Static objects are always easier to handle. You should ask yourself if sophisticated physics are really necessary for your game. Integrating a physics engine not only as a mere decoration, but as an important part of your gameplay leads to an even higher error rate. Especially when objects start to fall through floors instead of neatly landing on them. And you never know in which situation players leaves a room full of physical objects after toying around ...

For us, 3D is the most immersive form to play and build games. The third dimension opens tons of possibilities 2D will never have. (And doesn't want, of course.) But as always it also adds difficulties to the game design.
While 2D games look timeless mostly (but often typical indie 8bit-like), you always see in which era a 3D game was made – often enough, which engine was used. I still love the look of Thief 2, but how many people out there still appreciate low poly and abstract graphics?
The art style, especially for small teams, is harder to create. Even though you are indie, players will always compare your game by AAA standards. Photo-realism is the most common way of designing games, although it's the most boring form of expression, too. Building abstract or fantastic looking worlds is more difficult in 3D than 2D.

TRI - Early Alpha Footage

(YouTube videos try to set cookies and contact Third Party servers!)

So many things to fix and prepare before you can take a look at it and TRI the game! Meanwhile you can read more about the game now!

#01 - First look on TRI
#02 - Creating the look of TRI
#03 – TRI – Doing the big Reset

TRI – #3 Doing the big Reset

Tri screenshot testing

Yes! We are still alive! TRI got a new haircut and for the very first time of the TRI production process I can be sure of this: The first huge goal – making a convincing and playable demo/prototype – is nearly within reach!

But why exactly did it take so long to just tell you that we are still developing and working on our game?!
In the last feature article I wrote about design decisions and story, the latter being the main reason why we just stumbled clumsily around instead of getting the thing done (plus the Indie Buskers jam to earn some money).

Sometimes you have to make things too huge and uncontrollable, so you can get back to the point where the gameplay elements were simpler and more straightforward; elements that are actually needed to present your game and don't obfuscate it's purity. Especially too much focus on story lets you neglect the gameplay.

Remember that we already knew what the game would be about. We had this rough idea of a rudimentary story and the game elements were already finished and represented in a prototype. But how to start with the development? We planned the first level the players will visit in the game: A huge canyon that separates the poor people's quarters from the halls of the rich aristocrats. We tried to tell a story with the level style and asked ourselves most of the time: is this level design convincing? Would that make sense? Not for the players to use the triangles, but for what kind of usage those halls and rooms where built by their inhabitants long gone or dead. Our goal was to build a believable, non-linear world without test chambers and buildings that didn't look like game levels BUT a setting that could have been used by human beings to live in.

What become of our over-ambitious canyon level and why did we put this monster in the archive folder? I hope I can give you some learnings with this article, to prevent you from making those mistakes that ate so many weeks of development time.

Canyon Level Top

1. KISS – Keep it simple, stupid!

We are just two people – a programmer (Friedrich) and me (Jana), the graphics artist. We love 3D and first-person games. After resetting the level we already had, we decided to focus more on the level design that is REALLY needed to play our game.
Keeping everything extremely simple to achieve all the goals we have with our game basically means: down-scaling.

To check how complex your game should be: Make a level and monitor how long it takes to design, model, texture, fill the thing with gameplay and test your level. Multiply it with the number of levels you want to have in the end and check if you have the money and time to develop it.

What we want to achieve with TRI is an awesome, playable, mostly intuitively to understand game that looks good. But our emphasis lies on gameplay. That means that we design everything for you – the player – to look nice and fun to explore, but it won't have high-end cutting-edge graphics. It won't contain super non-linear level design. And most parts of the story will be told by the environment and books to be found in the world, and not by elaborated NPCs with facial animations.

The decision we made was somewhat hard, but necessary:

>> Learning #1: Everything that takes too long to develop, design or playtest should be cut out!

And additional: Everything, that is no fun at all AND needs to much time, should be outsourced or replaced or crossed out.

2. Recycling is good for you AND the player

This brings us to another learning we earned after fighting with the big-ass monster room:

>> Learning #2: Reuse as much textures and models as possible.

In our canyon level every second room had another texture design. The first had blue tiles. The second violet, the third was yellow. Did you see that our canyon had green textures?
At this time I couldn't see those greyish “coloration” of first-person games anymore. Most of them try to look photo-realistic but with a monochrome filtering. I wanted to have fantastic, colourful-looking, varied level textures. And that's what I did! I guess I tried to use every colour in the rainbow wheel, to present them in our game.

Bad idea! For many reasons:

- The game looked like a drunken clown.
- When I needed to adjust the coloration I had to adjust EVERY texture in this area, which was extremely time consuming.
- Players got totally distracted from everything while the whole world was a freaking highlight.
- There was no colour left over to be used as a colour-code for lights or special game objects.

What did we do for our current level? I'm just using two colours: Yellow and violet. Both are added in Unity, not in the texture itself. When I now decide to change the look, I just change the materials, which is so convenient! The colours are very monochrome with this technique and I'm not fully satisfied. But players can concentrate on the gameplay and I can later change everything much easier this time.

This is the reason why you should use prefabs (reusable game objects) as often as possible. Although many of them can or should be just placeholders at the beginning. As early as they exist, you can use, discuss and change them as you like. It's time saving and you keep up a clean and harmonized look.

3. Better Zelda than Skyrim

Zelda always got great level designs. But the more I read about level design, open world, sand box, Minecraft, etc., I began to hate level designs that looked like games that much. This led me more and more to the canyon monster level we build. The problem is that this kind of “realistic” levels totally limits your imagination what cool things a player could craft, enjoy, build or experience. Because we always pondered if an element we just added is logical or convincing.

But after building new levels without any restrictions or logical architectural building backgrounds we had more fun making those levels, and faster too! The approach of being realistic is even more stupid when you remember that you are creating triangles and walk on the walls – how realistic is that? Of course you should not break the rules you are building in your little world. But it's always better to not getting stuck in realism. Especially with photo-realism and a team of two!

>> Learning #3: Build the worlds you like. Just try to be consistent.

TRI - demo level

4. Consolidate your workflow

Although we are just two people working in one room next to each other, we had to define some rules to improve our pipeline and teamwork. We are now using a local SVN repository for TRI. SVN is a program for file sharing and version management. Which means that we are not just sporadically exchange some assets and stuff from time to time; instead we share everything, instantly. Since we established this we just have to update our repositories and start Unity in order to work with the latest version. A real time-saver (although there are some quirks with Unity), even for a small team.

We also decided to use a grid for the rooms. No strangely modeled rooms with thousand subdivided edges, but the rule to make every vertex divisible by 0.5 units. Sounds very rigorous? Again, this helped us to make more clear and harmonious designs. Restrictions like this help saving time, also for texturing. And players are more secure in those levels, because they intuitively know how they can place their triangles, or how far or high they can jump.

>>
Learning #4: Simplify and structure your workflow. Little rules can make things easier.

TRI Demo level

5. Testing!

One really big problem we had with our first/last level: We didn't test it enough. Friedrich built one room after another and I was blindly texturing them, eager to just getting things finished. We planned to let testers walk the rooms, when everything was finished …

>> Learning #5 Test as early as possible!

I know that testing the game is something very basic. You should know this as a developer! We knew this from our last games Pitman, Tumblox and The Sun Is Deadly, which were all too hard at the beginning. And I learned this through the game jams we regularly participate in. But with TRI it seemed that I needed to learn this again. Texturing and filling the room with little decoration gimmicks makes sense, when the players was successfully sent through the whole testing area.

To explain our strange behaviour this time I have to admit that the whole gameplay was just available for Friedrich (SVN was already there, but only used by him) and most parts of the gameplay were not integrated into prefabs. Having the game components (light rays, switches, character controller, doors, etc.) as easily to place game objects made things so much easier.

Again: keep things smaller, even the level structure, game elements and possibilities. That doesn't mean that you should add one collision box one after another in a cubical level structure. But it was more fun since we decided to be creative in the restrictions we set for ourselves. The game is better structured and far more understandable since then.

I guess the most important learning is:
>> If working on the game is no fun at all, it's time for a down-scaling!

And what is the next step for us? We TRI to present you a huge demo and more wordplay this June.