Tag «Programming»

TRI – scripter’s dev log #7

This is the seventh entry I wrote for the TRI dev log on TIGForums. You can find the previous parts there. From now on I will post the entries here, too.

Yes, we and our project TRI are still alive! After a pretty long break at the end of 2012 we decided to move the game into a different direction, especially regarding the style. The story changed, too, but this is not quite as relevant, as the story and plot we thought of were never an integral part of the alpha versions. In the current pre-release we even removed any hint of story, because we want to add NPCs later, and concentrated on other stuff this time.

2012 - 2013

The pause in the last quarter of 2012 was mainly for doing contract work, to get some money for food and shelter - but it also gave us time to rethink some design decisions we made regarding TRI. The main concern was to make everything easier for us to create content, which means:

  • simpler textures mostly just quadratic tiles
    • We combined this with a shader to look up the tiles – fed with the tile texture atlas and a noise texture, the walls, floors and ceilings don't look too much like repeating patterns.
    • Currently this shader works fully with Direct3D, but is a bit broken in OpenGL – because of a bug in Unity3D 4.x there are ugly artifacts visible for everyone on Mac or Linux. This will hopefully be fixed some day ...

random tiles on the walls

  • simpler mapping – standardized box mapping will do in most cases
    • This is done in the 3d modeling program (3dsMax). Additional customization of the mapping is done only when necessary.
    • Of course this means that for more sophisticated architecture the textures have to be carefully chosen, so for example it doesn't show too much seams on curved walls.

visible seams - will be fixed

  • simpler level creation– try to stay in a grid of 1x1x1 meters initially
    • I wrote a MaxScript tool for 3dsMax in order to have vertex snapping on a 3D grid. It's a pity this isn't built in, as my solution is quite prone to errors (often, undo doesn't work) and unintuitive to use. But it's better than nothing. I think in Lightwave this functionality is called Quantize.
    • The tool allows us "to go into detail": by clicking on a button you can half the unit, so it the unit 1m becomes 0.5m becomes 0.25m becomes 0.125m ... etc., thus everything really will be in a grid. Of course there are exceptions, like round shapes.

vertex snap
3D vertex snapping tool

  • simpler level export click a button in 3dsMax and the stuff is in the game
    • Another tool for 3dsMax is an exporter which automatically exports all the objects in the scene as a complete FBX which is used as the level geometry in Unity3D. Having a fast pipeline is awesome.
    • The exporter prepares certain objects specifically for the game. For example, there are surfaces in the game where the triangles don't stick, so we assign them a particular material. Every submesh with this material will be exported as its own gameobject, and therefore can be easily recognized in the code.
    • We can add some keywords to the name of a mesh so it gets treated differently when exported. For example, adding "$Export:Bridge" to the name will remove the object from the level and export it as a separate file named "Bridge.FBX", or adding "$NoExport" won't export this object at all.

export tool

  • simpler mission design – the main goal of every level now consists of collecting three keys in order to open a portal to the next level
    • With just three symbols in the top right corner of the ingame GUI, everyone knows what they have to do without much explanation (ideally).
    • Even though the premise of collecting three statues sounds kind of boring, it actually freed us from having to think of overly creative, but in the long run unnecessary mission goals. The goal is clear and creativity can be spent on the level design and puzzles.
    • The pacing is slower now and the learn curve for the player was decreased, because single levels are often dedicated to single gameplay elements. They are also less confusing as it is more clear what to do next; we reduced the elements that look interactive but really aren't.

collect statues = mission goal

All this simplification resulted in a better consistency of the looks and the gameplay. The new art style can be tweaked quite easily by changing a few colors, the ambient light and the global fog. Improving the gameplay and layout of a single level even after texturing and mapping it became easy. With the new limitations, we can predict the ideal size and content of a level much better and we're more confident now when creating the level design.

We also built a tutorial mission which will introduce the player to the world, so it contains a show-jumping course for learning the basic controls, but will also be the start of the story, as NPCs will give the player motivation to actually move through the levels.

tutorial parcours

Right now we get mostly positive feedback, especially regarding the level architecture. But not enough people are playing the game – let alone buying the alpha version. The trailers we do might be big turn-offs, as creating the triangles seems tedious. It's actually fun and feels natural, but how can we tell the hard to convince trailer-watchers? We probably need to make it more clear that TRI's focus is not only on puzzles but also on exploration.

Me Against The Mutants – Day ~3

This post is part of the PITMAN Birthday Sale Week - check it out HERE!

So, this is the follow-up to the first posting from Sunday. In it I explained that we're doing a roguelike in (less than) seven days, and what was the basic idea behind it: an infinity generator.
As we are also busy building our current game, TRI, we could not invest the time to make a full roguelike. We will try to make at least a game where you can walk around and hit some enemies and find some bling. :-) But currently, all that could be implemented is the procedural creation of the dungeon, the walking player and - tada! - the infinity device.
Yes, it is now possible to draw a rectangle inside the game via mouse. The character can be moved with the WASD keys, so he can simply walk into the rectangly area and be trapped in the INFINITY. Just click again to remove the rectangle. Try it out for yourself:

[kml_flashembed publishmethod="static" fversion="10.0.0" movie="http://dl.dropbox.com/u/10650964/7drl2012/test_002/7DRLCE2012.swf" width="490" height="350" targetclass="flashmovie"]

Get Adobe Flash player


(Press R in order to generate a new world.)

So, this is kind of bland right now. With the rects you can trap yourself, have an interesting view on the screen, see yourself (and yourself, yourself and yourself), and get out of and into the building (as it has no doors to the outside). This doesn't do much for the gameplay, not yet. I want to have enemies which can get trapped inside the rects and beaten up thanks to them.

I had the infinity working pretty soon after my last post, but then I realized they wouldn't work with enemies. So I spent half a day with refactoring and rewriting some parts of the code, fixing bugs and introducing new ones, until it worked again exactly as before. ;-) At least I can now potentially add enemies, which will happen in the next days, because after Saturday, 13 o'clock, the game has to be finished in order to be a legit 7DRL.
Although we will try to do an all-nighter from Friday to Saturday, this probably won't suffice for a truly full game. The enemy AI will be very basic and there won't be that much interaction possibilities. Yet the potential for a bigger game is still there (we think), and if we're not going for the out-of-challenge 10DRL we will work on it later perhaps.

Tell us what you think! Is this a prototype worth turning into a full game?