dislekcia
02-02-2009, 07:40 PM
Aeq and I were just talking about how we developed 48hr War (http://forums.tidemedia.co.za/nag/showthread.php?t=9466) and the things we did to make it go as smoothly as it did. So I thought I'd get the basics down here before the idea slipped away again...
Using GM in a team:
A lot of people think Game Maker isn't great for teams because of the way that all the files are contained in one shared editing environment/repository. You can't edit sprites without having the person currently editing the game re-import them, etc. That's not conducive to a happy team experience - what if you interrupt a crucial thought process with your "constant whines" for importing things?
Two coders are better than one.
We had Aeq and Nandrew alternating in the main coding seat, the other would code over their shoulder. This meant that a lot of those frustrating spelling error bugs that plague GM code were caught early and that there was always some extra brain-space free to keep sight of the bigger picture. That bigger picture awareness meant that feature creep was easier to deal with and someone would always call halt when something started getting over-engineered. There was also constant movement towards the "Ok, what's next?" question.
Merging games is awesome!
We handled all our resources via merging. Art and sound were in separate GM files, which Aeq would then re-merge as needed whenever we released a newer version of either. Having him simply delete the Animations folder from Sprites and Objects, then merge in the latest art was a lot easier than having to waste ages re-importing things if I'd changed them. Or even worse, having to stop working on the file so that I could create all the graphics objects!
One thing that helped a lot with that was how we only referenced any merged-in material via script... GM automatically kills references to deleted objects in its drop-down lists or in rooms where they're explicitly placed in the editor. So as long as we only used instance_create or direct type/name calls, we could delete and merge as often as we liked and things would keep working perfectly fine! I could even mess around in the graphics objects, often changing them rather drastically, inbetween merges and the only thing that would happen is that the next version of the game would look different: No code changes necessary.
We also maintained a separation between game logic and graphics. This happened because Aeq and Nandrew went from a prototype with placeholder sprites on the actual logic objects, to simply making those objects invisible and having them create objects that only had graphics logic (animations, particle effects, etc) on them, which they then moved around in lock-step with their controlling logic objects. This also meant that I was part artist and part programmer: I'd build some resources and then stick those together in my own GM file to create animated explosions and the like. Some things, like the appear/upgrade effects were added completely on the art side of things, with no involvement of the dedicated game logic coders at all ;)
Always having access to my own room that I could prototype animations and effects in made developing them a lot easier than if I had to keep playing the whole game just to trigger off a slightly tweaked animation every time I made a change somewhere.
Just thought those concepts might be useful to those of you working together in GM...
Using GM in a team:
A lot of people think Game Maker isn't great for teams because of the way that all the files are contained in one shared editing environment/repository. You can't edit sprites without having the person currently editing the game re-import them, etc. That's not conducive to a happy team experience - what if you interrupt a crucial thought process with your "constant whines" for importing things?
Two coders are better than one.
We had Aeq and Nandrew alternating in the main coding seat, the other would code over their shoulder. This meant that a lot of those frustrating spelling error bugs that plague GM code were caught early and that there was always some extra brain-space free to keep sight of the bigger picture. That bigger picture awareness meant that feature creep was easier to deal with and someone would always call halt when something started getting over-engineered. There was also constant movement towards the "Ok, what's next?" question.
Merging games is awesome!
We handled all our resources via merging. Art and sound were in separate GM files, which Aeq would then re-merge as needed whenever we released a newer version of either. Having him simply delete the Animations folder from Sprites and Objects, then merge in the latest art was a lot easier than having to waste ages re-importing things if I'd changed them. Or even worse, having to stop working on the file so that I could create all the graphics objects!
One thing that helped a lot with that was how we only referenced any merged-in material via script... GM automatically kills references to deleted objects in its drop-down lists or in rooms where they're explicitly placed in the editor. So as long as we only used instance_create or direct type/name calls, we could delete and merge as often as we liked and things would keep working perfectly fine! I could even mess around in the graphics objects, often changing them rather drastically, inbetween merges and the only thing that would happen is that the next version of the game would look different: No code changes necessary.
We also maintained a separation between game logic and graphics. This happened because Aeq and Nandrew went from a prototype with placeholder sprites on the actual logic objects, to simply making those objects invisible and having them create objects that only had graphics logic (animations, particle effects, etc) on them, which they then moved around in lock-step with their controlling logic objects. This also meant that I was part artist and part programmer: I'd build some resources and then stick those together in my own GM file to create animated explosions and the like. Some things, like the appear/upgrade effects were added completely on the art side of things, with no involvement of the dedicated game logic coders at all ;)
Always having access to my own room that I could prototype animations and effects in made developing them a lot easier than if I had to keep playing the whole game just to trigger off a slightly tweaked animation every time I made a change somewhere.
Just thought those concepts might be useful to those of you working together in GM...