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).
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.
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.
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.
(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
