Pokemon Java Engine

[danice123]

Yep, another Java engine. (This one isn't dead guys!)

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.

 

[Ayutac]

I don't understand, why don't the java developers work together? Much more can accomplished this way!

(Also offering my help)

 

[Lord Varion]

Showing maps is all fine and dandy, but why not something better like these menu's and battle systems?

 

[aasherknight]

This shows promise, hope you keep with it.

 

[danice123]

Cause I'm lazy, Nintendork...

Here you go:

<EDIT> moved images to first post because that makes much more sense</EDIT>

 

[Lord Varion]

That's alot better.
But, ''being lazy'' isn't a good sign.
I won't say anymore, don't want to 'start' anything.

But, If I used Java I'd consider using this.

 

[danice123]

Touche Nintendork... But I'll take your consideration as a complement.

 

[danice123]

Update:
Progress is slow, but there is progress:

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.

Pic for Proof:

 

[Hexogene]

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.

Hex

 

[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?

Your gender icon is red for male. Shoudn't it be blue?

Finally (sorry to ask this), when can we try it out?

 

[danice123]

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.

Hex

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.

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?

Your gender icon is red for male. Shoudn't it be blue?

Finally (sorry to ask this), when can we try it out?

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.

Thanks for the interest!

 

[Hexogene]

Thanks for your reply :)

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.

 

[Ayutac]

In addition, you could simply use Interfaces and cover your hardcoding with a class implementing the interface. Such things are pretty much exactly what interfaces are there for.

 

[andytu]

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.

Thanks for the interest!

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...

Again, best of luck with this, it seems a very well made project.

 

[Maruno]

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.

 

[Hexogene]

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.

 

[danice123]

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.

Example:
Layer 0

Spoiler:

Layer 1

Spoiler:

Layer 2

Spoiler:

 

[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.

 

[Maruno]

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).

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).

 

[danice123]

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.

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.