yea, so maybe something like:
select SNIPER
WHILE -> this unit is IN COMBAT
MOVE TO this location
so maybe have predefined commands, like while, if, etc, (but in button) and from there the player selects another unit/gameplay element, then selects another command like engaged, dead, alive, low hp etc - and then he selects the action for the unit to do.
Xpy
Codename:RTX - a Real Time Strategy Game
Personally, I think scripts are a bad idea, unless they're writen outside of the game and used as "order plugins":
// Parameter order determines the order of inputs, so this order
// would require the player to preselect a squad, then select a
// destination point, then a target
order MoveOnceDestroyed(selected squad s, point dest, target t) {
action a = move(s, d); // encapsulates a move command
t.setTrigger(EVENT_DESTROYED, a);
}
// Parameter order determines the order of inputs, so this order
// would require the player to preselect a squad, then select a
// destination point, then a target
order MoveOnceDestroyed(selected squad s, point dest, target t) {
action a = move(s, d); // encapsulates a move command
t.setTrigger(EVENT_DESTROYED, a);
}
Quote:
Original post by nuvem
Personally, I think scripts are a bad idea, unless they're writen outside of the game and used as "order plugins":
I'm inclined to agree, for the most part. Certainly you don't want to be frantically typing up scripts in the middle of a battle - it is far too time consuming and completely destroys immersion.
I think there could be potential for a robot RTS game involving user developed scripts - like that rover game whose name I forget (mind rover?). Scripts could be written before the battle and whoever has the best combination of strategy, control and cleverly thought out scripts will win.
exactly - and then you have the problem that it becomes who can type faster rather than who is the best general/orc/whatev - my interpretation was that you just use a few buttons - without typing anything, altohgh users could use a "sandbox mode " in SP to creaate custom scripts IF necessary, but it probably wont be
Xpy
Xpy
JUST-CODE-IT.NETManaged DirectX & C# TutorialsForumsArticlesLinksSamples
Quote:
so maybe have predefined commands, like while, if, etc, (but in button) and from there the player selects another unit/gameplay element, then selects another command like engaged, dead, alive, low hp etc - and then he selects the action for the unit to do.
That's sort of what I was thinking, too. Just some predefined variables and actions... maybe think of it more of like being able to queue up a set of actions.
To expand on what Kekko said, you should be able to select a dropship, tell it to move to a location, drop the crew, and then move to another location. This way, I don't have to babysit it and move it myself. I can just tell it to go, and then turn my attention elsewhere. Nothing terribly complicated, just a queue of actions and maybe some "IF" "OR" variables to give things more flexability.
"Take units to location B. If dropship comes under attack, retreat to location C. If not, deliver units to location B and then return to location A."
as morally shamed as i am, i shall have to resort to using a sims example for this (hey, im past that now)
when you click on a s*m, a list of options comes up - it would be like that - a list of interactions for each unit and then set the conditions etc in the same way
Xpy
when you click on a s*m, a list of options comes up - it would be like that - a list of interactions for each unit and then set the conditions etc in the same way
Xpy
JUST-CODE-IT.NETManaged DirectX & C# TutorialsForumsArticlesLinksSamples
Quote:
Original post by Stevieboy Quote:
Original post by Solias
Possibly you could limit the player's control over their units durring battle to make the creation of good scripts more important.
I think this wouldn't matter, if they are using a script anyway, they would just carry on doing what you wanted. I don't think games should really limit you (artificially) on things.
What I had in mind there was to prevent the player from overriding the script if the situation changed in the middle of battle, or limiting how they could alter it. This would force players to plan ahead more.
I agree that arbitrary limitations on the player should be avoided, but carefully chosen ones can add to the development of strategy.
Quote:
Original post by nuvem
Personally, I think scripts are a bad idea, unless they're writen outside of the game and used as "order plugins":
// Parameter order determines the order of inputs, so this order
// would require the player to preselect a squad, then select a
// destination point, then a target
order MoveOnceDestroyed(selected squad s, point dest, target t) {
action a = move(s, d); // encapsulates a move command
t.setTrigger(EVENT_DESTROYED, a);
}
I would agree for a typical rts (or rtt), a game based around planning battles ahead of time would be very different from your typical rts. It would be much less about micro management and rapid clicking and more about planning ahead. (btw I don't mean to sound negative about existing rts games, I've enjoyed them a lot.) I would probably keep the direct control model for things like logistics (resource gathering, building up forces, exploring, moving units around outside of combat) although optional plans could be used there too.
Quote:
Original post by Sandman
I'm inclined to agree, for the most part. Certainly you don't want to be frantically typing up scripts in the middle of a battle - it is far too time consuming and completely destroys immersion.
I wouldn't expect them to modify scripts in the middle of a battle, in fact I don't think the players should be allowed to change the plans once the fighting starts.
Quote:
Original post by Sandman
I think there could be potential for a robot RTS game involving user developed scripts - like that rover game whose name I forget (mind rover?). Scripts could be written before the battle and whoever has the best combination of strategy, control and cleverly thought out scripts will win.
That's the kind of thing I was going for: planning ahead, strategy, clever gambits, etc. But I don't think it would have to be robots, it's just a matter of how you present the mechanic. Call them battle plans and make the plans look more like english than programming language (although keep it simple).
Quote:
Original post by Taolung
To expand on what Kekko said, you should be able to select a dropship, tell it to move to a location, drop the crew, and then move to another location. This way, I don't have to babysit it and move it myself. I can just tell it to go, and then turn my attention elsewhere. Nothing terribly complicated, just a queue of actions and maybe some "IF" "OR" variables to give things more flexability.
"Take units to location B. If dropship comes under attack, retreat to location C. If not, deliver units to location B and then return to location A."
I was thinking of plans (scripts) that look more like that than like what Nuvem posted. Maybe something like:
Dropship plan
move to point A, pick up any units there, move to point b, unload, repeat
if under fire retreat, change drop point to c
if a unit calls for evac and hp > 50%, go for pick up
The language should look more like english than a programming language. And by all means allow the player to select actions and operations from a list or buttons or whatever. The user interface should be as easy to use as possible, auto completion of words would be nice too.
This game would probably need to be a bit slower paced outside of battle, give people time to plan and write their battle orders. Once combat begins it can go fast though. The tone should be more one of generals planning complex engagements than the quick and bloody skirmishes in a standard rts. The emphasis would be on out witting your opponent, you want to surprise him with a strategy he hasn't thought of or prepared for and that his battle plan doesn't cover. You could have larger armies too, since there is less micro management durring the battles.
Personally, I love games that require intense multitasking, like Starcraft. There are many others like me, so abstracting away micro-control from the game would limit your audience (however, so would requiring it, so its up to you).
EDIT: (Random points)
Its stupid to limit player control in order to make faster players fare worse.
-
You can make complex way point systems... but who will have time during the game to set them up? Unless the game is reaaal slow paced.
EDIT: (Random points)
Its stupid to limit player control in order to make faster players fare worse.
-
You can make complex way point systems... but who will have time during the game to set them up? Unless the game is reaaal slow paced.
Quote:
Original post by Solias
I wouldn't expect them to modify scripts in the middle of a battle, in fact I don't think the players should be allowed to change the plans once the fighting starts.
It would be nice if plans were shared with all players in multiplayer, and while plans themselves would be locked, players should be able to enable/disable plans at any time (so if I discover I'm not really going to use a certain plan this game, no reason to have it clutter the menu).
Quote:
Original post by Daniel Miller
Personally, I love games that require intense multitasking, like Starcraft. There are many others like me, so abstracting away micro-control from the game would limit your audience (however, so would requiring it, so its up to you).
EDIT: (Random points)
Its stupid to limit player control in order to make faster players fare worse.
-
You can make complex way point systems... but who will have time during the game to set them up? Unless the game is reaaal slow paced.
It has nothing to do with making faster players fare worse, it has everything to do with making slower players fare better. Personally, I don't mind seeing the twitchers go. Strategy games shouldn't be click-fests. A game can be fast paced without requiring a click-fest of micromanagement.
But then, I've always prefered TA to StarCraft. Nothing quite like automating all the b***h-work and concentrating on the battles.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement