Basically, I have spent the last two days with Dark Crusade, from a modding standpoint. I should be working on my current project, but I've been very busy and mentally stressed with IRL stuff (I recently changed employment, I have a big family vacation next week, there's a lot of stuff going down), so I thought I'd study another game engine for a minute, to compare it with Spring, and here are my resulting thoughts.
1. Dawn of War is a very, very, very messy game engine, compared to Spring. References piled upon references piled upon references. A single unit consists of model files, FX files, a single-unit description (with many sub-references), a Squad file that actually allows it to be called as a functional game entity, icons, contextual help-text files, and many other things.
While Spring has most of these things, the cleanliness and clear reference paths is comparably superior, in my opinion. For example, because we have BOS, many things that in DoW are a big mess of procedural animation calls can be done within a single script. And what we can do, in most areas, is superior in cleanliness of design and flexibility.
For example, DoW calls up sounds through FX calls. This is cool, and something Spring should have, but it also comes with a lot of additional pain. For one thing, you cannot just call a sound via a motion script- no, that's a seperate event, and it adds bloat, and yet another software tool you're supposed to use, just to call a fricking soundfile and send it to the audio output.
Moreover, it adds terrific complexity in terms of maintenance, and makes adding new content harder. Trust me on this- all I wanted to do, at one point yesterday, was to make the Dark Reaper's missile weapon (if you have no idea what I'm talking about, don't worry about it) into a projectile weapon that actually obeys gravity and has an arc and deviation.
After much back-tracking of references, I eventually found out that the true behavior of the projectile was caused by two different actors:
A. There was a LUA/RGD file that actually created some of the physical behaviors of the object in terms of game effects, as well as what FX are called when the projectile terminates (i.e., hits something or times out). It also calls the projectile model, but it doesn't directly control the sounds, etc. Compared to a Spring weapon's file... gawd, it's a nightmare! And even when I got through all of that... I looked at the main controlling LUA for the weapon, and realized that if I wanted to actually have the weapon obey true LOS (99% of the weapons in DoW ignore terrain and LOS entirely) I'd have to change yet-another thing, and one reference I read last night said basically, "don't do this with things that fire more than once every few seconds, because DoW's physics code is extremely slow"! So, I dropped that like a hot potato and moved on...
B. The projectile itself, buried in a sub-sub-sub-sub-directory (I wish I was kidding) controls the sounds and the FX of the projectile, including the smoke trail. I think that the smoke trail is yet another procedure, written in some debased, nasty LUA, that is tied to the model in yet-another sub-reference, but by the time I'd figured all of this out, I'd gotten tired of the whole thing, and the smoke trail, explosion event, etc., were all adequate to my needs at that point.
2. DoW's support of import/export of model content is comparatively poor. While it could be argued that Spring is worse off, since we're stuck with a boneless animation format, and I'd agree that that is one of the biggest things holding Spring back, that's about the only thing that's really terrible. You cannot add new content to DoW without having a (probably-pirated) copy of 3DS Max, v. 6-8 (can't use 9, because it's too new and the exporter script apparently borks) and you cannot use just any-old format for content creation- nope, gotta use 3DS, or you're hosed, because that's how the animation format works.
One of the major challenges for the developers of Command Engine (which, I assume, is going to be where we're all going soon) should be to develop a bone-system animation format that is useable through UpSpring (or whatever the new content-development tool is called) but is tied to a BOS-like language for animation control and arguments.
After viewing what a huge mess it is to develop working content in a game engine that doesn't have this basic backbone (the amount of working, non-buggy and 100% original stuff for DoW, despite its popularity with modders, is vanishingly small) I would have to say that Command Engine needs to put this issue at the forefront. I've made a very, very big deal about content-development on these forums since I got here, and as most of you know, I often jump into any discussion involving development of the game elements that players interact with a lot of the time, because, along with UI (a topic I'll admit I'm mainly ignorant about) these are the two biggest factors in terms of whether a community that is not paid to create things can actually get work done.
Anything less than simple, ironclad and robust implementation is very likely to fail, in my opinion, because it's one thing to design something that can make super-kewl demos that took a month of work and expert knowledge of the system to achieve... and another thing entirely to expect, say, me... to actually sit down and build an entire game with it. I keep being annoying, and saying, "hey, keep it simple, explain stuff, document what you're doing, make examples" with stuff around here, because when I'm working on a game, I simply don't have enough spare brain matter to devote to an entire system full of complexity, unless it's dead vital to what I'm doing at the moment.
I know that goes for most of the game developers here, too- we're trapped between the theoretical could-be-done of where Spring is now and the what-do-we-really-have-time-to-do aspects, just like a professional team working with a complex game engine is, only here we're not getting paid.
3. DoW's support for contextual events, and theoretical flexibility is much higher than Spring's. For example, you can have units in DoW show different FX, or even call new animations, depending on what weapon hits them. In theory, after reading some of the deeper sections, it appears that if I really, really, really wanted to, I could re-code the entire combat system from scratch.
This is great. But the overall awfulness of the interior of the game makes me want to puke, frankly. I thought Freelancer was bad, with files referencing other files ad infinitum. Compared to that mess, where the last major mod I did for that engine involved hand-tweaking or completely rebuilding hundreds of pages of text... this looks even WORSE. Flexibility without clarity and a straightforward file path is scary, nasty stuff!
4. DoW doesn't actually path whole units around, contrary to popular belief. Game designers are required to keep units that will be in a group (a Squad in DoW parlance) with the same movement rate, or the group moves at the pace of the slowest member. Instead of moving whole units around, it simply seems to do waypoints where the block tries to re-assemble, following very straightforward rules written as text, specifying the distance of every element. Then when the group reaches the final destination, it attempts to pathfind every individual to the proper final location within the static grid.
This is actually one of the main things I've been wanting Spring to do that nobody's bothered solving yet. DoW does this with LUA scripts that define the positions and assigns them to a table, which is then stored in a database and pulled up by the game engine as is required. It doesn't always keep formations intact, by any means- they're disrupted whenever terrain won't permit the individuals to maintain spacing. And the very low resolution of DoW's heightmaps (at a guess, I'd say it's about 1/4 of Spring's, for the same apparent scale- I'll have to dig up the conversation I had with Jelmer about this at some point, and get my facts straight) and the amount of emphasis mappers for DoW put on making terrain easily-navigable, as opposed to realistic-looking, all factors into this.
Basically, though, I think that with LUA, we could almost certainly do this in Spring. It'd have limitations (somebody would have to hand-code the various formation blocks, and you'd need different contexts, if your formations included unlike-sized objects, so there's a lot of fairly nasty contextual code that would be required) but I think it's actually doable, and better yet, it doesn't require anybody losing their soul trying to mess with the pathfinder code again- LUA could get a UI call (makeFormation, arg XYZ) and then do a lot of fairly complicated stuff (figure out if everything in the resulting formation is the same size and speed, if not slow everything down to slowest speed, sort by size or other factors). I'm concerned about the amount the game engine would slow down, though, if it didn't require a specific call, but was invoked every time a user selected a group of Units- it's pretty clear to me, after having done some experiments in DoW, that this can get very, very expensive, CPU-wise, when groups get large, or have many disparate elements within them.
5. DoW's physics code is both brilliant and terrible. One of the first things DoW players will tell you was a big hook for them, visually, was watching guys get thrown through the air. Now that I've looked at how this was done... well, the guys get treated as single objects, they don't really ragdoll (it's a static animation, picked from a list) and then they're instantly turned towards the explosion event and flung out. If you mess with the physics of explosion parameters much, you'll quickly see that they tweaked heavily on the animation ends of things, but had to keep most explosions either pretty close to each other, or, as in the case of the extremely powerful ones, they rely on the fact that the models move so fast that you can't really see that they are doing the same animations as they do with little events.
However, that said... objects can be given masses and collision boxes (they used boxes, not spheres), and when, for example, they wanted things to fall off of parents, they have events where they separate them and then have them just obey straightforward physical rules. On the one hand, it's a lot more impressive-looking than Spring's explosions and the FALL event, which does not bear looking too closely at it... on the other hand, they used it infrequently, and in odd places, mainly with newer content (the Imperial Guard and Necrons, especially) so it's not as amazing as it should have been. Not having played Company of Heroes, which is basically the same game engine, but having heard about how awesome it is, I'm sure that the developers took a lot more advantage of this.
6. DoW's system of upgrades, dependencies, and modifiers is brilliant, and actually suffers the least from overall messiness. While there are the usual problems with references, it's a great system. Basically, it works like this:
A. Unit (or Squad) has various things attached to it, that require other things to be true before they can occur.
B. When the dependency is true, then the event is triggered. This can be anything from upgraded hitpoints to a whole new model file and entirely new stats (that gets into nightmarishly nasty code, so they usually just kept all of the sub-models in one file, and then just hide-show what they wanted to).
This system can call "weapons" that cause various effects within their AOE, can boost stats of all units named XYZ within the Squad, or just effect the individual. I think that most of this will be possible when Trepan's code finally sees the light of day and we get a chance to really play with it, and I think that his way is probably going to be cleaner, but I do want to give DoW some props there- it's one of the main areas of the engine that doesn't make me shudder with horror, even though many of the sub-events certainly do.
7. DoW's FX system is both better and worse than Spring's. On the one hand... it can do quite a few things that would be hard to do in Spring, or completely impossible without invoking a shader through LUA (which is a giant topic which I'll be all over like a fruitfly on day-old watermelon when I can finally see some working sample code and can ask about a billion stupid questions, frankly) ... on the other hand, having looked at the code, it looks terribly bloated, compared to the ExplosionGenerator format, and it's not exactly... user-friendly. My only complaint about working with FX in Spring is that there's no viewer for it, short of firing up the engine (hmm, maybe I could convince JC to... lol... coder abuse) but otherwise it's straightforwards, and in the types we have at our disposal, very powerful.
However, FX in DoW are generally tied to models, which are tied into references and dependencies... it's very, very, very messy. It's as if the cross-reference that a BOS call must make to a Unit FBI, in order to access a given ExplosionGenerator, was multiplied tenfold in relative complexity. While I like that Relic made it possible to make certain kinds of FX that are currently impossible in Spring, I don't at like how they approached this issue.
8. Game-balance for unit/weapon interactions is much easier to work with in Spring than in DoW. DoW's weapons do damage something like this:
A. Weapon satisfies aiming conditions, and fires.
B. Weapon reads through a mass of sub-conditions regarding whether it has AOE, what type of AOE (in Spring, it's pretty easy to make a machinegun that acts like one physically, in DoW, it's a big mess, and the results aren't nearly as realistic), etc., and then applies itself to a point, an area (circular or pie-shaped) or an entire Squad.
It gets even worse with weapons like artillery. They have a set of sub-references defining their physical behaviors, and they miss based on a circular probability of error system, instead of Spring's fairly straightforwards deviation-from-true system. And I have yet to find anything allowing me to make a weapon that fires a true burst
C. Now the weapon has to decide if it hits or misses. Since it's not a physically-representational system, like Spring, it "rolls the dice" for every applicable target in the appropriate area.
D. All hits get applied to the target. Now things get REALLY messy, because, unlike Spring's straightforward Armor system, where damage is damage is damage, you have to look at sub-references, and see how much armor-piercing is done, vs. the amount of armor the target has. If damage < armor, then armor is reduced to armor - damage, or minimum armor levels. If damage > armor, then damage - armor is applied to hitpoints. In theory, this is exactly the same as Spring, except that it involves many more sub-references and is a royal pain to actually maintain! I love how in Spring, I can just define, flat-out, that a given weapon does zero, or minimal damage, to any Units that are in a given Armor category. In DoW, they have the same final results, but they have the added (and imho, idiotic) step whereby armor must be "degraded" before actual hitpoint damage occurs, which mainly just ends up being extra, hidden-from-the-end-user hitpoints, because they used the minimum-armor values so infrequently.
E. Some weapons may call a sub-event, that may do just about anything at all- slow down the units in the area, halve their armor values, degrade their Morale, whatever. OK, I'll admit- that's pretty awesome. It's not worth the rest of the pain, though.
The end result of all of the above is that, whereas determining the true combat power of a given unit in Spring is quite complicated (turret speeds, engagement cones, speed of projectiles, raw damage, reload, spread, salvo sizes, E/M costs, etc., etc., etc.) in DoW it's even worse, actually.
Final Summary:
All I wanted to do, frankly, was take an existing content mod and build a rebalanced version- just a quickie, rough project to get me fired up and thinking about game design (and start to get me thinking more about what I'll want to do with Trepan's code, and the implications thereof), separate from the many remaining issues of my current project. It quickly escalated into a major pain in the rear, mainly because of the sheer amount of interlocking factors.
I think that Spring/Command Engine can and should do a better job, in the following areas:
1. Dependencies. File-paths should remain as straightforwards as is humanly possible- DoW shows the dark side of entirely-LUA based design, and the ensuing mess that can result, on the maintenance end, if everything is ultimately dependent on too many other things. There's no way to avoid this problem entirely, mind you- if Spring games are going to start having even more complex gameplay implementations, then it's naturally going to get more complicated. However, there's a huge difference between having a COB call a LUA script, which then does a bunch of fairly-complex things and returns after executing (or a COB call that LUA and then goes on its merry way) and having the LUA reference another LUA which then passes a state to yet another LUA, which then... bleah! The amount of sheer wasted time, on a game developer's end, that this must result in, is simply tremendous, and debugging bad gameplay must be a royal pain.
2. FX. I think that Spring's system, where ExplosionGenerators are their own, separate entities, and are invoked through events that are clearly-defined (even if slightly messier than I would personally prefer, it's far better than DoW) is great. However, at some point, we need allow for greater flexibility, to replicate DoW's dependency system, but hopefully without so much mess and bloat.
For example, if a HitByWeapon returns the weapon's ID (and maybe we could even put ID #'s back into Weapon definitions, specifically for this purpose- that would even allow multiple Weapons to share the same ID, strictly for contextual event definition, so that we don't have 50 different IDs for 50 weapons that all basically do the same thing) then we could then just use COB to tell the Unit what to do, visually, and then invoke LUA through the COB to make other things happen. Simple, fairly straightforwards, and powerful. For many things, such as "I'm on fire, I lose health every SlowUpdate until X SlowUpdates occur) we can already do this through COB alone- however, we have no way to tell the Unit that it's on Fire, short of some sort of overly-complex LUA callback initiated when the weapon fires (my mind boggles at the waste and complexity).
3. Animation and content creation. Spring is, despite its obvious limitations in the animation category, quite excellent, and can only improve. If it supported some sort of bone system that was scripted, or even just a static-animation format for doing pre-posed animation series, then it'd be on a par with just about anything elsewhere.
While I understand the strong temptation to use Blender as the basis, since it is also Open Source and free, I'm not entirely convinced that this is a good idea. Blender is massive overkill for low-poly animation, frankly, and it'd probably be a good idea to just keep things as simple as possible.
One of the areas DoW is really ahead of Spring is that it supports multitexturing. This means that different areas of a model can be hidden, without adding to their overall costs per rendering pass, among other areas.
4. Rendering. There are two areas where DoW is superior- alpha transparency, and shadows.
One of the areas where DoW took a much different approach than Spring was in rendering shadowmaps (yes, I'm still obsessed with this, lol).
It turns out that different units in DoW use different approaches to shadows. Small units, and the vast majority of mobile units, use a simple blob shadow (i.e., a alpha-dark area projected onto the map) that turns with the origin of the model, and is projected on a straight line between sun and origin. This has obvious speed advantages, and I'd like to try doing that in Spring (remember that post about getting the sun's position?) however I think that doing it in LUA will prove too slow to be practical, because I'd have to do a COB --> LUA callout, get the returned angle, then bring it back to COB, move a Piece, and then call an ExplosionGenerator to "project" the blob-shadow (really, just a custom "scar", and I have no idea whether I'd be able to control orientation, frankly, which is why that idea stalled).
Large units, the map and buildings use stencil-buffer shadows. Again, DoW differs from Spring, in that it doesn't render that stencil over the entire map each rendering pass, but only the area in the camera, plus they use fog and other trickery to prevent users from seeing visual problems in long-distance situations. Personally, if I could have blob shadows, preferably with some sort of COB control (it'd be really kewl if they could be animated series that I could sync with motion) for anything mobile, I suspect that the performance benefits would greatly outweigh the small harm in visual quality, on all but the most angled-sun maps. In DoW, this is all customizable, per unit, and in fact if you wanted to, even small infantry could use stencil-buffer shadows, like in Spring, or all buildings could use blobs. I think that the performance advantages would be worth it, and I can see why they did that.
Alpha transparency is available for all models, and is used to great effect in a number of places. While there are some artifacts, and the DoW designers mainly used it for modeled "FX" that were really just attached pieces on the models, combined with glowmaps, it makes a huge difference in the overall level of quality. I still don't understand why alpha transparency has never been put into Spring, frankly, or why it's been quietly ignored- I assume that there are rendering issues that were nasty that nobody wanted to mess with, not that everybody coding the engine disagrees or doesn't understand that alpha-transparency is a very powerful, multi-function tool.
Lastly, DoW's coders did some very clever stuff, in terms of map rendering. Maps can have different environment types, and if a map is X environment, then, for example, units leave behind footprints that are alpha-shaded, but on other maps they'll leave muddy footprints, or whatever. That's pretty clever stuff.
5. Spring's map format is already superior to DoW's in multiple ways. And, if Smoth ever gets that LUA-based entity-placement code thingy done, so that we can have Units, as opposed to Features, placed onto maps, it will be even moreso! However! DoW has a couple of things that are very interesting, and I only wish I had enough free time away from my main project to really delve into this (however, that's not to be, I have too many people counting on me to be productive, frankly):
A. Areas that are total no-go zones that are obviously defined with a bitmap, not just a heightfield bitmap. This is probably very similar to Spring's support of custom movement-rates, but it's absolute (I don't know, so I'll ask here- can that custom movement-rates thing entirely stop movement through a given zone? my understanding is that it cannot) This is very useful, because it allows for non-square areas of no-go to be defined, allowing for placement of 3D terrain objects which do not really interact with anything. It's pretty obvious that it was done this way, instead of Spring's footprint system, which is cooler on the small end of scale, but impractical for giant scales (can you imagine the kinds of ruined cityscapes being done in DoW, in Spring? I can, but I can see the map's author being a mental wreck well before it was finished).
B. Some 3D objects have hitboxes, and block certain types of object. Some don't bother (they're just there for eye-candy purposes). While this isn't entirely ideal for Spring, given that Spring likes to literally depict the physical universe to a much greater extent than DoW, it is intriguing, because it might be done in Spring. Heck, if Units could just have multiple hitspheres, and if hitspheres were actually used for unit collisions during movement... we could replicate this entirely, and actually exceed it...
That's about it for now- I'm sure there are other thoughts I've had, during the last two days, that maybe you might find somewhat worth reading, but this post is already about as long as I ever get. I'm glad I took a couple of days to go over that engine more than just as a player, though, it was extremely informative, and I hope that anybody that reads this gets at least some benefit.
((
