Planning Game Development

Discussion in 'Game Design, Development And Publishing' started by Byter, Aug 12, 2019.

Tags:
  1. Byter

    Byter Member

    Joined:
    Feb 16, 2018
    Posts:
    10
    I have made some small games now with gameMaker but I dropped many of them because they became to unorganized and I didn't know anymore how I should add feature without accidently interfering another feature. So I thought about starting to plan projects. However I have no idea where I should even start planning and how detailed I should plan. How shouöd the plan look? Just a to do list? A flow diagram?

    Any tips how I should start?
     
  2. Kyon

    Kyon Member

    Joined:
    Jun 27, 2016
    Posts:
    467
    Using Folders and Regions early on in gamemaker helps a ton.
    Also try to use less "quick" variables like "a=0;" but explain your variables for your future self.

    For planning, idk, next to this yeah it's nice to work with a plan or to-do list.
    Write parts of your game out already. What exactly is the new feature you want to make. etc.
     
  3. Byter

    Byter Member

    Joined:
    Feb 16, 2018
    Posts:
    10
    What are regions?
     
  4. BaBiA Game Studio

    BaBiA Game Studio Member

    Joined:
    Jun 20, 2016
    Posts:
    824
    Regions are code-folding sections in your scripts. They are explained in the manual, just put "regions" (without the quotes) into the search in the manual and you should be able to find out all about them in the script editor section.
     
  5. Byter

    Byter Member

    Joined:
    Feb 16, 2018
    Posts:
    10
    Sidenote: I'm using GMS 1.4. Regions don't exist there, do they?
     
  6. RefresherTowel

    RefresherTowel Member

    Joined:
    Jul 13, 2016
    Posts:
    1,177
    Nah, they were introduced with 2.0. Planning and prototyping is how I manage to keep my code in check. First, I plan out a feature as best I can. This will always fall far short of what I actually end up needing, but it really helps to have some sort of baseline to refer to, especially when you come to segments of code that might actually conflict with each other, your original plan might have some aspect that helps you decide which direction to go in. After I've done the planning, I code out the thing in an empty prototype environment. This means starting a completely new project and only adding what I specifically need for that specific thing (for instance, in my combat section, I've recoded complete prototypes maybe 4-5 times and only went ahead adding it to my actual production version when I was happy with the prototype). This is where you'll often encounter the problems that lead to sloppy code and negative influences on your project.

    For instance, let's say you have a knockback feature planned. Everything seems cool, you add it to your project, and then you realise that you need to account for when you knock an enemy into another enemy. You didn't plan for this and so you do a quick fix of the code just to get the combat working properly again. During this "quick" coding of the feature, you probably neglected to implement the code in the best way possible. Or perhaps you're newly coded knockback effect has run-on problems (maybe the second enemy is getting knocked into walls). So you do a quick fix of those knock on effects. Suddenly, before you know it, this minor problem that you didn't foresee has led to multiple quick fixes to your code and probably a much dirtier code base than if you had it planned out from the start, with podges and bandaid solutions here and there that, once you've added them in, are all too easy to simply move on from and hope the codebase doesn't break any more.

    If you prototype things out in their own clean environment, you can encounter these problems, hodge-podge fix them and get the combat to a point where it works how you want but now you HAVE to code it again to put it in your main project, so now you can do that with foreknowledge of all the potential problems you'll have and a much better vision of how the code -should- look.

    Beyond that, using data structures effectively (especially JSON in GMS, as that is the most readily accessible one) is an important point. Make sure that your game is drawing information from structures that you control, rather than a hodge-podge of different variables in different instances and objects (I mean, there's no problem with using variables in this way, but too often people neglect the benefits of central storage when it comes to some of this sort of stuff and end up implementing multiple storage/retrieval solutions for a (single) thing/s, when something could easily be written from the start that gives you a centralised storage container to hold these things in). This is especially useful when it comes to saving games. Much easier to have a central map/list structure at the start of coding and store the vital things that you'll need to save in there than having to go through your entire codebase later removing/editing code so that you can have properly save functionality when you're three quarters of the way into your project (this is, of course, if you are using JSON for saves, a lot of people prefer buffers for speed, but IMO it's personal choice unless you need to really squeeze every single bit of speed out of your code to make it function well).
     
    Byter likes this.
  7. KPJ

    KPJ Member

    Joined:
    Jan 19, 2019
    Posts:
    113
    A game design document is a great start for planning your project. Game Dev Underground has a nice video about it, including a template:
     
    Cpaz and Mert like this.
  8. Mert

    Mert Member

    Joined:
    Jul 20, 2016
    Posts:
    358
    The template layout here helped me a lot.
    It is also on our list to create a "project management for Game Maker games" on GMDevBlog
     
    KPJ likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice