A preview of Super Mario Crossover 4.0 is released for WebGL
Update: The port was canceled due to getting a demanding job.
I have good news! I still know how to make games and am not dead. Due to those two things (and also getting a lot of requests), I have been porting Super Mario Bros. Crossover to WebGL. You can play a preview here.
Please note that this is a very much not done game. It is so not done, that playing the game will make you sad because there are bugs everywhere and performance is not so good. The good news is work on it is going fast, and it will not be too long before it catches up to the flash version.
I have spent the last 5 years working on a general-use 2D platforming codebase and workflow that I could use on multiple projects. It took a while, but it’s finally ready to start using, and this is the first project I made with it. It’s built on top of Unity.
It will take much less time to add new content to the game due to the clean codebase and data-based asset workflow. This is a complete rewrite of the game. In fact, I may allow people to mod the game in the future by open-sourcing the data portion of the game. There is no promise or timeline on that, but it’s a goal I have in mind.
Super Mario Bros. Crossover will be updated until it reaches general feature parity with the Flash version, but please note that not every feature will be ported to the WebGL version. There will also be additional features and characters added.
We discuss experimental preview of Super Mario Crossover released for WebGL, and then Jay and Matt debate The Legend of Zelda: Breath of the Wild.
Update: The port was canceled due to getting a demanding job.
We talk about the experimental preview for Super Mario Bros. Crossover released for WebGL, and then Jay and Matt debate The Legend of Zelda: Breath of the Wild.
Glitch Strikers takes giant leaps forward in the code that powers it and in its design with an unexpected epiphany.
The last month of development on Glitch Strikers is the best month the game has ever seen. I’ve made two huge advancements with the project, and I am more confident than ever that not only will the game get done; it will be great.
You can watch the video above for an in-depth discussion or read below for a summary.
A New Beautiful, Clean Codebase
I rewrote all the code for the game in a much cleaner, scalable, and maintainable way. I’m very close to being done with the refresh; all I have left to do is the attack system and sound effects. If you’re not a programmer, this may not sound like a big deal, but trust me; it is a huge deal, and it accounts for about 75% of my confidence boost for the project.
I had been working with more or less the same codebase for four and a half years, and I accumulated a lot of technical debt, especially in the months leading up to the trailer. In transitioning to the final iteration of the game, I was getting bogged down, so I decided to start fresh and apply everything I’ve learned since starting the project.
If programmers are curious, I’ve rewritten everything using dependency injection and reactive programming as a foundation. I’m also now using C# 6, which just became available in the most recent Unity beta.
A Game Design Epiphany
Throughout the development of this project, we never had a design that felt “perfect”. There aren’t many games that let you switch between characters that are very different because it’s hard to make every part of the game fun and challenging for each character. The more different the characters, the harder it becomes.
We solved the character switching problem right before the project was put on hold, and I never implemented the solution because I couldn’t figure out how to fit it in with the rest of the game.
Then… last month, an answer struck me like a bolt of lightning, and everything made sense. It’s a very simple idea, but you probably won’t recognize it unless it’s directly pointed out. I’m taking a well known game formula and tweaking it. The best thing about it is that the game is now unique. Once people see these mechanics working together, they will no longer say Glitch Strikers is unoriginal.
This epiphany also gives me a very clear way to make a non-episodic game. We will instead make a small game based on this formula. Instead of episodes, we can do sequels, and backers will get sequels for free because you deserve the world for what you’ve been through.
Next Milestone? Beat the game.
In all this time, we’ve never actually had a “game.” By that, I mean we had gameplay and some fragments of levels, but we never had a game that could be played from start to finish. That’s where I’m headed next.
I don’t mean the next step is finishing the game. To put it simply, we have a diagram for the flow of the entire game, from title screen to credits. Currently you can start on any level, but there’s no beginning or end. So this next step is turning it into a beatable game. Once we have that, it’s just a matter of filling in content, and we can also start thinking about early access and private betas.
I plan on posting again after I reach the beatable game milestone. See you then!
We made a lot of progress and will be showing it in a demo video soon.
I made a video talking about progress on Glitch Strikers since the release of the trailer. We got a lot done, including a new feature I’ll be demoing in an upcoming video. I hope to have it ready in two weeks. There will be some other stuff shown as well. See you then!
Early on, you should decide on a game unit that is simple and intuitive.
When making a game, one thing you have to decide early on is what you will use as units. Having a game unit allows you to consistently express things like distances and speeds. Below, you can see the units I use for Super Retro Crossover. Since the world is split up into tiles, 1 unit is equal to 1 tile (16 pixels).
Having a unit that makes sense and is easy to wrap your head around is important. For example, if I tell you that Mario’s max walk speed is 5.625 game units per second, can you imagine how fast that will be in your head? With the units I’ve chosen, it’s pretty easy. He’ll move past about 5 and a half tiles every second.
Units shouldn’t always have a direct relation to pixels though. For example, one unit is equal to 16 pixels now, but if I wanted more detailed graphics, one unit might equal 32 pixels or 64 pixels. It’s generally a good idea to think of rendering as separate from the rest of the game engine.
I’m telling you all of these things because I did them wrong in Super Mario Bros. Crossover. In that game, one unit was equal to half a pixel. Look how much more confusing this is!
In this case, Mario’s walk speed would be 180 game units per second. That’s a lot harder to visualize in your head. The point is, keep your game units simple and intuitive!
I implemented sprite flipping in the level editor and game engine. The image above shows flipping on hill. Those are both the same sprite.
I also built the first level of Super Mario Bros. There is a toad there because the story takes place after Mario beats Bowser, so he has freed the toads.
Speaking of that… does anyone have any ideas for how the first level would be different after Mario has beaten Bowser? So far I just have toads hanging around that you can talk to, there are no enemies, and some of the bricks and item blocks have already been hit. I was wondering if there could be anything else different to make it more interesting to go through the level. It’s important for the story that the player goes through the whole level.
Switched to using one collider per tile to make it quicker to build levels. The sides that are in red are ignored so they still behave properly.
For comparison, this is how colliders looked before. They are bigger, so they’re more efficient, but it takes longer to make them. I’ll probably eventually have something like this auto-generated when a level starts.
