1. Hey! Guest! The 36th GMC Jam will take place between February 27th, 12:00 UTC - March 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

Design Common pitfalls in mid-large scale projects

Discussion in 'Game Design, Development And Publishing' started by SilentxxBunny, Feb 13, 2020 at 8:36 AM.

  1. SilentxxBunny

    SilentxxBunny Epsilon

    Joined:
    Jun 21, 2016
    Posts:
    148
    There are common pitfalls in mid-large scale projects. Seasoned developers know to avoid them, how to avoid them, and why to avoid them. Beginners may (or may not) be aware of them, know the solution, and be oblivious to the fact they've missed the point entirely.

    Before they know what hit them: The project that they put their heart and soul into is a tangled web of interdependent objects and scripts which works great (unless they try to add a new feature or make a trivial change an existing one.)

    I want to compile advice for ambitious young'uns with big dreams: A big list of what to do (and what not to do) if plan for your next project with a "large scope" to survive it's own development cycle.

    If there's something that needs done a certain way... It's important for one to understand why so that one can apply the solution correctly when/where it makes sense. You're encouraged to share examples of shortcuts, bad practices, and **** that you might have gotten away with in your first game(s) but will end your first "big" project before you even start it (bonus points if you can "show them the ghost of dev-mas future." What will go wrong if someone continues to do it the wrong way?
     
    Last edited: Feb 13, 2020 at 11:22 AM
  2. danzibr

    danzibr Member

    Joined:
    Aug 27, 2019
    Posts:
    9
    I love it! I'll be checking back here regularly.

    I recently decided to give up a project because I made some noob mistakes (disclaimer: I'm a noob, and please enlighten me if I'm wrong). I did come up with some pitfalls/dos and don'ts.

    1) Art-wise: use a palette. Or one palette per region. But don't just conjure up colors willy nilly.

    2) Design-wise: have a focus. Don't just smash things together.

    3) Art- and design-wise: less is more. If your animation looks good with 6 frames, no need to make it 10. And you don't need a ton of subsystems. Like in Disgaea, you level your characters, your classes, your abilities, your equipment, even things that live inside of your equipment.

    4) Plan everything from the get-go. This really helps with not having to go back and tinker with earlier code. If you only have a nebulous idea and start art/coding, you very well may have to go back and fix things when you come up with new ideas.
     
  3. SilentxxBunny

    SilentxxBunny Epsilon

    Joined:
    Jun 21, 2016
    Posts:
    148
    Hi @danzibr

    I'm a noob, too. Might be "forever a noob" myself. Time will tell, but I've got plenty of tenure making noob mistakes.

    The latest of which was posting this discussion. No offense to you at all. I didn't have a focus and smashed together a very confusing and incoherent topic.

    I think that this is more or less the problem I that I was attempting to describe and help solve. I don't think that it's possible to plan everything from the start but it may be possible to plan for everything from the start.

    I'm pleased to make your aquaintence, but I've tinkered with the OP for several hours, wish I hadn't posted it, and might ask the mods to remove it. I don't know if it's against the rules, but it's unhelpful in it's current state and frankly so am I.

    I have so much anxiety, I need to get away from my screen right now. I'm sorry. Life's a lot and this small, basically insignificant event is just the "straw that gave the camel an anxiety attack." Take care.
     
    Last edited: Feb 13, 2020 at 7:30 PM
    Cpaz and RefresherTowel like this.
  4. otterZ

    otterZ Member

    Joined:
    Feb 7, 2020
    Posts:
    12
    What a great thread idea - I clicked 'watch this thread' as a lot of progression comes through making mistakes, even more progression if you can learn though other's mistakes.

    Here are 3 I've learnt:

    1) Make your game release date 2 or even 3 times longer than how long you plan to complete it. Not only can a game take much longer than was planned, there can also be all sorts of random real life dramas that occur during development that need your time and attention. I've personally made this mistake.

    2) Always keep a beginner's mind to becoming a better programmer, but make the code do what you want it to do. As in not thinking, 'what can I make in this game engine with my current abilities' but instead 'I have an idea / concept and I'm darn well going to make the code bend to creating exactly what I am picturing in my head; and if I don't know how to yet I'll learn it' (providing the scope of the ability of that game engine practically supports your idea). Basically, if someone else has managed to do it, if you are tenacious enough, you can do it too.

    3) Turn the spotlight on the player. As in not thinking about how cool the game looks, or how many people might Wishlist or 5 star the game. Just focus on how your game can help someone or add something to their lives, as in for example Stardew Valley - which transports people from their stressed and busy modern life to a chilled out world where morals and friendship are still strong. Or Cooking Simulator which encourages people to cook and learn from the recipes from that 3D world. Take for instance if I'm looking for a dungeon crawler game . . . as a player I don't just want to crawl though dungeons getting power ups and slaying enemies with cool graphics, there are tons of those kinds of games out there . . . no, I want to discover something unique, something that will expand my life experience, something that will be memorable and stick in my mind forever.

    Of course this is just in my opinion, take it all with a big pinch of salt lol. I do not take myself seriously, I enjoy laughing at myself and I expect and hope to never stop making mistakes and learning from them :)
     
  5. otterZ

    otterZ Member

    Joined:
    Feb 7, 2020
    Posts:
    12
    I love this topic, not confusing to me at all SilentxxBunny, I think that learning from mistakes make for the most interesting experiences. I am all in for being a lifetime noob lol as keeping a beginner's mind is what it is all about. Great topic.
     
    SilentxxBunny likes this.
  6. RefresherTowel

    RefresherTowel Member

    Joined:
    Jul 13, 2016
    Posts:
    1,227
    Cool topic idea. Here's a few off the top of my head.

    1. Plan interactions between entities well in advance. This is a general idea, but a specific version of it is a save/load system. If you are going to build a save/load system into your game, you'd better be planning for it from the first line of written code. There's plenty of things that won't save easily without some forethought and if you try to jam one together in the middle of development you're going to cause yourself unnecessary pain. Beyond a saving system, this applies to all sorts of things in games. How are you going to read the data for your enemies when you spawn them, what systems need to be built on top of what others, what data structures are you going to need to store what you need to store, etc...

    2. Don't build wildly extensible systems when it's not needed. I fall victim to this all the time: "Ah, but if I spend another two days developing system Y, I can generalise it into system X+Y and use it in more places!" More often than not what happens is I spend a lot more time than is necessary wrangling a single system into a state where it can serve multiple functions and either spend the rest of the time working with that system by constantly bug fixing edge cases I didn't account for, or I simply don't use the "other" functions of the system and basically wasted a lot of time. It's ok to make something specific, even if it can be generalised, if it's what your game needs.

    3. The Wall is real and you will hit it. Everyone does when working on a project for an extended period of time. The Wall is when you can barely even open the project up because all motivation has left. Plan for the fact you will hit this point and mentally prepare yourself ahead of time. Instead of giving up and moving on to a new project EVERY single time, try to stick through for at LEAST one project and fully finish it. Not only is it useful to learn all the skills necessary beyond the point of the Wall (polish, bug testing/fixing for a completed project, fully realised menu/audio systems, whatever else is the thing you leave last to program in a game, etc) but it'll give you something to show others and also a personal achievement. There are many skilled coders out there who are yet to finish a full project and you can literally prove that you are better at "making games" than them by actually making one, even if it's not as good as their tech demos.

    That's about it for now, I'm interested to see some advice from more seasoned veterans than I.
     
  7. Yal

    Yal GMC Memer GMC Elder

    Joined:
    Jun 20, 2016
    Posts:
    4,214
    Here's my two cents.
    • Let the computer do it. Tons of times I've struggled with systems that force you to do a lot of boilerplate work whenever you wanna add a single new piece of content (enemy type, inventory item, single level, NPC, etc) and this will really kill your motivation to add more stuff to the game. If your engine forces you to do a lot of work that's the same every time, you're doing things wrong. Write systems that lets the computer do boring things for you whenever possible (don't care how brittle or un-extensible they are, you're only gonna use them in exactly the same use-case every time anyway!) so you can spend your time doing the actually fun bits.
    • Not a Number: GM uses integer indices for a lot of things. You, however, shouldn't. Always use named constants. Some of my biggest projects broke because resource indices changed from constant over the project's lifetime to changing on a compile-to-compile basis in the GM8 --> GMS transition, and named constants are much easier to read and search for if you ever need to change something (you can't be sure that two identical numbers refer to the same thing, but a named constant removes all ambiguity).
    • Freeze-dry. Whenever you copypaste code, instantly stop whatever you're doing and turn it into a script instead. It might slow things down a bit now, but it will speed them up later when you need to bugfix something in that behavior.
    • Document Hacks. It's easy to make a clever hack that sets you up for critical edge case failure later, and then forget about it, and then your game breaks half a year later. Whenever you do a clever hack, always make a //HACK comment and describe what sort of dangerous shortcut you just took. If something breaks in weird ways, try searching for "//HACK" in all the scripts and see if your past self is to blame.
    • "To Be Continued" Is Okay: if you lose all motivation halfway through the game, consider adding a cliffhanger ending and release it as-is. You can make a sequel or a content patch later, but if you abandon the project altogether it's not gonna go anywhere.
    • Code Doesn't Rust: If something works, there's no reason to change it. Reuse it in other projects too, if you can look at it without vomiting. Only rewrite something when it doesn't live up to your demands anymore (whether in terms of features, extensibility or speed).
    • Premature Optimization is the Root of All Evil: Also known as Knuth's Axiom, this means that you shouldn't optimize your code until you know what's wrong. Write code that's easy to read, because computer CPU time is much cheaper and easier to replace than human thinking time.
     
  8. NightFrost

    NightFrost Member

    Joined:
    Jun 24, 2016
    Posts:
    2,101
    Sometimes I like to think I'm no longer a beginner coder, so here's a few observations I've done.

    Plan well in advance. I've noticed the easiest systems to create are those whose operations you've fully formulated before you write a single line of code. Planning stuff by writing down even a rudimentary design document can catch a lot of issues you'd face only partway through coding, and gives you a clear overview of the system.

    Comment that code! Yes, yes, code is the comment and all that. The advantages of clearly commenting your code and design cannot be overstated.

    Loosely coupled code, I think that's how they call it. When your systems are self-contained and have clear interfaces, they are not just simpler to access and manage, but much more easily portable to other projects. By interfaces I mean when you have a system that runs an operation or produces some result or stores something, it is cleaner to have a script (function) that accesses the system thus producing a standardized respones, instead of directly accessing variables. For example when I organize my game's data structures, I write setter and getter scripts to access that data. Every time data needs to be created, read, updated or deleted, it is done through the scripts. To be clear I don't mean accessing single variables but stuff like RPG inventory management or item database.

    In a more GMS-specific topin, not everything needs to be an instance. GMS can handle large amounts of instances easily, but many times handling things as pure structured data is a good or the best solution. I can't find many good examples as I've never really been a "let's make it all instances" person. I guess a standard 2D grid map is will serve. Normally there's no good reason for each of the tiles to be their own instance.
     
  9. danzibr

    danzibr Member

    Joined:
    Aug 27, 2019
    Posts:
    9
    Man, this is helpful :)

    @NightFrost, for your not everything needs to be an instance, I have a good example. I was working on an RPG until recently, and I handled combat by having a Controller object draw all the mobs and players. No instances of any objects.
     
    Rob and SilentxxBunny like this.
  10. SilentxxBunny

    SilentxxBunny Epsilon

    Joined:
    Jun 21, 2016
    Posts:
    148
    Parent Object Inheritance

    I just got checked out @samspade's Mobile Friendly Game Frame, and realized that the buttons do not work on HTML5. I started investigating the code, and discovered that he was using the "Tap" event instead of "Mouse Left Pressed" and "Global Left Released" (HTML5 friendly.)

    To make it work with HTML5: I only had to change the code in ONE parent object (versus each and every button object.) This was a great reminder of something that I know I should do, but usually don't (thanks Sam.) which is to utilize parent objects.

    If you're not clear on how that works: It's actually pretty simple. The secret is to utilize User Defined Events. Using buttons as an example: The hover effect, click effect, sound effect, etc. are the same, right? The only thing that's different is the button's function. So make the parent object's function to call a User Defined Event... but don't give the parent object a user defined event; give one to each child/inheriting object. Here's a very simple example:

    Code:
    /* Example Parent Object */
    
    /// Create
    
    pressed = false;
    
    /// Left Mouse Button
    
    pressed = true;
    
    /// Global Left Released
    
    if pressed = true {
     event_user(0);
    }

    Code:
    /* Play Button Example  */
    
    /// User Defined Event 0
    room_goto(rGame); 
    Code:
    /* Options Button Example  */
    
    /// User Defined Event 0
    room_goto(rOptions); 
    Code:
    /* Credits Button Example  */
    
    /// User Defined Event 0
    room_goto(rCredits); 
    It may seem like more work, and if you're developing/prototyping without a plan ("firing shots in the dark") it's easy to forget... but it will save you a lot of time in the end.

    ... this is a trap I fall into time and time again. If you're re-typing (or copy and pasting) the same code over and over: STOP WHAT YOU'RE DOING! Instead of pasting it into yet another (button, character, etc.) you should paste it into a parent object instead.


    Source Control


    Use source control from Day 1.

    A few months back I accidentally deleted an audio controller object that I'd spent nearly 8 hours working on. I'd meticulously fine-tuned ambient sounds (crickets, birds, frogs, etc.) and could not have been more proud of myself. I was deleting "junk objects" and got careless with "Shift-Delete" and the entire day was wasted.

    Currently, I cant find the latest version of that same game because there's so many copies/backups of the project on my computer. To be 100% honest: I have the same problem with all of my games. There's probably at least 20 versions of each scattered throughout the various folders/sub-folders my hard-drive.

    - - -

    It'll also make it easier to work in teams, and you'll spend less time re-writing code. Let's say you want to take another look at something you scrapped months ago? You can quickly/easily download an older version of the project from your repository.

    Using Source Control the Bad Way




    Using Source Control the Good Way


    While I have absolutely no idea HOW to set it up; Git support is "in the box" when you buy GMS2 - and you should use it in your projects... I should, too. I'm going to look into it soon, and will edit this post with whichever tutorial video 'splains it to me.


    Development Logs

    To end with something that I don't suck at: You should keep a development log. Take PROJECT ENIGMA for example. This will keep teammates in the know, help "hype" the project, and will help you "pick up where you left off" if you put the project on hiatus (come back to it later.) I'm working on a game that I hadn't touched since 2009 and it's been invaluable. Don't make it a chore. Have fun with it.

    I personally recommend WordPress.com because it's free, and reliable. PROJECT ENIGMA is a 13 year old game, and my development blog is still there after all these years. It's limited in terms of features - In other words, you don't get the "full WordPress experience" unless you host it yourself... but had I done that; this blog would be lost in the sands of time. On a related note, if you're looking for free and reliable file storage/hosting; I recommend host-a.net for the same reason. 13 years later, my files are still available and it hasn't cost me 0.01USD. Don't be "that guy" with broken download links on your games/tutorials or pictures advertising a mediocre photo-sharing website. Be timeless, like me.
     
    Last edited: Feb 17, 2020 at 8:46 PM
    Cpaz and otterZ like this.

Share This Page