Well, pretty much any type of game will be modifiable to some degree, it just takes a lot more planning/know how to make a game easily modifiable.
If you think you can tackle the technical side and are looking for more conceptual ideas (maybe I misunderstood what you were asking for), then you should check out BattleForge from Phenomic (developer)/EA (publisher). BattleForge has a resource gathering/management mechanism that is pretty unique (the idea that you get a large proportion of the resources back over time when units die... rather like a "respawn timer" from FPS games). It is also a good example of a game that can feature intense gameplay without any form of fog of war. Since power comes back when units die, the focus of the game is on gaining power advantage, and therefore map control. However, building new wells (buildings that collect power) will give you a power DISADVANTAGE until the well collects enough power to offset its cost (about 3 minutes).
In essence, when you gain power, it never really "leaves" your power pool unless you build wells or monuments (things that let you summon more powerful creatures ie tech). This introduces the notion of "bound power". If you have a large army on the field, you will have the majority of your power pool bound. This gives you a significant disadvantage, in that if your opponent pulls out something that you currently have no power for, you cannot immediately get the power that is bound in your army. You have to wait for the power to slowly return after you decommission the army.
There are a lot of other subtleties to the game, so it's definitely worth checking out. The game is completely free to play and funded with microtransactions, and you can get a decent feel for the game without spending any money on it.
Making a RTS, needs suggestions
Quote:
Original post by RayneRTS
Okay.
First of all, it's set in the future.
There is 2 types of resources;
ENERGY to keep buildings working, and
POINTS to purchase buildings/units/upgrades
POINTS are gathered mainly by harvesting, but you can also get it by controlling control points on the map, and taking control over buildings.
ENERGY is gain by buildings like POWER PLANTS and similar.
You can abstract resources more and also let the modder decide how many resources exist in their game. This will allow much more flexibility in how the game can be Modded.
Quote:
Original post by RayneRTS
TERRAIN - Can not change during gameplay. Different units may have more difficult to pass certain terrain. EX: Rough terrain, Water, pavement.
OVERLAY - Can be added, changed and removed during gameplay. EX: craters, roads, bridges.
ITEMS - Can be added, changed, removed and moved during gameplay. Can be both impassable and passable. EX: Trees, rocks.
These are good. You might also want to add in that Overlays and Items can do more than just be "Passable" or "Impassable". If you ahve a system like the Terrain system that can effect different unit type movement it could make for a much more interesting map design.
Also, have the effects moddable as well.
Quote:
Original post by RayneRTS
PARTICLES - Can be removed, added and changed during gameplay. May harm units and buildings. EX: Fire, debris, explosions.
IF you allow Items to have these properties, then these can be considdered a form of Item. They are so close in how they could work, you may as well merge them into a single object type.
Quote:
Original post by RayneRTS
BUILDINGS - Can be built, changed, destroyed, and sold during gameplay. May allow you to build more buildings/units. EX: House, factory, barracks.
UNITS - Can be built, changed and destroyed during gameplay. Units have different locomotors to control how they act and react. EX: Infantry, vehicles, aircraft, ships, creatures
Buildings and Units can actually be considered the same thing. Buildings can just be units with a Move and turn rate of 0.
This way, if a modder wants, they could have a unit that is capable of producing other units (think of the Necron Monolith from Dawn of War).
So if you abstract it a bit more, you can reduce the number of game object types to:
Resource
Terrain
Overlay
Placable (Items and Particles)
Unit (units and Buildings)
Of course, these are not trivial and they would have quite a few properties and setting you could include in them.
@MortusMaximus: The reason you would have had to rebuild the core game so much is that you didn't originally start out trying to design a Moddable game, but instead tried to take one in the middle of development and tried to make it moddable.
They are very different in what you have to do for them (as you would ahve discovered). Making a game Moddable is not just a simple matter of letting the modder set the variables that you use, but involves thinking about the whole way you handle game/code objects and the structure of your code.
If you don't set out with a proper architectural design, making a game moddable is a real nightmare.
I like your suggestions! The great difference between particles and items is that particles may spawn other particles, may move, may have many varying settings and similar, so I'd like them to be in an own category.
Honestly, you need to make sure the core program is as well designed as game play. Let me show you an example...
Player A - Has a fighter that flies around in selective air currents but is a very dangerous unit.
Player B- Has a ground unit capable of shooting down the Player A fighter but it is restricted to water terrain.
* Most people at this point would feel that these two do not work well together?
So you give Player A an option to alter the air currents due to a unit or building type.
Player B receives a unit that can alter the terrain to provide water tiles.
- Now before you say wait! That balances out perfectly... You put some tactical thinking into the mix. Player A & B can make only so many buildings... So if player A wanted to develop those air currents from buildings this reduces the amount of support buildings that player can make.
(But this makes it easier for player B right? Wrong.) If you make sure that on water tiles Player B is incapable of placing units/buildings then you have a balance. If during beta testing you find the balance is still lost and Player B is receiving too much of an advantage. Then you have several balance options to work with. In the end you need some technique and planned out balance that allows each player to take advantage in some way but also come out being equals. This allows tactics to be the only difference.
Plus I would think about what Edtharan is saying. If you want your particles to act in that way... As the programmer you can do anything you wish but anyone coming in behind you will question why you did it this way or that...
If particles have the option of moving/spawning/varied settings... Then I would set them in the building/unit function list with their more exotic affects being a called function. This allows you to have that alteration you want but keeps others behind you from asking why you added more functions when one could possible do.
That last part was only IMHO and has no true bearing on your programming skill. I would be careful though, too many companies now go with sloppy code and while functions should be small, clean and simple... Too many functions can confuse just as easily as to few...
Player A - Has a fighter that flies around in selective air currents but is a very dangerous unit.
Player B- Has a ground unit capable of shooting down the Player A fighter but it is restricted to water terrain.
* Most people at this point would feel that these two do not work well together?
So you give Player A an option to alter the air currents due to a unit or building type.
Player B receives a unit that can alter the terrain to provide water tiles.
- Now before you say wait! That balances out perfectly... You put some tactical thinking into the mix. Player A & B can make only so many buildings... So if player A wanted to develop those air currents from buildings this reduces the amount of support buildings that player can make.
(But this makes it easier for player B right? Wrong.) If you make sure that on water tiles Player B is incapable of placing units/buildings then you have a balance. If during beta testing you find the balance is still lost and Player B is receiving too much of an advantage. Then you have several balance options to work with. In the end you need some technique and planned out balance that allows each player to take advantage in some way but also come out being equals. This allows tactics to be the only difference.
Plus I would think about what Edtharan is saying. If you want your particles to act in that way... As the programmer you can do anything you wish but anyone coming in behind you will question why you did it this way or that...
If particles have the option of moving/spawning/varied settings... Then I would set them in the building/unit function list with their more exotic affects being a called function. This allows you to have that alteration you want but keeps others behind you from asking why you added more functions when one could possible do.
That last part was only IMHO and has no true bearing on your programming skill. I would be careful though, too many companies now go with sloppy code and while functions should be small, clean and simple... Too many functions can confuse just as easily as to few...
Sorry, I won't change the particles.
But beside that, I fully agree with you. Thank you.
Please, more suggestions!
But beside that, I fully agree with you. Thank you.
Please, more suggestions!
Essentials of a good RTS:
1] Complexity and at least 3 options at all times to allow for a sort of rock / scissors / paper system.
ie: don't just start with one available unit. Start with at least 3 and allow the player to combine them how they want.
2] Everything must have a strength and a weakness from beginning to end game. You can't call it a strategy game without the requirement of reasoning for each choice throughout the gameplay experience. This includes unit choices, teching, getting more energy etc etc. Two examples provided to be clear here.
example 1: the battle cruiser and carrier in bw are always a unit chosen by noobs. The problem with these units are:
a) cost a ton
b) very slow
c) high on tech tree
d) weak to casters
3) little to no micro required
example 2: You can expand right away in bw (get another base to start mining more resources), however if you do this you are exposing yourself in some ways:
a) less money for units / tech
b) more area to defend
c) can't be aggressive
3] Do NOT make a linear progression system. In other words, don't have a building do the same thing but at x times efficiency based on x upgrades. Really mindless to do this sort of thing. Make the tech tree cost with high risk and matter dramatically.
4] Ensure that offensive play has rewards. Even in this scenario, people tend to try and defend their base. If you play the aggression card, it will force people into conflict more often and they will have to adapt more rather than use a prebuilt strat.
example: A common Terran strat in bw is to turtle and go early mech. This is a prebuild, where everything is memorized for the first 5 to 6 minutes of play. Often the solution on pro maps is to simply ensure there is more than one entrance into the Terran base since this is much harder to turtle against.
1] Complexity and at least 3 options at all times to allow for a sort of rock / scissors / paper system.
ie: don't just start with one available unit. Start with at least 3 and allow the player to combine them how they want.
2] Everything must have a strength and a weakness from beginning to end game. You can't call it a strategy game without the requirement of reasoning for each choice throughout the gameplay experience. This includes unit choices, teching, getting more energy etc etc. Two examples provided to be clear here.
example 1: the battle cruiser and carrier in bw are always a unit chosen by noobs. The problem with these units are:
a) cost a ton
b) very slow
c) high on tech tree
d) weak to casters
3) little to no micro required
example 2: You can expand right away in bw (get another base to start mining more resources), however if you do this you are exposing yourself in some ways:
a) less money for units / tech
b) more area to defend
c) can't be aggressive
3] Do NOT make a linear progression system. In other words, don't have a building do the same thing but at x times efficiency based on x upgrades. Really mindless to do this sort of thing. Make the tech tree cost with high risk and matter dramatically.
4] Ensure that offensive play has rewards. Even in this scenario, people tend to try and defend their base. If you play the aggression card, it will force people into conflict more often and they will have to adapt more rather than use a prebuilt strat.
example: A common Terran strat in bw is to turtle and go early mech. This is a prebuild, where everything is memorized for the first 5 to 6 minutes of play. Often the solution on pro maps is to simply ensure there is more than one entrance into the Terran base since this is much harder to turtle against.
So this is a thread for random RTS ideas? I dig.
I disagree with the Rock-Paper-Scissors idea. Not completely, it's usually a very fun system that makes for a lot of interesting possibilities, but I don't see it as essential, as so many developers do. Why conform?
Instead of going on that mode though, I'll throw out my ideas.
How about having mainly generic units that can be set to follow certain behavior patterns. You could issue orders on the fly to your units but micromanaging one group will detract from your base as a whole. Perhaps to remedy this problem you could add options to train units to follow AI routines automatically, which would be expensive to set up but ultimately make units more effective without your own intervention. Infact, the entire system could be set up to make a balance not of in-game resources but of the player's own available attention span.
I disagree with the Rock-Paper-Scissors idea. Not completely, it's usually a very fun system that makes for a lot of interesting possibilities, but I don't see it as essential, as so many developers do. Why conform?
Instead of going on that mode though, I'll throw out my ideas.
How about having mainly generic units that can be set to follow certain behavior patterns. You could issue orders on the fly to your units but micromanaging one group will detract from your base as a whole. Perhaps to remedy this problem you could add options to train units to follow AI routines automatically, which would be expensive to set up but ultimately make units more effective without your own intervention. Infact, the entire system could be set up to make a balance not of in-game resources but of the player's own available attention span.
Yeah, it's a place for random RTS ideas, so you SHOULD dig. And keep the suggestions coming.
I've taken all your suggestions highly into consideration, and I'm thinking up ways to make it like that.
I've taken all your suggestions highly into consideration, and I'm thinking up ways to make it like that.
Now that I think about it, an RTS that requires a lot of micromanaging would make for some interesting cooperative multiplayer. You could actually split player duties between battalions and require teamwork or else the enemy would totally devour you. Even deciding who takes what responsibilities could be a strategic elements in its own.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement