The AI for all 8 Robot Masters, including their weapons, is finished, give or take some tweaking and additional bug testing. I have now moved on to developing the main portion of the game, making the interface for level selection and progress data. I still have the Wily bosses to work on, but that’ll be afterwards. Unlike the original, which used a password system, this port will use saving instead (up to 8 slots). Information for the save is displayed, which involves which weapons have been obtained, how many lives and e-tanks you have, and even the difficulty you chose to begin the game (and yes, there will be normal and hard modes). Unfortunately because of all the work I’ve done getting the game working under editor conditions, the original design for loading levels used by the past demos is broken, so that is going under repair procedures.
Long episode of no updates. Completely my fault. So many things going on, and this project was a small portion of that. Sometimes when I have a breather, it ends up being more than a breather. A few things to note that has happened recently.
First was an attempt to make a converter that would take in NSF files (Nintendo Sound Format, basically, NES music/sfx) and convert them into MML structure. I originally was going to put together a small article that would describe the instruments used for replicating the NES audio used in Megaman 2 PTC and how I was able to export them decently accurate, but after diving into that, I learned that certain NES audio players had their sourcse available, so I thought that maybe I could save people the trouble of manually making their own music copies by creating this program and doing it automatically. The output seems to work decently, excluding various effects like pitch sweeps. Unfortunately, attempts to find the main loop points for each musical composition has been less than stellar, likely because the exportation method works off examining the state of the channels at a rate of 60 times per second when the music updates at a far more significant rate. Since the base of the exporter/player is made by someone else, I’d have to examine their work and see if I can retrieve the data a lot more often, or find another way to export the audio. This converter has been put on hold until further notice.
That is what I’ve spent most of my time on since this last update, though I have worked on MM2PTC here and there among other things. Various other distractions came about, such as family unexpectedly dropping by for the week from Idaho, Mario Kart 8, and just recently, E3. At the very least, I can say that all the Robot Master AI is completed, but only Bubbleman’s weapon AI has been programmed. There is one problem that I’m hoping I can get passed. When the program reaches a certain number of sprites on-screen (around 8-9, which include enemies, bullets, etc), the program begins to slow down. In most cases during the main game, that shouldn’t be too much of a problem. However, bosses like Heatman use so many individual sprites at one time (weapon fire mainly) that I can’t help but imagine that their fights will become slow. I’m devising a method that I hope will not only improve those scenarios, but general performance as well.
Sorry for the lack of updates. Been busy with things other than this project. I have continued working on the Robot Masters, but a lot of complications have been introduced as I worked on each one, so I had to make more adjustments to the overall code. As I mentioned in my last post, the Robot Masters won’t act exactly the way they do in the original game because of the inclusion of placing them in user-made rooms via the editor, though they should still act fairly close when introduced in an exact replica of their boss rooms.
Take for instance Bubbleman. He floats up into the water in Megaman’s direction and then floats down. The original room has a completely flat floor and no obstacles in between, so he would always float up and then down. But, what if the floor was raised in multiple spots, or solid platforms elsewhere? The original AI could have him floating up and up until he is off-screen above. In such a case, I changed the AI so that if he is to float around in the water above a certain point, instead off floating up, he’d float down instead. I even set them so that they can die in a pit (like if the room made for the boss has an open pit right below where they spawn). These took me time to devise, and while most can handle an altered room, some are going to take a bit more time.
Metalman comes to mind. His AI is rather simple. When being attacked, he’s jumps up to 3 potential heights, and throws a number of blades based on the height. however, introducing a room that is different from the original can mess things up. If a platform is above him, should he jump to it? How high should he jump to reach that platform, and how many blades should he throw in the process? If he’s too high, he should be able to drop down? Should he throw blades in that scenario? There are numerous variables to take into account with using the original AI and transforming it to become more dynamic in a unique room layout.
Currently, I have the AI for 5 robot masters done (excluding their weapon AI). The two remaining other than Metalman should be a cinch as their AI is originally designed to handle rooms with no flat floors and such. In other news, I had a request about how I was able to make the music/sfx for the game, so I will also work on a tutorial about that. It won’t be a tutorial about how to make MML scripts, but more about what instruments are used to produce the 8-bit audio.
Sorry for the gap in updates. After dealing with the HDD crash mention in my last post, it became apparent that I was in need of upgrading my computer. So, I did quite a bit of researching as to what I could use/need, and with money saved up (along with my tax return), I purchased items and built a new computer. This dug into my time that I usually spend with this project, but I have done some work nonetheless. No more “terminal” interface appearance. Now the menu system has been implemented for going from one part the program to another. With that, extras have been included, such as the Audio Player and even the Credits. Using methods meant for the menus, I am also incorporating them into the editor so the method of displaying information doesn’t look so plain.
The robot master AI has been put on hold for the moment because I have to decide how I am to deal with them in custom rooms, much in the same way I had to alter/add AI routines for some enemies because they can be placed anywhere that are not normally allowed in the original game.
Had the unfortunate incident of my desktop going out because the main drive stopped working. Thankfully, I had long since used DropBox to store all data and backup versions of my work, so nothing regarding this project has been lost. I can’t say the same for some of my own stuff like pictures and some documents. Drive won’t rev-up during the boot sequence, and so doesn’t get recognized by the system at all. Had someone tell me to try a “freezer-fix” because it might be the grease inside has become tar-ish, but I gotta find some silica gel first (packets usually placed with clothing, shoes, and electronics to absorb moisture). So, there’s a chance of at least getting the drive to run long enough to get some important things, but its general use is over. I’m currently using my laptop for everything now and not just for on-the-go.
As for the project, I’m working on the 8 robot masters right now. Haven’t gotten to the individual AI yet, but the general execution across all of the masters is about done, such as engagement, general hitboxes and responses, exploding and “level cleared” execution. I’m designing them to be usable in the editor (with some restrictions, of course). Some of the restrictions are as follows, to which a robot master will not appear if:
- The sublevel they are placed in is longer than 1 screen segment.
- Another robot master is already designated in the room.
They won’t necessarily be what ends the level, so technically, you could link 8 rooms together, and fight each of them sequentially. Transitions from room to room will be disabled during a boss fight, but will become enabled once they are dead.
Sorry for the lack of updates. Been going against a bunch of hurdles with the program, but most have been dealt with. As of right now, all enemies and sub-bosses have been completed with their AI improved and adjusted. Dealing with the sub-bosses was a bit of a chore because they didn’t deal with just sprites, but also messed with the background as part of their visuals. Also, because of being able to place them anywhere with the editor, I also had to make numerous code adjustments (to prevent overlapping) as well as numerous palette execution changes with regard to them because of how they may use palette animations (so by doing a palette animation to one, it would have affected all others of the same type in visual range).
I’ve also been refining the code that deals with transition data (that allows moving from one sub level to the next) as I added gate placements. This did cause me to require changing map collision data so now, there will be a 1 tile invisible wall on either side. While this makes Megaman react correctly like the original did in this instance, it will affect how enemies will react to this wall, which are supposed to act differently. Shouldn’t cause much of a problem though. The transitions can either be activated by touching any open portion of the sides, or just one open portion. The gates can be placed on any open section on the left/right sides. The original game does not have gates leading up/down, but I wouldn’t cross that off the list just yet. It won’t be a focus atm.
Before I begin work on the bosses, I will be going through a stabilization session, to ensure that what can be created with the editor would not result in errors that stops the program.
I’ve been sick for the past couple of days, so I’ll make this brief. Been working on numerous things, most involving the remaining regular entity/enemy AI, so the blocks that phase in and out, lazer beams and even lighting changes in Quickman’s stage are all functioning (the lighting, however, restricted to that stage). I have yet to begin AI work on the sub-bosses and regular bosses. Also found numerous bugs in the editor which began to pop up when I began working on the Entity subcategory.
A curve ball comes your way that you weren’t expecting……well, for most. Yes, your computer screen (or other display device) is not screwing with you. This is indeed an editor designed to make Megaman 2 levels, and it is the 2nd main feature of this project with will be built-in. I held off on saying anything for a while because I wanted to have something presentable and in a fashion that it wouldn’t be complicated for anyone to make levels using it, not to mention that it’s been almost a year since the first demo, so it was like an anniversary gift. This was indeed used for making the 3 levels of the last demo, with the exception of enemy/entity placement (that is currently in the works).
This will be in the final version of the game, but unfortunately, any demo releases from here on out will unlikely have it included. This is because I’m working on it alongside the game engine, and anything can change between releases. Anyone that were to make levels in older versions might find themselves unable to use those levels with newer versions. The video below shows a quick example of using it, though quality isn’t exactly the greatest. It also shows the sub weapons.
- Air Shooter
- Crash Bomber
- Time Stopper
- Quick Bommerang
- Metal Blade
- Bubble Lead
- Atomic Fire
- Leaf Shield
I’ve been spending the past little while handling Megaman’s sub weapons, and with the exception of a few tweaks and a couple missing effects, they are all fully operational, including charging up and releasing Atomic Fire (which wasn’t as hard than I thought). The next thing on my list are the Item weapons (1, 2, 3) and platform rails (from Crashman and Wily Castle 4 stages) as they share a commonality of needing to interact with Megaman far more than anything else so far.
Alright, it’s been over 2 weeks since I released v0.2 of this project, and I got back from my vacation this past Saturday. Tired and sore from a week-long camping trip in a little place called Patricks Point, off the coast of northern California. It’s a beautiful place where you just relax, or go adventuring as you trek to different amenities. There’s a few other places around that area, like Fern Canyon, which have become tradition to go to with my family.
Anyways, even though I am back, I have family from Idaho and Indiana visiting for the week, so my plans to get back into MM2′s development are going to have to wait a little longer. But, I was able to make a few changes before I left for vacation which will be available in v0.3, whenever that comes out. Those changes include no insta-death to spikes when in the invulnerable phase after getting hit, the Battons behaving more appropriately, and something else that I can’t remember now.
Fun Fact: Many people don’t know this (and I didn’t know until last year), but Patrick’s Point was one of the places where they filmed scenes for The Lost World: Jurassic Park, particularly the basecamp/cliff scenes and when the Gatherers watched the inGen Round-Up. The picture above showing “Wedding Rock” can be seen in The Lost World during the inGen fly-in. The area they are standing on is actually a parking lot they had to fill in with dirt.
Fern Canyon, as mentioned earlier, was also used for The Lost World, where Stark is killed by Compys.