Mega Man Battle Network 3D

It’s been a while since the last devlog. Way too long a while. Anyway, this devlog I wanted to take some time to talk about characters! Yes, playable characters. I’m not revealing any this time around, I prefer doing that with videos.

Much like with movement, I decided to look at playable characters from their core. As everyone knows, we got Mega Man in first and then others (including Proto Man and….. nope, not telling).

We just built Mega Man from the ground up into the one and only playable character at first for two reasons, A) we just kinda winged it. It’s not like there’s a “MMBN movement tutorial” around and B) we hadn’t even planned on having multiple characters when this project originally started.

When I decided to add more characters I had to make a framework so I could add more characters later with relative ease instead of having to build them from the ground up AND for a change to mega man to affect all navis and not just him.

Here’s a diagram detailing all of Mega Man’s features when he was developed.

Basically, it was all stuck inside one big glob of code. This is BAD. Why is this bad? Because there are things that ALL navis have in common and things that each navi does separately. You have to figure out a way to have the common stuff be reusable or else you’ll be making the same stuff over and over!

Let’s go back to Mega Man’s features and mark what every navi shares and what’s unique about every navi… (note, animations and the model are obviously different for every navi but if you say “play animation ATTACK” and you keep the name for the animation the same on every character you don’t have to alter it in code. It’ll just play ATTACK on whatever model is currently being used.)

Movement, chip usage, taking damage, state management (invisibility, invincibility etc.) and misc. logic (can’t move on occupied panels, tracking for tracking attacks and so forth) are all shared between all navis in the exact same way.

Buster attacks (and charge shot), the way the arm morphs into a sword and buster and for chip attacks is all different and will need to be interpreted differently per navi. So how that will work is through layers. There will be a base that all navis share and then on top of that there will be code that defines what every navi does differently! So two layers. Let’s illustrate those layers.

The arrow is meant to illustrate that one flows to the other. As in, each navi has the same “Navi” component but each navi has its own “custom” component. This means name (which also gives the name of the image for the logo) but also custom code for charge attacks and other passive traits. 

Arm morph is especially an interesting one because not all navis change their arm the same way, obviously. A navi like Mega Man has a separate neutral, buster and sword mode. But Protoman’s neutral stance has his sword out and he never shows his hands unless he’s in his PET and not in-battle! The arms however are still modeled because… why not?

This system means that if I want to change Proto Man’s charge shot only Proto Man will have this change in gameplay, however if I want to change the way Mega Man moves around the field (increasing the delay between movements or adding graphical effects) ALL navis will get this effect without any added effort!

And that’s how adding new navis works after the implementation of this system, all I need is the model, the animations and the code for their charge shot and arm morphing and some other minute things (the 3D location of where chip appendages (think vulcan) have to spawn to attach to their arms properly). So you’ll be seeing more playable navis as time goes on…

Now, I said I wasn’t going to reveal a navi this time and … I lied! Consider it a reward for sticking with this whole post.

Like I said only just yesterday, this devlog will be about the movement and panels in our engine.

Usually before implementing architectural ideas or concepts into code I like to draw them out, whether it’s with pen and paper or in MS Paint, it’s always good to visualize the buildings blocks before you build them and that what is inside of them.

The battlefield is divided into squares that Mega Man (or the enemy) can move over, I refer to those as the panels (or battlesquares). I decided to assign a number to each square like so:

This means that if you are on panel 1 (bottom-left) pressing down would add 10 to your current location (the positions are saved numbers (integers)) which would make your position 11, which is the second row! So down a row is +10, up a row is -10, right is +1, left is -1. The only valid locations are between 1 and 26. The enemies and Mega Man both use this system. Mega Man cannot move until he’s “done” moving to a square. 

The panels have various properties, whether it’s blue or red, whether there’s someone on it and so on.

When someone (or something) is on a panel it tells the panel, the panel is then able to basically reject others from stepping on it. The way we handle damage is similar. The panels hold the damage (damageBlue/damageRed, the color refers to from which side it is) and as such anyone being on that panel at that moment has that damage applied to them (barring invincibility and so on).

Part of those properties are also things like panel type (grass, poison etc.), whether it should be marked yellow and so on.

Anyway, that’s about how we tackled movement, there are more nuances but those are maybe a little too deep to be interesting to read about. Personally I’m very curious about how other teams have tackled this in the past. We’ve tried to keep it as faithful as possible so I hope everyone will enjoy it! 

Again, thanks for reading. Send me messages if there’s something in particular you wanna know about, if it’s something detailed like this I’ll write a devlog about it!

 - Heatphoenix (Zack) (Follow me on twitter here)

For this devlog I wanted to talk a bit about the engine that we’ve made for this game. Maybe this post will be a bit hard to follow for people that aren’t really interested in this kind of thing or maybe it will be interesting for exactly those people! We will see.

One of my main goals was to keep the code as extensible as possible within the boundaries of Mega Man Battle Network. This might include being able to incorporate any kind of chip we would want to make, any virus, any boss, any navi, any stage and so on. 

For enemies we made code that you could basically apply to any enemy and every enemy is required to inherit this code before being able to be registered as an enemy to the game. This code handles things that all enemies have in common like movement or having HP and so forth. Then “on top” of that as it were they have their own specialized code that’s purely for that type of enemy, so you have [basic enemy code] + [special enemy code] + [3d model & animations] = a full enemy!

The same basically goes for the chips, you have basic chip code that includes things that happen in all chips like having a character, the name and such data. On top of that is the code specifically for that chip, the code that makes the attack itself happen.

I’ve tried to apply this kind of extendable pattern to all types of components in our game. Maybe my execution wasn’t the best at some points but I believe this has made it sufficiently easy to add new content to the game.

(Not in-game screenshot)

By the way, I am aware that most of our followers do not read these logs but I hope that they’re at least a little amusing to the fans that do. As a tip, we’re a lot more receptive to requests and such than you might think. We might even add chips or enemies if we like your suggestions, you know?

Next time I’ll talk about the movement in our engine a bit.

 - Heatphoenix (Zack) (Follow me on twitter here)

Today for the second devlog I wanted to talk about 3D modeling. Before starting out this project we had no prior experience in either 3D modeling or animation. We just knew what we wanted the game to look like and we went for that. We’ve tried to convey that aesthetic through our 3D models and textures. 

As you can see in this screenshot we decided to go with no shading, the only shading you can see is the shading we’ve applied to the models themselves. This gives the game a very distinct look. This kind of look obviously does not work for every game but we felt that it worked quite nicely for a colorful type of game like Mega Man Babble Network. 

I usually start with collecting reference material of whatever it is that I’m trying to model. I draw a few basic shapes off of which to model, this is called “box modeling”.

After finishing the mesh we unwrap the “UV” (the location of the parts of the texture on the model) and add the texture. This brings us to our finished model. After that is rigging and animating and even then we’re not done yet, we’re just halfway. After that is gameplay programming but that’ll be the focus of another devlog!

Thanks for reading.

- Zack (@HeatPhoenix)

Honestly, I didn’t really know what to talk about at first, but I figured you guys might also be interested to hear how and why we came to make this game. In the interest of length I will spare you all previous projects and stories of terrible games I made when I was a middle/high schooler and cut to the chase. Me and Drsypher first met through Mega Man Battle Network many, many years ago on a little website called “PET-World”. It was about the physical PET toys that were coming out as the games were coming out (with battle chips that actually worked, too).

Drsypher and a friend of his made a small PET-esque game/application in MMF2. I was interested so we got to talk because of that. Nearly 8 years (and many adventures) later, here we are, trying to pay tribute to what even got us together as best friends.

As we were both programmers to begin with, we had to begin learning how to make 3D models and so forth from scratch without any formal education on that. We actually only started modeling last november. This project formally began in February. The first model we made was Swordy EXE for me and Mettaur EXE for Drsypher. This is also the first game we’ve made using the Unity3D game engine. Next time I’ll talk about programming!

- Heatphoenix (Zack) (Follow me on twitter here)

Hi all, Drsypher here! I figure now would be the best time to answer about what we include in the project! I’d like to say that there isn’t much of a problem in choosing what to include, but that isn’t necessarily true. For this project, we want to include features and other things that we like the best in MMBN. As it turns out, though, that’s a lot harder than it seems. There are a lot of things we’d like to include in the game, and a lot of navis and features we like.

Things like Style Changes, Soul Unisons, Crosses and features like those are all cool ideas that we certainly like and know you all do too. Figuring out if we have the ability to replicate those properly, choosing what to put in, what navi or virus we’d like to put in… A lot of that is based on whether it’s feasible for us, and so we not only have to answer “What features do we like?” but also “Which do we like the best?” and that’s actually pretty hard!

At the moment, we’re trying to rule nothing out, but we know we certainly can’t include everything, so we’re still trying to answer those questions ourselves. That being said, you can be sure we will do our best to include what we can and that it’ll be all cool and fun! So please look forward to it! As Zack said above, we started modeling a few months ago, so I’ll be talking a bit about that next time. Until then!

- Drsypher (Dave) (Check out my deviantArt here)