View Full Version : EXE3 Engine
Here is my partially functional engine, with which I seek to recreate the engine of Battle Network 3, my favorite game in the series.
The engine is fully customiseable, and is programmed in Java, meaning you'll have to download that to run the executable. Current version has no source code attached, but all sprites and config files are yours to mess around with.
Noteable features:
-Event scripting system allowing you to handle npc movement, cutscenes, portals, and chat dialogues.
-Config-file driven engine allows you to add/customise any element you wish, though at the moment the implemented elements are rather scarce. You can easily change your player sprite, add npcs, portals, and maps.
-Supports audio, preferably vorbis.
Coming Soon:
-Multiple maps
-Multi-level maps
-Menues, such as the pause menu
-Subchips, chips, key items, etc
-Save system
Later:
-Battle system
-Netplay (possibly)
Newest version:
http://www.mediafire.com/?bnl33j03f1xieg5
Well, i wanted to test it out, but i cant get it to work...
I run the command line and write
"java.exe <path>drawboard.class", but i get an error, and cant get it to execute...
And i do have java installed...
Well, haru :D, it worked fine on my computer, using textpad; I don't like doing commandline stuff. You could try recompiling the .java file and/or post the error.
So far all the engines I've seen here are either just a video or grid based... or nothing like battle network. I'm going for an accurate engine. As such I've defined animated backgrounds (which will tile seamlessly no matter the window size).
Glad to hear you watch Katekyou Hitman Reborn! as well!!!:D
I searched a little, and finally found a way to execute the game, so, for anyone wondering how to do it, here goes:
1. Unzip the 7z file into a folder
2. Open the command line
3. Go to the folder where the DrawBoard.class file is (folder you unzipped)
4. Write "java DrawBoard" (remember, the DrawBoard IS case sensitive)
5. Be happy!!!
NOTE: You must have jre to play the game!!!
Now, i see you pretty much just started, but it could become something cool!
However, you need to work seriouslyon it, and remeber, i think the most important part of the game/engine, is the battles, so work a lot on that too.
I'll be waiting for updates, and good luck!!!
Well, the main thing I'm focusing on now is the rpg aspect, because I'd like the engine to be adaptable to other things as well. Otherwise I might have done battles first. Battles are in some ways easier to deal with.
Still, as a start, it seems better to me than some of the others I've seen here :D.
(I actually stopped watching reborn once they started dragging things out in the future. May continue once they finish the future arc.)
Sprite class is being problematic as I try to implement a portal sprite. Don't know how I can have an array index out of bounds when that's what the line is checking...
After finding someone else interested, progress is once more being made. The current version of the game isn't too much further ahead from the user's perspective, but we've fixed most of the problems with the sprite class, as well as starting to think about pathabillity some more.
http://gamekit.co.nz/forums/download/file.php?id=17&sid=159b4f9a00dcb1b54d49344096073196 is the current version of the engine. Got exams this week, so not sure how much progress will be made during that time, but probably some.
GameDragon
25-04-10, 01:32
Just ran it. It's extremely early work. You still have a lot of work to do.
Keep it up though.
Yeah; but I'm rather enjoying it. It's the first thing I've really tried programming on my own, not as part of an assignment. I fully intent to finish it, and to post its status here occasionally.
Also, recently fixed the problem with the portal not displaying; was my pure stupidity really. Now I need to come up with a way to deal with layers/elevation.
Glad your making progress, but the download link is down ( it says the attachment no longer exists)
Yeah, not surprising. The original thread was deleted. I'll update it when I have an update you'll be able to see. Meanwhile, I've been cutting up megaman sprites from here (http://www.sprites-inc.co.uk/files/EXE/Megaman/OverworldEXE123/), and have noticed that they aren't even slightly aligned, making photoshop and any other tile-splitting software completely useless for the job.
I can do it. It's just about 5x the effort it ought to be.
mega rock.exe
01-05-10, 00:10
I can do it. The sprite exporter exports them at the correct level.
That'd be wonderful. Most of the exe 3 stuff seems fine, luckily.
Really, it'd be nice if all the sprites on the page were aligned, so they could be easily sliced. The whole exe 3 section has everything aligned relative to the sprites on their line and centered.
mega rock.exe
05-05-10, 04:58
Do you need anything specifically?
Megaman's overworld sprites mostly. And maybe a normalnavi, though the current one seems aligned fine.
Other members don't like that the sprites are so low-res, so in the future I may double-size and detail them, but since our priority is the engine rather than making a whole game, that might not happen.
(Basically, our goal is a megaman-specific rpg-maker, which can be adapted to anything else)
mega rock.exe
06-05-10, 04:48
Here are the sprites you wanted. Every line is a new animation. If it's set up correctly, a fully-operable overworld engine should be possible.
http://i55.photobucket.com/albums/g144/mega_rock_exe/megaman_exe3_overworld.png
http://i55.photobucket.com/albums/g144/mega_rock_exe/exe3_normal_navi.png
http://i55.photobucket.com/albums/g144/mega_rock_exe/exe3_normal_navi3.png
It also seems like there are a lot of Normal Navi sprites that haven't been ripped. Also, because they have double data, I could only correctly rip the purple one, but the green one is there, too.
Now the way the game uses these sprites is based on the line. The first line is facing north. it continues in a clockwise direction. The line after the sprite facing north-west starts the walking directions. Starting with north and ending at north-west. Then it begins running animations which are the same frames, but faster (except with Lan)
Perfect! This exactly what I needed. Java can handle transparency, so I'll have to get rid of the black, but that's really easy.
Still some problems slicing the sheets, since the rows aren't aligned, which means my cuts will all have to be different widths. Not sure whether that's more work for you or me.
Well, the pathing system works now, with the overworld at least. Once we implement an npc, we'll get collision with them working. Took a bit of effort to get megaman to slide along walls correctly, but brutalbarbarian got that working, as well as the paint system, which means that everything will be drawn in the correct order. All in all, progress is being made.
Next we're working on the threading system, since I did it really badly at first, making it take up one whole core of any cpu it's run on. Once that's finished, the engine will run much more efficiently. Once the new sprites are cut and inserted, I'll upload a new version of the engine.
Threading now works. I'll start cutting up a normalnavi tomorrow.
mega rock.exe
16-05-10, 01:40
Wait. Are you still okay with the way the sheets were exported? I have two other types you might want to consider.
Both of these have each frame equally spaced.
This one is better suited for game developing, I think.
http://i55.photobucket.com/albums/g144/mega_rock_exe/mmexe3overworld2FC312AC59W96H138.png
This one works the same as the one I described before.
http://i55.photobucket.com/albums/g144/mega_rock_exe/mmexe3overworld1FC312AC59W96H138.png
There are hints in the file name. FC is frame count. The total frames or individual sprites. AC is the animation count or how many lines there are. W is for width of each frame and H is for height of each frame.
That second one is absolutely perfect. With stuff like this, getting it in will be a piece of cake.
EDIT: The single line one ended up working better with photoshop. They were a bit too close to the edges, but i just stretched the canvas and sliced it. Now I need to add a proper offset to the sprite class, and everything will work.
Thought I'd show you guys how we're going.
http://www.mediafire.com/?mldml4nekim
It's a java executable, so as long as you have a recent java installation, you should be able to just double click it.
(Note: Sprite readme out of date)
Now things are much better, but there's some things you could/should change (in MY opinion, so please don't think you must)
-you have to increase Megaman's speed and decrease it's walking/run animation (add frames)
-decrease the overworld speed.. portals and background animate way too fast
Now this last one is an idea... In my opinion, the MMBN games are good to explore, and i understand you want to make a big window, so thatthe user can see more than the original 240x160 window, but by doing that, you take away most of the "exploring" part, because you can see a lot of the map around you... But maybe i'm exagerating, and you already thought of something about that...
And if you need help i think i can provide it (i don't work with Java, but i'm "working" on a Flash MMBN (...no kidding...) as well (i only work on it when i REALLY feel like).
Anyway, the compiled jar file is a very good thing (no more command line), and overall it's going smoothly, so keep it up :)
-you have to increase Megaman's speed and decrease it's walking/run animation (add frames)
Agreed. We're planning to do this, but we want to get everything working first, and then we have to get the right values. All animations are too fast.
As for the window size, agreed. Currently the background has issues if we decrease it too much. When that's fixed, we'll fix the window size.
Btw, normalnavis cut that way would help a lot.
Really. It'd be nice to have an npc sprite to work with.
Also, since I'm on holliday now, I may be able to start working on the battle system, though I should probably start with item definitions.
Hollidays are ending. Would be nice to have some npc sprites for the next semester. Also, I'll start on the battle system during this semester probably.
mega rock.exe
17-07-10, 02:28
Like overworld sprites?
Hey guys, got an update:
http://www.mediafire.com/?wmfjobh4c6ws3a5
Next version will include dialogue boxes.
New version working, complete with smoothe dialogue boxes, and audio support. Next release will include a pause menu.
http://www.mediafire.com/?bnl33j03f1xieg5
Dialogue boxes and pause menu will be scalable.
EDIT: Updated main post.
I'd actually really like to see how people find the engine in its current state. The pause menu is implemented already, but I don't have a new release yet. I think the next release will allow multiple maps as well. As you can see, each version is quite a bit more functional than the last.
But I do want to see if anyone likes the way we handle npcs and maps and such. We're trying to make it as open to game designers as possible.
mega rock.exe
07-10-10, 00:28
Well it's terribly slow for me. Maybe the redrawing is inefficient? I don't think the game should run at such a large scale. 256x192 should be the max. Walls should never change the player's sprite.
I thought the sprites should have stayed as one large sheet. That way each animation belongs only on one line and everything is organized.
I think the redrawing is actually being rethought, since we noticed it lagged occasionally. As for the scale, thats entirely configurable. The engine is being build for MMBN, but we want it to be extendable to almost anything.
We can probably make the sprite change at a wall be based on a settable flag.
As for the sprite sheet structure, it's really easy to implement as is. Files can be organised by name, and the name doesn't matter to the engine. We may be able to just use sprite sheets, its just not possible at the moment.
Also, in later versions we may switch rendering to opengl rather than java's version, which should improve efficiency for those who have graphics cards.
The goal is for the engine to be customiseable, so I'm trying to keep everything configurable, mostly through config files. That's the part I'd really like some input on.
mega rock.exe
12-10-10, 03:09
I see. I can understand how using separate files could be useful. I think a template could help.
Well, the implemented ones basically are templates. megaman.sprite and such. Open them in any text editor. I think there are readmes, though they may be outdated.
Hi there, i've been missing for quite a while...
Well, i've downloaded the latest release, and it looks like the project it's proceeding smoothly.
And so, i've noticed a couple things i think you should fix/modify:
- As mega rock.exe said, it runs really slow, don't know why, but you really must fix it;
-The npc walk too fast;
-And as i (and mega rock) said before (and i don't know if you keep this just for testing), you should make the window 240x160 (or something like that... 300x200 would be nice too);
Now, this next ones are just suggestions
-You should use another font in the dialogues (although your probably just using the current for testing);
-Something more complex... To help you saving pc resources, you could use tiles instead of a full image map. it helps saving space (if you have several spots in a map which use the same tile), and (i suppose) you can make it so the pc only draws the tiles displayed in the screen (and not all the others);
It's basically all, overall this is going smoothly (and btw i liked the dialog frame/window).
Oh, and if i said something wrong with the tiles thing or something else, please correct me ok?
I'll post more if i remember something else!
The way we handle tiles at the moment doesn't allow that. We've completely separated the visual from the pathing. It might be cool to do it differently, but displaying an image shouldn't be a strain on anyone's computer.
We do plan to use OpenGL in the future, which should increase performance considerably.
As for npc speeds and res, its just a switchable value. If/when I make a real game on the engine, I'll set them to game values.
The engine is undergoing some major restructuring in order to allow multiple maps/levels, and I've also started defining things for combat.
One thing I'd like to implement to make combat more interesting is appliable elements. Elements are defined in an xml file with most other data (current internal build) which will be parsed at game initialisation. This means styles and elements will be seperately applied to the character, allowing for additional elements/styles to be implemented with minimal effort. I just need to design a system for handling pallates. I'm sure you can see why this would be good, but an example: SwordShield Style or something. It'd just require adding a sword element.
It's worth noting that I won't just add a bunch of elements and such for no reason. I just want the engine to have all the capabillities I can get into it.
mega rock.exe
16-10-10, 04:15
I think to improve the speed is to refresh only the part of the map that can be seen. I don't know the exact details, but I read somewhere that it's less resource-intensive if only tiles or a screen size is refreshed as opposed to the huge dimensions the whole map would have.
Well as to that, I have a hard time believing many computers bought in the last 4 years or so wouldn't be able to display an image the size of scilabsqr or undernet4, even many times per second.
But I do get the idea; probably the background system is also to blame; I do intend to rewrite that sometime soon, but the code may have some rather large changes in drawing-related stuff when we begin using opengl, so I'm putting that off a bit.
Also, I have exams in the next couple weeks, so progress may be slow for the next month, but I'll definitely be thinking of new/better things the engine needs.
But on a separate note, check the object (.obj) file in the objects folder, as well as the items in the maps folder to see what you think of the current implementation. If you can't see those, try extracting the .jar archive. For things related to combat at least, we'll probably use xml format, but I'd like to get some idea of what people think atm. Edit some stuff, mess around, I'm interested in knowing what you think. (though we dont have any way of doing stairs or multiple levels yet. should be in the next build)
brutalbarbarian
23-10-10, 11:53
Hey guys... I'm brutalbarbarian, the guy whos been coding this engine... extremely slowly :P
Anyway... I understand theres been running issues in the recent release, and while I'm not 100% sure of whats causing it, I will be looking into it. One thing that would help however is if people could tell me, for those who has experienced problems with the recent releasee, to tell me if they have also experienced problems with my previous 2 releases which links I'll post here now (since i'm not sure if i gave them to 'Magus' to post here before). This would at the very least give me a reference point to what I had implemented which screwed over the engine.
Thanks in advance for any replies.
1.0.7
http://www.mediafire.com/?wmfjobh4c6ws3a5
1.0.8
http://www.mediafire.com/?9r9w8i7813h5r8v
Brutalbarbarian
So, in a couple weeks we'll start working on the engine heavily again. It'd be nice to have some of our questions answered. So far every time I've asked what you think about how we implement things, I get the response, "Fix the lag." Now we're asking for some feedback on that particularly, and we aren't getting any replies.
I'm not angry or upset, but we need feedback.
mega rock.exe
27-10-10, 03:49
I would need to see more development to know how to correct its implementation. It's kind of hard to describe in detail.
K, I think i'll state our requests once again. Please tell us:
1. What you think of the system for implementing characters, maps, etc.
2. Whether or not the version in the main post performs better than the ones posted by Brutalbarbarian, above.
brutalbarbarian
27-10-10, 04:49
Hi again
I'm merely asking for people who complained about the lag, to try run the previous versions that I had posted in my last message, and tell me how the lag are like in there. This way I have an idea what to correct, because on my laptop, I'm not experiencing any real noticeable lag in any of them.
I'm not asking you to correct or check my code, though if you wish to get involved with coding I can send you the current code to you via email. I'm only asking for some black-box testing at the moment.
I have exams atm, so progress will likely be extremely slow, but I do need feedback to fix problems, and I'm reluctant to move forward when there's clearly something wrong.
Again, thanks in advance.
mega rock.exe
28-10-10, 21:39
K, I think i'll state our requests once again. Please tell us:
1. What you think of the system for implementing characters, maps, etc.
2. Whether or not the version in the main post performs better than the ones posted by Brutalbarbarian, above.
Then the XML idea is okay since the settings for anything in the game should be organized and easily modifiable. That's how the game would handle this and for making games, creating a flexible template is key.
Next version should run better, since some more animation-related stuff was moved to its own thread, separate from the painting thread. Meanwhile, I'll get to work rewriting all the current configuration files as xmls.
brutalbarbarian
02-11-10, 22:55
Hey again
Been working on the engine a bit more.
I believe the lag problem as of now is fixed, though still not 100% sure.
Also, theres a pause menu implemented, though atm doesn't do much (pause using the 'p' key, arrows change options and 'spacebar' is select).
Also, theres a portal on the top left of the map which takes to a different map, though atm that map is empty.
Anyway, comments would be highly appreciated.
http://www.mediafire.com/?julo82kyhjh99x1
mega rock.exe
03-11-10, 17:51
The lag is still here for me. There's no reason for the screen to be that large since the scale of the maps and characters don't fit to that. The screen is 402x302. It should be 256x192 at max.
Running south was also significantly slower than the other directions. The player shouldn't stop when hitting a wall. "Hugging" the wall is a common habit when traveling the narrow passages of the maps and stopping the player would be inconvenient.
The warps look correct though. They just need the warp sprite which should have been included in the sheet. If not, they can be dumped with the tools you have.
Yeah, as I said, at the moment the screen is resizeable, but had some issues if it was too small. If you were making an actual game on it, you'd probably set the window size (which we give people the abillity to do) and the abillity to lock it. At the moment though, it's more useful as is. Remember that this overworld could be used to make any sort of isometric rpg, we're just trying for megaman style at the moment, because I really liked bn3. The warp sprite is easily changeable, since all the animations are already ingame, you'd just have to mod the script.
Currently, I think vertical movement is half the spee of horizontal, which makes sense since the panels are half as tall as they are wide. That can be modded once we know the appropriate speed, but it doesn't matter much since it's basically just changing a variable.
As far as stopping when you hit a wall, that doesn't happen on my laptop, brutalbarbarian's laptop, or his old laptop with a 1.6ghz single core. Old versions did lag on his old laptop when he ran the game on linux, but that stopped with the newest version. So I have a hard time believing that the issue is with the program. Maybe update java?
brutalbarbarian
08-11-10, 02:12
Issues:
lag:
512mb or less ram seem to be most effected. However, I'm hoping lag issues will be eliminated once the next version is released, which I have been working on the past few days.
failing in 'wall hugging':
honestly no idea why you would have that trouble. The ability to 'wall hug' was implemented early in the engine, and has been there since I took over coding and implemented collision.
slow vertical movement:
scale in isometric dimensions means vertical movement is half speed of horizontal as a 32/32 tile is actually 64 pixels wide and 32 pixels high.
upcoming features:
Load screen:
nothing dazzling atm, but i won't say much more then that
lag
lag issues should be completely (or i hope so anyway) eliminated.
xml:
all input files have been converted to use xml format instead of the old text files. This probably makes them easier to read in any case, but this has also other advantages when coming to the actual coding.
save:
attempting to get working, should also be part of the release.
Other:
Please remember, this is not a remake nor emulation of the original game. This is simply an engine which I'm trying to keep flexible based on it. Please do not complain about how some things aren't exactly like the original game.
brutalbarbarian
13-11-10, 09:00
Hi
For all those who still follow this thread, this project has been offically moved to the following link:
http://code.google.com/p/jpgengine/wiki/Introduction
The people cutting up the maps for bn3 were really sloppy. Very few feature the doodads cut out with all their frames. I can make the portals out of what I've got, except the undernet ones. And there's no way I can manage the arrow pathways...
Also, there are very few backgrounds listed there, when the game has quite a lot. Also, very few maps have actually been ripped. While not important perhaps, that IS what this site is for. I'd actually like to try reproducing a lot of the game with the engine as we go, but mostly I just want lots of individual sprites and such all working.
Safe to assume noone cares at all about this project?
First of all, sorry for not posting for so long, and making you think i donīt care about the project...
Now, onto the issues
-The lag as disappeared in the last version, it runs perfectly
-The background and portals (red round things) animations are too fast, although i'm sure this is no issue for you, since you can easily slow it down
-I think megaman runs too slowly and, megaman's y-axis movement (up-down) is slower than it should be
-About the wall-hug thing, it tecnicaly works correctly
Other graphical issues are
-Megaman's walking animation shouldn't stop when he it's a wall or object/person
-While doing wall-hug, the animation should be the same as you press
Example (you are wall-hugging in a wall like this (M-Megaman)
/
/
/M
/
, while pressing up-left, the animation should remain northwest, but in your engine it becomes northeast /the direction of the wall
Sorry if this explanation isn't very good, but i think it's quite understandable
For last, i too, think that the xml instead of text, is a major thing in the engine
EDIT: Not important, but in the undernet map, if you go north, theres a small green line, which does not belong to there
Thanks for replying.
As far as the movement goes, we just made the Y axis movement half the X axis movement, since it's half the size. As such, diagonals work perfectly. It may be possible to deal with this some other way, but I certainly have no idea how.
I'll see about the walk animation continuing when stopped.
And as for the wall hug animation, I think brutalbarbarian implemented it that way on purpose. It'd be easy to change probably, but it may come from the fact that he's moving diaonally, and therefore gets the diagonal sprite. Since this can be used for other rpgs, not just megaman, where people may want this, its not really an urgent matter.
But I think i'll clean up the undernet map some time. I hope to see the next floor drawn soon.
Not sure if you've seen the latest updates, but the rendering is now done in opengl, so it uses your graphics card, and has a save/load system. Note that it WILL NOT run unless you have decent graphics drivers... it shouldn't be an issue on any machine made in the past 5 years, and the average lifespan of a computer is only about 4 years, so it should be fine for everyone.
Once the multilevels are completed next version, this should be a perfectly functional overworld engine with which you could make a simple game with no coding except in the xml files. You could probably also make movies with it, so this site is pretty much perfect for it at the moment. Once we begin construction of the battle system, the engine will be fully useable. We may construct several battle systems, from bn to typical rpg style, to turn based strategy even. A developer could use whichever they want.
Stay tuned.
vBulletin v3.5.4, Copyright ©2000-2012, Jelsoft Enterprises Ltd.