Week 1 - Update

Hah, I started making Input and I did something else before Input. Things I have done so far are...

- States (done)

- Game objects (done)

- Input (partially done)

- Logger (partially done)

What do I mean by 'States'? 'States' is a way to store different game states. For example 'MainScreen' could be one state. There is buttons, graphics etc. that are used only in 'MainScreen'. Those things could go to 'MainScreen' state. After clicking for example load button in 'MainScreen' state game could go into 'LoadScreen' state in which there is new buttons, graphics etc.

What are game objects? Game objects are for storing data in game. Every texture, every sound etc. is a game object. They are done? Well, there is a class that can be used to store them. That is the easy part when I am using pure aggregation. The hard part will be using them when everything can really be anything and they can have anything.

Lastly some stats. (Made with Code Analyzer by mteel)

C++ std & TSOTR

I had some time yesterday and this evening to develop more TSOTR.

One thing is for sure. C++ std is not enough when creating something as complex as TSOTR. I tried to use std only, but I just couldn't do it. Now I am using boost and there is more than enough stuff to satisfy my needs of a bit more exotic stuff.

TSOTR itself is coming along quite nicely. I have designed and coded some parts of state system, subsystems and input.

I also had some random thoughts about making TSOTR 2D game and turn based. Current plans are to make TSOTR 3D and real time with possibility to accelerate time when needed. What do you think? Should TSOTR be turn based or real time game? What about 2D and 3D?

As 2D game reference this is what I can make in one evening.

http://www.youtube.com/watch?v=J0eAyLNZ-h4

Designing input

One could say that it easy to design and code input system. I admit that it is fairly easy to make simple input system. Problems occur when it has to be something as complex as TSOTR needs. Basically input system has to be as dynamic as possible. First of all it has to work whatever device you use. Sure there are some limitations, but the main thing is that if you want to config button X to do Y thing(s) in TSOTR, it should work. Second any data in TSOTR should use same class as any other data.

The input designing part? So far so good. I am done with input design and next thing to do is to actually code it. There are some parts I am not sure whether should I use tools in current design or some other tools, but I'll figure them out when I am coding it for real.

WTF is TSOTR?

You can see TSOTR and Minarus all over my blog, but no explanation what they really are. This post should clear some things up.

What is TSOTR?

It is name of my game project. Initially it was called Minarus, but I changed it to TSOTR. As you maybe have guessed TSOTR is an acronym. I reveal the words behind TSOTR after I have somewhat working version of TSOTR.

And Minarus, what is it?

Minarus is the name of the world in TSOTR and initial name of the TSOTR project.

What is this TSOTR like?

Think about oblivion in larger scale with beings that actually live, breed and die in that world. Basically there will be no random encounters and items do not magically appear into the world. Everything that will happen is because of beings and items actually move in the world.