Millie Megavolte 8: Millie and the Mole King

[myroidtc]

Millie Megavolte 8: Millie and the Mole King



1. Background
Millie Megavolte was a Flash-based game series that ran from 2007 to 2013. I made a spiritual successor Zeran's Folly in SFML (and the sequel Leowald) but now I'm making a proper new Millie installment in fancy HD resolution for PC with SFML instead of Flash since, you know, Flash is kinda dead.

I moved from Flash to SFML back in 2013 as a school project to port Millie Megavolte 7. I felt limited by Flash and was impressed by what I could do with SFML, particularly with the gamepad and shader support. I liked SFML so much I made a couple big games with it with more on the way!

After completing my last game Johnny Lionface in Unity, I wanted to go back to SFML. Johnny took over three and a half years to make so I wanted to do a shorter project. The Millie games were always small so I decided to make another one. While gutting a copy of the Leowald engine to use for Millie, I had a lot of ideas and decided to refactor the engine to make it easier to add lots and lots of content.

There will be the base small game of a story mode for Millie and her friends but there will be tons of content to come as the game and engine will be my sketchpad. Whatever stupid characters, levels, and ideas I want will go in. I'll keep working on it until I run out of ideas.

I plan on releasing the small game on Steam for free with a paid DLC that unlocks everything else. The previous Millie games were all free so why not this one too?



2. Why I (still) use SFML
I (still) use SFML because it's exactly what it says: simple and fast. The library abstracts a lot of boring implementation details but is still powerful enough to do almost anything you want.

SDL doesn't appeal to me because it's based on ugly C and isn't as easy to use.

Unity doesn't appeal to me because I prefer keeping things simple enough to where I know everything that's going on. If there's a camera system, I know how it works because I coded it, not because the software provided it.

Overall, I'm familiar and comfortable with SFML so that's what I use instead of other libraries. Maybe newer libraries are faster or whatever but that's not important to me. A lot of beginners will agonize over what library or software to use to make games and the answer experienced people give every time still holds true: use what you like. I like SFML!

3. Additional Libraries Used
SQLite3: The game uses databases for level data, text strings, object information, and more.
GLM: Math library used for trig and vector functions.
Spine: Bone-based animation library from Esoteric Software.
Box2D: Used only for the shape collision check functions, none of the simulation stuff.

4. Game Basics
Millie 8 is an action platformer. Gameplay consists of running, jumping, and using directional-input attacks to fight enemies and bosses. The game has a Sonic-inspired physics engine meaning characters can run along curves and jumping is affected by angle and momentum. Some attacks also affect momentum.

There will be several game modes:
Story Mode: Levels bookended by cutscenes
Adventure Modes (regular, all levels, endless): Pick a team of four characters and fight through a selection of random levels. You can switch characters during gameplay.
Roguelite modes: These modes will be more complex and have upgrades. Instead of being linear, levels will be a collection of rooms organized in a maze.

Playing the game awards a meta currency called Gelder. Gelder may be used to buy characters, outfits, levels, and more.

There will be many playable characters. No two playable characters will play exactly the same. Currently
there are 10 playable characters partially-done and there are plans for more than 30. Making new characters and stories is one of my favorite parts of making games.

What sets Millie Megavolte 8 apart from other games? Simple: style. It has a tone and sensibility you won't find anywhere else, at least not these days. My games have been compared to mid-2000s edgy webcomics but I like to think they're at least a little more refined, ha. Everything in the game has to be cool, cute, funny, or sexy. I'm also making an effort to step up the stylishness compared to previous games. You can see this in the main menu with the custom font and lively background art. I want the game to be pure MTC--nobody makes games like I do.

5. Example Technical Things
Water Effects

Reflection: The part of the screen above the water is copied, flipped upside down, shrunk vertically, and drawn with reduced opacity on the water.

Animation: There are two scrolling repeated images. Their speed is set to different primes so they line up less often. To achieve the scrolling effect, the sprite simply moves the textureRect (since the texture repeats).

Waves: The part of the screen below the water is run through a shader. The shader has timers that offset the pixels to give the wavy effect.



Drawing on transparent layers:
I figured this out the other day. If you draw things with reduced alpha (between 0 and 255) to a transparent layer then draw that layer onto another layer using renderTextures, you MUST use a different blendMode in your drawing states! In this case, what worked for me was sf::BlendMode(sf::BlendMode::One, sf::BlendMode::OneMinusSrcAlpha).

Comparison using bad blend mode (left):


Comparison using good blend mode (left is directly drawn, right two use a transparent intermediate layer)


6. Current State
The game is playable but lacks core features such as particles, bullets, enemies, attacks, pretty much everything that isn't running around and jumping.

There is no timeline for release. I'm doing this as I go along and putting in whatever I want until it gets around to being done.

7. Links
MTC YouTube - I may post more videos here when more of the core systems are in.
Official MTC Website - For completeness' sake.
VERY NSFW: MTC Discord - I post about the game's development in a dedicated channel and explain my process occasionally. It's mostly naughty drawings and harsh language though so be warned.

[myroidtc]

Progress video showing most of what's functional so far:



Mandatory SFML-related stuff:

In this version of the engine, strips of spikes are constructed more efficiently.

In the old version used in Zeran's Folly and Leowald, every spike unit was its own object and was updated individually. Each one used an sf::Sprite.

In the new version, each strip of spikes is one object instead of many. They have one hitbox and construct a single sf::VertexArray which is filled with random frames from the spikes texture. sf::Transforms are used in conjunction with the camera to position them on the screen. This saves a lot of time in computing collisions and drawing.

[myroidtc]

I recently implemented the Steam Input API for the sole purpose of including the controller button icons.

One thing I love about SFML is the documentation. Every function is explained and there are even tons of step-by-step instructions and examples of how to use different modules. SFML's documentation is something other libraries should strive for. It is certainly something Valve's team should strive for.

As of the time of writing, without being too much of a Negative Nancy, the Steamworks API documentation sucks. It's outdated, some of the example files throw errors, some of the newer functions/constants aren't listed anywhere in the documentation or even online.

If you plan on implementing Steam Input in your own SFML game, here is what I learned and what I recommend:

Link to developer tutorial for Steam Input

• In the spirit of SFML, please make sure your game can run and rebind controls without the Steam Input API implemented or enabled.
• Being an API, it needs time to start up and won't get things right away. If you initialize the API in class constructors, have your game try to get relevant information a second or so later. Otherwise, if it tries to get things like controller bindings right away, it will return garbage or worse yet, nullptrs.
• Instead of keys, think of the inputs of your game as actions instead. Example: instead of seeing if the space bar is down, have a Jump action with an associated keyboard key and test for that instead. Steam Input works on Actions, not specific keys.
• ACTION_LAYERS DOES NOT WORK. IT IS A MYTH. Either it was deprecated or it just flat out doesn't work anymore. If you include an "action_layers" section in your controller vdf, it will throw errors. Just forget about it. I wanted to use action_layers so I could have separate confirm/cancel buttons for menus but it just doesn't work. Instead, define it as a separate action set and switch between them in-game as needed. Action sets can share actions (example: you can have up/down/left/right in more than one set and they'll still refer to the same action)
• Oh, and guess what: if your vdf has errors, Steam will tell you it has errors, but not what they are. Clicking the button to view errors displays basic information about the configuration instead. Useless.
• unFlags: Since this isn't documented anywhere, here is what the uint32 flag does for GetGlyphPNGForActionOrigin(). It changes the style of the glyph it gets. 0 = knockout, 1 = light, 2 = dark.

I have attached some relevant files, including the manager I wrote, the InputConstants it mentions, and the in-game actions vdf file for the game.

Anyway here's a progress video of Millie 8 with one of the most recent characters added:

[TobBot2]

Really interesting read! I'm actually writing a sort of report for my game I made, so it's nice to see how you organized your post into sections in a cohesive manner.