Welcome Guest [Log In] [Register]
Welcome to the Fire Emblem Arena Battle League.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join the FEABL, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, free enemas, and voting in polls. Registration is simple, fast, free, and highly recommended.


Join our community!


If you're already a member please log in. Don't keep us waiting (or else)!

Username:   Password:
Add Reply
How to create you own maps and event data
Topic Started: Oct 9 2007, 06:35 PM (593 Views)
User33
Meh. Franz.

Note: This tutorial was created by Icy Toast, and I am merely posting it here. I take not credit for this whatsoever

http://feantho.ipbfree.com/index.php?showtopic=359

~CHAPTER 1: Maps~
-------------------------------------------------------------------------------------------------------------------------------------------
I might as well have started this thing with a load of theoretical stuff, but I instead chose for a more practical approach. In fact, you'll be able to create a (almost) completely custom chapter at the end of Chapter 3. The first thing you need for a chapter is obviously a map, and that's why this first chapter will be about maps and how to code them.

Map Data
First off, for those who didn't know, all FE maps consist of tiles, which are squares of (in this case) 16x16 pixels. The game draws these tiles from tilesets (also called object sets) which are collections of tiles around a certain theme. The colours are only applied to the tiles afterwards, so a particular tileset could look completely different in different maps, depending on the used palette. However, each map can only use tiles from one tileset, and can only use one palette.

Before coding your own map data, you'll need to know how the data is built up. To see an example of what map data looks like, use your hex editor to look at offset 0036AF00. This is the starting byte of the Prologue's map data. Before the information about the actual tiles starts, there are 7 other bytes. In the case of the Prologue, these are 10 2E 01 00 00 0F 0A. The 2nd, 3rd, 6th and 7th of these bytes differ from chapter to chapter. The 6th and 7th ones are respectively the horizontal and vertical dimensions of the map, measured in tiles. The 2nd and 3rd bytes actually store a single value, so you'll have to reverse them to read it: 012E. This value tells the game something about how many tiles should be loaded in total for the map, but I don't know exactly how it works. Anyway, the general formula to find this value for your own maps is: length * width * 2 + 2. You might want to use a hex calculator for this. (Shouldn't be difficult to find an online one.)

After this, the tiles that are on the map are listed. There's no reference to their location on the map whatsoever, they're just listed from left to right moving from top to bottom on the map. Each tile's reference is just its number in the tileset, and it takes up two bytes (which are, as usually, in reversed order). Note that only numbers ending in 00, 04, 08 and 0C refer to valid tiles, the rest isn't usable in a map. There's a good reason for this, but I won't be explaining it here in order not to overcomplicate things.
Additionaly, there's a 00 added in after the first 3 tiles' references, and beyond that after every fourth tile.

As a really random example, a very small map's data could look like this: (the seperation 00's are in bold print) (note that a map as small as this can't exist; every map must at least be large enough to fill the screen)

10 2A 00 00 00 04 05 10 05 14 06 2C 01 00 7C 0D
48 09 2C 0F 64 08 00 A8 04 38 00 08 03 94 0A 00
50 07 90 08 A8 01 A8 01 00 74 05 C8 02 D0 09 D4
09 00 30 0B

By now, you might have noticed that the map data of the Prologue, which we were looking at earlier, doesn't quite match this format. In fact, none of the actual game maps do, since they're compressed. Because of that, we can't just go ahead and change existing maps; instead we'll have to create our original maps to replace them, but seeing that we were going to do that anyway, that's not really a problem.

You might also be wondering how you could possibly know which actual tiles the numbers refer to. For that, you could try ripping all the tiles of the tileset you want to use and collecting them into a table like I did with this one... but looking up every single tile of a custom map you want to code in a table like that would require extremely much time, so I'm going to explain a simpler method to you in a minute.

If you prefer just to go ahead and code a map manually, you should be able to do that knowing what you know at this point, but I advise you not to overwrite the existing map data, and to expand the ROM so that you have empty space to put your map code in instead. Repointing the pointers to map data to point to your new map is something that will be discussed later.
I strongly advise you though, to just read on and learn a far easier way.


An all-powerful shortcut...
The easy way I was referring to, involves designing your map in Mappy Map Editor, using the FE7 tilesets the link to which is in the prologue of this guide. How to use Mappy to design a custom map should be fairly clear, but here are a few advices that'll definitely make life easier:

- Adjust the tileset window's size in such a way that tiles like castle's or villages align in so that you can easily see how to use each tile.
- First pick a tileset, then start a 'new map' and load the tileset again. If you don't, a tileset might load incorrectly if you load it after loading another one first. It's not unlikely that you'll only notice this once you first see your map in-game and realise it doesn't look at all like what it should've been, so I strongly suggest that you pay attention to this.
- Always remember to set tile size to 16x16 pxls in the 'new map' window.
- Never create maps with dimensions exceeding 43 x 36 tiles, as the game might not be able to load them if you do.
- Remember exactly which tileset file you used as you'll need that information later. In fact, you should probably write it down somewhere.
- Don't use layers. If you want to use doors that can be opened or walls that can be broken, just make it look the way it should at the start of the chapter, and you'll learn the rest later. If you want to use removable roofs, I can't tell you how to do those, since I don't know it myself. =P
- Ignore the fact that the animated tiles don't perfectly connect, since I didn't rip all of them when they were at the same animation frame.

Once you've finished creating a map, export it as a .mar (map array) file. If you now get an error message telling you there are more than 1024 tiles in the tileset, you'll know that you haven't been paying attention to my second advice above.

Now, we'll manually convert this .mar file into the format Rekka can understand. I'll describe this process step by step to avoid confusion. I'll use Cygnus here, since I don't know the exact functions to use in other editors.

1. Open the file in Cygnus

2. Choose the 'Tools->Modify' function

3. Set the 'number of items to modify' to something high enough so that the entire file is highlighted, set the item type to 'Word (2 bytes)', set the action to divide, the action value to 8 and make sure Big Endian is not checked.

4. Press OK. The hex editor will now divide the value of each pair of bytes by 8. (if it asks whether it should extend the file because your 'number of items to modify' was greater than the total file, choose 'no')

5. Insert a '00' byte after the first 6 bytes, and another after every 8th byte beyond that (not counting the 00 bytes you inserted as one of the 8)

6. Insert 10 XX XX 00 00 YY YY at the start of the file, with YY YY being the map dimensions (in hex!) and XX XX being length * width * 2 + 2 (all in hex). Remember to reverse the bytes!

At this point, your file is ready to be inserted into the ROM. To keep things nice and clean, we'll just expand the ROM and insert this in the newly created open space. Inserting it can be done by just using the copy/paste functions of your hex editor. Obviously, the game won't be able to use your map now, since it has no way of knowing it's there. That's why we're going to need to make a pointer to it.
Remember how there's a 'map used' byte in the chapter data? (you could use my NM module to find it) Clearly, this byte is not an actual pointer to the map itself; it's a reference to a pointer in the pointer table starting at 00C9C9CC. You'll learn to remember this table's offset, as a lot of important pointers, including those to tilesets, map palettes and event data are in there.
Let's say you wanted your map to replace the prologue's map. As the 'map' byte in the chapter data says 04, the fourth pointer in the table is the one you'll need to change. Make it point to the location of your own map intead of to 0036AF00 like it does right now. Note that a pointer to an expanded area of the ROM will end in 09, since the address starts with 01 instead of the usual 00 (and you have to add 08 to it).

If you hadn't realised it already, know that replacing the prologue's map pointer with yours won't mean that your map has to be used for the prologue. If you want to, you can change the map reference bytes of various chapters' chapter data around to change which map is used by each chapter.

Finally, change the Object Set, Palette, Tile Configuration and Tile Animations settings in the chapter data to correspond with the tileset you used for your map. (Again, I advise using my chapter data editor). If you're not sure which tileset or palette it is, check its (=the tileset's) file name; it matches the values you need to enter.


Changing tiles - about chests, doors and more
Your map is now in the ROM, but if there are chests, doors, villages, snags or walls in it, you'll have to do some extra things in order for it to work properly. We'll have to edit, or rather, replace a bit of data that describes which tiles of the map can change to other tiles (like a closed chest changing to an opened chest). It allows you not only to make the door/chest/wall/snag tiles themselves change, you can also change the surrounding tiles, if you want to.

You might have noticed the chapter data byte labeled 'Triggerable Map Changes' in my editor. Like a lot of values in the chapter data, this refers to a pointer in the table at 00C9C9CC. This pointer points to the data we're going to edit now. If the chapter you want to use your map for has a 00 at this byte, just take a reference number from another chapter. Remember though, that if you're going to make more than one custom chapter, you can't use the same number twice. (Or... in fact it could be done if you very carefully chose which ones to combine, but I advise against it)

Anyways, let's take a look at the data these pointers point to. I'll use the data for chapter 2 as an example here, which is at 00CE1D20 (since the byte in the Chapter Data says 0E, which means the 14th pointer of the table, which points to 00CE1D20).

The data looks like this:

Offset ---- Data
00CE1D00 -- -------- -------- -------- 80072C0D
00CE1D10 -- B40D280D 30090000 240C0000 300D240D
00CE1D20 -- 000D0001 02000000 0C1DCE08 010D0001
00CE1D30 -- 02000000 101DCE08 02080102 03000000
00CE1D40 -- 141DCE08 FF000000 00000000 00000000

The underlined byte is the byte that the pointer points to. It's the start of what is essentially a list of all the changes the map could possibly undergo during the chapter. Each element of the list consists of 12 bytes in this format:

GGHHJJKK LL000000 PPPPPPPP
In which:
GG = Identification number (as in, the first element of the list is 00, the second is 01, the third is 02, etc.)
HH = Horizontal coordinate of the top lef tile of the part of the map that changes
JJ = Vertical coordinate (note that coordinates are counted from the very top left tile of the map being ( 0, 0 ))
KK = Horizontal size of the part of the map that changes (measured in tiles)
LL = Vertical size
P = Pointer to the tile references of the tiles the defined part of the map needs to be filled with if it changes

The bold-printed bytes are the starting bytes of each element of the list for the chapter 2 map-change-data. As you can see, the list ends with 'FF000000 00000000 00000000'. So should yours.
If you read the pointers in the example, you'll also see that the tile data is right before the list. Although this is always the case in Rekka, it doesn't need to be so. For your custom map, you might just as well first do the list and add the tiles after that. Remember though, that in any case, the pointer in the pointer table points to the first byte of the list.

Making your own list like this shouldn't be too difficult, and I advise you to make one in the expansion part at the end of the ROM (if your map already took up all the new space, expand it further =P). Note that the game doesn't need to know what triggers the tile changes, it just executes any change it can find in the list that includes the tile a chest/door/pick/attack/visit command is used on, at the moment that command is used in the game. This means that the areas of the map that can change cannot normally overlap eachother, or things will go wrong.
The only exception to this rule would be a situation in which the same tiles are changed multiple times throughout the chapter, which is the case in the cutscenes of chapter 2, where the door at the top right of the map is closed at one point and opened at another point. This is why that part of the map is listed twice in the example data above.
Using this for a cutscene is rather tricky though, so I recommend against doing that, but there is another kind of situation in which you will need to include a certain part of the map twice no matter what. I'm talking about villages. Since they can either be visited (so the gate closes), or destroyed, they must be listed twice. The first one is the change that takes place if the village is destroyed, and the element listed immediately after that should be the change that happens if the village is visited. Also, the 'destruction map-change' must cover the whole village, whereas the change executed upon visiting only replaces the open village gate for a closed one.

Getting the right tile numbers can take a bit more time than the list, even though it works in the same way as the tile numbers in the map data itself: the tiles are listed in order of appearance from the top left to the bottom right tile of the indicated part of the map that will change.
There are no seperator 00's at all, as the list already tells the game how many tiles to 'read'.
Anyways, to find out the tile numbers of the change-able tiles after their change, you'll need to either consult a table like the one I showed you before (I haven't made tables like that for every tileset, so don't ask me for them >_>), or just use Mappy to export another .MAR with the tiles you need to know the numbers of all in one row, and then convert the byte pairs by dividing them by 8 (in hex!) to find out.
Oh, and if a certain tile within the area you indicated in the list doesn't need to change, you can just put 00 00 in its place.

Once you've finished your tile data and the list, repoint the pointer to it (the one in the pointer table, remember?), and your map should now be playable. Unfortunately, your chapter isn't, so you'll need to have a bit of patience and wait for the next two chapters before you'll be able to actually enjoy your custom chapter. =P

Chapter 2 is old news

~CHAPTER 3: Events~
-------------------------------------------------------------------------------------------------------------------------------------------
Well... it's about time to arrange the last few things for your custom chapter to become playable. Not meaning that those few things are unimportant. In fact, the event data - yes, that's what I'm talking about here - forms the backbone of any chapter. It determines what happens at each point in the chapter.
Unfortunately, event data is fairly complicated when compared to what we've been doing so far, and, truth be told, I only know a few things about it myself, really. However, if you want to find out how to program more complex events than the basic things I'm describing here, feel free to explore the existing events a bit . Those start at 0xCA7A40, but for clarity's sake, I strongly advise you to start making your own events in some empty space instead of replacing the existing stuff there.

Reinforcements
We'll start with the simplest part: reinforcement events. First off, collect pointers to all groups of units (not the ballistas) you coded in the last chapter. Then, make a code like this for each of them:

32000000 *INSERT POINTER HERE* 3B000000 0A000000 00000000

It doesn't matter whether you put all these codes in a row or at completely different places, so just arrange them in whatever way is clearest to you. Erm, yeah, that's all there is to reinforcement events, really.

End-chapter scene
Since only reinforcement events don't make a chapter, we'll at the very least also need to create an end-of-chapter event, which ends by taking the player to the save-screen before proceeding with the next chapter. For the rest, how it'll look is up to you.

This taking-the-player-to-the-save-screen event is coded as follows:

8100XX00 02000100 01000000 0A000000 00000000

In which XX is the chapter reference number of the next chapter.

So that's how the end-chapter scene must always end, but what about other things you might want to happen before that?
Let's say you wanted to have a dialogue right before the save-screen thing. Then you'd have to add
0D000000 XXYY0000 right in front of the other code to load text XX from text bank YY. I know I haven't explained much about text yet, so don't worry if you don't understand it right now.
But what if you wanted that dialogue to be shown with a background behind it instead of the map?
In that case, you'd have to put a 0500XX00 code, in which a different XX will load a different background, right before the 0D byte. If you're going to have multiple dialogues and you want to return to the map view at some point, you could use 09000000. And if you wanted to change the music too, you'd have to add a 7800XX00 code, with XX being the track to be played.

As you might have guessed by now, there are many more event codes you could use to put together your own cutscenes, but I hardly know any of them, so I can't really explain them to you either. So if you really badly want to add fancy animations, camera movements, effects or whatever, you'll have to try and find out the code for yourself. Obviously, the most logical way to do that would be to try locating the event data for an occurence of that event in the original game. =P

The things I've described so far can of course not only be used for end-chapter cutscenes, they can be applied to any cutscene occuring at any time in the chapter, including the chapter's intro scene. However, you'll have to experiment with that on your own to find out more about the exact structure of the event data; I can't tell you much about it since I haven't examined it a lot yet. >_>


Some other event stuff
If you want to have cutscenes for villages, or houses, you'll also need to create those. You should be able to construct simple ones using the information above. As for item giving, it's certainly possible, but you'll have to look for the right code yourself *doesn't know* . Sorry. XD

Something I cán actually help you with are the shop lists. These are loaded when the player enters a shop/armory and tell the game what items are sold there. To create a shop list, just look for some empty space, and type out the item reference numbers (there's a list in the previous chapter) seperated by 00. At the end, there should be another 00.

Putting it all together
Good, now that you have a set of events - even if most of them only load units onto the map - it's time to tell the game when to load all these things. This is arguably the hardest part to pull off, and I'm not sure I completely understand it myself, so don't shout at me if something goes wrong XD.

The piece of data we're going to make now has a very strict structure, so try to follow these steps carefully, and don't add any more/less zeroes than I tell you to. =P

1. First, we'll make a list of the events that occur based on turn count, starting with the intro scene, which occurs at the start of turn 1, obviously. This is signified by a code line saying:

02000000 *pointer to event data* 01000000 00000000

Copy this code for every event that occurs on turn-count basis, insert the right pointers for each one of them, and change 01 to whatever turn the event should occur on. Additionally, if the event should take place at the start of the enemy turn, use TN008000 (where TN is the turn number) where it says 01000000 in the code shown above.

2. Add an extra 00000000 once you've finished the list of turn-count-based events.

3.Now it's time for the character-based events, like recruitment convos, of your chapter. No, I didn't explain you how to make those, but if you manage to make some anyway (shouldn't be too hard), this is where they go. The codes are all in a row and go like this:

0300XX00 *Pointer to event* YYZZ0000 00000000

This code tells the game that character YY and ZZ can talk to eachother in this chapter, and if they do, the event at the location pointed to should be loaded. XX is somewhat like an identifier of the event. Or maybe it's better to see it like a variable that can only take the values 'true' or 'false'. Once the event is executed it becomes 'true', and in that way the game can remember that the event has already taken place, so the characters can't have the same convo again.

To us, this simply means that of events with the same XX value, wether it be character-based or location-based or something else, only one can be executed. This is a useful function if you want to e.g. make a character recruitable by two other characters, but you don't want him/her to be recruited twice (once by each character).
Something you ought to keep in mind here, is that you can't use 01 here, since that is by default the event identifier for the boss' battle speech. I'm not too sure about 02; it could be that it's preset for something as well, so be careful with it. You can't just use high (say, above (hex) 30) numbers either, since those apparently last for the rest of the game (so only one event with ID 87 can take place in one playthrough, whereas an event with ID 08 (which can be different for every chapter), can occur in every chapter). I'm not sure where the permanent variables start though, so, again, be careful. Yeah, this stuff is tricky. >_>

4. Add an extra 00000000 once you've finished the list of character-based events. Even if there are no character-based events in your chapter, add the 00000000 anyway.

5.Next up are the location-based events. These are pretty simple, really. (Obviously, it's also possible that your chapter doesn't have any.)
Just make a list (doesn't need to be in any particular order) of codes like this:

0500PP00 QQQQQQQQ XXYYZZ00

The PP is the event identifier, as explained in step 3. For houses, vendors and armories, which you'll want to be able to be visited more than just once, leave this empty ( = 00).
QQQQQQQQ is the pointer to the event data to be loaded for houses, the pointer to the shop list for armories/shops, or just 01000000 for a seizable gate/throne. XX and YY are the horizontal and vertical coordinates of the location, and ZZ is the type of command that can be used at that location to trigger the event. 0F represents 'seize', 0E is for visit, 13 is armory and 14 is shop.

There are some types of location-based events that use a slightly different code, and you can add those after the standard ones I just described.

The first irregular type are the visitable villages. Those use the following code:

0600PP00 QQQQQQQQ XXYY0E00 0500PP00 01000000 LLMM1D00

PP is still the event identifier (note that the one after the 06 and the one after the 05 need to be the same), QQQQQQQQ still represents the pointer, and XX and YY still represent the coordinates. As do LL and MM. Be very careful though, as at the XX and YY, you'll need to fill in the 'visit' location, which is the village gate, whereas the LL and MM are the 'destruct' coordinates for bandits, which should be the center tile of the village (the tile above the gate).

Chests also have their own code:

07000000 TT000000 XXYY1200

As always, fill in the coordinates at XX and YY. TT represents the item reference number of the item inside the chest.

Finally, the following code is used for doors:

08000000 01000000 XXYY1000

6. Once you've finished the location-based events list (even if it's empty), add 00000000.

7. After this, there's usually a lot of weird stuff that I don't understand in the original data, so I'm going to skip that for now, as the chapter still functions without it. In any case, it's apparently a set of conditions (and the pointers to the event data triggered by their fulfilment) that the game constantly checks for. There's one code of this part I do somewhat understand though, and that's the one that tells the game to load a certain scene once all enemies have been defeated, effectively creating a 'defeat all enemies' goal if you make that certain scene the end-of-chapter scene. The code goes like this:

0E000000 *event pointer* E99F0708

If your chapter isn't a 'defeat all enemies' chapter, just put some 00000000's.

8. Since the game is kind of dumb, it needs some help reading all the lists you wrote. =P Therefore, we'll need to make a set of pointers. 16 pointers, to be more precise. Just put them all right after one-another and it should work fine. These are the pointers you need to make (in this order):
1. A pointer to the turn-count-based events list you made in step 1
2. A pointer to the character-based events list from step 3 (or the 00000000 seperator if there aren't any)
3. A pointer to the location-based events list explained in step 5 (or the 00000000 seperator if there aren't any)
4. A pointer to the weird-conditions-based-events list mentioned in step 7 (so it'll point to the 0E .... if you made a 'defeat all enemies' chapter; else just let it point to the 00's.
5. A pointer to the ballista data for Eliwood's mode that you learned to make in the previous chapter. If there don't need to be any ballistae in your chapter, this pointer can point to anywhere where there's a 00 byte.
6. Same as the above, for Hector mode.
7. Pointer to the first byte of the enemy unit data, ENM
8. Same, EHM
9. Same, HNM
10. Same, HHM
11. Pointer to the first byte of the player unit data, ENM
12. Same, EHM
13. Same, HNM
14. Same, HHM
15. Pointer to the chapter's first event scene
16. Pointer to the end-of-chapter scene


Heh, you're almost there now. In fact there's only one thing left to do. You'll need to formulate a pointer that points to the start of the pointer set described above, and that pointer needs to take the place of the event data pointer of the chapter yours is replacing, in the big pointer table that starts at 00C9C9CC. To find out exactly which pointer it is that yours needs to replace, check the 121st byte of the chapter data of the chapter in question. Or just use my chapter editor NM module and look at the 'Event Data Reference' byte.
While your at it, you might at this point also want to use that same chapter data module to add some finishing touches to your chapter, like the music or the weather.

Oh, and if you were wondering about chapter goals, you might have noticed that you can use the event activation table stuff to create various goals:
- You could create a 'survive' chapter by setting the end-chapter scene to occur at a certain turn-count
- You could create a 'talk to ...' chapter by setting the end-chapter scene to occur if certain characters talk to eachother
- You could create a 'seize gate/throne' chapter by setting a 'seize' location in the location-based-events list. Note that in this case, as you're not actually entering the pointer to the end-of-chapter scene into that list, the game just uses the 16th pointer in the pointer set you made.
- You could create a 'defeat all enemies' chapter by using the code I already explained.

I'm not sure about other kinds of goals. I have some ideas about how a 'defeat boss' goal should work, but since I haven't managed to create one yet, I'm not going to write them in here.

By the way, you should remember to also set the goal text in the goal window (use my chapter data module! XD) to correspond with the chapter goal you created.

Despite the fact that I said there was only one thing left to do, there's something else that might need to be taken care of. If your chapter replaces a tutorial chapter, it's possible there's still some tutorial stuff left in there. To stop that from happening, you'll need to disable the tutorial pointer table at 00C9EA2C. I say disabling and not erasing, as just changing all 48 pointers to 00000000 won't work. You'll need to repoint all of them to someplace in the ROM where there are at least four 00's after eachother. Take care not to mistake the bytes right after the table, which say "01 02 04 08 ..." for a pointer; they're not.

Well, that was all. Time to go play your newly produced chapter, pray it works, and throw a party to celebrate its completion. I must admit I haven't extensively tested everything in this chapter, so there might be some mistakes in my explanations. I sure hope there aren't, but still, know that it could be my fault if something turns out to be wrong with your chapter. >_>

------------------------------------------------------- END OF CHAPTER 3 ---------------------------------------------------
[/QUOTE]

Mappy available here: http://tilemap.co.uk/mappy.php

Tile sets here: http://www.fileden.com/files/2006/8/26/187...yFETileSets.zip

So looks complicated, but it actually isn't too difficult. Go out and make your own maps now!
Offline Profile Quote Post Goto Top
 
Bears


I assume this is FE7-only?

Anyway, from a quick skim of it, looks AWESOME.
4:24 PM - John Ѯzzingford: "Alternate Universes".
4:24 PM - John Ѯzzingford: Taking an existing set of characters, and putting them in an altogether different setting.
4:25 PM - John Ѯzzingford: For example, you could take the cast of the Mario games, and set them up in some kind of detective-versus-cannibal-mastermind drama.
Offline Profile Quote Post Goto Top
 
User33
Meh. Franz.

And a note: Start with "An all powerful shortcut". That's the easy way.

Oh, and I haven't tested it with FE8, so I don't know...
Offline Profile Quote Post Goto Top
 
Bears


Looks like making our own FE games, using FE7 as a base, isn't far off at all... intriguing. Very much so.
4:24 PM - John Ѯzzingford: "Alternate Universes".
4:24 PM - John Ѯzzingford: Taking an existing set of characters, and putting them in an altogether different setting.
4:25 PM - John Ѯzzingford: For example, you could take the cast of the Mario games, and set them up in some kind of detective-versus-cannibal-mastermind drama.
Offline Profile Quote Post Goto Top
 
User33
Meh. Franz.

I've gotten a few maps to work, so just ask me if you have any questions.

Oh, and I forgot to link to the tilesets. You'll need them if you use Mappy (trust me, use Mappy its a billion times easier. I linked to it at the end)
Offline Profile Quote Post Goto Top
 
Abyssal_Shrimp
I broke my shades!

This looks quite impressive.
Kruen, level 20/5 Berserker
Xiella, level 20/1 Guardian
Fernand, level 5 Knight
Aurelia, level 8 Dragonrider
Mariann, level 4 Hunter

RETIRED
Raedul, level 20/20 Paladin
Tancred, level 100 Tangrowth
Offline Profile Quote Post Goto Top
 
iammax
Member Avatar


tl;dr
Offline Profile Quote Post Goto Top
 
User33
Meh. Franz.

^Then don't read it, and forever create inferior hacks compared to everybody who actually bothers to read it.

I'll post pics of my custom levels soon :D
Offline Profile Quote Post Goto Top
 
iammax
Member Avatar


I don't need to hack to win!
Offline Profile Quote Post Goto Top
 
User33
Meh. Franz.

http://www.youtube.com/watch?v=FPxY8lpYAUM
Offline Profile Quote Post Goto Top
 
Nate
Member Avatar
yeah

Wow, this is great!

Although I'm starting to think that programming my own game would be easier than hacking FE7 if you want to get really complex <_<;
Gigs
 
[00:47] Gigs: nothing on feabl is drama worthy
[00:47] Gigs: and yet...


Posted Image
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
« Previous Topic · Fire Emblem · Next Topic »
Add Reply

Etavarium Theme created by Zeus00 and converted by Wolt of the ZetaBoards Theme Zone