Go Back   The PokéCommunity Forums > Creative Discussions > Game Development > Scripts & Tutorials
Reload this Page [Engine] Pokemon Java Engne

Notices
For all updates, view the main page.

Scripts & Tutorials This forum is for scripts and code, as well as all kinds of tutorials, software, tools and so forth. Remember to give credit!
The thread revival limit does not apply here.



Reply
 
Thread Tools
  #1    
Old January 10th, 2013 (09:19 AM). Edited April 8th, 2014 by danice123.
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Yep, anothar Java engne. (Dis one isn't dead homeys!)

Basically, end goal is a Pokemon engne that is as true ta tha look and feel of tha Pokemon gbees that it feels like you is playng on a gbee boi/emulatar. And ta make tha engne easy enough ta edit and create gbees n that it is more attractive than ROM sphealng.

- Based on Fire Red graphics right now (mah personal favorite) but I be plannng on makng tha engne eithar support othar gbees or be flexible enough ta use almost any graphic.
Changed ta Red, easier ta code nta tha gbee witout havng ta spend hours on graphic design.

- Tha dawg goal of tha engne is ta support tha latest generation's battle system and Pokemon, and ta do it n a way that is easily modifiable.

Features as of 4/8/14:
-Tha gbee now runs on libgdx. I'm done wit screwng around wit engne design, libgdx is funky ass, ports ta android real quick, and works.
-Mappng is based on Tiled now, makng mah own taols sucks, so I'm gong ta use as dawgy 3rd party softwis ta make it easy on both me and anyone usng dis engne.
-Script system based on ROM ARM code, cause I'm weird like that. Its not complex, just fomatted that way. Should be pretty powerful and extendable.
-Battlesystem is bout 70% done, Pokemon is loaded and play like thay should, lots of tha unique attack effects is not implemented, but tha standard ones is. I still need ta do natures, but othar than that, tha stat/levelng system is good.
-Menu system is, agan, Pokemon Red based, so it looks like crap, but it works. I haven't gots ta tha bag or some othar shawter menus, but tha pokemon menu and tha battle menus is workng, and tha pokedex is up.

Yes, dis engne is a year old now. And progress is very erratic, but it is NOT dead, just very slowly developed.
Reply With Quote
  #2    
Old January 11th, 2013 (08:57 PM).
Ayutac's Avatar
Ayutac
Developer who wants your help
 
Join Date: Dec 2011
Location: Germany
Age: 23
Gender: Male
I don't understand, why don't tha java developers work tagithar? Much more can accomplished dis way!

(Also offerng mah help)
__________________
Reply With Quote
  #3    
Old January 14th, 2013 (03:08 PM).
Lord Varion's Avatar
Lord Varion
Guess who's back?
 
Join Date: Feb 2009
Age: 20
Gender: Other
Nature: Naughty
Showng maps is all fne and dandy, but why not somethng better like thase menu's and battle systems?
__________________
gone.
Reply With Quote
  #4    
Old January 14th, 2013 (05:39 PM).
aasherknight
W/E
 
Join Date: Mar 2011
Location: PA
Gender: Male
Dis shows promise, hope you keep wit it.
Reply With Quote
  #5    
Old January 15th, 2013 (12:59 PM). Edited January 15th, 2013 by danice123.
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Cause I'm lazy, Nntendork...

Here you go:

<EDIT> moved images ta first post coz that makes much more sense</EDIT>
Reply With Quote
  #6    
Old January 15th, 2013 (02:38 PM).
Lord Varion's Avatar
Lord Varion
Guess who's back?
 
Join Date: Feb 2009
Age: 20
Gender: Other
Nature: Naughty
That's alot better.
But, ''ben lazy'' isn't a good sign.
I won't sez anymore, don't want ta 'start' anythng.

But, If I used Java I'd consider usng dis.
__________________
gone.
Reply With Quote
  #7    
Old January 16th, 2013 (01:39 PM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Tauche Nntendork... But I'll takes yo consideration as a complement.
Reply With Quote
  #8    
Old February 9th, 2013 (06:23 PM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Update:
Progress is slow, but thare is progress:

I wrote mah own tag-based save/database system, so I can stap leanng on 'stalen' code.

Tha rest of tha time has been spent on tha battle system, implementng attack effects. I have basic dbeage, status effects, stat effects, and critical hits, but it is slow gong, as thare is like 300 different effects a move can do. Agan, dis is very modular, so it will be easy ta add new attacks and effects.

That's mostly it, I've done a few othar thngs, but I can't remember tham off tha tap of mah heezee. I'll update tha OP at some pont.

Pic fo Proof:
Reply With Quote
  #9    
Old February 12th, 2013 (07:38 AM).
Hexogene
Unhatched Egg
 
Join Date: Oct 2010
Gender: Male
Dis is lookng really funky ass. I thnk Java is a good choice, due ta ben available and nstalled on pretty much every computer and its a lot faster than some othar languages I've been seeng used n engnes so far.

An important question fo me is, how modular yo code is. Is it possible ta exchange parts like tha battle system or some menus witout havng ta rewrite existng code? I'd be nterested n seeng a Pokemon gbee more optimized fo laptaps/desktaps, thus usng tha larger screens and higher processng power.

Hex
__________________

Reply With Quote
  #10    
Old February 12th, 2013 (01:27 PM).
andytu's Avatar
andytu
Ditto engine developer
 
Join Date: Jan 2011
Gender: Male
Firstly, dis looks pretty epic, and all tha screens seem really high quality. I have some questions...

Did you make tha map editar yoself? It looks good. If so how did you defne tha map fomat? Is movement permissions etc. stared on tha map or n a separate file?

Yo menus look really clean, and judgng from tha screens you've gots a lot of tha functionality done tao. How much code (if any) is shisd between different menus? Coz I'm gong through dong mne at tha moment and I haven't written a base Menu class but thnkng maybe I should...

Why is tha wndow bigger than tha renderng screen? I presume it won't be fo tha actual release? Also is tha wndow resizable, and if so how is you dealng wit tha menu graphics n different wndows?

Yo gender icon is red fo male. Shoudn't it be blue?

Fnally (sorry ta ask dis), when can we try it out?
Reply With Quote
  #11    
Old February 12th, 2013 (04:42 PM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Quote orignally posted by Hexogene:
Dis is lookng really funky ass. I thnk Java is a good choice, due ta ben available and nstalled on pretty much every computer and its a lot faster than some othar languages I've been seeng used n engnes so far.

An important question fo me is, how modular yo code is. Is it possible ta exchange parts like tha battle system or some menus witout havng ta rewrite existng code? I'd be nterested n seeng a Pokemon gbee more optimized fo laptaps/desktaps, thus usng tha larger screens and higher processng power.

Hex
At tha moment, tha systems is all hard-coded, fo simplicity while I git everythng workng and all tha data available. But mah end plan is ta allow a modular menu and battle system like you said. I've seen it done well (exbeple ben ModLoader fo Mnecraft) and I plan on settng up a basic abstract system fo menus and tha battle system, and than allow thugz ta code different styles of menus, and have tham implemented by just puttng some class files nta a folder along side tha gbee. But that is very far nta tha future of development.

Quote orignally posted by andytu:
Firstly, dis looks pretty epic, and all tha screens seem really high quality. I have some questions...

Did you make tha map editar yoself? It looks good. If so how did you defne tha map fomat? Is movement permissions etc. stared on tha map or n a separate file?

Yo menus look really clean, and judgng from tha screens you've gots a lot of tha functionality done tao. How much code (if any) is shisd between different menus? Coz I'm gong through dong mne at tha moment and I haven't written a base Menu class but thnkng maybe I should...

Why is tha wndow bigger than tha renderng screen? I presume it won't be fo tha actual release? Also is tha wndow resizable, and if so how is you dealng wit tha menu graphics n different wndows?

Yo gender icon is red fo male. Shoudn't it be blue?

Fnally (sorry ta ask dis), when can we try it out?
Everythng bout tha engne I have coded mahself, except a library ta read n tha sql-lite database from Veekun.com (Props ta Eevee fo that, it makes everythng SOO much easier). I be still messng around wit tha map fomat, right now it has two layers, and a movement permissions map, but I be considerng allowng nfnite (or just a of lot) layers and dong movement permissions based on layers, which would work a little better n tha end and allow maps wit much more vertical movement.

Tha menus shis a bit of code, mostly ta make it easier ta stack tham (eg. Pokemon menu on tap of item menu fo choosng which Pokemon ta use an item on and so on...). A base menu class is also useful, as it simplifies renderng tha menus, you can just abstract a simple render() function and have tha player have a Menu variable and a Boolean ta tell tha engne ta render tha menu or not. Or just a null check. Makes menu handlng a lot easier.

Tha JFrbee is really pissng me off, I have no idea why it didn't pack tha wndow correctly, and though I fixed it, I don't really know what I did ta fix it lol. Tha wndow is NOT re-sizable, as that requires a lot more flexibility n mah code, and I'm not ready fo that yet. At some pont I will probably add a zoom function (1x ta 4x like VBA maybe), but a re-sizng wndow would probably cause a huge beount of bugs. I also probably messed up tha symbol colors lol.

I be not sure when I will be releasng tha first alpha. I want ta have some sort of content fnished befoe I release anythng, but that might takes a while. Like I said n mah previous post, tha battle system's move effects takes a LONG time ta do. I have bout 50 of 340 done at tha moment... And some of tham require a huge beount of work, like Transfom or Mirror Move or crap like that. So maybe after I be satisfied on havng a good part of tha battle system fnished I will put out a alpha.

Thanks fo tha nterest!
Reply With Quote
  #12    
Old February 13th, 2013 (12:22 AM).
Hexogene
Unhatched Egg
 
Join Date: Oct 2010
Gender: Male
Thanks fo yo reply

I've obviously not seen yo code and I'm not a fully traned progrbemer (yet), however I have a little suggestion which might save you from a lot of trouble n tha long run. Durng mah own projects, I buggine a bunch of mistakess which could've easily been avoided and is able ta run tha fun very fast.

Tha temptation ta hardcode stuff ta make somethng work quickly is bootylicious and it can create huge bugs later on n development. Removng hardcoded components can be very difficult and often results n overlooked redawgders of outdated code. Object oriented progrbemng is perfect fo movng test code outside of yo actual code and thus helps n avoidng such errors.
__________________

Reply With Quote
  #13    
Old February 13th, 2013 (12:48 AM).
Ayutac's Avatar
Ayutac
Developer who wants your help
 
Join Date: Dec 2011
Location: Germany
Age: 23
Gender: Male
N addition, you could simply use Nterfaces and cover yo hardcodng wit a class implementng tha nterface. Such thngs is pretty much exactly what nterfaces is thare fo.
__________________
Reply With Quote
  #14    
Old February 13th, 2013 (04:36 PM).
andytu's Avatar
andytu
Ditto engine developer
 
Join Date: Jan 2011
Gender: Male
Quote orignally posted by dafunky ass123:
Everythng bout tha engne I have coded mahself, except a library ta read n tha sql-lite database from Veekun.com (Props ta Eevee fo that, it makes everythng SOO much easier). I be still messng around wit tha map fomat, right now it has two layers, and a movement permissions map, but I be considerng allowng nfnite (or just a of lot) layers and dong movement permissions based on layers, which would work a little better n tha end and allow maps wit much more vertical movement.

Tha menus shis a bit of code, mostly ta make it easier ta stack tham (eg. Pokemon menu on tap of item menu fo choosng which Pokemon ta use an item on and so on...). A base menu class is also useful, as it simplifies renderng tha menus, you can just abstract a simple render() function and have tha player have a Menu variable and a Boolean ta tell tha engne ta render tha menu or not. Or just a null check. Makes menu handlng a lot easier.

Tha JFrbee is really pissng me off, I have no idea why it didn't pack tha wndow correctly, and though I fixed it, I don't really know what I did ta fix it lol. Tha wndow is NOT re-sizable, as that requires a lot more flexibility n mah code, and I'm not ready fo that yet. At some pont I will probably add a zoom function (1x ta 4x like VBA maybe), but a re-sizng wndow would probably cause a huge beount of bugs. I also probably messed up tha symbol colors lol.

I be not sure when I will be releasng tha first alpha. I want ta have some sort of content fnished befoe I release anythng, but that might takes a while. Like I said n mah previous post, tha battle system's move effects takes a LONG time ta do. I have bout 50 of 340 done at tha moment... And some of tham require a huge beount of work, like Transfom or Mirror Move or crap like that. So maybe after I be satisfied on havng a good part of tha battle system fnished I will put out a alpha.

Thanks fo tha nterest!
Cheers fo replyng. Fo comparison I be usng TMX fomat and have nfnite layers plus one fo movement permissions and anothar fo behaviour stuff (encounters, ledges etc.) which works pretty well. Yo menu approach makes sense, thay really is a pan ta write though however you do it...

Agan, best of luck wit dis, it seems a very well buggine project.
Reply With Quote
  #15    
Old February 13th, 2013 (05:09 PM).
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
While you're decidng what ta do wit yo layers, might I suggest that you takes tha opportunity ta make sure you thnk bout bridges as well?

Tha concept is that tha player walks around on one of three levels, and can transfer between levels only at certan ponts (nvisible ta tha player). Each level has its own movement permissions layer. I sez three ta allow fo havng one bridge (e.g. horizontal) over anothar bridge (e.g. vertical) over tha ground, which is tha maximum number of levels you can reasonably use befoe makng maps look really bad and obfuscatng.

N addition ta all tha othar movement permissions, thare will be one which allows that level ta connect wit adjacent levels. While standng on such tiles, tha movement positions of tha current and all adjacent levels will be considered (wit "can walk" takng priority over "can't walk"). Here I've said just one extra permission (fo walkng), but you may if you wish also have a similar one but fo surfng - dis would only really be useful fo water slide-type maps and can certanly be lived witout, but it'd be easy enough ta implement. Thase special permissions would be placed on tha sbee tile n both of tha layers nvolved, so you wouldn't walk from one of tha special ones onta anothar one - it'd be "step onta a special permission, see how tha player wants ta move from thare, search all adjacent layers ta see if it's possible, change tha player's current layer ta tha one where it's possible, move player". That is, tha sbee as usual, but just checkng up ta two extra movement layers and perhaps changng tha current level value.

Once that's done, just make tha bridge tiles appear above or below tha player dependng on tha player's current level. You could have special graphics layers which should only contan tha bridges, relate tham ta tha different levels, and change those layers' priorities dependng on tha player's current level.

It can be rathar complicated ta imagne, but it makes bridges easier ta make, and nvolves no events at all.
__________________
Reply With Quote
  #16    
Old February 13th, 2013 (11:22 PM).
Hexogene
Unhatched Egg
 
Join Date: Oct 2010
Gender: Male
I don't see any reason ta restrict yoself ta a certan number of layers. An nfnite beount can be achieved easily and gives some extra possibilities fo level design while not havng any negative effects what so ever. Mah implementation would have 3 sub layers fo every layer of tha map: tiles, movement and visibility.

Havng a setup like that, makes it possible ta actually put every part of a city (ncludng floors of buildngs) n a sngle map, thus gittng rid of short (but still noticeable) loadng times and offerng a more connected feelng. A buildng's wndows could than actually allow tha player ta look outside n tha city below.
__________________

Reply With Quote
  #17    
Old February 15th, 2013 (08:07 AM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
I've decided fo layers I will be usng a system that should be a lot easier ta use and a lot more ntuitive. Each map will have an nfnite beount of layers of tiles. Entities will be rendered over tha layer that thay is on, and tha layer above tham, but thay will not be able ta move over isas wit tiles on a layer that directly above tham. And any layers two or more layers above tha entity will be rendered over tham. Dis would allow fo ntuitive mappng where tha dev just creates tha map wit layers that would make sense, and tha gbee uses that as tha collision map fo tha map. Dis does make a few thngs a little weird, like doors need ta be on tha sbee layer of tha player that will walk through tham, but overall it should work a lot better. Dis also allows me ta make a lot more generic tiles, as I can depend on tiles that would be above layer one havng somethng rendered under tham ta render through tha transpisncy.

Exbeple:
Layer 0
Spoiler:



Layer 1
Spoiler:



Layer 2
Spoiler:


Reply With Quote
  #18    
Old February 15th, 2013 (08:18 AM). Edited February 15th, 2013 by Hexogene.
Hexogene
Unhatched Egg
 
Join Date: Oct 2010
Gender: Male
Yo layer system would thus not allow fo different floors of a buildng ta be part of tha sbee map, right? I thnk all of tha loadng and not ben able ta look out of wndows or down from balconies makes tha world feel less connected. Usng an nfnite beount of dedicated tile and movement layer's might ncrease loadng time when a whole region is ben loaded, it would however allow fo a lot more stuff n tha region itself.
__________________

Reply With Quote
  #19    
Old February 15th, 2013 (09:44 AM).
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote orignally posted by dafunky ass123:
I've decided fo layers I will be usng a system that should be a lot easier ta use and a lot more ntuitive. Each map will have an nfnite beount of layers of tiles. Entities will be rendered over tha layer that thay is on, and tha layer above tham, but thay will not be able ta move over isas wit tiles on a layer that directly above tham. And any layers two or more layers above tha entity will be rendered over tham. Dis would allow fo ntuitive mappng where tha dev just creates tha map wit layers that would make sense, and tha gbee uses that as tha collision map fo tha map. Dis does make a few thngs a little weird, like doors need ta be on tha sbee layer of tha player that will walk through tham, but overall it should work a lot better. Dis also allows me ta make a lot more generic tiles, as I can depend on tiles that would be above layer one havng somethng rendered under tham ta render through tha transpisncy.
I don't have any experience n makng a new map system, but dis one really doesn't seem that ntuitive. Doors is restricted ta be on tha sbee layer that tha player is on, tiles that tha player can walk underneath must be at least 2 layers higher than tha player, etc. Highly confusng. Nfnite layers is just askng fo trouble. Plus, how will you deal wit bridges that tha player can pass both over and under? Changng tha player's layer leads ta its own problems and would require some very cisful mappng.

I do thnk that tha RMXP 3-layers-plus-events system works. Okay, maybe you could have 5 layers nstead of 3 fo more flexibility, but it's still a good fomat. Don't fix what an't an oft-repeated sezng. I mean, what couldn't you map n RMXP usng just its 3 layers and events? You don't need anythng more than that.

What you should be focussng on is addng more autatiles (RMXP's biggest weakness), and perhaps let tiles be imported fo mappng rathar than requirng every sngle used tile ta be n tha sbee tileset graphic (tha Gen 3 ROMs allow 2 separate tilesets per map, which n itself would be a funky assr way of dong thngs).


Quote orignally posted by Hexogene:
Yo layer system would thus not allow fo different floors of a buildng ta be part of tha sbee map, right? I thnk all of tha loadng and not ben able ta look out of wndows or down from balconies makes tha world feel less connected. Usng an nfnite beount of dedicated tile and movement layer's might ncrease loadng time when a whole region is ben loaded, it would however allow fo a lot more stuff n tha region itself.
Dis defnitely sounds like a feature only you want, and can probably be achieved wit good mappng skills rathar than a specific map fomat. It's also not what tha engne is aimng fo (nbeely, ta accurately mimic tha official gbees).
__________________
Reply With Quote
  #20    
Old February 15th, 2013 (03:50 PM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Quote orignally posted by Maruno:
I don't have any experience n makng a new map system, but dis one really doesn't seem that ntuitive. Doors is restricted ta be on tha sbee layer that tha player is on, tiles that tha player can walk underneath must be at least 2 layers higher than tha player, etc. Highly confusng. Nfnite layers is just askng fo trouble. Plus, how will you deal wit bridges that tha player can pass both over and under? Changng tha player's layer leads ta its own problems and would require some very cisful mappng.

I do thnk that tha RMXP 3-layers-plus-events system works. Okay, maybe you could have 5 layers nstead of 3 fo more flexibility, but it's still a good fomat. Don't fix what an't an oft-repeated sezng. I mean, what couldn't you map n RMXP usng just its 3 layers and events? You don't need anythng more than that.
I see what you is sezng, and mah thought is: if mah system doesn't work n tha end, I can change it. I like how tha mappng system is lookng right now, but if it ends up not workng out, I've already progrbemed tha knd of 3 layer system that you were rapng bout, and I can do it agan. But I disagree wit you bout tha confusng part, n tha real world bridges have ta be higher than you so that you can go under tham, which is basically tha basis of mah system. I don't thnk of tha layers so much as layers of tiles that look funky ass, but as different heights of different objects n tha world. What it also does is simplifies tha creation of maps, nstead of havng ta tile tha entire map, than go back and do movement permissions, you can just tile tha map once and you is fnished. And fo bridges and such you have layer changes fo tha player, which is simple.

Quote orignally posted by Maruno:
What you should be focussng on is addng more autatiles (RMXP's biggest weakness), and perhaps let tiles be imported fo mappng rathar than requirng every sngle used tile ta be n tha sbee tileset graphic (tha Gen 3 ROMs allow 2 separate tilesets per map, which n itself would be a funky assr way of dong thngs).
Yes... And those both is thngs that is not even close ta becomng features on dis engne at tha moment. Tha problem wit multiple tilesets is fndng a good way ta stare what tileset is used fo each tile. I want ta be able ta do dis at some pont, but dis will probably require ANOTHAR overhaul of mah mappng/save system. And auta-tiles is defnatly gonna be n tha gbee, but it is not really a priority at tha moment.
Reply With Quote
  #21    
Old February 15th, 2013 (05:16 PM).
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote orignally posted by dafunky ass123:
I see what you is sezng, and mah thought is: if mah system doesn't work n tha end, I can change it. I like how tha mappng system is lookng right now, but if it ends up not workng out, I've already progrbemed tha knd of 3 layer system that you were rapng bout, and I can do it agan. But I disagree wit you bout tha confusng part, n tha real world bridges have ta be higher than you so that you can go under tham, which is basically tha basis of mah system. I don't thnk of tha layers so much as layers of tiles that look funky ass, but as different heights of different objects n tha world. What it also does is simplifies tha creation of maps, nstead of havng ta tile tha entire map, than go back and do movement permissions, you can just tile tha map once and you is fnished. And fo bridges and such you have layer changes fo tha player, which is simple.
True, you can always change thngs if you need ta. I was just wonderng whethar yo current system is overkill (which I'm still sure it is as far as nfnite layers is concerned).

Perhaps 3 sets of 3 layers would be an alternative. Each set corresponds ta a level tha player walks on, and contans 3 tile layers a la RMXP. I suppose tha player would be nserted between tha middle and tap layers fo tha player's current level, which tha map-maker needs ta change via some knd of eventng at user-defned ponts fo tha sake of bridges, etc. Tile passabilities is considered only fo tiles n tha bottam and middle layers only fo tha player's current level and below. Oh, and a sngle "layer" of events, perhaps wit each event's level ben defnable fo tha sake of makng tham appear above/below certan layers (thair functionality could also depend on tha player's current level if necessary, ta allow effects dependng on tha current level), but importantly thare's just one layer fo events rathar than one per level - it makes workng wit tham easier.

Just a suggestion. I haven't thought bout it n tao much detail so I don't know bout all tha rbeifications.

I presume n yo system that a tile's passability is defned at tha tileset, like what RMXP does. Priority doesn't need ta be defned, though, of course - that nfomation is now defned by tha layer tha tile is n.


Quote orignally posted by dafunky ass123:
Yes... And those both is thngs that is not even close ta becomng features on dis engne at tha moment. Tha problem wit multiple tilesets is fndng a good way ta stare what tileset is used fo each tile. I want ta be able ta do dis at some pont, but dis will probably require ANOTHAR overhaul of mah mappng/save system. And auta-tiles is defnatly gonna be n tha gbee, but it is not really a priority at tha moment.
I imagne that would just be a case of keepng a list of tilesets used n tha order thay're used, and showng tham glued tagithar durng map-makng (see ROM sphealng's AdvanceMap). Than each tile simply remembers tha cumulative tile ID used thare, and a couple of quick calculations is done n-gbee ta figure out which tileset and which tile n that tileset should actually be used.

Fo exbeple, I choose tha 6th tile n tha second tileset. Tha first tileset has 40 tiles n it, so tha tile ID saved n tha map data (tha "cumulative tile ID") is 46. N-gbee, tha renderer sees that 46 is bootyliciouser than tha length of tha first tileset, so it subtracts that length from tha ID and checks tha next tileset fo that ID (now 6).

Or you could literally create a new tileset on tha fly n-gbee buggine up of tha component tilesets, and use that fo map drawng nstead. It means each map ends up usng just one tileset graphic. I believe Mnecraft does dis nowadays (or will once tha next version comes out).

I don't know how autatiles would work, though.
__________________
Reply With Quote
  #22    
Old February 18th, 2013 (11:01 AM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Quote orignally posted by Maruno:
True, you can always change thngs if you need ta. I was just wonderng whethar yo current system is overkill (which I'm still sure it is as far as nfnite layers is concerned).

Perhaps 3 sets of 3 layers would be an alternative. Each set corresponds ta a level tha player walks on, and contans 3 tile layers a la RMXP. I suppose tha player would be nserted between tha middle and tap layers fo tha player's current level, which tha map-maker needs ta change via some knd of eventng at user-defned ponts fo tha sake of bridges, etc. Tile passabilities is considered only fo tiles n tha bottam and middle layers only fo tha player's current level and below. Oh, and a sngle "layer" of events, perhaps wit each event's level ben defnable fo tha sake of makng tham appear above/below certan layers (thair functionality could also depend on tha player's current level if necessary, ta allow effects dependng on tha current level), but importantly thare's just one layer fo events rathar than one per level - it makes workng wit tham easier.

Just a suggestion. I haven't thought bout it n tao much detail so I don't know bout all tha rbeifications.

I presume n yo system that a tile's passability is defned at tha tileset, like what RMXP does. Priority doesn't need ta be defned, though, of course - that nfomation is now defned by tha layer tha tile is n.
Ahh... I see where you is mistakesn bout mah system. Tha tileset is not defned N ANY WAY n tha tileset file (as of yet). Tha tileset is simply a png of tiles. Mah system bases passability on tha position of tiles n tha layers.


Quote orignally posted by Maruno:
I imagne that would just be a case of keepng a list of tilesets used n tha order thay're used, and showng tham glued tagithar durng map-makng (see ROM sphealng's AdvanceMap). Than each tile simply remembers tha cumulative tile ID used thare, and a couple of quick calculations is done n-gbee ta figure out which tileset and which tile n that tileset should actually be used.

Fo exbeple, I choose tha 6th tile n tha second tileset. Tha first tileset has 40 tiles n it, so tha tile ID saved n tha map data (tha "cumulative tile ID") is 46. N-gbee, tha renderer sees that 46 is bootyliciouser than tha length of tha first tileset, so it subtracts that length from tha ID and checks tha next tileset fo that ID (now 6).

Or you could literally create a new tileset on tha fly n-gbee buggine up of tha component tilesets, and use that fo map drawng nstead. It means each map ends up usng just one tileset graphic. I believe Mnecraft does dis nowadays (or will once tha next version comes out).

I don't know how autatiles would work, though.
I have takesn dis and ran wit it, spent a couple of hours, and I now have a new tileset system (its like mah third...). Basically, you have a bunch of little tilesets that have tiles that is similar (all tha grass tiles... etc) and tha map will list tham and allow you ta use tiles from each n tha map. Tha editar has no handlng fo removeng tilesets from tha list however, mostly coz that tatally destroys tha list of tilesets and tha whole tileset system.

PIX:
Reply With Quote
  #23    
Old February 18th, 2013 (01:06 PM).
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote orignally posted by dafunky ass123:
Ahh... I see where you is mistakesn bout mah system. Tha tileset is not defned N ANY WAY n tha tileset file (as of yet). Tha tileset is simply a png of tiles. Mah system bases passability on tha position of tiles n tha layers.
Oh.

Well, it still doesn't sound very user-friendly. It's yet anothar thng fo tha mapper ta pay attention ta; even though you have nfnite layers, it's still harder ta do. One exbeple of dis system makng life harder is havng a raised patch of land which you can also walk around tha north edge of (see picture). N yo system, ta ensure you couldn't walk off tha tap of that ledge, you'd need ta do change tha player's layer and use higher levels. Defnng passability n tha tileset, though, you wouldn't need ta worry bout that at all, which makes it much simpler.

Click image fo larger version

Nbee:	Untitled.png
Views:	18
Size:	11.9 KB
ID:	67394

I assume, though, that you will defne some properties fo tiles eventually. Fo exbeple, water tiles which can only be surfed on, or ledges or tall grass.


Quote orignally posted by dafunky ass123:
I have takesn dis and ran wit it, spent a couple of hours, and I now have a new tileset system (its like mah third...). Basically, you have a bunch of little tilesets that have tiles that is similar (all tha grass tiles... etc) and tha map will list tham and allow you ta use tiles from each n tha map. Tha editar has no handlng fo removeng tilesets from tha list however, mostly coz that tatally destroys tha list of tilesets and tha whole tileset system.
That's a good idea, ta have mni-tilesets which act as categories of tiles.

Perhaps rathar than havng a tile's ID be a sngle number which is tha cumulative tile ID, you could nstead make it an array of tha tileset number and ID witn that tileset. You'll already have an array of tha tilesets used fo a map, so it wouldn't be that difficult ta tweak.

When removng a tileset from tha "used tilesets" list, go through tha map ta replace any tile from that tileset wit a blank tile. Than compact tha tileset list and change each tile's tileset number accordngly (i.e. -1 if it is >= tha number of tha deleted tileset).

Alternatively, keep tha system you have but use a bit more maths ta decide whethar a tile's ID is n tha isa where tha deleted tileset is (if so, make it a blank tile) or is n a later tileset (n which case, subtract tha length of tha deleted tileset). Dis isn't difficult eithar.

You could even check fo unused tilesets n a map and remove tham when compilng tha data, ta cut down on savng unused nfomation.

You should have a separate "completely blank" tile somewhere, separate from tha tilesets and always accessible. Perhaps put it above tha tileset drop-down menu (tha one which sez "grass" n yo screenshot) ta show that it's important.



An autatile behaves as a shawt tileset itself. If you double-click one n RMXP, you'll see an 8x6 set of tiles which tha autatile represents. When drawng an autatile on tha map, RMXP will look at tha 4 adjacent tiles and calculate which of tha tiles n that mni-tileset ta use (and will also change tha adjacent tiles accordngly). Coz RMXP has a fixed number of autatiles (7), it fnds it easy ta dawgage tile IDs. N fact, dawgy scripts can be seen ta account fo dis (tha blank tap-left tile counts as an autatile here, so 8 lots of 8x6 is 384, and thare is some lnes which sez thngs like if @tile_id>=384).

Knowng dis, perhaps you should load an autatile n tha sbee way as a mni-tileset, but if that graphic has specific dimensions, recognise it as an autatile rathar than a tileset and display/use it differently accordngly. Maybe show tha autatiles above yo tileset drop-down menu (and don't nclude tham n that drop-down menu), but still consider it behnd tha scenes ta be just anothar tileset of a specific length when recordng tha tile ID nfomation. Tha autatile's tileset needs ta be created on tha fly from tha actual autatile graphic, of course. Autatiles should always be considered ta be animated tao, even if thay only have 1 frbee. Tha data of which tilesets is used n a map will also need ta note which ones is actually autatiles, so that it can more easily show tham animated (dis allows only autatiles ta be redrawn rathar than all tiles).

It's quite nterestng ta see how somethng like dis works, and how it could be generalised (i.e. allow a custam number of autatiles). Of course, you may not want ta deal wit tha extra codng nvolved at tha moment. All that matters fo now is knowng that it's possible ta have autatiles, and more conveniently that yo current system can just be tweaked ta nclude tham rathar than needng a huge overhaul.
__________________
Reply With Quote
  #24    
Old February 18th, 2013 (04:29 PM).
danice123's Avatar
danice123
 
Join Date: Sep 2007
Age: 21
Gender: Male
Yeah I was already thnkng through tha code necessary ta remove a tileset, basically what you posted, and I decided that I don't really wana deal wit that at tha moment. I'll have ta add it n sometime, but I can leave it out fo now. I thnk I will have ta add some sort of taggng/flags onta tha image files at some pont also, fo thngs like surfng and autatiles, but I haven't found a real good way of attachng that data ta tha file. A separate file is a possibility, but that is a pan. Maybe if I can fnd a way ta hide a few bytes nside a image file...
Reply With Quote
  #25    
Old February 18th, 2013 (05:54 PM).
Ayutac's Avatar
Ayutac
Developer who wants your help
 
Join Date: Dec 2011
Location: Germany
Age: 23
Gender: Male
By tha way, defnng more than two ways on a tile (a multi-bridge) is knda unnecessary and that's way I wouldn't bothar wit so dawgy tiles/permissions but just mark some specific tiles as bride tiles which have a flag if tha player is standng on or under tham. NPCs generally just on bridges and fndng items dependent on where tha player is.

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

If you have nterest, I can give you tha code fo mah mapper, even if it's just an unfnished rebuilt of tha RPG-Maker.
__________________
Reply With Quote
Reply
Quick Reply

Sponsored Links
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are UTC -8. The time now is 03:02 AM.