RTS how
Moderator: Moderators
RTS how
If spring was lost forever, and a new engine with uber fast rendering and crossplatform support was handed to them, but with no game mechanics of any kind written ontop of it save for a basic API for rendering camera and input kind of stuff, what would be the best way fo implementing an RTS ontop of it for maximum flexibility?
Re: RTS how
are you gearing up to make your own rts in ogre or something?
look at folder names in spring source, those are generally the high-level components you'll need. the rest is an implementation detail, albeit an important one.
due to multicore stuff you probably want to look at id rage presentation if you're asking for a modern architecture howto (in short - job-based design).
look at folder names in spring source, those are generally the high-level components you'll need. the rest is an implementation detail, albeit an important one.
due to multicore stuff you probably want to look at id rage presentation if you're asking for a modern architecture howto (in short - job-based design).
Re: RTS how
Not implementing one. Maximum flexibility is a blank slate. As soon as you start offering features, you start defining constraints.AF wrote:If spring was lost forever, and a new engine with uber fast rendering and crossplatform support was handed to them, but with no game mechanics of any kind written ontop of it save for a basic API for rendering camera and input kind of stuff, what would be the best way fo implementing an RTS ontop of it for maximum flexibility?
Re: RTS how
1). Define the core tasks you want the engine to (be able to) do.
2). Define the auxiliary tasks you want the engine to (be able to) do.
3). For #2, find out which are better done in a scripting language layer and move them there.
4) Stop making suggestive posts.
2). Define the auxiliary tasks you want the engine to (be able to) do.
3). For #2, find out which are better done in a scripting language layer and move them there.
4) Stop making suggestive posts.
Re: RTS how
I would go with the following:
Money system:
Oil derrics built on patches of oil, that may end somtime dependant on their size.
Weapon\Armor system:
Same as Spring has with the little addition of sub classes( or prioities) that work like in the example tutorial. Unit might be Aircraft and Bomber and that latter has a higher priority, so if a weapon has both it will be chosen over the other.
Other features:
Technologies randomly assigned to the player that improve or replace certain units (thats the plan for NWO
)
other: perhaps more failure tolerance to make it easier to get into modding and also a bit cleaer error messages so you know what went wrong.
Money system:
Oil derrics built on patches of oil, that may end somtime dependant on their size.
Weapon\Armor system:
Same as Spring has with the little addition of sub classes( or prioities) that work like in the example tutorial. Unit might be Aircraft and Bomber and that latter has a higher priority, so if a weapon has both it will be chosen over the other.
Other features:
Technologies randomly assigned to the player that improve or replace certain units (thats the plan for NWO
)other: perhaps more failure tolerance to make it easier to get into modding and also a bit cleaer error messages so you know what went wrong.
Re: RTS how
I'm just thinking about university assignments, Id rather build a basic RTS than say an action RPG that has been suggested for every coursework of every year since I started.
Do you have any links ot any presentations in particular? Ill go google the id rage presentations now
edit: To further clarify, I was asking given a clean slate how would you guys re-implement spring?
Do you have any links ot any presentations in particular? Ill go google the id rage presentations now
edit: To further clarify, I was asking given a clean slate how would you guys re-implement spring?
Re: RTS how
uni projects? a 3d rts engine is way over the top, even if all the graphics is provided by a black box. you might as well give students spring and tell them to make their own games in lua.
what could work is perhaps learning java by writing some dumb AIs, if you give them something slightly more advanced than the null AI and a very simple mod, like com shooters.
what could work is perhaps learning java by writing some dumb AIs, if you give them something slightly more advanced than the null AI and a very simple mod, like com shooters.
Re: RTS how
Not at all, I know other people who have implemented RTS engines for university assignments. Nothing as vast or complicated as spring.
That and I am genuinely curious as to what the best way to re-implement something like spring would actually be.
That and I am genuinely curious as to what the best way to re-implement something like spring would actually be.
Re: RTS how
I wrote a really terrible simple RTS for the gameboy advance last year as the final project for my nontraditional platform computing course.
For a school project I'd recommend you not bother with making a fully genericized engine; clean but game-specific code and a solid-looking application will probably get you a much better mark than a highly expandable engine that is useless without additional work external to the engine.
For a school project I'd recommend you not bother with making a fully genericized engine; clean but game-specific code and a solid-looking application will probably get you a much better mark than a highly expandable engine that is useless without additional work external to the engine.
Re: RTS how
Agreed, something more generic would be more work, but I would like to understand how I would do it before I work on specifics.
Re: RTS how
I apologize for the length. I seem to be writing Argh novellas again. Ah well.
1. Make sure the engine can support all of the hacks n' tricks used for modern rendering, such as lightmaps, deferred rendering of the geometry, etc.
Don't try to brute-force it, basically. Spring's getting a lot better in this regard recently, but it still has a long way to go, and is almost a poster child for how early design decisions can hamstring you later. I'm sure SJ is amazed that people have been hacking this thing for so long, frankly, instead of ditching it and starting over.
Really nice modern engines are an amalgam of programmers providing tricky ways to cheat, and artists taking full advantage of same. In fact, the more I learn about how it actually works, and how pros do it, the more amazed I am that Spring is built the way it is.
Most of the tech's non-trivial, but OGRE gives you a big boost, so it probably won't hurt too much.
I'd also strongly suggest sitting down with the people in your program that are training for the content jobs (or, if you don't have any at your school, contact a local arts college that has a game-art curriculum and arrange some time with a professor there, if possible) and talk to the people on the art side about their process, and what they expect. People like me, with no formal training and a fair amount of experience with do-it-yourself-period, can't really put you into their head space, and they probably have different expectations of what they expect an engineer to provide for them.
Anyhow, I don't know the scope of your project, or whether it will include other students contributing content, etc., but I thought I'd throw that out. You can probably save a lot of time and frustration, if you know what they're going to expect, in terms of input / output / tools and ease-of-use / UI. Assuming that you're going to build a final project with a real, live level design, not just some crappy WIP graphics and a long paper about how cool the underlying algorithmic goodness is.
I know OGRE has all sorts of gee-whiz... theoretically... but from what I've read, it requires a lot of thought and the willingness to tackle its deep code to really get what you need from it, to create a truly modern game. I'm sure Smoth can tell you horror stories, but bear in mind, that was several years ago.
2. Because of inheriting OTA's Unit / Feature system, we have serious problems in terms of flexibility in terms of scene construction.
Plan this area with extreme care, if you're serious about the graphical side, and want to demonstrate that you're ready to become a full-fledged engine architect. If you're going to settle on a demo project that's mainly just showing off your programming prowess, you can skip this entire bit, although I'd talk about it in a final paper, certainly, no matter how you design it.
Anyhow, these are my thoughts on this.
I cry about this issue a lot here, but I certainly have reasons. I want to build whole dynamic cities, that (eventually) have elements that do a lot more interactions with one another... without clobbering end-user's CPUs. But my choices are pretty limiting, largely because of fundamental design constraints in this engine. I can either have proper functionality and interaction with the engine's full suite of tools, or I can have a Feature, which is basically worthless as a serious production-value prop, other than really basic items like groundcover, which doesn't need to be interactive. It sucks, to be stuck with 1993 choices in a 2009 game engine, but there it is.
A truly well-designed engine would (imo, at least) avoid this problem by never making this choice at all, at the engine level. I'd build it with fast core logic, and have Unit behaviors be entirely constructed via a single callin that starts Unit logic, implemented in Lua, that then uses callouts to perform the actions a Unit needs to do in order to function.
There isn't any reason why this can't work, and be plenty speedy, given that for the most part, it's just going to be a very simple structure on the Lua side that will hardly be a load vs. whatever compiled language you use. But the key advantage of this is that, if you have an object where it doesn't even need to do a check vs. a tag... hey, there are no tags, so you just don't make that callout at all. So a blind Unit that doesn't use any Energy or Metal, can't cloak, has no animations scheduled until it dies, for example... doesn't touch the LOS logic, the economics logic, etc... at all.
People get on my case for continually stressing optimization stuff that seems worthless, and that's fine, we're all entitled to our POV. All I know is that I build what are easily the most complex scenes on this engine, period, and that I am always having to struggle with finding yet-another shortcut that will save some CPU time. If I could run Unit-equivalents with Lua, I'd almost certainly load-balance the entire game, item by item, to cut as much fat as humanly possible.
Why go to all this trouble? For tomorrow's games, either you build a laser-specific engine designed around avoiding anything that isn't essential, or you build a generally robust platform that can be used for projects with epic scope. It's getting harder and harder to do the first, outside of very limited game designs, so in many ways I think that this is the final solution- build the second, but make its logical components called in a very flexible way.
That, and to be really honest, I think it's less trouble, in the end, to build a large, robust engine this way.
Anyhow, that's just a thought, but it's something I've been thinking about for awhile. Since JC's project quietly died, I haven't really had much urge to vent about all of this fundamental stuff, since it's incredibly unlikely that this could be done with Spring at this late date, and there are so many low-hanging fruit still left.
3. I know you're an AI wizard, but... again... this is an area where interpreted language support could do pretty amazing stuff, in terms of load-balancing and maintenance.
Have a Unit that needs to make a decision whether to fly somewhere or take a ground route? Well, making that decision may require some very fast, compiled checks, but deciding when to schedule it... doesn't. Yet how often to schedule it is a massively-crucial part of final load balancing. Why stick that stuff into an area that's hard-coded, which also makes overall engine design harder, when you can avoid that issue entirely? Why build logic that is all-inclusive and specific, when you can build logic that is modularized?
I'm not saying that you can avoid large logical issues entirely there- some things, like the overall decisions of where to send groups, and when to build or not build, are pretty much required. But that's about it. The rest of it can be behavior emerging from a bunch of sub-cells, and each sub-cell can be load balanced according to its real needs. It makes no sense to run a search for nearby enemies thirty times a second, for example, for an attack unit that moves very slowly but has a long-ranged weapon... so use an open design where it can avoid these problems. In practical situations, a game designer could do a few hours of boring copy-pasta work, then gradually improve the performance of the game... all without you having to constantly do more work! Sounds like a win-win to me.
Amongst other things, this also provides a very ready way to optimize their resulting emergent behaviors by passing signals to each other as they finish a given logical step.
For example, the Overlord, our main AI, wants Energy.
Unit A is a builder, can build Energy, can find suitable ground, and is not near to a current conflict zone, and has several nearby Builders that can help.
Instead of doing all of that work and then passing back to the overlord, Unit A can use callouts to determine the logical action... and then as a result, pass a message to the nearby Builders to assist it, which would also activate a flag, Lua-side, for them, so that the Overlord doesn't need to even communicate with them at all, let alone have them all repeat the same calculations again.
Unit A's thread would return to the Overlord with a "action being taken, do not bother me again for X seconds, and don't bother Units B, C, D and E, either, because I've already talked to them", basically, saving a lot of overhead, even though the cost for Unit A's Lua side is non-trivial. Just a thought, mind ye... but you said the word, "general", so I'm throwing that out.
4. Lastly... I'd rather see an engine that incorporated a lot of the ideas above, that wasn't necessarily an RTS engine. Part of what Spring's shown me is that... if Spring had not been locked into many of SJ's fundamental design choices so long ago, then we'd be seeing a lot more game designs on this thing.
A demo of a straightforward RTS design is a good way to show off the capabilities of an engine, though. If nothing else, it'd show how well you can deal with CPU load handling, which is the major chokepoint on most games atm, if they aren't really horribly designed graphically. Normalmaps and other shader techniques have finally given the GPU side a lot of flexibility and breathing space (at least, in a well-designed engine).
1. Make sure the engine can support all of the hacks n' tricks used for modern rendering, such as lightmaps, deferred rendering of the geometry, etc.
Don't try to brute-force it, basically. Spring's getting a lot better in this regard recently, but it still has a long way to go, and is almost a poster child for how early design decisions can hamstring you later. I'm sure SJ is amazed that people have been hacking this thing for so long, frankly, instead of ditching it and starting over.
Really nice modern engines are an amalgam of programmers providing tricky ways to cheat, and artists taking full advantage of same. In fact, the more I learn about how it actually works, and how pros do it, the more amazed I am that Spring is built the way it is.
Most of the tech's non-trivial, but OGRE gives you a big boost, so it probably won't hurt too much.
I'd also strongly suggest sitting down with the people in your program that are training for the content jobs (or, if you don't have any at your school, contact a local arts college that has a game-art curriculum and arrange some time with a professor there, if possible) and talk to the people on the art side about their process, and what they expect. People like me, with no formal training and a fair amount of experience with do-it-yourself-period, can't really put you into their head space, and they probably have different expectations of what they expect an engineer to provide for them.
Anyhow, I don't know the scope of your project, or whether it will include other students contributing content, etc., but I thought I'd throw that out. You can probably save a lot of time and frustration, if you know what they're going to expect, in terms of input / output / tools and ease-of-use / UI. Assuming that you're going to build a final project with a real, live level design, not just some crappy WIP graphics and a long paper about how cool the underlying algorithmic goodness is.
I know OGRE has all sorts of gee-whiz... theoretically... but from what I've read, it requires a lot of thought and the willingness to tackle its deep code to really get what you need from it, to create a truly modern game. I'm sure Smoth can tell you horror stories, but bear in mind, that was several years ago.
2. Because of inheriting OTA's Unit / Feature system, we have serious problems in terms of flexibility in terms of scene construction.
Plan this area with extreme care, if you're serious about the graphical side, and want to demonstrate that you're ready to become a full-fledged engine architect. If you're going to settle on a demo project that's mainly just showing off your programming prowess, you can skip this entire bit, although I'd talk about it in a final paper, certainly, no matter how you design it.
Anyhow, these are my thoughts on this.
I cry about this issue a lot here, but I certainly have reasons. I want to build whole dynamic cities, that (eventually) have elements that do a lot more interactions with one another... without clobbering end-user's CPUs. But my choices are pretty limiting, largely because of fundamental design constraints in this engine. I can either have proper functionality and interaction with the engine's full suite of tools, or I can have a Feature, which is basically worthless as a serious production-value prop, other than really basic items like groundcover, which doesn't need to be interactive. It sucks, to be stuck with 1993 choices in a 2009 game engine, but there it is.
A truly well-designed engine would (imo, at least) avoid this problem by never making this choice at all, at the engine level. I'd build it with fast core logic, and have Unit behaviors be entirely constructed via a single callin that starts Unit logic, implemented in Lua, that then uses callouts to perform the actions a Unit needs to do in order to function.
There isn't any reason why this can't work, and be plenty speedy, given that for the most part, it's just going to be a very simple structure on the Lua side that will hardly be a load vs. whatever compiled language you use. But the key advantage of this is that, if you have an object where it doesn't even need to do a check vs. a tag... hey, there are no tags, so you just don't make that callout at all. So a blind Unit that doesn't use any Energy or Metal, can't cloak, has no animations scheduled until it dies, for example... doesn't touch the LOS logic, the economics logic, etc... at all.
People get on my case for continually stressing optimization stuff that seems worthless, and that's fine, we're all entitled to our POV. All I know is that I build what are easily the most complex scenes on this engine, period, and that I am always having to struggle with finding yet-another shortcut that will save some CPU time. If I could run Unit-equivalents with Lua, I'd almost certainly load-balance the entire game, item by item, to cut as much fat as humanly possible.
Why go to all this trouble? For tomorrow's games, either you build a laser-specific engine designed around avoiding anything that isn't essential, or you build a generally robust platform that can be used for projects with epic scope. It's getting harder and harder to do the first, outside of very limited game designs, so in many ways I think that this is the final solution- build the second, but make its logical components called in a very flexible way.
That, and to be really honest, I think it's less trouble, in the end, to build a large, robust engine this way.
Anyhow, that's just a thought, but it's something I've been thinking about for awhile. Since JC's project quietly died, I haven't really had much urge to vent about all of this fundamental stuff, since it's incredibly unlikely that this could be done with Spring at this late date, and there are so many low-hanging fruit still left.
3. I know you're an AI wizard, but... again... this is an area where interpreted language support could do pretty amazing stuff, in terms of load-balancing and maintenance.
Have a Unit that needs to make a decision whether to fly somewhere or take a ground route? Well, making that decision may require some very fast, compiled checks, but deciding when to schedule it... doesn't. Yet how often to schedule it is a massively-crucial part of final load balancing. Why stick that stuff into an area that's hard-coded, which also makes overall engine design harder, when you can avoid that issue entirely? Why build logic that is all-inclusive and specific, when you can build logic that is modularized?
I'm not saying that you can avoid large logical issues entirely there- some things, like the overall decisions of where to send groups, and when to build or not build, are pretty much required. But that's about it. The rest of it can be behavior emerging from a bunch of sub-cells, and each sub-cell can be load balanced according to its real needs. It makes no sense to run a search for nearby enemies thirty times a second, for example, for an attack unit that moves very slowly but has a long-ranged weapon... so use an open design where it can avoid these problems. In practical situations, a game designer could do a few hours of boring copy-pasta work, then gradually improve the performance of the game... all without you having to constantly do more work! Sounds like a win-win to me.
Amongst other things, this also provides a very ready way to optimize their resulting emergent behaviors by passing signals to each other as they finish a given logical step.
For example, the Overlord, our main AI, wants Energy.
Unit A is a builder, can build Energy, can find suitable ground, and is not near to a current conflict zone, and has several nearby Builders that can help.
Instead of doing all of that work and then passing back to the overlord, Unit A can use callouts to determine the logical action... and then as a result, pass a message to the nearby Builders to assist it, which would also activate a flag, Lua-side, for them, so that the Overlord doesn't need to even communicate with them at all, let alone have them all repeat the same calculations again.
Unit A's thread would return to the Overlord with a "action being taken, do not bother me again for X seconds, and don't bother Units B, C, D and E, either, because I've already talked to them", basically, saving a lot of overhead, even though the cost for Unit A's Lua side is non-trivial. Just a thought, mind ye... but you said the word, "general", so I'm throwing that out.
4. Lastly... I'd rather see an engine that incorporated a lot of the ideas above, that wasn't necessarily an RTS engine. Part of what Spring's shown me is that... if Spring had not been locked into many of SJ's fundamental design choices so long ago, then we'd be seeing a lot more game designs on this thing.
A demo of a straightforward RTS design is a good way to show off the capabilities of an engine, though. If nothing else, it'd show how well you can deal with CPU load handling, which is the major chokepoint on most games atm, if they aren't really horribly designed graphically. Normalmaps and other shader techniques have finally given the GPU side a lot of flexibility and breathing space (at least, in a well-designed engine).
Re: RTS how
A Lua interpreter, plus all the Lua functions of Spring. Which is what Spring is already becoming.AF wrote:If spring was lost forever, and a new engine with uber fast rendering and crossplatform support was handed to them, but with no game mechanics of any kind written ontop of it save for a basic API for rendering camera and input kind of stuff, what would be the best way fo implementing an RTS ontop of it for maximum flexibility?
Re: RTS how
Argh, load balancing is something us AI devs ran into 2-3 years ago, and conjured up various solutions, such as switching to task/job based systems, using messages with throttling, or staggered periodic checks.
*sends pm*
*sends pm*
-
Master-Athmos
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: RTS how
Maybe ask around at a Torque forum what exactly was done to get this running...
http://www.garagegames.com/products/rts-genre-kit
http://www.garagegames.com/products/rts-genre-kit