What makes my Pokemon game different than any other?:
-6,750 Pokemon including variants, customs, mixes, megas and shines.
-All Regions in game from Kanto to Alola. As well as custom Regions.
-A Server for RP and a Server for RPVP.
-742 Moves In game.
-The traditional pokemon game battles with the cards and themes.
-Every Pokemon will be able to move around with you.
-You can have your own house OR lab and put all the pokemon you capture in the house OR land you have to watch them run around.
-Interactivity with all your pokemon.
-Accurate and Relative pokemon sizes to the Anime!
-Events!
-Pokemon Tournaments
-520 Custom Maps
-25 Custom Regions to insure continuous game play.
AND MORE!
I'm not a novice when it comes to development, but I am seeking a reliable team. If anyone has recommendations let me know. I have posted an ad so check it out. I would like some opinions or suggestions on how I should go about this Pokemon Game. Any things you'd like to see in a Pokemon game?
Any support or advice is welcomed.
BYOND: Zapatron
Discord: Zapatron#5804
ID:2473675
 Jun 4 2019, 1:58 pm
|
|
Oh I know, I intend to release in stages, I mention it in my ad. I will do a total of 10 MAJOR updates(Each update per region plus 2 custom regions)
So I may not be a noob when it comes to programming and making a project by myself but when it comes to hiring people I am. What is too much to pay for a pixel artist and a programmer? | |
Ter13 wrote:
[Seeking Advice] I can 110% agree with all of the above including the subtle video | |
-6,750 Pokemon including variants, customs, mixes, megas and shines. Your project includes features that even Nintendo would struggle to create: you've already failed to complete the project. | |
We will see, its worth a try.
| |
Anyways Im gonna delete this thread Ter13 is the only one who gave actual good advice.
| |
Thank you Ter
| |
I'd say there's nothing wrong with aiming to complete a large amount of content, but keep in mind how long it might take you, and adjust your hopes accordingly
With 6,750 pokemon, assuming you already have all sprites ripped and named for ease of use, and can automate the process of creating them from an existing source, it's reasonable to think it's possible. If it takes you 2 minutes to create and test 1 pokemon, that's 13500 minutes total, or 225 hours. Certainly a daunting task, but not impossible if you're committed and can allocate a lot of time towards the game. Assuming it takes a more reasonable 20 minutes to create and test a pokemon (After all, you need to convert even existing spritesheets to DMI, allocate stats, create a table for what skills it learns and when, what TMs it can use, what skills it can use, and then eventually put it in an encounter table somewhere), that's 2250 hours, or 56 1/4 full time work weeks to finish. And that's not assuming the extra work for custom spritework or programming in additional skills/talents. My advice is either to find a way to automate the process of pulling data from Smogon or some other source I'm sure that exists, or more realistically aiming small and making sure the systems work like you want with a small number of pokemon and then adding them to the game as needed as you add more content. Also keep in mind that with 6 pokemon a side, how much worth are you getting out of having so many pokemon? Is it worth spending so much time on that rather than polishing other aspects of the game? These are things to think about. | |
Pulling big numbers out of a hat may sound impressive, but Techgamer is right. Having big numbers to boast is nothing compared to the good will having a polished, focused product that is fun to play.
The bigger you try to go before you have your polished experience, the harder it's going to be to polish your experience. This all reminds me of a conversation I had with one of the YuGiOh guys on BYOND. I wanna say it was DevDuelist, but it might have been WorldWideDuelist. To be honest my memory is hazy, but Ishuri and I had a long conversation with him over a period of weeks about his game, and why how it was structured was absolutely not viable. He insisted that BYOND couldn't handle what he was doing, because he was literally ripping YuGiOh scans from a large dataset that were all scanned in highly compressed JPEG, and weren't using consistent image sizes. He was using the dynamic RSC to scale them down to the appropriate size, and it was just resulting in his game being slow and crashing --with good reason. We did the math and before you even considered the duplication of assets caused by the icon manipulation he was doing, we were looking at around 36 gigabytes of image data uncompressed. There was no way he was going to pull this off in any engine. We explained a process by which he could construct cards from a series of pixel-art pieces during the actual render of the game, reducing a huge amount of space that needed to be used to store that data in every single card's image file. All he had to do was store the actual card art, and we recommended he convert that card art to a minimalist style by manipulating the palette data of the card art so that it looked a bit like pixel art rather than true-color art. This would give the game a stylized look and reduce the size of the rsc file by making the png color tables in each image smaller. The end result to all of this was 1.2gigs or so of uncompressed image data if every card was loaded in the game at one time, which would never happen, and since we were constructing cards from multiple pieces now, we were able to eliminate all the dyn.rsc mutations that were happening by simply using atom.transform to turn cards, rather than physically generating a new icon for every direction the card could face. Ishuri wound up showing the guy a script to automatically process that huge dataset and crop out all of the card art in less than an hour. The point I'm making here, is that going big out of the box, unless you understand your engine deeply under the hood, can blow up in your face fast. Better to start with a working, small product, explore the edge cases, and refactor it until you are able to make it grow. If you start out going big and do all this grunt work for a project that's just not going to work, you are going to lose motivation and quit the minute you hit those roadblocks, thinking the engine is the problem, when it's actually your methodology being applied incorrectly to suit the engine's quirks. I've seen it hundreds of times over the last 2 decades. People don't understand how the engine does things, they run into problems with their methodology, go to another engine, and wind up running into the same or similar problem in another engine, only this time they are confident the problem isn't the engine and actually fix the problem (or they give up on gamedev as a whole and just flit from engine to engine being a negative nancy that doesn't contribute anything but hostility and toxicity to everyone they can possibly talk to). Start small. Build a solid, efficient core. Tape stuff to it. Hide the seams. Repeat. Also, I'll just leave this here: -Accurate and Relative pokemon sizes to the Anime!  For the sake of your sanity alone, abandon this bullet point. If you want accurate relative sizes, your game would need to be 3D to even remotely work, because the smallest pokemon are 10 centimeters tall, and the biggest pokemon is 14 meters tall and 120 meters long. The reason that sprites are inaccurate in size is because to correctly render pokemon according to their size with pixel art would obliterate your ability to recognize the smallest, and to even see the largest. Further, if you worked from the smallest up, your tile size would have to be absolutely massive, which would obliterate the rendering efficiency of your project and bloat the resource size to the point of not being able to achieve your stated goals of a large scale game. Lastly, working from the midpoint outward would result in poor information granularity from your art, and ultimately result in a dissatisfying and dysfunctional end product. Inaccuracy isn't a bad thing where it creates functional form. You need to accommodate the engine and medium you work in. To do this, you need to understand the engine and medium you work in. If you had that level of understanding, most of these bullet points wouldn't exist. If you don't have that level of understanding, you should not be trying to lead a team on a project until you have that understanding of the engine you are using and the and medium use are representing your projects in. Start small, fly solo; attract birds of a feather with what you have built, and lead with skills and experience you have earned. | |
An uncountable number of BYONDers have already tried and failed to even recreate the original Kanto games in their most basic form. So even doing that would be considered a triumphant feat of fortitude.
| |
yea this is just gunna be a huge waste of time
| |
Ter13 wrote:
This all reminds me of a conversation I had with one of the YuGiOh guys on BYOND. I wanna say it was DevDuelist, but it might have been WorldWideDuelist. To be honest my memory is hazy, but Ishuri and I had a long conversation with him over a period of weeks about his game, and why how it was structured was absolutely not viable. That was most likely Dev. Him and I are really good friends, so I can see why you'd be confused. Thanks for the shout out though! As for the gentlemen in this thread, start small. Seriously. As someone who has a history of fan-games, it is a process and a half. The most important thing about a game is actually getting it out. Remember that. Also, I wouldn't recommend working on a fan-game that big in general, because sadly, it's eventually going to be a waste of time. You can't make money off of it, plus the minute you get a C&D, there goes 3+ years of work or more. | |
WorldWideDuelist wrote:
Also, I wouldn't recommend working on a fan-game that big in general, because sadly, it's eventually going to be a waste of time. You can't make money off of it, plus the minute you get a C&D, there goes 3+ years of work or more. Especially with Nintendo IPs. Nintendo is very protective of their IPs, so if this project were to get traction and move forward, the biggest problem in the future would be the inevitable DMCA notice. Now there are of course IPs that you can develop fan games based on and not have your hopes stomped into the ground, but any Nintendo IPs are certainly not on that list. | |
Oondivinezin wrote:
WorldWideDuelist wrote: It's funny because for the longest time with Pokemon, Nintendo were pretty lax on it. Once the RPG Maker and ROM Hacking community started to get more popular and youtubers started making Let's Plays of their games, did Nintendo really start hunting them down. Also, it doesn't help that every new Pokemon Game after Gen 5 is complete garbage | |
Also, it doesn't help that every new Pokemon Game after Gen 5 is complete garbage You misspelled 3. | |
Ter13 wrote:
Also, it doesn't help that every new Pokemon Game after Gen 5 is complete garbage Gen 4 and 5 were great, they were just slow because of the DS. They still had that challenge. Gen 6 was complete ass (except for ORAS of course). Don't even get me started on Gen 7 aka "Hold your hand through the entire fucking game". And Gen 8 is looking like ass. I'm just tired of these battle gimmicks | |
Dragon warrior monsters is really the superior monster game franchise anyway.
| |
Set smaller goals.
Start by trying to get a reasonable, small scale test environment together with 150 pokemon, the Kanto region, and a decent approximation of the battle system / game mechanics.
Forming a massive committee to make a massive pokemon game is only going to lead you to wasted time when you could be doing something productive to better your own skills.
Also, see Rule #1:
The more hype you try to build, especially if you are trying to monetize your project, the faster that C&D hammer is gonna hit you in the ass.