X Engine

Editor UI Changes

2012-01-25T18:43:00.000-05:00

Hey there everyone. This weekend I finished off the changes to the latest build of the X Engine, so if you're a tester and haven't noticed it yet, go check it out.

I've yet to release the complimentary editor build, as I'm still working on it, mainly ensuring that everything is usable. I've done some very small changes to the user interface to help with that.

For a comparison, check out my older post here.

A few weeks ago, back in the far away year of 2011, I showed the interface for editing stage music. Since then, I've done a little placement changes here and there. As I was working on it, I realized that some buttons were either redundant or completely unnecessary. It isn't that much different as the overall idea is still the same. Regardless I think this version is bit more aesthetically pleasing.

The other thing I changed was the UI for loading levels. It previously used a very standard file selector but there were two problems with that. The first being that you could select a level from any place on your hard drive. That might sound like a good thing, but the issue there is that the engine requires level be in a certain folder in order for it to read and load information correctly. So loading from anywhere other than the required folder would be pointless. The second problem was that even if it was in the correct folder, you could potentially load files that were not even made for the X Engine (if one were silly enough to rename files or something). Not a common problem, but still there.

This new level selector checks all levels in the required folder and ensure that each one is genuine and compatible with both the engine and editor. On top of that, it organizes it so that you can clearly indicate which levels will appear on the Stage Select screen on the engine, and which level can be played standalone as well as give some basic info like map size and object count.

Before I can finish off this build of the editor, I need to ensure that the process for importing animated backgrounds is clean and functional. If all goes smoothly (and it almost never does), then this will be the last major changes I make before I get to work on the demo. So that's good news for everyone.

I hope that was somewhat interesting. As always, please leave any comments you have below. If you like what you see, please subscribe and follow to this blog.

Until next time everyone!

Progress Report

2012-01-15T03:45:00.002-05:00

Greetings all! How has the new year been treating ya? Apologies for being absent for the last few weeks, I've been extremely busy. Small post this time around but I feel I should share what little tidbits I can.

I could not focus all my attention to the engine for the last couple weeks, so things are a bit off schedule (granted that schedule was very rough to begin with). The background system at this point of posting is still a tad incomplete. The engine seems to be having trouble importing images with any kind of transparency. I've yet to figure out the reason for this so it's been extremely troubling.

This was to be my final addition before I release Build 038 to testers, and it's mandatory that I fix this for the X Engine to be even remotely usable. I'll need to experiment with other alternatives, but if I can't get it to work, I'll have to postpone background support until Build 039.

On top of that, I didn't get around to fixing all the bugs found in the previous build so that workload has been piling up. Depending on how quickly I fix the background system, I may have to postpone this til Build 039 too.

All this might not seem important to you if you're not a tester, but it directly affects how long until the demo is released. Build 038 was to be my last revision and then all attention would be focused on bringing a playable demo to the rest of you guys. I simply can't release it if important aspects are still broken.

Anyway, quick messages to folks. If you're a tester, the next build should be up sometime between now and two weeks. If you're a spriter or musician for me, I'm going to need those assets I requested as soon as possible, since crunch time is nearing. And to everyone else, if you want to get your hands on the playable build, please keep your eyes open. I'll try to keep everyone posted on the current situation.

Background and Music Options

2011-12-23T08:47:00.000-05:00

It's been a very slow month for me thus far. I had planned to implement atleast one of these by the beginning of week, but I unfortunately got through neither. Regardless, I will still discuss what I have planned so far. Since these two things have not been fully implemented, the images posted are only mockups. However they do fully show what the final implementation will generally look like.

First thing is backgrounds. While backgrounds are present in almost every single game in existence, you'd but surprise how incredibly complex they could be. There are numerous amount of factors (that I won't go into) you have to take into account when placing a background. As such, adding backgrounds directly inside of a level editor is a brain busting process, even from a user point of view.

In the editor, you're allowed to upload any image from your PC to be used as a background. While there is currently no limit on dimensions or file size of an image, I've limited the amount of backgrounds you can use in a single stage to 5. Theres several reasons for that. When it comes to distributing levels, backgrounds will almost always the largest file size. It's best to keep the images small, and the amount of frames low. If a user were to stockpile backgrounds into a single level, load times would be catastrophic. I feel that 5 is a good limit for now; I personally don't think anyone would need that many different BGs.

There will also be parameter functions for backgrounds. The details I'm still a bit fuzzy on, but I know there will be four types of scrolling: Static, Auto-Scrolling, Parallax, and Auto-Scroll Parallax. Static and Parallax are simple enough to implement, but auto-scroll is a different beast. Dimensions have to be taken into account, so auto-scroll needs an additional algorithm to increase the width of an image to ensure that everything flows smoothly. I've yet to attempt this, so I'm not even sure if this is fully possible yet, but the idea is there.

Custom music support has already been implemented into the latest build of the engine (Huge thanks to Azu for helping me out with that) but the UI for actually adding and configuring those tracks were missing. I will be adding those options into the editor. There's not much to discuss regarding this, the concept is incredibly simple. After uploading a song of your choice, you're able to designate the introduction and main portions of the track. The main portion is the only part that will loop.

Unfortunately, the engine will only support OGG and WAV formats. It's possible for me to implement other formats, but it would require workarounds of MMF2 that I'm not willing to do. On top of that, this would keep file size smaller than say an MP3 would, so it works out for the better in the end.

Things are progressing at a snail pace right now. I can only hope that the New Year will be better to me. Thanks for reading, please post any comments or suggestions you have below. If you're interested in this project and haven't already, please be sure to both follow and subscribe to this blog. Thanks again, Happy Holidays and Happy New Year everyone! =D

Object Parameters

2011-12-14T15:44:00.003-05:00

Hello again everyone. I finally got my Internet back, so I should be picking back up on things. Then again, finals are starting and I've been really focused on that.

Anyway, Parameters are something I brought up in a previous post. Unfortunately there weren't working exactly as intended it, so I ended up removing it from the first build of the level editor. It's been reworked and seems to be working correctly now. Even though I briefly talked about it before, I want to go into greater detail of how important parameters are.

First, I need to describe how Multimedia Fusion 2 would normally handle a procedure like this. Creating a single object in MMF2 is simple enough, and copying that same object through out places on the map is also simple. The problem comes when you need to differentiate the two. Alterable Values for an object can be changed for an object before runtime, but it will apply to all similar objects. If I had three moving platforms moving at 1 pixel per frame, and I wanted to change the middle platform to 3 pixels per frame, MMF2 would end up changing all of them. The only way around this would be to hard code events and manually instance them using spread values. If you've used MMF2 before, this might be familiar to you. For the images below, imagine that the length of the arrows represent the speed the platform will move at.

Changing value 'Y Speed' of middle platform in MMF2, changes every similar platform in the level.

The level editor itself is still made in MMF2, but it uses a more easy workaround. Objects aren't created until runtime, and every single individual object will have a unique sets of parameters. By creating those same three platforms in the editor, even if they happen to be moving at the same speed, they are actually still different from one another. As such, using the same example from before, changing the middle platform to move at 3 pixels per frame would be incredibly simple.

Changing 'Y Speed' using Parameter feature, only effects selected object, keeping every platform unique.

As of now, I've only implemented basic parameter functions, but now that the basework is complete, it's possible for me to add in more advanced things. Some examples would be script objects to instantly change the weather effects in a level, or adding auto-scrolling with variable speeds. Right now, I opted not to do any parameter functions for enemies, as I'm planning on working out a custom scripting system for them and bosses, so you can create your own. There's no actual... plan... yet. But I'm thinking about it.

Thanks for checking in. Feel free to post below if you have any comments, suggestions, or criticism for me. I'm open to everything. I'll be working on the background and music systems on the weekend, and I hope to finish atleast one of them by next week. If so, that'll be the topic of next post. Until then, take care.

Unfortunate Hold Ups

2011-11-28T23:54:00.001-05:00

How was everyone's Thanksgiving last week? Nommin' down those avians!

This post is going to be mostly short and personal. Just a bit of warning if you really don't care.

I've already mentioned before things might be going a bit slow while testing is still ongoing. But seems it might go even slower than I expected for personal reasons. Money has been a real issue for me and my family and we lost our phone and internet connection last Wednesday and nearly lost the entire apartment. I wouldn't really mind having no internet, if it didn't inhibit my work. See, I generally spend most of my time in school, that's where I do all my work, either through remote desktop (if available) or Logmein. Of course, with no connection on my desktop, those are impossible to do. As such, there hasn't been much done on the engine, and it will unfortunately stay that way for about 1.5 - 2 weeks. I can only really sit down and work on the weekends, but even then I can only do so much.

Anyway, that's enough of that. Bug fixing is really the only thing I'm focused on at the moment. I'm quite happy with the results of the testing, there's been around 30 or so bug reports so far, the amount I expected. I only got about 10 of them fixed, but I'll keep working on it of course.

Unfortunately that's about all I have to report for this week. Depending on how my situation goes, I may or may not do a post next week.

For the regulars here, a bit of a survey. I'm wondering, how many of you here are planning to use the X Engine for your own personal projects? If so and if you don't mind sharing, what kind of ideas are you planning?

Tiny Updates

2011-11-22T09:55:00.001-05:00

First off, big thanks to the lot of you who applied for testing. Though I didn't get quite as many people as I hoped for, many of you are doing a great job with picking out issues. I hope everyone will continue at this speed. I'm sure many of you can see that while things look nice on the outside, things are not quite sugar and rainbows on the inside. That's alright for now, the sooner these issues are spot out, the quicker they can be repaired. So thanks again in that regard.

Okay, that's taken care of. Now for the updates.

I spent majority of the week doing minor tweaks for the editor. One of the main issues with it was that the descriptions for all the objects (among other things) were missing. I originally opted not to add them since I really wanted testing to be done, so it would take up too much time. Thinking about it in retrospect, it might be a tad harder to test if you don't know the purpose or usage of some objects. Regardless, the descriptions are in now, so things should be a bit easier to manage.

One other thing I added to the editor was a minimap. I had originally reserved space on the tile edit screen for a minimap, but I realized the reserved space would be too small on larger maps. So my alternative was to make a MM Powered Up style minimap, where each sector node is lit when you place a tile there. I ended up putting it in the upper-left, over the main window, but so far it's been far less intrusive than I thought it would be.


It may look like a mess of nothing now, but it's actually pretty helpful.

The light grey nodes represent the play area, blue nodes are checkpoints, and the purple node is the boss room. I don't have any other ideas for colored nodes, and I don't want to make it look like a messy rainbow either, so I guess this will suffice for now. Though if you have suggestions, feel free to share them.

The final thing I worked on this week was the lifebar. I had made the life maximum 32, like in the original X games. But someone requested that I increase the maximum and have layered lifebars ala Mega Man Zero. So I did just that, and increased the max health to 96, three times the original. Honestly, in a Mega Man X game, where you're constantly increasing your health, defense, and repertoire of attacks, I can't see why'd you need that much health, but regardless the option is there now and more options are better, right?
... right?

I'll have to tweak the actual colors of the bars a bit to fit with MMX palette, but the base work is done.

Thanks for checking in. As always, if you have any comments, suggestions, or criticism, feel free post it below. If you're interested in this project, be sure follow and subscribe to this blog. Thanks again, take care.

Call for more testers!

2011-11-15T09:16:00.001-05:00

I thought the testing phase would go by pretty quickly, but I seem to have lost contact with majority of my testers. So I want to pick up some new blood. If you're interested please contact me either by email located on my Blogger profile or on my YouTube account.

Keep in mind, I'm looking for folks that will thoroughly test for issues, and not just play for fun. If you know you can't do that, please don't bother. I only need a small handful, so not everyone will be accepted.

Good ol' Egoraptor

2011-11-10T11:59:00.000-05:00

Something I forgot to post yesterday for some reason. Most of us have probably seen it already but if you haven't, Egoraptor recently did another episode of his 'Sequelitis' series with Classic Mega Man and Mega Man X. It's quite hilarious and entertaining as well shed some light on very basic game design.

There is a lot of language in this, so if you're a baby and get offended easily, I would avoid it. If not, you can check the video after the break.

Where yo demo at?

2011-11-09T13:22:00.003-05:00

This will be a short post, but let me get some things out of the way first.

First off, I apologize for posting this so late into the week. I got into a bit of trouble recently and I really wasn't in the mood to do anything.

Secondly, something I neglected to bring up on my last post for some reason; I thank everybody that contacted me both about the spriting job and just motivational e-mails. I really only expected 1 or 2 people to message me about the job, but I somehow got double that. Thanks again guys, you're all my property now =).

Third, if you are a tester, Build 037 will be uploaded within the next few days. If there's any confusion regarding anything please let me know.

And finally, another apology...

On multiple occasions I've promised a playable demo and fell short every single time. I continuously underestimate the amount of time I need to make any progress. Which is weird, considering how long I've been working on this, you'd think I'd know how much time I need. There was also that long very problematic period of time. If you're one of my testers, you know what I'm talking about. The demo will come, definitely, but I can't say when. I really want to give an estimate date but my second most hated thing to do is breaking promises (The first is quitting), so I won't do that. But when it's ready I will definitely say.


The beginning portion of demo level I started that's about a year and a half old now. The final demo level may or may not look the same way but the theme will be the same for the most part.

The engine will be going through a bit more testing, and once all the major bugs are worked out, I will be focusing all my attention to only releasing the demo. That means I won't be adding anything new to the engine for quite sometime, so the posts here will likely get very lackluster. I'm debating if I should post any progress of the demo during that time. I actually kind of want it to be a surprise for when I drop it.

If you have any questions or suggestions regarding anything, feel free to post it below.
Take care for now. Thanks for reading.

Level Performance

2011-10-31T23:07:00.001-04:00

Greetings all,

I took quite a bit of a break, but now it's time to get back into it. I've been stressing a lot with school lately, so I haven't gotten as much as I wanted done (Ya, more excuses) but I'll get there eventually.

I've been tweaking the way the engine reads/runs levels created with the editor and I believe I've come up with a suitable execution. There won't be any pretty pictures this time since it's difficult to convey, but I'll try to explain what's going on the best that I can.

First up, keep in mind that although I'm interested in game design, I'm not very familiar with the terminology, so if I say anything wrong, please feel free to correct me.

Creating a level editor and saving each tile into a single file, while time consuming, is simple enough. But there is multiple ways one could go about reading and implementing this file. One way to do it would be to render the entire level as soon as it starts. This is similar to way MMF2 does it by default. One would think this is the best solution, but it's really not. The first issue would be heavily increased load times. While it would greatly depend on the size of the level itself, having to check each position for an existing tile is incredibly cumbersome. The next thought might be to only check positions that you know have a tile there, but that would mean having to make a completely different kind of file. And once it again, the size of the level would matter. Even if you did decide to use one of these two methods, there arises another issue. The size of the screen is only 256x224, but 99% of the time the level is going to be much larger than that. And so, you have active tiles/objects in unnecessary places which will bring down the overall performance.

So the next obvious choice is to only load parts of the level at once. Again, there's multiple ways to approach this but I'll explain my solution. Instead of loading the entire level, the very first thing it does is load the area around your starting position. This is a very small area so load time will not be an issue here. From there, tiles will on spawn/render in the direction that you're moving, and previously rendered tiles that are now off-screen will be deleted. This method is more consistent as the size of the level doesn't matter at all and also helps reduce memory usage. This is not original at all, many tile based games use this or a similar method, especially noticeable in NES games.

On some very basic tests, the peak frame rate on my machine with the old coding was 87 FPS. Using this new method, the peak was 370 FPS. Of course this will vary on different computers but the results overall are clear. There are still tweaks I need to do in other areas though so I can make it more constant.

That's all I got for now. I apologize for the lengthy and likely boring post this week. It'll be nothing but tweaks and bugfixes for quite awhile, but once that's all taken care of I'll be able to give you all something playable =). As always, if you have any questions and/or suggestions feel free to post a comment. If you're interested in this project I encourage that you to follow this blog. Thanks for reading.

Rewritting Tile Bytes

2011-10-18T16:39:00.000-04:00

For the most part, I mainly focused this week on bug fixing. There's still a lot I need to take care of but I'm hoping to get most of them out of the way by the end of the week. But that's not anything interesting to discuss so I'll skip that.

One of the other things I tried to add was background tiling through objects. It might be a bit difficult to explain what that is, but I'll try.

Using Mega Man X as an example, in the introduction level, there are points where the ground breaks apart beneath your feet. When that happens, the tile byte that was previously there is overwritten, and a new tile goes in it's place. It really serves no gameplay purpose, but it makes the background look a lot more dynamic. Of course, rewriting bytes at runtime is not something you can do from the editor itself, so I gave a few objects the feature to leave specified tiles on activation.

Click for larger image. Just tiny examples of what this is used for.

So far, that works just fine, but it requires that you reserve space on the limited tile sheet, which may potentially cause problems later. The obvious solution is to just increase amount of tiles you can have, but that'll increase both save and load times, something I want to avoid. I'll likely just leave it as is for now.

A short post, but that's all I got for now. I've been a bit sick lately, so I don't think I'll be doing or posting anything next week. Though before I end this, I want to request that if anyone is pretty good at spriting and willing to help out with this project, please contact me. As always, if you have any comments or criticism, please feel free to post.

Value Changing

2011-10-10T05:58:00.000-04:00

Pretty sure that I said this recently, but I'm trying to allow the user to do as much as possible without having to rely on MMF2. One way I thought to improve that was to allow for complete value and physics changes straight from the engine itself.

So in the pause menu, I implemented a secondary menu that gives you the ability to that. Of course, as of now it's extremely limited but overtime it should get better. Obvious things are there like gravity and movement speed, but I'm going to add some fairly unique ones eventually. One idea I had was to be able to set the charged buster to X1, X2, or X3 style. You can also modify armor abilities with this, but again, it's really limited.

To lower any confusion, any default values will be in blue. Any changed value will be in white. As of now, you have to change values everytime you restart the engine, but I plan to make it so that it can be saved as a default for that level.

From a general point of view, this might seem a bit useless. And if you're just here to play it, then it is. But let me give random two examples of why something like this could be useful. Let's say you wanted to make an.. err.. space themed level. And you wanted to make the gravity there lower than the other stages. This would be the easy way to do that. Another, more probably example would be if you wanted to build a similar but different engine entirely, like a 32-bit X Engine. Though honestly, as it is now, it's not possible to do that, but eventually, yeah.

Other than that, I've been trying to work on optimizing the lasers I mentioned in my "Changes in Build 036: Part 2". Although I referred to them as "Quickman" lasers, they're more like X5's. I redid them from scratch and they are a tiny tad better, but not by much. The thing is, in Mega Man 2, the lasers are only active per screen, and deactivate when you enter the next one. But due to the scrolling nature of Mega Man X, that's not likely. I could be just thinking too hard on it, I'll give it a break for now and come back to it later.

That's pretty much all I did for this week. I picked up Dark Souls over the weekend and I'm getting addicted to it, so I have no idea how much work I'm going to get done on this... >.<

Changes in Build 036: Part 3 (Final)

2011-10-04T11:45:00.002-04:00

Sorry this is a few days late, I had a very busy weekend. I'll try not to make a habit of it.

So anyway, we have our damage system in place with a handful of enemies and stage obstacles to enhance gameplay in each level. But now we need an actual level. So I'll talk about one of the more important features I've been working on: the level editor.

My overall goal for the last year or so was to improve overall usability for the engine and to ensure that I can make what I could as simple to use as possible. Working with Multimedia Fusion, you come to the quick realization that it is not suited for quickly creating levels from scratch. That and the fact MMF2 does an extremely poor job of internally rendering levels. Of course, the obvious solution was to work around that.

The editor works uses a tile sheet that is 128x768 in size and separates each tile into bytes. As the level is built, it is kept and saved into an array to be easily read by the engine itself. Any objects placed in the level can have several preset parameters altered directly from the editor. If you don't understand what I mean by "parameter" let me say this way. Say for example, you had three identical elevators. If needed, you could have all of them moving at completely different speeds from one another, even though they are actually the same object. As basic as that sounds, this is something MMF2 cannot do without either creating a new object entirely or doing some kind of runtime editting. This is actually nothing ground-breaking, majority of simple level editors work the same way.

When I started this, I tried for a more "Standard Windows" design. I'm not sure why, but the few people I showed it to had a difficult time finding where things were or how they worked. So I opted to completely redesign it and use a GUI made completely from scratch, which for some reason helped folks see/locate things better (which is odd, since everything was laid out the exact same way as in the Windows GUI. >_>). Personally, I think it's a bit ugly looking, but it works for the moment. Cosmetics always come last in my book.

These are not full levels, but demonstration mockups made using the level editor.

Something I'll point out now that I know I'll get asked about. This is just a level editor. As of now, this does not do anything other than that. It's not an enemy AI editor or weapon creator or anything of that sort. I really want to be able to do something to that extent, and it seems very well possible. But at the moment, I don't have enough knowledge of the subject to be able to effectively do anything like that. And even if I did, it would be an even harder task to make it simple to newbies without losing efficiency. If this is something you're informed on, please by all means, enlighten me.

As of now the editor is still primitive and basic. I drew a lot of inspiration for Mega Man Powered Up's editor and at some point I hope to reach a simplicity of that level. But I'll continue to try improve the editor, alongside the X Engine itself.

That pretty much concludes this post. As always, if you have any questions feel to post it below and I'll get back to you as soon as I can. If you're interested in this project, I highly encourage that you follow this blog and let others know about it. Thanks for reading (or skipping and just looking at the pictures, but whatever), next week and onward will be more "blog-like," as I'll briefly discuss what I'm currently working on, and the progress of it.

Changes in Build 036: Part 2

2011-09-24T15:03:00.000-04:00

Hey folks, back again. Keeping this one really short, so let's roll into it.

This time I'll talk about implemented level features and gimmicks.

As I've likely mentioned before in a YouTube comment or two, I'm trying to implement as much foundation as I can for building a Mega Man X fan game. X games are divided into stages, and as obvious as this is, enemies are not the only obstacle you must past. Sometimes you have to battle against the stage itself.

At the time of my last video, there was only about 6 level gimmicks implemented in the engine. Currently, that number has risen to 25 including classic nightmares such as Yoku Blocks and Quickman Lasers. All of these can be easily placed and altered in any real level. Unfortunately, there's nothing much else I can say on the subject. Words and screenshots can only convey so much, so most of these I'll show in a video when I get around to doing that.

Not everything is fine and dandy unfortunately. I've admittedly been having some issues with the Mine Carts and Quickman Lasers. The carts require a lot of position checks that really bogs down the computer. Having two carts moving at once is pretty much impossible at this point. I've thought of using sensors as a replacement, but that overcomplicates things and makes level building that much harder. The lasers also gives performance problems when theres a lot of them active at once.

I haven't spent as much time as I wanted to trying to fix those issues yet, so I can't say if they're permanent or not for now. They still work properly when used sparingly, so that's enough for me right now. I have other things I want to focus on before I try tackling those problems.

Anyway, that's pretty much it for now. Sometime next week, I'll do one final post on the changes in Build 036. Take care til then.

Changes in Build 036: Part 1

2011-09-18T12:31:00.001-04:00

Before I start posting about my current progress, I need to show some of the important changes done to the engine in the last 15 months. I won't cover everything, as some of it honestly isn't too interesting but I'll be sure to hit get important points. Not sure how many parts I'll be splitting this into yet.

Due to the numerous bugs and laziness on my part, this is stuff even most of my testers do not know about. So let's get it started. This is going to be long, so gear up.

First, I'm gonna talk about the changes to the damage system.

Previously, all damage values were held in each specific bullet object which would subtract from an enemies' health on contact. That worked fine at first, but there's two major problems with that.

One: Changing the damage value requires that you use Multimedia Fusion 2. Something not everyone has access to.

Two: It's incredibly cumbersome to change values during actual gameplay. If I wanted to lower the damage values for a boss, I'd have to do so for each and every boss bullet object and with every single boss. Trying to add weapon weaknesses is even worse.

Fortunately, the solution to this is simple. Values for all weapons are held in an XML spreadsheet, externally from MMF2. It's easy to change anything you need to and accessible for anyone. It also allows me to easily add or change any weapon weaknesses a boss may have.


For example, Boss 3 has a clear weakness to charged shots in this case.

I still need to tweak the coding a bit. As it is now, the engine needs to read the external XML every time you fire a shot. I've yet to run into any issues with this method, but it can potentially cause some performance issues.

On top of this, I've also made tweaks to the actual values the X Buster uses for damage. To understand the reason for this, I have to explain how the original games (X1-X3) uses it's values.

Prior, the engine was using X1's values. In Mega Man X1, the value for the buster was 1:2:4 (not including upgraded buster), but some enemies had what I'd like to call a "damage resistance" set into them. On most enemies, a charged shot would do 4 units of damage, but an enemy like Dig Labour/Degraver it would do 5 units of damage, and on a Mole Borer, 3 units. This forces me to have to hard-code resistances into certain enemies, something I really dislike doing. In previous builds of the X Engine, Dig Labour was the only enemy to have damage resistance.

X2/X3 uses a completely different set of damage values for the buster (3:5:8). Because of the gaps in damage, it require less need for resistance change. In X2/X3, there are very few enemies (if any at all) who have damage resistances. However, because of the difference in values, all enemies in the X Engine needed to have health adjustments to fit the system. Below is a list are all the implemented enemies and their previous and current health values.

Ray Trap and Rolling Gabyoall are invincible enemies.

It's a much cleaner way of doing things honestly.

That's pretty much it for this part. A bit technical I know, but hopefully I've shed some light on how things work in the engine. If you have any questions feel free to post a comment. I'll be back soon with another post, take care!

Let's start this up!

2011-09-17T23:54:00.001-04:00

Greetings all!

I realize it's been a long time since theres been any new information on this engine. The last video was already over a year ago... wow, time flies. I've been wanting to get a new video up for awhile now, but I don't have as much time as I used to anymore unfortunately. Of course, that also means I can't work on the X Engine as much as I want to either. Now, don't take that the wrong way. I've still been working on it as much as I can and it's still progressing very nicely.

So what's the point of this blog anyway? Why is it here?
As much as I know people would like actual video footage (or even better, actual hands-on), it's so much easier and convenient for me to discuss what I've actually done. I would need to spend a lot of time at home in order to get a video out, but a blog is something I can do wherever, I don't even need a computer in front of me. At the same time, you folks will get more info on the engine at a faster pace than waiting for me to post a new video.

Now, I'm not saying there's not going to be anymore videos. I realize text and images can only convey so much. But just give me some more time on that regard, it takes a lot of time really. As always, I'm open to comments and suggestions on how I can make this better. I'll try to get something out atleast once a week.

Hopefully this wasn't tl;dr... If you're interested in this project, I'd appreciate if you would could follow this blog and especially leave a comment. :)