Rtw Clone

[ScionTheWorm]

if you're a experienced programmer, the use of libraries already out there would make the advanced stuff that c++ offers less important, but with a little less understandable syntax than java. I think it would be pretty easy. also, scripting via python (and lua I think) is possible, so maybe that could be a possibility for the campaignmap. that would make the campaign map part very maintainable, and the great speed isn't really required here. (could always make c++ libraries for the python to make at crucial places, I know how to do that).

it's nice to know there are people here that might join if I could get something going, but I would'nt assume too much. A major point, is that if the engines out there can handle so many units in an acceptable way. I really don't know, but I'll find out. I have tried out one, and got up some pretty nice landscapes and skies, but no animated units yet. I have also found some really easy ways to make the game gui, and handling the physics of the game.

anyway, I just I could just write down some more ideas I have found the engine to be capable of...
- large(!!) landscapes... wouldn't do much without the gameplay in place, but I've also concluded that the map generation we know from rtw will be very easy. (would use smaller scale though) No need to design "levels".
- multiple textures at models... this would mainly apply for the face, every unit loads their face from a "face database". this way it would be less work to get the animated textures I've planned, giving the units emotions. (only rendered at pretty close range though)

this isn't meant to be any hype and making false hopes, or me just talking and doing nothing. it's the only way it's going to happen. It's a longshot.

[Lord Adherbal]

- multiple textures at models... this would mainly apply for the face, every unit loads their face from a "face database". this way it would be less work to get the animated textures I've planned, giving the units emotions. (only rendered at pretty close range though)

IMO stuff like that should be left out until a very late point in the development stage. It adds nothing to the gameplay and only puts extra strain on the CPU, no matter how few. Believe me, you'll need all the CPU time you can get for unit and individual soldier AI.

I honestly dont care how the GFX look. Eyecandy adds nothing to gameplay and only makes things harder. I you are serious about this then focus on gameplay (and AI).
I would get rid of the zooming function the RTW camera has. If you can't get too close to your men then they don't need to look too detailed. Zooming adds nothing to the gameplay either.
By focusing on gameplay (instead of GFX) you can make sure the game becomes fun to play early in the development. And that's a big stimulance for motivation. I saw many of my game projects die because I focused on the GFX, not the gameplay.

EDIT: some screenshots of RTSes I made (or better, started), to prove them I'm not lying about having experience.

[player1]

Reminds me of some free Civ projects.

At the end, one of those that got finished needed more then 5 years, and end result was nothing more then a bit more customable Civ2, pretty much outdated game compared to Civ3 (or even Call to Power).

Some other projects had big design documents full of ideas, but end result were just few ugly builds and then stagnation due to lack of motivation.

[ScionTheWorm]

I agree that's not a priority at all, and gameplay would be the main focus. however, it would vastly reduce skinning time, for instance putting the skins together from different sources before running the game. for instance, each unit will have it's own directory or package containing optional several skins as well as all stats and all descriptions - in general, everything that defines that unit. this would give the option to use it later on, the fancy animations would be something made in the skinning stage, in photoshop or whatever, not a concern until then (and maybe not even to be used). the zooming could optional be disabled, but it wouldnt take much cpu with the different models for each unit, with different number of vertices for the various zooming distances.

another thing I've been thinking about is having a large number of units on the field. this would typically bring an extended zoom-out, with very low-detail units for performance. you say, the ai would go berserk. I'm thinking about a grouping system where there would be a "2 stage hierachy". For instance 3000 men in group one, 4000 in group two and so on. These groups would then have their own ai, until they would be very close upon the enemy.

Also, there should be some kind of scripting system for ai/enemy tactics and formations.

the main focus would without doubt be gameplay, but I think it's very important to think about as many different aspects that may turn up before starting the real coding. the purpose will be making a better wargame.

[Lord Adherbal]

another thing I've been thinking about is having a large number of units on the field. this would typically bring an extended zoom-out, with very low-detail units for performance. you say, the ai would go berserk. I'm thinking about a grouping system where there would be a "2 stage hierachy". For instance 3000 men in group one, 4000 in group two and so on. These groups would then have their own ai, until they would be very close upon the enemy.

unless "professional" languages are a heck of a lot faster then the ones I used, I'm sure the TW games already use that system. So having an equal number of men as the TW games would already be quite an achievement. I know I had to use a system like you suggest, because all the distance calculations between every soldier (1000 VS 1000 = 1000*1000 = 1,000,000 distance calculations every second or so, not including distance checks with friendly units for collision detection) resulted in horrible framerates.

[ScionTheWorm]

just to prove I'm not bs, I spelled rtw in the height map

I haven't even heard about DIV, Fenix, DarkBasic. A fact I know, is that for instance python which is a scripting language is highly capable of making games, but then again are minimum 11 times slower than c++. On the other hand it might be 100 times faster to get results. However, as you can see above, I got this up and going after barely one short tutorial (took me 30 minutes). Also I managed to switch cameras, add different lights, add fog, different skydomes etc, and I'm no c++ guru at all. So getting results is pretty easy.

edit:
btw your games look very nice! looks like they're playable and you've worked quite a lot with them.

[Lord Adherbal]

I'm willing to give another look at C++ (I once did but got bored after Hello World ;)) if it appears this project is really going somewere. But that'll be atleast months from now (after ChivalryTW is done).

Good to see you have a map working already, now there are just another zillion things left to do :P

[ScionTheWorm]

hehe yes I'm not exactly planning my victory dance yet...

I'll try things out, get some system to define units. already found some horsemodel, but haven't been able to get it to animate yet. It's day two anyway. So if I can get these units to appear and hopefully move on the battlefield, I could similate ai with some dummy loops eating cpu to see what it can take. That's where the decision will be made I guess. if it can take what I have in mind, it would be awesome..