Week 15 - Update

This is getting pretty funny. I have complete system for states, but it so flexible that I have to design how to actually use it. It can be pretty much used in any way. However I was able to create actions, which will be the core of what can be done in the game. For example if AI wants to go forward, AI will send message for actions and its action will be handled in actions and if player wants to go forward players action will also go through same actions. Basically AI will be like player and player will be like AI. Neither AI or Player will get any bonuses or anything and they can only do the same things. Of course AI could react much faster than Player even without any bonuses, but I try to make so that AI simulates reactions according to beings stats it uses.

Stats (Made with Code Analyzer by mteel)

Week 14 - Update

Nothing really happened last week. I was able to think about the design and how to continue with TSOTR, but thats it. I also added menu tab and some information on the blog.

Week 13 - Update

Last week didn't happen that much. I just had to redesign some parts to make them more useful and I was able to make only few lines of code.

Stats (Made with Code Analyzer by mteel)

Week 12 - Update

What has happened?

I have been mainly resting this week, but I still did something. I implemented methods for 2D/3D modes and some parts of main menu.

(There is only two colors in that texture, black & white. Shades on them come from lights.)

What next?

Next thing is to make states work. This means that there should be working main menu and fps game mode and user should be able to switch from one to another and of course user should be able to move in fps mode.

Stats (Made with Code Analyzer by mteel)

Week 11 - Update

What has happend?

Some nice changes this week. I integrated part of the old 3d engine to TSOTR and was able to make it work with new core. I also was able to figure out how should I make states system and it is pretty much done now. Demo is now in 3d and it will be last demo on this blog for now at least.

Demo: TSOTR_2011_10_08

What next?

I have to create main menu state and in game state and of course test my state system.

Stats (Made with Code Analyzer by mteel)

Week 10 - Update

I was able to do a lot last week. I made player input handling, config file handling, timer and made initial version of graphics handling and there is even first demo program. No, there is no 2D box you can move on the screen. I didn't do it because it would have been something extra I wouldn't need in my game. So what does this incredible demo program do? It only opens blank black screen you can close with button you configure in configuration file, hah. Well as you know or should know, if you have been reading this blog, there is more than meets the eye going on.

Demo: TSOTR_2011_10_03

What next? I will have to think about how I will use states and put them in use somehow. Also I need to integrate my 3D engine into TSOTR. So maybe in next post we could get playable demo.

Stats (Made with Code Analyzer by mteel)

Week 9 - Update

I have been able to do a lot. Input without states is now done. I also ran program for the first time and everything went just fine. Next things to do are timer for everything and initial version for player action handling. Maybe next week I will be able to make small demo program too. Don't get too exited. Demo will be something like small controllable 2D box or something.

Stats (Made with Code Analyzer by mteel)

Week 8 - Update

Finally I got some time to actually do TSOTR. Input is mostly done. Next thing I have to do is config file handling. Input will also use config files so it shall wait until I have done config file handling. Btw, I haven't even tried to run anything I have already made. Debugging will be fun especially because of some very exotic choices I have made. Well, it will be my problem.

Stats (Made with Code Analyzer by mteel)

Week 7 - Update

I was able to check one todo and implement it. Yeah, its not much, but at least something happened last week. Hopefully I will be able to do more this week.

Stats (Made with Code Analyzer by mteel)

Week 6 - Update

I couldn't do a thing last week. Neither can I do anything this week. My weekend is fully booked and I won't even stay at home.

Week 5 - Update

Just as I thought. I didn't have time to even think about TSOTR. So no changes last week. There is still some matters I have to handle early this week, but later this week I might be able to do something.

Week 4 - Update

This week I was able to sacrifice only one hour coding and few hours designing for my ever hungry TSOTR project. I made use of GameObject a bit easier and designed how to do it and how to do some new parts. Unfortunately next week I might not able to do TSOTR at all. Well, I can always design TSOTR and write down something, but I might not be able to code it at all.

Stats (Made with Code Analyzer by mteel)

Week 3 - Update

(Elitist Coding)

Hiya, I am just sipping some wine and trying to figure out wtf am I doing. The design of TSOTR is ok, but c++ and how to use it's libraries especially boost is something terrible. When I have stuff like this...

boost::shared_ptr<std::vector<boost::shared_ptr<GameObject>>>playerActions(new std::vector<boost::shared_ptr<GameObject>>);

... in my code I am not sure should I cry or laugh. No, I am not going to back off and switch language. Don't get me wrong. I really like c++, but when you need to get something more or less dynamic stuff code can look like above. Sure I could use typedef this and that, but then code would get even harder to understand, because all definitions would be hidden. Oh and you don't even want to know what kind of error messages monsters like above can produce...

Stats (Made with Code Analyzer by mteel)

Week 2 - Update

I have been busy with other things lately. So there isn't that many changes. I just found out some major problem with current design. When everything can be the same thing and when there is pointers to those same kind of things, those pointers will run out eventually. Fortunately the problem occurs more easily when using 32-bit programs and we already have 64-bit computers. That means TSOTR will be 64-bit. Unfortunately mingw doesn't really support compiling in 64-bit mode yet. I just got nothing but "..\src\TSOTR.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in". Sure there are versions of mingw that support 64-bit mode, but those things won't support debugging and thats something I really need. I can continue with 32-bit mode, but eventually TSOTR will need 64-bit mode. So lets hope there will be mingw that supports 64-bit mode and debugging in near future.

Current stats. (Made with Code Analyzer by mteel)

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)