User Tag List

Results 1 to 8 of 8

Thread: Using GM in a team-friendly way.

  1. #1
    Game.Dev Moderator
    and bettar-rar game developer than Wea-sel
    dislekcia's Avatar
    Gamertag: dislekcia

    Default Using GM in a team-friendly way.

    Aeq and I were just talking about how we developed 48hr War 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...

  2. #2

    Default Re: Using GM in a team-friendly way.

    That is something GM desperately needs some method of source control so teams can work on a game.

    Sure your way is good but at the end of the day it's a hack (Probably #113 in my little book of GM hacks you need to know to be able to use it properly) that we're better off without.

  3. #3
    Game.Dev Moderator
    and bettar-rar game developer than Wea-sel
    dislekcia's Avatar
    Gamertag: dislekcia

    Default Re: Using GM in a team-friendly way.

    Quote Originally Posted by ShadowMaster View Post
    That is something GM desperately needs some method of source control so teams can work on a game.

    Sure your way is good but at the end of the day it's a hack (Probably #113 in my little book of GM hacks you need to know to be able to use it properly) that we're better off without.
    ...

    It's not a hack, it's a way to use the tool more effectively...

    There are ways to use source control more effectively too: For instance, my final point about having a means to test and refine animations outside the game itself really helped a lot. It took ages to test tweaks properly in SpaceHack, despite running everything off SVN.

    Besides, if you really wanted to write a GM-friendly source control system, I'm pretty sure you could. The gmk file format is pretty easy to understand (from what I hear) and is well documented. Putting an app together that compares two different gmk files and flags/merges differences shouldn't be too large a problem. In fact, it might even work perfectly fine if you were to stick a gmk into something like SVN as-is. The only caveat would be having to re-open the file after a save, but that's just a habit to learn, much like checking a file in or out.

    ...

    In the end, maintaining that level of code separation and abstraction is completely platform/tool agnostic. It's a good idea for any team. The fact that we did this in GM isn't a reason to hate on the software :(

  4. #4

    Default Re: Using GM in a team-friendly way.

    Quote Originally Posted by dislekcia View Post
    ...

    It's not a hack, it's a way to use the tool more effectively...
    True I maybe spoke too harshly about this method when I called it a hack, thank goodness merging exists...

    Quote Originally Posted by dislekcia View Post
    There are ways to use source control more effectively too: For instance, my final point about having a means to test and refine animations outside the game itself really helped a lot. It took ages to test tweaks properly in SpaceHack, despite running everything off SVN.
    Yeah that's true, can't add more without repeating what you've said.

    Quote Originally Posted by dislekcia View Post
    Besides, if you really wanted to write a GM-friendly source control system, I'm pretty sure you could. The gmk file format is pretty easy to understand (from what I hear) and is well documented. Putting an app together that compares two different gmk files and flags/merges differences shouldn't be too large a problem. In fact, it might even work perfectly fine if you were to stick a gmk into something like SVN as-is. The only caveat would be having to re-open the file after a save, but that's just a habit to learn, much like checking a file in or out.
    It would be interesting to see if that actually does work and reopening a project is a small price to pay for easy SVNing. Though then testing animations and stuff outside the game would become difficult... though a temporary development room in the game that you can just make the first room when you need it, will solve that.

    Quote Originally Posted by dislekcia View Post
    ...

    In the end, maintaining that level of code separation and abstraction is completely platform/tool agnostic. It's a good idea for any team. The fact that we did this in GM isn't a reason to hate on the software :(
    I know and I agree it's a good practice for any team and possibly even a single person.

    To be honest my biggest problem with GM is it's awful scripting language, where the flaw is that there is no way of packing a lot of related data together in something lightweight like code and passing it around. This doesn't really make a blip.

    But to sum up this post I'm sorry for being too rash in my previous post.

  5. #5

    Default Re: Using GM in a team-friendly way.

    interesting read dis,i think the toolchain pre game usage is key to easy development.

  6. #6

    Default Re: Using GM in a team-friendly way.

    I always wondered - is there a way to automate the merging process (i.e. command line from script, or something like that?)

  7. #7

    Default Re: Using GM in a team-friendly way.

    A quick hunt through the GM help file reveals nothing. I'd say that the best best for a script-based merge call is something along the lines of the "load Sprite/Sound from file" function.

  8. #8

    Default Re: Using GM in a team-friendly way.

    Thanks for the answer Nandrew. It's a pity...

    ht

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •