If you remember, I have an overworld. This feels weird writing it like that, as if it's an illness. But back to the topic. The first thing that I missed thinking about, when do I switch from overworld to "fight view", and vice versa? And since everything else kind of depends on that, I should think about that first, right? Maybe, but I won't. I try it the other way around.
The Overworld is rasterized, I call one square a "sector" in game. Of course it doesn't make sense mathematically, but it sounds cool and very military like.
While trying to solidify the idea of the overworld, I came up very Usability-Like requirements... I am baffled, what has dry technical stuff to do with fun games? This makes sense, in Jagged Alliance, you could have let the player run through every sector of the world, but that wouldn't be fun. So my overworld only exists so the gamer can cope with the vast levels. Pure usability. Well done, I tried to do a project to get away from the dry stuff, at least it has more colors and features guns.
But anyways, the overworld view should provide time saving mechanisms and should serve as an information hub, giving an overview of all relevant informations (well duh, it's called OVERworld, of course it should give an OVERview). I know this is a bit like being captain obvious, still it is an important requirement to meet.
This too seems to be a no-brainer at first, FAST FORWARD! It gets a bit complicated when looked at carefully. When is the gamer able to fast forward? Does it have some kind of dark side? How can he simply command tasks that are to be fast forwarded?
For example, is he able to let his soldier do reconaissance on it's own and fast forward it? Well then it is a useless mechanic and I only waste the player's time, even if it isn't much. Or do I let him chose to do it himself and award him with something? Or do I get rid of it and tell in the lore that satelites provide all necessary info? It is amazing how you can easily include or remove a whole gameplay mechanic. This decision is more important than any "what language to use" decision for the actual game.
Back to the most obvious fast forwarded task, travelling. This too hides some problems. In Jagged Alliance for example, you could fast forward when you travel from sector to sector, there wasn't anything "between" the sectors, even when you manually walked through a sector, you still had some travel time to go to the next. Project Phoenix on the other hand, should have a seamless transition from one sector to an other. In a game like that, where you could get ambushed at any time, it is important for you what route you choose inside of each sector. So I need a powerful tool to let the user chose his path of desire at the right level of abstraction. Furthermore I have to define when the gamer is allowed to fast forward, how far away enemies have to be, and so on... and an other very important question, if I allow the gamer to fast forward, do I allow him to stop time? ...oh boy.
Still, very easy at the first glance, but what information should I put in the overview? What is relevant to the gamer?
What information do I actually have?
I don't know, or I don't know everything not one thing definitively, this shows that my game is "work in progress". At least I now know what I don't know, this is progress, progress is good.
A view thinks are self descriptive:
- Your camps, and as a pop-up your equipment and supplies.
- Yout home base and save zones.
- Your target city/stronghold
- Enemy movement you know of (somehow)
Here, Jagged Alliance has a nice solution idea, there you can toggle displayed information on and off. For example, you can toggle to display enemy troops on and off.
Now that's not too bad of a start, I wanted to write anything about the overworld here, but I start to think I wrote about everything I currently can vote. Like I've written before, I now know what I don't know, I have to write more about the demons and furthermore I have to think about something I call macro strategy. What strategy the gamer can pursue to defeat the demons.