#Which patterns could I use for a minigame-based game?

1 messages · Page 1 of 1 (latest)

lavish ledge
#

I'm trying to develop a really small-scale, simple minigame-based game (quick minigames, like Dumb Ways to Die, for example)

Which patterns will be useful in this case? I'm trying to wrap my head around developing an abstract or default minigame base with start and end conditions based on a timer.

From that minigame, I want to make simple things, like a clicking minigame, for example, or a writing one.

#

Would a strategy pattern be useful in this case? Applying it to a MVC-like pattern where the model is the logic for each type of minigame is good or i'll make a mess of scripts and data?

#

Or, if anything, is there any resource or source code I could look at or read about for this topic in particular?

delicate walrus
#

I don't think there are any resources on "programming patterns to use in a game that is a collection of mini games"...

#

Instead of thinking about patterns first, I'd recommend thinking about design first. The flow of the program, what is common between the minigames: game loops? UI? Data structures?
Maybe start with implementing the simplest dumbest version you can with a few mini games, then analyse it in terms of what could be generalized and merged, decoupled, etc...

#

Patterns are good to have a general idea about, but there's no software that adheres to them 100%. It would be a poop.

#

Basically, patterns are for solving local well defined problems. Not for defining the general design of your program.

floral rampart
#

is this a 2p game? if so you could have a points/split screen control template. Otherwise a timer template and win/lose. Tbh just make some basic templates for minigame features that would be useful for multiple minigames, but really youll develop a library of those if you just start building minigames

#

idrk tho

lavish ledge
#

Alright, Ill try to develop the bases first.

Overall it's intended to be a single-player, small scale game.

I don't exactly know where to start, though. I know the minigames will have a shared portion of the UI which is the timer, but, for example: would it be best to start programming this general aspect of the game (solving the timer) or solving the minigames issue.
The minigames sound a bit confusing despite being kind of simple: different win conditions and different inputs.
Could I have an input system and subscribe to specific events on each minigame? And about the win condition, should I have an abstract bool method to override to check for win conditions?

buoyant walrus
#

Each minigame can be its own prefab that handles input independent of the "outside" player controller.

The root object of each minigame prefab can have some monobehiour that implements an interface or inherits from a super class for EnterGame() and ExitGame().

When the player interacts with a minigame, check for an available minigame (something like a raycast hitting an arcade box or whatever the minigame prefab will be). If there's an available minigame, cache it in an activeMinigame var, and set the outside player controller to stop taking movement inputs and whatever else you dont want to happen while the player is in a minigame. And call the EnterGame() method on the minigame to start it.

When the player presses the exit minigame button, call the ExitGame() method on the activeMinigame var you saved to pause/end it. And then set the activeMinigame var back to null and re-enable input.

#

Thats the framework I would make based on what I understand you're making

#

You can add an OnWin and OnLose event to the Minigame super class if you need to pass that back out of the minigame, but otherwise I would keep the generalization light. The more uniform you make your mini games the harder it will be to get creative with it. Since you want it to be small scale, I wouldn't worry to much about the individual minigames getting messy in terms of code. Just avoid letting any of that mess escape the confines of that minigame