Are there 'must knows' for when making a big game?

[Sheepolution]

I'm not talking about the game development, but about programming with LÖVE. Are there any simple concepts that you should apply? I'm working on a big game right now, and I want to prevent the 'I learned so much, I should start over' loop. Do you guys have any tips or tricks that can be useful in such big projects?

[richardperkins]

Develop a GDD (Game Design Document). Spend a few days, or a few weeks on your GDD. Plan out everything, especially the complex parts. How should the controls feel like? What is the story? What does the player need to be able to do? How smart is your enemy? Ask yourself all of the detailed questions you can think of, and come up with a true answer for it. Don't gloss over anything, because you would be setting yourself up for failure.

Modularize. Do not build the entire game in one chunk. Take it a piece at a time. If you learn something that works for one part of the project, design it so that part can be rewritten and still output what it needs to. Most parts should always accept only certain information and output certain other information.

Keep detailed notes of all systems, functions, inputs, outputs and types of everything. This will ease the pain of rewriting modules.

But when it comes to LÖVE, there are a few things I would:

• Maintain control of your variables and functions. Memory leaks are bad for framerate and your processor. Be sure to not use globals, nullify any unused variables/tables. For instance, I had a table of enemies. When they died, I removed them from the table. What I forgot is that I added the explosion particle system into another table. I forgot to nullify the systems that were complete and my framerate went nil.
• Use dt - if moving anything, be sure (if you don't already) to move like so: player.x = player.x + 50 * dt. Without the dt, the speed of the player would vary based on framerate. Also keep in mind that in the example, the player would move 50 pixels every second.
• Use local variables and functions as often as possible. Global variables should be as sparse as possible. This also helps with ridding your program of memory leaks.
• Read this: A Better Approach to External Modules

By far, the best thing to do in a big project is divide and conquer. I have been doing that for the past couple of weeks, and I feel like I am further ahead than I was on another project I spent a few months on.

I wish you luck on your venture!

[Sheepolution]

Thanks! This helps a lot!

[richardperkins]

Anytime!

[micha]

• Keep separate things separate (camera, physics, graphics, input ....)
• Choose variable and function names such that they speak for themselves, see here and here.
• And my general approach is to implement things in the simplest possible manner and then, when it turns out it needs to be more general/flexible, generalize it. Don't overthink things in the beginning. But I'm pretty sure there will be people disagreeing on this.

[JovialFeline]

Can't say I'm a pro but here's a few little things off the top of my head:

• Try and make your objects or scripts as isolated from the rest of your project as possible. It's great when you can painlessly re-use your sound manager, logger, or whatever else in a new project. This also makes debugging much easier. Instead of having to account for what the rest of the program is doing, you'll just have to ensure the incoming data is valid.
• Try and make each bit of code as brief as reasonably possible. If a single function is getting huge, consider breaking it down into other parts. You might well be re-using those parts anyway. To use the sound manager example, this would be something like self:getVolume being used in self:fade, self:resume, etc., where self:getVolume returns the volume level a player has set in the options menu.
• For the most part, don't bother truncating your variable names, function arguments, and so on. Type 'position', not 'p', and 'sound', not 's'. You will be revisiting your code time and again, and readability will be key. I'd consider commonly used terms like 'i' for 'increment' or x/y fine as they are. Just make sure you'll know what it means at least 2-3 months down the road.

e: Pardon me for essentially repeating most of your points, micha.

[Plu]

Prototype, prototype, prototype. At least, if you want your big game to be fun in addition to complete. It's very difficult to get it right the first time, and it's a waste to build a big, detailed system if it turns out that it isn't fun to play with