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.
Jay and Matt talk about technologies unrelated to games, like cryptocurrencies.
In this completely different episode of the Exploding Rabbit Podcast, Jay and Matt talk about technologies unrelated to games, like cryptocurrencies. Game development will return next episode.
If you are worried about the job mentioned near the end of the podcast and how it affects Exploding Rabbit, don’t be. I decided not to take it.
0:01:01 – Matt’s Job
0:06:42 – Bike Accidents and Injuries
0:12:46 – Mac v. Windows
0:17:11 – Crypto-rabbit hole Part 1
0:22:06 – FPGA and Electronics Tangent
0:28:11 – Crypto-rabbit hole Part 2
1:05:01 – Jobs, work, and new opportunities
1:18:01 – Web technologies
1:26:35 – What We’ve Been Playing, Fortnite, Captain Toad’s Treasure Tracker, God of War
Jay and Matt talk about code architecture, making levels in Super Mario Bros. Crossover, what they’ve been playing, and quantum computing.
Jay and Matt dive into an Exploding Rabbit Hole full of code architecture. We also talk about making levels in Super Mario Bros. Crossover, what we’ve been playing, and quantum computing.
2:28 – ECS Architecture (Entity Component Sytem)
11:00 – Thoughts on Unity and the Godot Engine
19:54 – Engine Agnostic Code Design with Entitas
26:07 – View abstraction
31:06 – How levels were made in Super Mario Bros. Crossover
41:31 – Matt’s been playing Super Meat Boy
44:56 – Jay’s been playing Assassin’s Creed Origins
The first episode of the Exploding Rabbit Podcast features a look at the early days of developing Super Mario Bros. Crossover.
We started a monthly podcast for Exploding Rabbit. In each episode, we’ll be taking a deep dive on one topic related to Exploding Rabbit or gamedev, and then we will have a few smaller, supplementary topics like what games we’re playing, what I’ve been working on, and anything else we find interesting.
I’m co-hosting the podcast with my cousin, Matt Gyure, a very smart/funny guy that knows his way around code and other technical parts of gamedev. Matt knew I was trying to figure out a good way to keep people informed about Exploding Rabbit and recommended doing the podcast with me, so you can thank him.
The focus of the first episode is how I started Super Mario Bros. Crossover and what it was like working on it in the early days. It was just meant to be a test episode, but it turned out so well that we decided to release it.
Matt and I are very excited about where this thing will go. We’re open to feedback so let us know what you’re interested in and what you’d like us to change.
I’ve been working on a panel system and a color picker for Exploding Editor.
I decided to start writing in-depth posts for the devlog instead of doing tweets because I can add explanations to things. Also, the last devlog was about what I had done before, but from now on, I’ll be writing about what I’m doing now.
Clean up and Panels
When I first started working on the Exploding Editor, it was just a personal tool, and I wanted it to get it working fast, so the code was not the best it could be. After I decided to release this to the public, I decided to go back and clean things up to save myself time and headaches in the future. While doing that, I also decided to make a major design change to the editor. Compare the two images below:
Here’s how the editor used to look.
Here’s how it looks now. The biggest change is the panels, but there is also space for a toolbar at the top, and it’s now possible to add a toolbar to any panel.
If you’re interested in the programming details, each panel is now in its own dependency injection subcontainer. I follow the facade pattern, so each panel is a facade and other classes have no access to the panel’s internals.
You may also notice in the current image that the textfields are a darker color. I wrote a simple styling system that I can apply to elements. That way, if I decide to change something, I only have to do it in one place. If you do things the regular way in Unity and use prefabs, getting everything to match style can be a real pain, so this is a nice simple solution.
public interface TextInputFieldStyle {
Color backgroundColor {get;}
Color textColor {get;}
Color selectionColor {get;}
}
public static void applyStyle(this TMP_InputField target, TextInputFieldStyle style) {
target.selectionColor = style.selectionColor;
target.textComponent.color = style.textColor;
target.targetGraphic.color = style.backgroundColor;
}
textField.applyStyle(style);
Here’s the gist of how it works.
Color Picker
People will need to change colors of things in the editor, so I needed to have some kind of color picker tool. There are several solutions on the asset store, but there’s no way to try them out or see their code without buying them.
Instead I found a free one and then built my own while using it as a reference when I ran into trouble. It’s not completely done, but here’s how it looks.
Another reason I didn’t want to use any of the asset store solutions is that none of them use TextMesh Pro, the superior text solution in Unity. Exploding Editor supports retina displays, so it will be especially noticable if any text is low resolution.
The color picker doesn’t generate textures for the color box or the hue slider. They are implemented with shaders so they’re fast and use little memory.
Reactive Programming Example
The color picker UI is a great example of the benefits of reactive programming. I think in general not enough people use it, so I thought I’d show how using it can save you a lot of time and make your code lean and clean. The following code is in the ColorSliderView class which is used for each of the RGBA sliders shown in the animation.
Take a look at this code. It’s generating an IObservable to let observers know when something changes. It automatically combines changes from both the slider and the textfield, and it stores that value before sending the event. It also limits the event for the textfield to make sure it only sends it when the textfield has focus. This is to prevent a stack overflow.
And here’s where the IObservables are subscribed to. Whenever any of the sliders change their value, the function in Subscribe is invoked, and the color picker’s color is updated with the new values.
What’s Next?
There’s a little bit of work left to finish the color picker, and then I have to finish transitioning the rest of the editor to the panel system. I mainly just have the sprites panel and the panels related to tilemapping remaining.
I started posting a development log on Twitter. Here’s a consolidated version.
I started posting a development log on Twitter. You can see related tweets by using #ExplodingDevLog. I’ll be posting consolidations of the devlogs on this site as well. Here’s the first one!
Started working on the sprite editor, but all you can do right now is look at a sprite sheet and drag it around. Not too exciting yet.
Added an assets panel that displays all files in the project instead of having a separate sprites panel. Also added very basic sprite slicing. Slices lines are drawn with Unity’s GL class.
Wrote the basics of the ?Exploding Data file format (why is everything exploding with me?). It uses JSON because it’s easy to work with and is human readable. I also set up saving and loading of these files.
Added right click to assets panel to allow simple creation of entities, sprites, and animations. Also got basics of properties panel working.
Added grid overlay for sprite sheets. The cell size can be set in the inspector panel. Benefits of grid-based sheets and how they work with Exploding Editor will be shown later.