:
Also, even if you have too many people, doesn't mean they ALL have to work on the same project.
|
An excellent point! (well, the whole post had some very good points, but I wanted to comment especially one this one)
The beauty of having a big team working on several projects is also that the different projects should be able to borrow things from each other, meaning the progress on EACH one will be sped up (in theory).
But one thing I notice is that everyone on the list so far seems to be a programmer (although some may have other skills), so I wonder if you really need more people dedicated to other fields, graphics in particular. Because if I'm going to be contributing to this I think I speak for most of us here when I say I'd like the quality to be as top notch as possible.
Another thing I'm wondering is, how will the group best communicate? MSN and such are options, but that would cause problems with the different time zones etc. Maybe it would be a good idea to set up a dedicated forum for this group on invisionfree or something?
Now, onto the topic of an RTS, just some practical ideas from a programming perspective:
- Pathfinding - this is one of the big challenges in an RTS game - because everything has to happen quickly and you may have dozens of units trying to find paths at the same time, you can't really use things like the A* algorithm, as it would just be too slow. But you don't want to have the frustrating pathfinding of early RTS games such as the original Age of Empires where they just try to make a beeline to the destination and get stuck if that doesn't work. I could probably create a DLL that could do a rough calculation for pathfinding at a much faster speed than GML, but in order to do this there should be some file that both Game Maker and the DLL can read that has the necessary information. Which leads me onto my next point.
- File management - I personally don't like having all the levels and everything hard-coded into the game, so I think ideally we should have a special file format that will contain the level data. Again I could create a function in the DLL to read this into GM, or even just a GML script. This would provide the common file that the pathfinding function could use to read the level information and work out obstacles to plot around etc. Also this means it's a lot easier to make minor changes without having to recompile the entire game. My own turn based strategy actually used a similar system to the original Command & Conquer games how unit information, levels, etc were all stored in human-readable ini files, and it worked perfectly.
Also, from a gameplay perspective, while I like the idea of controlling one main character and directly commanding the others, we'd have to think it out thoroughly of how to work this in game - for instance, is it going to be a base building strategy game? If so, how would we implement things like managing your base while also leading an attack on the enemy? One option would be to go for a very realistic approach, where maybe you could have other mudokon chiefs who are under the player controlled one, who you could assign the duty of overseeing construction of given buildings or leading an assault, but this would require some heavy AI scripting and also it might not be terribly great for fun gameplay purposes. Just throwing some ideas out there.
As for music, I quickly threw together a midi file last night, but I'll do a high quality recording of it this evening and maybe attach it then if I don't get distracted by other things.