Flarelocke-
Didn't like my RPG-type posts? :) What can I say, I like PnPRPG's, and like my strategy games, I want to make them different. Hence, I wanted to create something that was more deep and profound.

But I haven't forgotten about my strategy game. I'm still trying to decide even what exactly the GUI portion of the interface would look like. Obviously the interface can't take up too much screen real estate, but since it's the most critical aspect of control for the game, I'm envisioning something that's somewhat large.

My initial vision has mini-icons or banners representing the top-level chain of command and another set that represents your resources. Now, in my game, you don't have factories per se, but instead have allocation request pools, and you have Distribution Hubs to worry about. So in a nutshell, you've got Commanders, Allocation Requests, and Logistics.

Because communication links as well as transportation links are vital in my game, you can lose contact with any basic entity (I define an entity as any game object which can be given an order either directly by the player, or indirectly by an AI Commander), up to and including top-level Commanders. Jamming equipment, poor terrain or weather may cause an inability for some part of your armed forces to be cut-off from your control. Just ask the British 1st Airborne during the battle for Arnhem bridge how sucky it is when an entire division can't communicate with headquarters, nor the regimental or battalion commanders between each other.

To model this, if communication is cut off, they simply become "greyed out" on your interface screen, and on the main map itself, you lose any information that only those entities would have been privy too. In other words, although those units are still alive, they're now no longer under your control, and hence, the re-establishment of communications should be a top priority. Obviously, the AI has to be robust enough to recognize and handle this, and it should be a "hard encoded" rule that if any of the C3 links are broken, it should make it a top priority to fix them.

So communications is relatively easy to implement. The Command and Control aspect is a bit more tricky though, mostly since it relies on very flexible and adaptable AI algorithms. The Command and Control aspect is also less influenced by the actual Interface screen, since the Interface screen is used more to set certain Order parameters, which in turn are used by the AI Commanders to set the Control scheme. For example, determining aggression levels or standing orders would be done through the interface and used as guidelines for the AI. As an example, you might order a Company Commander to hold a certain position and set the priority to high (maybe this company is on the flank edge, and if it folds, then it will threaten the rest of the battalion, hence the high priority). You can set these through the interface, but the actual Command of the Company falls to the AI Commander who implements the defense given the priorities that you input.

I'm still working on how to implement Orders vs. Motivations. Orders are the set of actions along with their conditions and parameters that you give to a Commander (and hence to all the basic unit types under his chain of command, and ergo, this means that depending on the Rank of the Commander, different Order types will be available). Motivations on the other hand are the messy real world conditions that people in battle must face. It is a blend of psychology of the troops, tactical considerations, and morale.

After playing a shitload of starcraft (and the Dawn of War demo), I think I know why that interface has become the genre standard. While it may not be all that great for implementing strategy and tactics, it does mean there's never a dull moment in the game. You're always doing something, and when big battles get going, it gets pretty frantic.

However, as you say, it really isn't all that great for the strategy side of things. Player time is probably the most important resource in the game, and the interface makes it rather difficult to make the most efficient use of it.

It might be quite interesting to experiment with some sort of 'briefing' system, whereby you don't control your units directly, but you give them a series of objectives and waypoints - much like you might be given in a first person game - and let them get on with it themselves. You can watch the events as they unfold, even issue new objectives and throw in reinforcements, but you don't have direct control over the unit's movements, and you certainly aren't bothered with little details like whether to throw a grenade or not.

Quote:

I've often lamented that I can't issue more precise or detailed orders to units, and that's because I'm scrabbling about looking for the units. In short, this sort of traditional design needs you to fight the interface of the game, and that always unconditionally sucks.

This C3 type of interface certainly sounds like an interesting idea, and one I'd definately like to play. However, I think you'd lose some fans of traditional RTS - I've noticed that those who tend to really excel at the type of game don't have the issue mentioned here - I actually got some friends to play a quick game with me (C&C Generals) for testing purposes before posting, with a non-playing friend testing us, and in almost all cases, any of us could have a specific requested unit displayed center of screen and selected ready to issue an order within a second.

I think that although the C3 interface is an excellent idea, some players will feel that it costs them control - and indeed, I'm sure some people could still be far more efficient through micro-management. Also in favour of C3 though, is the fact that it will probably more closely represent reality.

Quote:

Original post by Kazgoroth I think that although the C3 interface is an excellent idea, some players will feel that it costs them control - and indeed, I'm sure some people could still be far more efficient through micro-management.

A lot depends on scale, I think. The standard paradigm works extremely well for relatively small numbers of units. With careful micromanagement, you can pull off some fairly cool tricks with a small number of units. However, it doesn't scale well at all - as soon as you start getting large groups of units with lots of different abilities, the standard control mechanism falls apart completely.

The C3 approach sounds like it might well work better with large numbers of units, but you lack the fine control to be able to do as much with a small number. Perhaps some kind of combination of interfaces might be a good idea - this way you have better scalability, and a slightly more approachable game, since people are already familiar with the small scale interface.

Quote:

Original post by Sandman Quote: Original post by Kazgoroth I think that although the C3 interface is an excellent idea, some players will feel that it costs them control - and indeed, I'm sure some people could still be far more efficient through micro-management. A lot depends on scale, I think. The standard paradigm works extremely well for relatively small numbers of units. With careful micromanagement, you can pull off some fairly cool tricks with a small number of units. However, it doesn't scale well at all - as soon as you start getting large groups of units with lots of different abilities, the standard control mechanism falls apart completely. The C3 approach sounds like it might well work better with large numbers of units, but you lack the fine control to be able to do as much with a small number. Perhaps some kind of combination of interfaces might be a good idea - this way you have better scalability, and a slightly more approachable game, since people are already familiar with the small scale interface.

Ah yes, with more units, perhaps with additional abilities available, the C3 approach would indeed begin to offer notable advantages.

Quote:

original quote by Sandman I think I know why that interface has become the genre standard. While it may not be all that great for implementing strategy and tactics, it does mean there's never a dull moment in the game. You're always doing something, and when big battles get going, it gets pretty frantic.

Well, that's precisely the point (or problem, depending on how you want to look at it). Strategy games shouldn't be a fast paced frenetic click-fest. Imagine if Chess was played in the same fashion as most RTS games are nowadays. That's why I second the notion of Krysole's TBS games solving some of the issues that crop up with how RTS games play. I'd daresay that most RTS games aren't really strategy per se, but algorithmic formulations of what unit production facilities to build which units for your particular tactic...all under a vicious time constraint. Indeed, the time constraint is so great, that sometimes RTS games feel more like races than about strategy.

So I think the whole RTS genre needs to focus back on its core element....strategy. This in turn requires the ability to plan. I personally want to create a system that not only factors in tactical choices, but to recreate the elements that a battlefield commander must face.

I was in another forum about PnPRPG design, and because of my computer background and my own philosophical bent, I tend to be very precise, rigorous and simulationist in my design methodology. I had to explain to some people there that when you try to model a system, the very inputs you chose not only dictate what the output will be (domain -> range), but by your very choice of including those inputs, it makes those outputs (or results if you want to think of them that way) as important.

For example, let's say I design my game in which communication is a control factor. By making that decision, communication now plays a vital role in the gameplay itself, because communication inputs (and initial conditions or states) affects the output state. As Sandman pointed out, time is the most critical resource we have, though not just from a system architecture standpoint but from a user standpoint as well. Hence, time itself must be seen as a (hidden) input which affects all the outputs of the game.

Quote:

Original post by Dauntless Oluseyi- Screenshots of my game?? I wish :)

Want help?

Dauntless,

As someone else has stated here, I think what you're suggesting would bring RTS closer to TBS. So, I wonder if your suggestion would also make it easier to have a strategy game that allows both options. I think it would.

- Rob

Oluseyi-
Any help is greatly appreciated. I wish I had more time to devote to the game, but between school, work, and working out....I'm lucky if I can spend an hour or two a week on my game design.

Tell you what, what's your area of expertise? To be honest, I'm not even sure where I should be prioritizing what software modules to build first. Sometime after mid-terms are over, I'm going to put up a user requirements specification that will detail how the game will appear to the player. Later, I'm going to draw up a developer requirements specification that will list most of the software components that I could think of. I developed a very basic UML class diagram that I can put up, but no Use-cases or sequence diagrams or anything like that.

RobAU78-
I was thinking of doing something similar to what Combat Mission did, or Battle Isle, in that the game would be a hybrid TBS and RTS system. In essence, the real time part only lasts a minute or two, and every RT phase is preceded by a turn based system. They are in effect, "pauses" which you use to give orders, rally troops, organize, and properly manage your forces. The key here is the insightful application of forethought, because the orders you give here are what is going to be carried out in the RT phase.

I've been toying with the idea of having "Command Points". The idea is that you "pay" for your orders. This will simulate the notion that as a commander, you can't micromanage everyone all the time, and you have to focus your attention at any one moment. So if the caca hits the fan, you pay your points to order whichever Commander's force you wthink is the most important. This will also further reinforce the Chain of Command purpose. IF you have a limited amount of Communication points to "spend" your command points on, then if you issue them to the right leader, that Commander can in turn tell his subordinates what to do.....exactly how the chain of command is supposed to work.

Of course, so much of this is riding on good AI implementation. It really is the Achilles heel of my game design. So anyone good at AI paradigms would be a great help for me (I'm pretty much ignorant of AI solutions....which sucks considering how important it is).