Features and Components Suggestions

[herbertmilhomme]

Would like to use this as a suggestion box where users can submit their own creative ideas and inputs. A single area where everything can be stored and presented. You'll know whether it's been done, included, or mentioned, because everything will be in one area where you can scroll thru and view. I would also like to encourage the use of a voting system as well, positive ideas should be encouraged, while ideas that are not so good would be dismissed or skipped over until they hold enough support to deem it worthy.

List of ideas that can be suggested may fall in any of the categories labeled on this ticket:

• UI designs that we can create using unity's engine
• C# scripts that can be implemented to improve the game's/framework's core functionality and features.
• General and generic gimmicks that would add a bit of flare and flavor to a user's a experience, whether it be during the developments phase or while in-game built into the framework.
• Feel free to ask questions on how to create certain code examples/demonstrations (I'll use questions to write wiki's or sample scripts in the unit test project that display code in use and it's functioning status).

New channels/issues can and should be opened up to add dialog and conversation to ideas suggested. I would prefer this to be a list of new ideas with a sample explanation of how it would work, or what the benefits would be if the idea were implemented. If users agree or disagree, they can either thumbs-up or thumbs-down, or they can open a new issue and make their case while tagging any representative or parties that capable of listening to their case.

Please show your support by either thumbs-up or thumbs-down on this post, to help reflect if this idea is worth sustaining long term or will be scrapped as a short-term fling/concept that didn't make the cut.

--Thank you, Flak.

[Fallenleader]

The first goal should be abstracting away all engine components required to run "pokemon" away from Unity, and interfacing to them. Not sure how far along you have managed, but my last look at Pokemon Unity blended too much together making it nearly impossible to leverage the code with a new skin, in this case a 3D environment.
Layers should look similar to this in order from high level unity dependent to low level C# abstract:

• Anything related to on screen sprites, animations, textures, over world handling.
• interface to read the pokemon data and apply it in a game manager gameobject at runtime. This includes the logic to read/write saves.
• Low level pure C# data. This is the code than is engine independent and makes the framework for an engine to handle items, pokemon data, and provides a base system for battle states, such as buff/debuff, status effects, etc.

Ideally, this setup would allow anyone to replace the high level portion with any other method of content, regardless of 3D or 2D by writing their own hooks to the mid level code. The midlevel should interface between the pure C# and Unity in such a way that everything from give pokemon, generate a wild battle, attack, stats, damage, etc can be printed out in debug.log, or even ran as a purely text based game. The low level should be contained in such a way one can easily read and convert it to other languages and write their own interfacing for that engine, be it blueprints, C++, etc. This would as a consequence allow the solution to be engine agnostic AND easier to flesh out.
By splitting this out, it also allows for easier fixes and potentially speed improvements.

[herbertmilhomme]

@Fallenleader,

I will admit this post has caught me off guard, so i've pretty much only skimmed the surface of the content/post (will re-read it again in a bit). But, i didnt think my contributions to the project were still being followed or of any interest to anyone, at least not anymore. With all of that being said, i have uploaded some new commits that does pretty much as you've suggested, as it's been more core and driving focus to separate pokemon logic/mechanic away from the engine or platform that utilizes it.

I just want to make sure that i understand you clearly that this isnt in response to PKUE original project, as i am no longer a part of that repository as a leading dev member or contributor. Your response is made entirely to me or my branch as an individual, right?

If that's the case then, yes, i would repeat myself by admitting that i have made some new commits that separate backend logic from frontend unity/design, and still intend to upload a few more that continues that trend.

[Fallenleader]

Glad to hear that. No, my comment was directly to your branch, as it is the most up to date. I was working on a 3D pokemon gen 1 before LGPE was ever announced, using assets data mined from the 3DS games. This project came out, and looked like a good framework, but alas, it was an utter mess.
Being I am learning UE now as well, it would be easier to convert between engines having a solid agnostic framework. Coding has been a thorn in my side for a long time.

[Fallenleader]

Oh, and another good idea is to redo the data types used in the game. I noticed a LOT of bytes being used, which on some platforms is actually slower than defaulting to ints. It made sense back in the days of Gameboy - NDS to utilize precise data typing because of heavily limited memory, but nowadays even devices like the 3DS (which no one should be trying to target given no leaked SDK + Unity, meaning watermarks everywhere), Vita, and mobile phones tend to have more than enough memory to compensate for the ints, and the speed gains are preferable.
While the ability to potentially import actual pokemon data from official games may seem like a cool idea, it wouldn't likely be a good idea to have the project tie in to official games in any shape, so the default goals should be speed and engine abstraction.
I actually managed to get a little progress in this regard myself, going from accurate but slow, to actually usable as a demonstration once.
https://www.dropbox.com/s/n80lnisu3y6aco8/VID_20171226_211703906.mp4

[herbertmilhomme]

I'm really happy that as a supporter, you reflect the end user that I've been dedicated and focused on helping. From your feedback and concerns, with your experience and all is exactly why I pursue separating the two layers into distinct and standalone projects/tools.

As far as your second post goes, I actually didn't use exact variables because I wanted to favor importing pokemon data and rips. Honestly, furthest thought from my mind as I actually don't even care about the hard copies or dragging player data over. That's something end users can do on their own. To be honest, part of the reason was because I wanted to stay as true to the original model as possible, since it's a remake... to emulate the source material. Also, I was mostly focused on protecting the game from outside influence. Easier to protect functions when data works within relative expectations. Just because data saves as a byte doesn't mean performance will suffer. Not as if we're doing any math and equations on it. If the data only needs 1 byte of data, no need to leave it uncapped. I would prefer to not see pokemon stats with "999999999" in places they don't belong. I think whether intentional by player, or accident by developers is a little more that ridiculous.

[Fallenleader]

I understand the concern there, after all this is a free project for multiple reasons, some hopefully obvious, so it makes sense not to invest time in hard capping a bunch of ints to real expectations. My suggestion for going that route was solely based on the Vita and 3DS in particular which don't have the most noteworthy of CPUs in terms of speed. The overhead for them is noticeable once you start going beyond gen 3 setups into the gen IV+ territory where more advanced formulas are used, assuming you are polling stats to imitate the originals.
Either way, I am hoping to re-approach my original project again thanks to LGPE existing now (I still curse the removal of wild battles, as it traded one grind for another).

[herbertmilhomme]

I'm sorry, it's not that I don't respect your opinion. Just in grand scheme of things, there's more reasons (pro vs con) to cap than there is to uncap.

I wrote ALL of the code in the project (I reviewed every commit entry or have had modified and tweaked enough of it to know what's what and where everything is). By formulas I refer to the metrics used when testing whether or not an int is better than a byte. I'm not using functions and data processing around the values... in pretty much all loops there's no bytes (as someone had made a similar remark to speed of performance). Storing value in appropriate size and running processes on data in exact size are two different arguements. Remember, I stated that they were stored, not processed. Also, most users plan on relying on saving LARGE amounts of data values. Those variables take up space, and need to go somewhere, when not actively used in mem cache. For me, most issues for things is often times size and not necessarily speed. It's easier to Ctrl+F "byte, short, long, float, decimal" to int, than it is to do the reverse. It's actually less of an issue writing code with ideas implemented, because the concern is easier to resolve than it is to fix. If someone doesn't like concept, it's easier to take it out and change, than it is to go in and implement.

Remember, in a digital age of inclusivity, most users prefer net play with friends, than they would prefer to play alone. In a pokemon game, eventually, NPCs lack experience that another player would give. Saving in SQL, size matters... and reading and writing back and forth is more of an issue if the variables are not correct. Again... I don't care about anything else when building framework except helping those who can't code for themselves. The platform another person decides to use is not even a thought or preference. I'm straight, running and designing (testing) for PC, all the way. Most PC games I've seen source code for (all of them), will cap data variables to exact size, and use formulas around them (as mentioned earlier).

Expectation vs reality, is issues like "missingno", that glitch that occurs because data is loaded outside of game's variable limit. If code is written for numbers to stay inside brackets at all times, less chances for those issues (what I was trying to say earlier with "999999" reference). You expect a number between 1 and 10, so you write code for numbers between 1 and 10, and default it to either return 1-10 or error (expected results). That's how I've addressed most of the code I've written. Unity doesn't do good with throwing exceptions and doc says it eats resources trying to handle them. It's recommended to code around errors and intercept them by generating solutions in code, than it is to ignore them and throw bug splat in user/player face. Which goes back to example of 1-10, and writing code to meet expectations. Having data caps offers more pros than cons.

TLDR; I'll welcome a discussion to debate changing it, but I think this is a lot better as you can perform your own metrics for and against cause in a reasonable time frame, using ctrl+F.
Also, I'm not big in pokemon community, can you explain what LGPE stands for? All I can think of is "lead green..." which I'm sure that's what it's not.

[Fallenleader]

Ah, sorry bud, I was agreeing. Remember, I am stuck between beginner and intermediate. I can code some complex things, but when it comes to tying them together? There is a reason no project I have attempted to date has made it to release state. I was confusing the age old argument of int is better than byte. Initial processing is fine for loading and storing, so it makes absolutely perfect sense.
Also, I don't code for errors. I literally will spend time dedicated to fixing an problem personally. Might not be viable in a professional environment, but for a freelance homebrew dev, I can spend as much time as I dang well please on a bug :P

LGPE = Let's Go Pikachu/Eevee. The Switch remake of gen 1. They changed wild battle mechanics to capturing mechanics, but instead of solving the issue of grinding wild battles, they just traded the wild grind into a capture grind at certain points of the game. The only way to stay ahead at a just high enough for a challenge, just low enough not to crush the opposition, you have to invest a decent hour catching in every section of the game, as well as battling every trainer. It literally broke the overall experience for me.

The biggest question is knowing how pokemon stadium stores and recalls data, is the project in a current state where you can name the CS files I need to build from to make a stadium remake at this point? All tadium free battle does it pull from preset move and level lists of pokemon, and generates them with 0-IV/EVs for fairness. I would love to collab on the graphical side if you can help with the code side. This portion would finalize the backend needed for just the pokemon alone, and would give me a chance to get familiar with the changes.

[herbertmilhomme]

@Fallenleader Sorry, the last paragraph was edited and didnt notice it. I wouldve been fine with notification on a second post submit. I've been modifying and improving the current code to fix errors and bring up to standards. Currently, all of the tests are pretty much passing with success, and i will be moving on to incorporate more of the code to handle the missing features and functions i've ignored.

I dont have resources for pokemon stadium, and do not know anything about it, or it's mechanic (game code/logic). I would like to assume that what i'm making should be good enough to handle the task, but design direction and code semantics both require their own form of planning and discussion. Unless you intend to share resources for me to help direct you, or enough for me to tweak code, then all i can give you are my assumptions. As far as what i've done with the code, i've designed the project to generate pokemons with random moves, default IVs and EVs... though, i've sure if you're interested, you can tweak that however you like.

Since i intend to continue to finish backend code of the framework, i dont see the value in putting down the project to pick-up another at a different progress state than where i'm currently at. If you want to offer suggestions and directions, i would be more than happy to help integrate and design towards them. But as far as stopping or starting over, i wouldn't see enough motivation in it for me to agree to that. Again, if you want to know how much of the code i've written is working, i'll be publishing reports soon so you can see for yourself.

[Fallenleader]

I think we are mis-communicating somewhere. I never asked you to drop any project XD

Pokemon stadium due to technical limitations among other reasons uses a watered down version of the first generation pokemon engine. This is irrelevant aside from these key points:
The entire move pool is accessible. This is because of the ability to plug in the cartridge and use existing pokemon. the "rental" pkemon built into the game are always standardized. Set moves, set stats (0IV/0EV) for fairness. otherwise, it functions similar to battle factory
https://bulbapedia.bulbagarden.net/wiki/Battle_Factory_(Generation_III)
Where I got stuck in the project was at the menu, making a call on button press to store the pokemon with specified stats, simply because the original code was an utter mess and hard to utilize.
I also never managed to set up a battle state machine to poll for input, calculate moves and damage, then run the animations. This is all stuff I should be able to manage with more knowledge and experience, along with clean code. I have been watching the commits you have been doing, even made a joke about "pokemons", but jokes aside, these changes are exactly what I was looking for.
Pokemon logic is seperated from item logic, which in turn the battle manager would be pokemon/item independent since items are not mandatory where pokemon data is, and that is further decoupled from any sort of unity sided setup, such as models, animations, particle effects, etc.
I have no qualms sharing the data and setting up some sort of private repo, but keep in mind the project would grow in size very rapidly since models and textures eat up a LOT of space. My build targets are aimed at PS Vita, PS3, PS4, Android, and PC. If you are interested in collaborating, let me know. It gives a clean stadium mode (think Colosseum/XD) later on, and the battle state manager would again be abstract enough to utilize in a remake/custom fan game. basically my goal was to bake the foundation to build a full game from later, while remastering a beloved childhood classic.

[Fallenleader]

I also have a discord I had set up a while back, that while it's kinda pointless for it's original intentions would be a better place for communication. Invite link is set to never expire with no user limits.
https://discord.gg/V7dMp3e