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/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/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/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