Design Common pitfalls in mid-large scale projects

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:
D

danzibr

Guest
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.
 
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.

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.
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:

otterZ

Member
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 :)
 

otterZ

Member
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.
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.
 
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.
 

Yal

šŸ§ *penguin noises*
GMC Elder
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.
 

NightFrost

Member
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.
 
D

danzibr

Guest
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.
 
Parents (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.

Edit: @samspade just released a great tutorial on this very subject.



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.


One Last Thing...


I'd like to thank EVERYONE for sharing their insights, and "being excellent to eachother." Personally, I've learned a few new things, and been reminded of several others that my brain had "archived." I thought about replying to each of them, then realized that would only make the 1st page of this discussion longer (and doesn't add any value to it.) I'll post again if I can think of anything else worth sharing... but otherwise know that I'm subscribed to this topic and eager to see more posts. "None of us is as smart as all of us" so you never know who you might help. :)
 
Last edited:

Bearman_18

Fruit Stand Deadbeat
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.
I think this is very much something I needed to read. Especially now, still early in my project. Thanks.
 
Here's what I will add since a lot of the technical aspects have already been mentioned.

Take Care of Yourself
This is true of all game projects (and life in general) but is especially important for large scale projects, and extra especially for hobby projects with no funding and only one or very few developers. The greatest challenge (I think) for actually finishing a large game project is your own motivation. Making a game is a ton of work, and for many parts of it, there is very little reward for that work besides what satisfaction you can scavenge for yourself. Thus, it is critically important to take your time and make sure you're having fun doing it. This self-care is something you have to figure out for your own individual self. It looks different for everybody. Here are a few things that work for me.
  • Make Lists: I like making lists for two reasons. First, it helps organize the project, as has been mentioned above. Secondly, it helps keep me focused on just one step at a time, and I find immense satisfaction from checking something off a list. Write these lists in a physical notebook, and check things off with a big bright marker. This applies to Git also. To me, committing to my git repo helps make me feel like I'm making progress. Even as the development is taking longer than you'd like, if you can check just one thing off the list, then you're making progress!
  • Take Breaks: When you don't feel like working on your game, that's okay. Or when you don't have time because of other obligations, that's okay. Take a break! That's part of the development process. Take the time doing something that relaxes you, and come back focused and rejuvenated. Your ideas need time to develop. That can happen in the background while you're doing something else. For me, taking a break looks like going for a walk, spending a day reading a book, drinking tea. (Well... I drink tea all the time anyway).
  • Find People to Talk To: If possible, find some friends IRL that are cool enough to listen to you talk every once in a while. What is so critical for my own motivation is to be able to share what I'm working on and have an engaged listener. (Just be sure to reciprocate in that relationship, as in any relationship, of course). Share what you're passionate about. Often verbalizing it helps renew my passion for development, generates new ideas. If you can build an online community that will play your game while it's in progress, that is also awesome, but you can't really do that until you actually have a game.
Being in a healthy mental state is really helpful to make games. (I would say, even, required). I struggle myself when I find I'm not working on my game. I feel guilty that I'm not making progress, sometimes I feel like I am worthless because I have so little motivation. That's why I want to stress this: Self-care is part of the development process. Take the time required to be healthy. That is the only way to make it work in the long run. Mark breaks on your calendar. Remember it's not your fault or lack of ability that means you aren't motivated--humans work that way, and the obligations we already face in society are more than can honestly be expected most of the time.

There's more I could say, and this is really just my own experience. Maybe it doesn't I apply to you, but I hope this is helpful.
 

kburkhart84

Firehammer Games
My advice to all game developers is to join a combat sport like judo, boxing, or mma. If you're strong enough to break bones, you're strong enough for game development!
Taekwondo Blue Belt here....I'm still not in the shape I'd like to be but its a good way to take care of yourself.

*********************
Lots of good advice here. I think I could add on something that I fail at way too much....analysis paralysis. Instead of taking so long to decide on the best engine, the best framework, the best tutorial code, whatever....just pick something and go with it. Either you find out later you could have done it better(and maybe swapping things out), or you find it you chose the best path...but either way, you actually got something done, unlike me.
 
C

carlosagh

Guest
Some of my own advices from my mistakes
1 Always practice
One may have a significant experience with a certain lenguage, or a tool, but if you do not practice it regularly, it will affect your speed, regardless of the experience.
2 Do EVERYTHING low level
When coding a program of any kind you have to organize yourself before coding, you cannot fully build each feature one by one, because many features require the most simple ways to switch between them. Low level emphasis makes your code scalable, makes it VERY EASY to implement new stuff in the long run and keeps your code SQUEAKY CLEAN and easy to read.
3 Practice the Wim-Hof method
It's good stuff
 
Top