Welcome to the PokéCommunity!

Hi there! Thanks for visiting PokéCommunity. We’re a group of Pokémon fans dedicated to providing the best place on the Internet for discussing ideas and sharing fan-made content. Welcome! We’re glad you’re here.

In order to join our community we need you to create an account with us. Doing so will allow you to make posts, submit and view fan art and fan fiction, download fan-made games, and much more. It’s quick and easy; just click here and follow the instructions.

Basically, end goal is a Pokemon engine that is as true to the look and feel of the Pokemon games that it feels like you are playing on a game boy/emulator. And to make the engine easy enough to edit and create games in that it is more attractive than ROM hacking.

- Based on Fire Red graphics right now (my personal favorite) but I am planning on making the engine either support other games or be flexible enough to use almost any graphic.
Changed to Red, easier to code into the game without having to spend hours on graphic design.

- The main goal of the engine is to support the latest generation's battle system and Pokemon, and to do it in a way that is easily modifiable.

Features as of 4/8/14:
-The game now runs on libgdx. I'm done with screwing around with engine design, libgdx is nice, ports to android real quick, and works.
-Mapping is based on Tiled now, making my own tools sucks, so I'm going to use as many 3rd party software to make it easy on both me and anyone using this engine.
-Script system based on ROM ARM code, cause I'm weird like that. Its not complex, just formatted that way. Should be pretty powerful and extendable.
-Battlesystem is about 70% done, Pokemon are loaded and play like they should, lots of the unique attack effects are not implemented, but the standard ones are. I still need to do natures, but other than that, the stat/leveling system is good.
-Menu system is, again, Pokemon Red based, so it looks like crap, but it works. I haven't got to the bag or some other smaller menus, but the pokemon menu and the battle menus are working, and the pokedex is up.

Yes, this engine is a year old now. And progress is very erratic, but it is NOT dead, just very slowly developed.

I wrote my own tag-based save/database system, so I can stop leaning on 'stolen' code.

The rest of the time has been spent on the battle system, implementing attack effects. I have basic damage, status effects, stat effects, and critical hits, but it is slow going, as there are like 300 different effects a move can do. Again, this is very modular, so it will be easy to add new attacks and effects.

That's mostly it, I've done a few other things, but I can't remember them off the top of my head. I'll update the OP at some point.

This is looking really nice. I think Java is a good choice, due to being available and installed on pretty much every computer and its a lot faster than some other languages I've been seeing used in engines so far.

An important question for me is, how modular your code is. Is it possible to exchange parts like the battle system or some menus without having to rewrite existing code? I'd be interested in seeing a Pokemon game more optimized for laptops/desktops, thus using the larger screens and higher processing power.

Firstly, this looks pretty epic, and all the screens seem really high quality. I have some questions...

Did you make the map editor yourself? It looks good. If so how did you define the map format? Are movement permissions etc. stored on the map or in a separate file?

Your menus look really clean, and judging from the screens you've got a lot of the functionality done too. How much code (if any) is shared between different menus? Because I'm going through doing mine at the moment and I haven't written a base Menu class but thinking maybe I should...

Why is the window bigger than the rendering screen? I presume it won't be for the actual release? Also is the window resizable, and if so how are you dealing with the menu graphics in different windows?

This is looking really nice. I think Java is a good choice, due to being available and installed on pretty much every computer and its a lot faster than some other languages I've been seeing used in engines so far.

An important question for me is, how modular your code is. Is it possible to exchange parts like the battle system or some menus without having to rewrite existing code? I'd be interested in seeing a Pokemon game more optimized for laptops/desktops, thus using the larger screens and higher processing power.

At the moment, the systems are all hard-coded, for simplicity while I get everything working and all the data available. But my end plan is to allow a modular menu and battle system like you said. I've seen it done well (example being ModLoader for Minecraft) and I plan on setting up a basic abstract system for menus and the battle system, and then allow people to code different styles of menus, and have them implemented by just putting some class files into a folder along side the game. But that is very far into the future of development.

Quote originally posted by andytu:

Firstly, this looks pretty epic, and all the screens seem really high quality. I have some questions...

Did you make the map editor yourself? It looks good. If so how did you define the map format? Are movement permissions etc. stored on the map or in a separate file?

Your menus look really clean, and judging from the screens you've got a lot of the functionality done too. How much code (if any) is shared between different menus? Because I'm going through doing mine at the moment and I haven't written a base Menu class but thinking maybe I should...

Why is the window bigger than the rendering screen? I presume it won't be for the actual release? Also is the window resizable, and if so how are you dealing with the menu graphics in different windows?

Everything about the engine I have coded myself, except a library to read in the sql-lite database from Veekun.com (Props to Eevee for that, it makes everything SOO much easier). I am still messing around with the map format, right now it has two layers, and a movement permissions map, but I am considering allowing infinite (or just a of lot) layers and doing movement permissions based on layers, which would work a little better in the end and allow maps with much more vertical movement.

The menus share a bit of code, mostly to make it easier to stack them (eg. Pokemon menu on top of item menu for choosing which Pokemon to use an item on and so on...). A base menu class is also useful, as it simplifies rendering the menus, you can just abstract a simple render() function and have the player have a Menu variable and a Boolean to tell the engine to render the menu or not. Or just a null check. Makes menu handling a lot easier.

The JFrame is really pissing me off, I have no idea why it didn't pack the window correctly, and though I fixed it, I don't really know what I did to fix it lol. The window is NOT re-sizable, as that requires a lot more flexibility in my code, and I'm not ready for that yet. At some point I will probably add a zoom function (1x to 4x like VBA maybe), but a re-sizing window would probably cause a huge amount of bugs. I also probably messed up the symbol colors lol.

I am not sure when I will be releasing the first alpha. I want to have some sort of content finished before I release anything, but that might take a while. Like I said in my previous post, the battle system's move effects take a LONG time to do. I have about 50 of 340 done at the moment... And some of them require a huge amount of work, like Transform or Mirror Move or crap like that. So maybe after I am satisfied on having a good part of the battle system finished I will put out a alpha.

I've obviously not seen your code and I'm not a fully trained programmer (yet), however I have a little suggestion which might save you from a lot of trouble in the long run. During my own projects, I made a bunch of mistakes which could've easily been avoided and are able to ruin the fun very fast.

The temptation to hardcode stuff to make something work quickly is great and it can create huge bugs later on in development. Removing hardcoded components can be very difficult and often results in overlooked remainders of outdated code. Object oriented programming is perfect for moving test code outside of your actual code and thus helps in avoiding such errors.

Everything about the engine I have coded myself, except a library to read in the sql-lite database from Veekun.com (Props to Eevee for that, it makes everything SOO much easier). I am still messing around with the map format, right now it has two layers, and a movement permissions map, but I am considering allowing infinite (or just a of lot) layers and doing movement permissions based on layers, which would work a little better in the end and allow maps with much more vertical movement.

The menus share a bit of code, mostly to make it easier to stack them (eg. Pokemon menu on top of item menu for choosing which Pokemon to use an item on and so on...). A base menu class is also useful, as it simplifies rendering the menus, you can just abstract a simple render() function and have the player have a Menu variable and a Boolean to tell the engine to render the menu or not. Or just a null check. Makes menu handling a lot easier.

The JFrame is really pissing me off, I have no idea why it didn't pack the window correctly, and though I fixed it, I don't really know what I did to fix it lol. The window is NOT re-sizable, as that requires a lot more flexibility in my code, and I'm not ready for that yet. At some point I will probably add a zoom function (1x to 4x like VBA maybe), but a re-sizing window would probably cause a huge amount of bugs. I also probably messed up the symbol colors lol.

I am not sure when I will be releasing the first alpha. I want to have some sort of content finished before I release anything, but that might take a while. Like I said in my previous post, the battle system's move effects take a LONG time to do. I have about 50 of 340 done at the moment... And some of them require a huge amount of work, like Transform or Mirror Move or crap like that. So maybe after I am satisfied on having a good part of the battle system finished I will put out a alpha.

Cheers for replying. For comparison I am using TMX format and have infinite layers plus one for movement permissions and another for behaviour stuff (encounters, ledges etc.) which works pretty well. Your menu approach makes sense, they really are a pain to write though however you do it...

While you're deciding what to do with your layers, might I suggest that you take the opportunity to make sure you think about bridges as well?

The concept is that the player walks around on one of three levels, and can transfer between levels only at certain points (invisible to the player). Each level has its own movement permissions layer. I say three to allow for having one bridge (e.g. horizontal) over another bridge (e.g. vertical) over the ground, which is the maximum number of levels you can reasonably use before making maps look really bad and obfuscating.

In addition to all the other movement permissions, there will be one which allows that level to connect with adjacent levels. While standing on such tiles, the movement positions of the current and all adjacent levels will be considered (with "can walk" taking priority over "can't walk"). Here I've said just one extra permission (for walking), but you may if you wish also have a similar one but for surfing - this would only really be useful for water slide-type maps and can certainly be lived without, but it'd be easy enough to implement. These special permissions would be placed on the same tile in both of the layers involved, so you wouldn't walk from one of the special ones onto another one - it'd be "step onto a special permission, see how the player wants to move from there, search all adjacent layers to see if it's possible, change the player's current layer to the one where it's possible, move player". That is, the same as usual, but just checking up to two extra movement layers and perhaps changing the current level value.

Once that's done, just make the bridge tiles appear above or below the player depending on the player's current level. You could have special graphics layers which should only contain the bridges, relate them to the different levels, and change those layers' priorities depending on the player's current level.

It can be rather complicated to imagine, but it makes bridges easier to make, and involves no events at all.

I don't see any reason to restrict yourself to a certain number of layers. An infinite amount can be achieved easily and gives some extra possibilities for level design while not having any negative effects what so ever. My implementation would have 3 sub layers for every layer of the map: tiles, movement and visibility.

Having a setup like that, makes it possible to actually put every part of a city (including floors of buildings) in a single map, thus getting rid of short (but still noticeable) loading times and offering a more connected feeling. A building's windows could then actually allow the player to look outside in the city below.

I've decided for layers I will be using a system that should be a lot easier to use and a lot more intuitive. Each map will have an infinite amount of layers of tiles. Entities will be rendered over the layer that they are on, and the layer above them, but they will not be able to move over areas with tiles on a layer that directly above them. And any layers two or more layers above the entity will be rendered over them. This would allow for intuitive mapping where the dev just creates the map with layers that would make sense, and the game uses that as the collision map for the map. This does make a few things a little weird, like doors need to be on the same layer of the player that will walk through them, but overall it should work a lot better. This also allows me to make a lot more generic tiles, as I can depend on tiles that would be above layer one having something rendered under them to render through the transparency.

Your layer system would thus not allow for different floors of a building to be part of the same map, right? I think all of the loading and not being able to look out of windows or down from balconies makes the world feel less connected. Using an infinite amount of dedicated tile and movement layer's might increase loading time when a whole region is being loaded, it would however allow for a lot more stuff in the region itself.

I've decided for layers I will be using a system that should be a lot easier to use and a lot more intuitive. Each map will have an infinite amount of layers of tiles. Entities will be rendered over the layer that they are on, and the layer above them, but they will not be able to move over areas with tiles on a layer that directly above them. And any layers two or more layers above the entity will be rendered over them. This would allow for intuitive mapping where the dev just creates the map with layers that would make sense, and the game uses that as the collision map for the map. This does make a few things a little weird, like doors need to be on the same layer of the player that will walk through them, but overall it should work a lot better. This also allows me to make a lot more generic tiles, as I can depend on tiles that would be above layer one having something rendered under them to render through the transparency.

I don't have any experience in making a new map system, but this one really doesn't seem that intuitive. Doors are restricted to be on the same layer that the player is on, tiles that the player can walk underneath must be at least 2 layers higher than the player, etc. Highly confusing. Infinite layers is just asking for trouble. Plus, how will you deal with bridges that the player can pass both over and under? Changing the player's layer leads to its own problems and would require some very careful mapping.

I do think that the RMXP 3-layers-plus-events system works. Okay, maybe you could have 5 layers instead of 3 for more flexibility, but it's still a good format. Don't fix what ain't an oft-repeated saying. I mean, what couldn't you map in RMXP using just its 3 layers and events? You don't need anything more than that.

What you should be focussing on is adding more autotiles (RMXP's biggest weakness), and perhaps let tiles be imported for mapping rather than requiring every single used tile to be in the same tileset graphic (the Gen 3 ROMs allow 2 separate tilesets per map, which in itself would be a nicer way of doing things).

Quote originally posted by Hexogene:

Your layer system would thus not allow for different floors of a building to be part of the same map, right? I think all of the loading and not being able to look out of windows or down from balconies makes the world feel less connected. Using an infinite amount of dedicated tile and movement layer's might increase loading time when a whole region is being loaded, it would however allow for a lot more stuff in the region itself.

This definitely sounds like a feature only you want, and can probably be achieved with good mapping skills rather than a specific map format. It's also not what the engine is aiming for (namely, to accurately mimic the official games).

I don't have any experience in making a new map system, but this one really doesn't seem that intuitive. Doors are restricted to be on the same layer that the player is on, tiles that the player can walk underneath must be at least 2 layers higher than the player, etc. Highly confusing. Infinite layers is just asking for trouble. Plus, how will you deal with bridges that the player can pass both over and under? Changing the player's layer leads to its own problems and would require some very careful mapping.

I do think that the RMXP 3-layers-plus-events system works. Okay, maybe you could have 5 layers instead of 3 for more flexibility, but it's still a good format. Don't fix what ain't an oft-repeated saying. I mean, what couldn't you map in RMXP using just its 3 layers and events? You don't need anything more than that.

I see what you are saying, and my thought is: if my system doesn't work in the end, I can change it. I like how the mapping system is looking right now, but if it ends up not working out, I've already programmed the kind of 3 layer system that you were talking about, and I can do it again. But I disagree with you about the confusing part, in the real world bridges have to be higher than you so that you can go under them, which is basically the basis of my system. I don't think of the layers so much as layers of tiles that look nice, but as different heights of different objects in the world. What it also does is simplifies the creation of maps, instead of having to tile the entire map, then go back and do movement permissions, you can just tile the map once and you are finished. And for bridges and such you have layer changes for the player, which are simple.

Quote originally posted by Maruno:

What you should be focussing on is adding more autotiles (RMXP's biggest weakness), and perhaps let tiles be imported for mapping rather than requiring every single used tile to be in the same tileset graphic (the Gen 3 ROMs allow 2 separate tilesets per map, which in itself would be a nicer way of doing things).

Yes... And those both are things that are not even close to becoming features on this engine at the moment. The problem with multiple tilesets is finding a good way to store what tileset is used for each tile. I want to be able to do this at some point, but this will probably require ANOTHER overhaul of my mapping/save system. And auto-tiles are definatly gonna be in the game, but it is not really a priority at the moment.

I see what you are saying, and my thought is: if my system doesn't work in the end, I can change it. I like how the mapping system is looking right now, but if it ends up not working out, I've already programmed the kind of 3 layer system that you were talking about, and I can do it again. But I disagree with you about the confusing part, in the real world bridges have to be higher than you so that you can go under them, which is basically the basis of my system. I don't think of the layers so much as layers of tiles that look nice, but as different heights of different objects in the world. What it also does is simplifies the creation of maps, instead of having to tile the entire map, then go back and do movement permissions, you can just tile the map once and you are finished. And for bridges and such you have layer changes for the player, which are simple.

True, you can always change things if you need to. I was just wondering whether your current system is overkill (which I'm still sure it is as far as infinite layers is concerned).

Perhaps 3 sets of 3 layers would be an alternative. Each set corresponds to a level the player walks on, and contains 3 tile layers a la RMXP. I suppose the player would be inserted between the middle and top layers for the player's current level, which the map-maker needs to change via some kind of eventing at user-defined points for the sake of bridges, etc. Tile passabilities are considered only for tiles in the bottom and middle layers only for the player's current level and below. Oh, and a single "layer" of events, perhaps with each event's level being definable for the sake of making them appear above/below certain layers (their functionality could also depend on the player's current level if necessary, to allow effects depending on the current level), but importantly there's just one layer for events rather than one per level - it makes working with them easier.

Just a suggestion. I haven't thought about it in too much detail so I don't know about all the ramifications.

I presume in your system that a tile's passability is defined at the tileset, like what RMXP does. Priority doesn't need to be defined, though, of course - that information is now defined by the layer the tile is in.

Quote originally posted by danice123:

Yes... And those both are things that are not even close to becoming features on this engine at the moment. The problem with multiple tilesets is finding a good way to store what tileset is used for each tile. I want to be able to do this at some point, but this will probably require ANOTHER overhaul of my mapping/save system. And auto-tiles are definatly gonna be in the game, but it is not really a priority at the moment.

I imagine that would just be a case of keeping a list of tilesets used in the order they're used, and showing them glued together during map-making (see ROM hacking's AdvanceMap). Then each tile simply remembers the cumulative tile ID used there, and a couple of quick calculations are done in-game to figure out which tileset and which tile in that tileset should actually be used.

For example, I choose the 6th tile in the second tileset. The first tileset has 40 tiles in it, so the tile ID saved in the map data (the "cumulative tile ID") is 46. In-game, the renderer sees that 46 is greater than the length of the first tileset, so it subtracts that length from the ID and checks the next tileset for that ID (now 6).

Or you could literally create a new tileset on the fly in-game made up of the component tilesets, and use that for map drawing instead. It means each map ends up using just one tileset graphic. I believe Minecraft does this nowadays (or will once the next version comes out).

True, you can always change things if you need to. I was just wondering whether your current system is overkill (which I'm still sure it is as far as infinite layers is concerned).

Perhaps 3 sets of 3 layers would be an alternative. Each set corresponds to a level the player walks on, and contains 3 tile layers a la RMXP. I suppose the player would be inserted between the middle and top layers for the player's current level, which the map-maker needs to change via some kind of eventing at user-defined points for the sake of bridges, etc. Tile passabilities are considered only for tiles in the bottom and middle layers only for the player's current level and below. Oh, and a single "layer" of events, perhaps with each event's level being definable for the sake of making them appear above/below certain layers (their functionality could also depend on the player's current level if necessary, to allow effects depending on the current level), but importantly there's just one layer for events rather than one per level - it makes working with them easier.

Just a suggestion. I haven't thought about it in too much detail so I don't know about all the ramifications.

I presume in your system that a tile's passability is defined at the tileset, like what RMXP does. Priority doesn't need to be defined, though, of course - that information is now defined by the layer the tile is in.

Ahh... I see where you are mistaken about my system. The tileset is not defined IN ANY WAY in the tileset file (as of yet). The tileset is simply a png of tiles. My system bases passability on the position of tiles in the layers.

Quote originally posted by Maruno:

I imagine that would just be a case of keeping a list of tilesets used in the order they're used, and showing them glued together during map-making (see ROM hacking's AdvanceMap). Then each tile simply remembers the cumulative tile ID used there, and a couple of quick calculations are done in-game to figure out which tileset and which tile in that tileset should actually be used.

For example, I choose the 6th tile in the second tileset. The first tileset has 40 tiles in it, so the tile ID saved in the map data (the "cumulative tile ID") is 46. In-game, the renderer sees that 46 is greater than the length of the first tileset, so it subtracts that length from the ID and checks the next tileset for that ID (now 6).

Or you could literally create a new tileset on the fly in-game made up of the component tilesets, and use that for map drawing instead. It means each map ends up using just one tileset graphic. I believe Minecraft does this nowadays (or will once the next version comes out).

I have taken this and ran with it, spent a couple of hours, and I now have a new tileset system (its like my third...). Basically, you have a bunch of little tilesets that have tiles that are similar (all the grass tiles... etc) and the map will list them and allow you to use tiles from each in the map. The editor has no handling for removeing tilesets from the list however, mostly because that totally destroys the list of tilesets and the whole tileset system.

Ahh... I see where you are mistaken about my system. The tileset is not defined IN ANY WAY in the tileset file (as of yet). The tileset is simply a png of tiles. My system bases passability on the position of tiles in the layers.

Well, it still doesn't sound very user-friendly. It's yet another thing for the mapper to pay attention to; even though you have infinite layers, it's still harder to do. One example of this system making life harder is having a raised patch of land which you can also walk around the north edge of (see picture). In your system, to ensure you couldn't walk off the top of that ledge, you'd need to do change the player's layer and use higher levels. Defining passability in the tileset, though, you wouldn't need to worry about that at all, which makes it much simpler.

I assume, though, that you will define some properties for tiles eventually. For example, water tiles which can only be surfed on, or ledges or tall grass.

Quote originally posted by danice123:

I have taken this and ran with it, spent a couple of hours, and I now have a new tileset system (its like my third...). Basically, you have a bunch of little tilesets that have tiles that are similar (all the grass tiles... etc) and the map will list them and allow you to use tiles from each in the map. The editor has no handling for removeing tilesets from the list however, mostly because that totally destroys the list of tilesets and the whole tileset system.

That's a good idea, to have mini-tilesets which act as categories of tiles.

Perhaps rather than having a tile's ID be a single number which is the cumulative tile ID, you could instead make it an array of the tileset number and ID within that tileset. You'll already have an array of the tilesets used for a map, so it wouldn't be that difficult to tweak.

When removing a tileset from the "used tilesets" list, go through the map to replace any tile from that tileset with a blank tile. Then compact the tileset list and change each tile's tileset number accordingly (i.e. -1 if it is >= the number of the deleted tileset).

Alternatively, keep the system you have but use a bit more maths to decide whether a tile's ID is in the area where the deleted tileset is (if so, make it a blank tile) or is in a later tileset (in which case, subtract the length of the deleted tileset). This isn't difficult either.

You could even check for unused tilesets in a map and remove them when compiling the data, to cut down on saving unused information.

You should have a separate "completely blank" tile somewhere, separate from the tilesets and always accessible. Perhaps put it above the tileset drop-down menu (the one which says "grass" in your screenshot) to show that it's important.

An autotile behaves as a small tileset itself. If you double-click one in RMXP, you'll see an 8x6 set of tiles which the autotile represents. When drawing an autotile on the map, RMXP will look at the 4 adjacent tiles and calculate which of the tiles in that mini-tileset to use (and will also change the adjacent tiles accordingly). Because RMXP has a fixed number of autotiles (7), it finds it easy to manage tile IDs. In fact, many scripts can be seen to account for this (the blank top-left tile counts as an autotile here, so 8 lots of 8x6 is 384, and there are some lines which say things like if @tile_id>=384).

Knowing this, perhaps you should load an autotile in the same way as a mini-tileset, but if that graphic has specific dimensions, recognise it as an autotile rather than a tileset and display/use it differently accordingly. Maybe show the autotiles above your tileset drop-down menu (and don't include them in that drop-down menu), but still consider it behind the scenes to be just another tileset of a specific length when recording the tile ID information. The autotile's tileset needs to be created on the fly from the actual autotile graphic, of course. Autotiles should always be considered to be animated too, even if they only have 1 frame. The data of which tilesets are used in a map will also need to note which ones are actually autotiles, so that it can more easily show them animated (this allows only autotiles to be redrawn rather than all tiles).

It's quite interesting to see how something like this works, and how it could be generalised (i.e. allow a custom number of autotiles). Of course, you may not want to deal with the extra coding involved at the moment. All that matters for now is knowing that it's possible to have autotiles, and more conveniently that your current system can just be tweaked to include them rather than needing a huge overhaul.

Yeah I was already thinking through the code necessary to remove a tileset, basically what you posted, and I decided that I don't really wana deal with that at the moment. I'll have to add it in sometime, but I can leave it out for now. I think I will have to add some sort of tagging/flags onto the image files at some point also, for things like surfing and autotiles, but I haven't found a real good way of attaching that data to the file. A separate file is a possibility, but that is a pain. Maybe if I can find a way to hide a few bytes inside a image file...

By the way, defining more than two ways on a tile (a multi-bridge) is kinda unnecessary and that's way I wouldn't bother with so many tiles/permissions but just mark some specific tiles as bride tiles which have a flag if the player is standing on or under them. NPCs generally just on bridges and finding items dependent on where the player is.

Did I mentioned interfaces? ... Oh yeah, I did.

If you have interest, I can give you the code for my mapper, even if it's just an unfinished rebuilt of the RPG-Maker.

The PokéCommunity

Meta

Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, or The Pokémon Company International. We just love Pokémon.