Minigame Madness

Last updated 2024-04-09 – version 0.14-uncursed
Downloads – Source Code
Play Online Now, Guys!

Minigame Madness is a collection of 20 14 fun microgames which hearkens back to the good old days, when Flash games ruled the Internet and anarchic fun was an acceptable passtime. Think you can handle the pressure? The challenge??? The sheer balls-to-the-wallsedness‽ There’s only one way to find out!

Minigame Madness is also the first game I made using the Godot Engine, a game engine for 2D or 3D games with an easy-to-use interface and scripting language which makes the game easy to build and easy to extend.

• Design
• Challenges
• What I’ve Learned
• Public Domain Status

Design

Minigame Madness is my homage to Four Second Fury and its sequels, developed by Flash game designer jmtb02. Much like Four Second Fury, Minigame Madness is a collection of simple games with a strict four-second time limit. At the start of each game the player is given a single instruction or hint which they must use to quickly determine what to do and get it done.

Also like in the Four Second Series, Minigame Madness uses only the arrow keys and space bar¹, meaning that the various microgames play relatively consistently and require little experimentation in order to play. This is done firstly to simplify the design of the various microgames but also so that the main challenge factor is the strict time limit.

The player has five lives to complete all of the microgames with; if they run out of lives, they fail. In order to win, you must play all of the microgames in a random order without running out of lives.

Unlike the Four Second Series, I made it a point going in that every microgame must be distinct from all the rest. Four Second Frenzy and Firestorm, the second and third games in the original series, were collaborative efforts with microgames contributed by various Newgrounds users, and unfortunately a lot of them had the same basic design, just with different graphics. I wanted every microgame in Minigame Madness to play differently from the rest, so that the player felt like they were getting a new challenge with each game.

Challenges

The most obvious challenge in the design of Minigame Madness was coming up with a bunch of different microgames. I started developing Minigame Madness in early November with the goal of getting it out by Christmas or New Year’s Day. With the original intent being to develop 20 microgames, one secret game, and a boss battle, this gave me a very brief window in which to develop the game, and I ended up not being able to get all of them out on-time.

In practice, this turned out to be much easier than I thought, because the games by design need to be very simple. Each game has to be completable in four seconds or less, which means there’s actually very little pressure on me to make something very complicated.

On top of that, the various microgames all have the same basic structure: They have a win state and a lose state, the player either loses or wins by default if the timer runs out, and they all use the same control keys. The only real difficulty in terms of development is making all of the games fun, challenging, and distinct.

Another problem I ran into with Minigame Madness is that I can’t draw. I do okay at pixel art, but with a deadline coming up I didn’t have time to carefully hand-craft sprites and backgrounds pixel by pixel. There really wasn’t a fix for this except to embrace an intentionally crappy art style, which is fairly consistent throughout most of the games. This ended up working in my favor, however, because the slapdash art style worked with the frantic pacing to make the game feel more rushed.

What I’ve Learned

Working on a number of tiny games instead of one big game was a great change of pace for me. I was able to complete a microgame in about a day or so, sometimes three if it required more assets or if the code needed to be tweaked. During the day I could come up with a basic concept for several minigames and test that concept with some basic code and assets.

Of course, the fast pace of work also meant that I had to refine my process. Part of that was giving all of the microgames the same basic structure, with a win and lose state and all using the same basic controls.

# This signal is used when the player has beaten the minigame, especially if
# the win state occurs before the timer runs down
signal won
# Similarly, this signal is used when the player has lost the minigame
signal lost

# A brief string used to give the player some hint as to what they're doing at
# the start of the minigame.
export(String) var _instruction setget ,get_instruction

# Whether the player wins by default when the timer expires.  If not, they
# lose by default.
export(bool) var _win_by_default = false


# This function is used to force the minigame to decide whether to throw the
# `won` signal or the `lost` signal.  Mostly used if the minigame has not
# given any such signal by the time the timer runs out.
func decide():
	stop()
	if _win_by_default:
		emit_signal( "won" )
	else:
		emit_signal( "lost" )

Every microgame expands on the same basic template so that the mainloop is able to handle all of them the same way without any need for special-casing. The microgames themselves determine the win or lose state, with the decide function only being used if the game is still running by the time the four-second timer runs down.

The export statements in the above code sample mean that the variable can be initialized in the Godot editor rather than having to initialize it in code. This is why there’s no setter function for the _instruction variable, for example.
This was a very new framework for me to work in, because up until Minigame Madness I was used to doing everything manually in code. Taking advantage of Godot’s editor like this made it very easy for basic variables used in each microgame to be set, which is useful for those minigames that don’t need any special code to handle gameplay or define the win/lose conditions.

Indeed, Minigame Madness got me used to working with an editor. My earlier projects like SwashRL and Orange Guy’s Quest were written entirely in code, which is easy to implement and offers a lot of control, but it does mean that making minor adjustments is more cumbersome. With the Godot editor, I can just create a new microgame that inherits from a single class and quickly start adding assets with just a few clicks.

The way the Godot engine handles nodes also made it very easy to take advantage of this process so that I can project minigames onto a canvas with a main node in full control of what goes where, meaning that as I continue to work on Minigame Madness I can add transition animations and other cool effects for flavor.

One of the most important things I learned from Minigame Madness was how to optimize the labor that goes into a project. Because I needed to build a lot of microgames in not a lot of time, any art or other assets that a game needed had to be built quickly. This resulted in kind of a sketchy art style for the project, especially for microgames that had a lot of moving parts.

My solution to this was to deliberately make the art very slapdash for a lot of microgames and focus more on making sprites look good when there weren’t a lot of moving parts. I had to get comfortable with doing that so that I could focus more on making sure the actual gameplay was functional, snappy, and fun.

I learned from designing the game in this way that I can make a game that’s still engaging without necessarily having to put 100% into every single corner of it as long as the core appeal still works. That’s not to say I didn’t devote myself to making the game well, just that I had to use my resources optimally and sacrifice some elements of the project to make others as good as they could be.

Public Domain Status

I made the decision very early on to release Minigame Madness into the public domain. There were some limitations on my ability to do this, however. For one thing the game engine I used is not in the public domain, and for another any third-party assets I used had to be very permissively licensed, ideally also public domain.

Finding suitable third-party assets that are in the public domain turns out to be surprisingly difficult. I was able to find some useful fonts which are public domain, which is good because my handwriting is terrible and I didn’t have time to try to build my own font from scratch.

Music was much harder to get a hold of. I eventually found a musician who goes by Loyalty Freak Music who mostly works on video game projects and publishes exclusively in the public domain, but none of their work seemed to fit for the core gameplay loop.

Eventually, for the main music, I compromised and settled on a song called Skippitybop by Spadezer. Even this song wasn’t ideal, since it was released under a Creative Commons-Attribution License, but since the game already had to include some licensing information in order to see any kind of release I decided the compromise was just going to have to happen. Besides that, the song is just perfect for the anarchic and frantic style of the game, and it’s frankly criminal that it hasn’t gone viral yet.

The practical effect of this is that the original Minigame Madness source code files are all in the public domain, but compiled binaries are still subject to copyright. There’s really nothing I could have done about this, due to the licensing terms of the engine I was using, but I stuck to my guns on this one because as long as Minigame Madness is open-sourced it matters that my original work be available unencumbered.

Back to top.

This website is maintained by Philip Pavlick.
All content on this website is available in the public domain unless otherwise specified.
Hosted by GitHub Pages