What do you want to see in a Science Fiction game?

Hi,

the AntEngine (with which I will develop Warlock) is almost done. So, it's probably time to test it on a little project.
As I mentioned earlier I'm thinking about a small science fiction game.
So, the main idea was to give the player some options to solve it and I was already working on a flowchart how the story may or may not unfold depending on your choices.

But then I noticed something. Whereas fantasy is rather straight forward and doesn't have too many sub-genres (or at least popular sub-genres) science fiction has tons of those.

Two quite different approaches to science fiction (2001 and Star Wars)

One sub-genre of science fiction as an example is rather fancy and full of strange alien races, whereas the other one takes the expression "sciene-fiction" more literally. Those movies, books or games in our case really try to give a more or less accurate prediction of future societies and technology.

We probably all know some examples for the former and the latter.

There are of course even more sub-genres of science fiction. Remember the movie "Aliens" which is a mix of Dark Future and Horror. Or remember William Gibsons cyberpunk novels.
Most of them can still be categorized roughly in the above mentioned sub-genres but there are also some examples where the case is a little bit more tricky (steampunk to name one).

What I want to know from you: What do you enjoy most in science fiction?
Which elements do you like to see? Aliens everywhere? The vastness of space and the dangers of space travel? Stations with scientists and engineers getting ripped appart by rogue AIs?

Feel free to drop me a line.

[insert robot sounds here]

Actually I wanted to start writing the skill system but-OH GOD WHAT THE HELL AM I DOING?

Beep-boop-vrrrrr!

I read some robot stories yesterday and couldn't resist.
Maybe a good setting for a tech-demo? Who knows?

Until next time!

A look at the dialogue system (alpha)

Hi,

today I want to show you a little bit of ToFs dialogue system. The design is, as always, work in progress but the technical background is ready to use.
As you can see I have outdone myself from a literary point of view while writing those testdialogues.

Such a deep and intelligent conversation!

The system itself is quite simple, but considering the textflow you can do a lot of stuff with it. From normal sequential text to complex dialogue trees everything is possible.

Until next time!

The new interface explained

To cut a long story short: I've been polishing the interface. Shiny buttons instead of writing!
Also the group system is implemented now!
But see for yourselves:

Next point on the list is the dialogue system. I'm looking forward to that. Writing those dialogues is a little bit like writing assembly code. Huzzah!

Until next time!

A brief look at the character individualization

Hi,

let's take a very quick look at the character individualization:
Tower of Fentrax will feature 3 different ways of customizing your characters basic appearance (Skin, Hair and Beard). There will also be 9 item slots for equipment. Every equipped item alters the characters appearance. So all the armor parts you equip will be visible on the character. A few examples:

The item design is of course still w.i.p. but I just wanted to show you that there are quite some combinations possible with this system. That will naturally affect NPC design too.

You might have also noticed that the relation between pixel- and character-size of these characters is a little bit different to that of the knight which was on all the previous screenshots. Of course the knight was just a placeholder but the main reason is that I'm also changing the tileset size at the moment (from 50x50 to 32x32).

Until next time!

On the subject of survival

Today I want to write a little bit about the survival system.

The system is handled by a certain amount of character states (most of them independant from each other) respectively several little state machines or state sequenences to make it more understandable (the states are not really sequential though).


There are some very basic state sequences:

Eat nothing for days => starve => stats heavily decreased => die of starvation
No sleep/rest for days => exhaustion => stats heavily decreased => fall over somewhen
Drink nothing for days => stats heavily decreased => die of thirst


There are also some less obvious state sequences:

Sleep outside in bad weather => probably get sick => stats decreased => no treatment => dead
Walk far with one pair of boots => boots destroyed => boo-boo on feet => stats decreased
Eat poisonous plants => diarrhea => no treatment => dead
etc. etc.


Of course there are ways to prevent suffering and death.
You can break almost any sequence at any point by an action that sets back the particular sequence (unless you are dead sick or already crapping your pants for the third time). The thing is, the further you go into a sequence, the harder it might be to get into the initial state again.

There are also survival skills which might help you. Like medical treatment, basic repair, tracking etc.
We will cover the skill system another time though.

Until next time!

A few thoughts about middleware

 LupLun wrote a comment in the last posting that made me think:

 You're doing it wrong. Get some cheap middleware to handle the behind-the-scenes B.S. for you so that you can focus on content. Otherwise, your game will be crap. Don't take my word for it, ask the good people at Viridian.

So why didn't I get some middleware like GameMaker, UDK etc.?
I will be completely honest: It did not come to my mind. I definitely thought about UDK earlier but not while planning this project.

But in fact that has a certain reason. I don't think writing the whole framework by yourself is really the problem when it comes to focusing on a certain part of the game. Be it code or content.

In my opinion it's rather a matter of planning.
The planning stage is one of those stages that are dangerously underrated. Not only in game development but in any project, anywhere on the world, anytime and most likely forever. It's like the bane of modern software production.
Plans have to be really well rounded. Especially considering content creation planning should not only be about scheduling but mostly about structuring your work.

Let's play this through. In my opinion it works like this:
You plan your game and then you wait some time. Yes that's right. You wait some time and then you plan your game again. And again and again and again.
It's like smoothing a board. Take your time! It's like choosing between time-honored cabin work and out-of-the-box furniture shop products.
And you know what the best thing about time-honored cabin work is? It lasts.
You'll thank yourself for the long plan(n)ing (what a pun) period later.

So after planning the game plan your framework. It's basically the same process of writing down stuff (with the games ideas in mind of course) and scrap it again until the thing seems "rounded" and optimized.
After planing your game and your framework you start writing the framework. You will be surprised how easy it suddenly is.
Well and once you have finished your framework you make your content with it (which you have hopefully already planned). Most important here: Be flexible (so it's no problem to make some minor changes in the framework or whatever) but stick to the plan. No journeys into the unknown and no messing around anymore. That's what the planning stage was for. Same goes for the "Stuff takes longer to make than to play"-problem. Try to already address that in the planning stage (which is not easy at all of course).

I also know it is very hard to keep every workstage consistent. I find myself working on maps and tiles where I should work on the script language. I'm only lucky to have a soft spot for modular design and software architectures. So most of the stuff I write is completely independent and does not stand in each others way.


Of course you can still call it a bad habit, if someone wants to write everything by himself or ask for the justification of it when there is stuff like the UDK or XNA or whatever.

But you have to consider one thing: Once you write everything by yourself you're in total control.
I wouldn't even dare to say: "Well my framework handles this or that basic algorithm better than the UDK/XNA/GameMaker etc". That's just insane. But there is one thing i can say for sure: If problems arise I know what's happening in the background.

The last thing that comes to my mind when I think about this topic is that I also enjoy writing core code. I know it's a sloppy excuse but still. This and and an elaborate plan make the whole development process very worthwhile. That doesn't mean I wouldn't use middleware. Just not this time.

Talking about time: Until next time!

P.S.:
However the post at Viridian was a most interesting read.