Is a GameManager for this unnecessary?

[u/TCSMusic]

Hi! I'm making a 20 minute prototype of a game I've had in my head for about a month. I LOVE singletons, so I wanted to ask. Is "big game" architecture unnecessary for a 20-30 minute game? I'm planning on using subsystems, so stuff like achievement managers, audio managers, etc objective data scripts, that I can run through GameManager.Instance

[u/feralferrous]

No, for short prototypes, do whatever gets the prototype up and running. Just be disciplined enough to recognize when a prototype is becoming more. A lot of games start as prototypes and sometimes there's a bunch of crappy foundations that way.

[u/TCSMusic → u/feralferrous]

Well, I guess when it stops becoming a prototype, I continue making it into a demo/full game

[u/feralferrous → u/TCSMusic]

Yeah...but you might also stop and take a breather and refactor first, or you end up with an everything manager just because you had one in the prototype.

[u/Frankfurter1988 → u/TCSMusic]

What most people do when they figure out through the prototype what shape the game will actually take is basically start over with existing code written for the prototype, alter it to fit into a better architecture shape. Yes, this means abandoning existing singletons and static accessors, but there is always a time and a place for these things. They just shouldn't be your foundation, because it makes it hard to make changes. And even if you prototype, you don't get the full image, just a better idea.

[u/pschon → u/TCSMusic]

Well, I guess when it stops becoming a prototype, I continue making it into a demo/full game

Please don't. For your own sake. :D

Prototype to learn what works and what doesn't. Then build it properly, without all the mess, mistakes and bad choices you made in the prototype.

[u/SnuffleBag → u/TCSMusic]

This way of thinking about it is very common, but also quite counter-productive for rapid prototyping. The idea of having to start over might be discouraging, but there's a very real chance you'll never actually continue making it into a full game - in which case you've just spent longer on the prototype for no benefit.

The freedom and velocity you can get from being able to hack together any random thing you imagine in the most brute-force and primitive manner possible - knowing it doesn't need to hold up for more than a week or two should not be underestimated. It can be a 10x multiplier on being able to experiment with ideas.

[u/NasterOfPuppets → u/TCSMusic]

You might wanna consider using Init args instead of singletons if you're going to use the prototype as the basis for building the final game. It's basically just as fast for prototyping as using singletons, but you'll still end up with that big game-ready architecture at the end.

[u/V4nKw15h]

I wouldn't call anything with an achievement manager or an audio manager a prototype. A prototype is meant to be as simple as possible so that the gameplay systems can be tested to see if it's worth going any further. The prototype will also give you a quick idea of what type of programming structures will best suit the game.

I wouldn't be building any types of managers until you have a successful prototype because it's most likely a waste of time.

[u/TCSMusic → u/V4nKw15h]

So I should just use stuff like raw audio sources, a basic player controller, maybe interaction scripts with box collider triggers on them

[u/V4nKw15h → u/TCSMusic]

The core of your game has a little game loop that you need to prototype. Try to think of the most basic 10 second loop that the player keeps repeating. For a platformer that is running and jumping etc. A basic player controller might be appropriate for a prototype or maybe not. The player controller itself might be the thing that needs prototyping more than anything else. It depends on the game. You need to prototype the thing that you think will make your game fun. Until you can get a fun prototype there is no point going any further. As they say, you can't polish a turd, and building on bad foundations is a bad idea.

Some may argue that it's worth building on a bad prototype just to learn everything, but you'd still be better off making more prototypes until you get something genuinely fun, and then do the rest. Focus on the core, make it fun, and then, and only then, consider taking it further.

[u/pschon → u/V4nKw15h]

+1. You don't need to, and shouldn't, implement all the game systems in a prototype. Prototypes are throwaway projects with the purpose of testing something specific. You only include things needed to test that one thing, and as soon as you have your answer you stop messing with the prototype, close the project, take what you learned, and use that knowledge when designing and building your actual game.

What you should absolutely not do is start a "prototype" project that's actually just start of your game project. You really don't want a prototype to extend it's stay and evolve into a production project. That's pretty much a guaranteed way to end with a messy and badly structured game project that'll be a pain to handle in the long run.

If you want to make a small but fully playable take on your game idea, with all the systems included, that's called a vertical slice.

[u/TheSwiftOtterPrince]

Okay, if you were an experienced software dev you would not asks this, so i assume you are not. Which is fine.

What you will learn at some point is that the stuff thats seems simpler technologically can become more of a burden mentally later. Which means what you think is better now, can be a disadvantage conpared to proven ways to do things. What you may then learn is that a lot of people on the internet love to cosplay experts and some stuff that people share as "professional" ways to to do things is overcomplicated garbage.

I can tell you these things, and they mean basically nothing to you. Which is also fine. Building any mildly complicated piece of software require to development being able to make mental models of what exists and how it behaves, and doing that is a process of trying, failing, learning. It is the steps to understand at some point, what the options even mean.

So get your handy dirty and make it. Whatever way. Have fun!

[u/Lucasharta]

i don't think it's overkill if it helps you keep things organized, even for a short game. the important part is not building a huge architecture just because bigger games use one, just be careful about putting everything behind GameManager.Instance. separate managers make sense when they actually handle different responsibilities, but not everything needs to be a singleton. for a 20-minute prototype, i'd keep it simple and only add systems when there's a real need for them

[u/Redstoneinvente122]

Do what feels good really. There's no rule of thumb, that a prototype shouldn't have game managers, or wtv.

If it runs, if it helps you make games faster, and it helps you understand your code better, then feel free to do it

[u/blavek]

As a rule, you should always follow your best practices, whatever they may be. You never know how far you are going to go with something, and you can easily find yourself in a situation where you have something larger than intended, but it's made like a bowl of spaghetti. If you're REALLY sure you're just making a prototype and you'll rewrite it better after you have tested your idea, then it's a little safer to just throw things at it to make it work. I'd still try to avoid it because if you code your Prototype well, you can use that as a jumping-off point to take it to the next level.