I apologize in advance for the long, example-full description that follows.
Things will go much faster if different people work on different things at the same time. So while one person might work on particle effects, another could work on the thermal visor, and yet another might start making some creatures. Then we attach these pieces together in one place and enjoy.
Of course, that would never work out on its own. Attempting to multitask as a team now would only end in a complicated mess, especially in Game Maker: creature and particle graphics would constantly have to be changed according to updates from the thermal visor person, mixing the thermal visor code in with the rest of the engine, and adding the X-ray visor later would take weeks of headaches, tangling the code further, not to mention that new programmers would have to be educated on visors and particles before making a single platform, and updating visor effects may be too much work at this point.
But situations like that can be avoided, if we plan out how each piece of the engine will be as independent as possible from other pieces.
My approach would be to first build the connections between pieces before building the pieces themselves. This is a little difficult to explain, but I’ll try.
Say we’re looking at an engine with only visor effects and creatures walking around. For the sake of this example, the pieces in this case are visors and creatures. The creatures are connected to the visor effects because their graphics will change with the visors. The visor code should not have to know anything about specific creatures or their code (therefore allowing for creatures to be created and updated later), and likewise the creatures’ code should not have to worry about how the visors operate (therefore allowing for changes in visor effects, and what they can be extended to). This can be done by building the connection between them: the functions for displaying sprites. All creatures simply would be required to display their graphics through customized engine functions, and these functions include the visor code (and probably also lighting code and such). It is impossible for these two pieces to be truly independent–after all, creatures should have heat signatures for the thermal visor–but a few values to report and specific functions to call would not tangle the engine, because they would likely not have to change with code updates.
So after creating a dummy creature that doesn’t do anything and a dummy visor effect that doesn’t do anything, connected by a few customized graphics functions, two different people can work on the two pieces simultaneously without a problem, assuming the connection has been built perfectly.
However, that’s another issue: if the connection wasn’t built perfectly, the two would have to communicate on how to fix it. CreaturePerson might have to explain to VisorPerson that there is no way to draw a rotated sprite using the engine functions, and so they would have to get that part of the connection built. Later, VisorPerson would have to explain that the required arguments for the scaled sprite function need to be changed in order for visors to work, and then CreaturePerson would have to search through all of their code to change all of the calls to that function. This is wasted time that could have been avoided had the connection been better to begin with. However, changes in connections are pretty much guaranteed, so the best we can do is limit them by planning ahead.
So, in summary, this is what I’ve said so far:
- Engine progress will be much greater if people can work independently at the same time as others.
- Code is easy to tangle, so careful planning would be needed to keep pieces connected but independent.
- Connections should be built before the pieces.
- As the pieces are built, connections may need to be updated. Connections should be high-quality to begin with to limit this.
So, that is my idea. Was that too vague?
(I’m already aware that it was far too long)
So, basically what we have to do first is map out all of the engine “pieces” and how they’re connected, in terms of code and design and such. Then we work out how to connect them in a way that leaves them very independent from other pieces. After building the connections, more than one piece can be worked on at the same time.
A “piece” is defined as an engine feature, by the way. Examples include the HUD, physical objects, visors, physics/collision, resource management, rooms, sound effects, cutscenes, menu screens, etc.
So all pieces must be considered when making the core bone structure of connections. We can’t just assume that we’ll figure out a way to get certain objects to freeze during cutscenes while others still animate and others yet can still move, for example. We would have to build the connection between objects and cutscenes first–probably by setting up a few functions that objects can use to check if they can move or animate or not, and a few functions that cutscenes can use to freeze these certain objects.
It’s going to be difficult to map this all out, but once the blueprint is made, people can easily grab a piece and go with it.