Ardumon Mockup Image


(Pharap) #142

I think held items might take too much space on top of the other stuff.

If the held item is just a stat booster then it might fit,
but once you start trying to make it do anything special it ends up needing more code,
and of course code takes memory too.


(Sam) #143

What if we added ardu to the front of names of pokemon.
e.g. Ardusaur :smiley:


#144

That’d drive me mad, to be honest with you. :rofl:


#145

Held items were added in the second generation. Their functionality wasn’t that diverse either. Leftovers outclassed pretty much any other item. When I played a lot it was really only 4 items that where used bar frindge cases so I wouldn’t say you would need too many choices if they where to be included. You also have to keep track of those items in the inventory and on the monsters though. Limiting items to balls, and key items would be better in my opinion. I’m on the fence about tms.

Also this has made me consider the non attacking moves. Rest, recover, buff,debuff, satus moves, ect. All of those would require they’re own function for whatever they do. Maybe only one or two types would be worth including. I would say recovery moves and then status moves would be the two highest. As much as I love a stockpile set hippodown.


(Pharap) #146

Most attacking and healing moves can be expressed simply as a type, their base damage (negative for healing), their target (user or oponent), and perhaps an additional status type and a chance to induce that status.*
(Interestingly this could allow the equivalent of STAB to be applied to healing moves.)

Anything more complicated than that and you either need the move to reference a function handling its extra effects.

Likewise with item effects.


* The equivalent of the pokemon move ‘Rest’ could be expressed as something like Move(-128, Target::User, Status::Sleep, 255) (chance would need less logic if it’s based on per255 instead of percent).


#147

Hmm. I don’t think there’s much more to think about when it comes to gameplay and mechanics. Just story ( which isn’t really important) and monster concepts, really. One thing that I feel that shouldn’t br added are TMs (don’t remember if someone mentioned this). Instead, let’s just use some key items as tools.


#148

I started up a stat sheet based of of @Revlis sprites. Here. I also started a typing graph, but there’s only 10 types so far. Ballparking ~monsters, I don’t know if dual types would really be necessary. There really aren’t that many monsters to go around. Also along that line, evolution might not be 100% necessary. With so few monsters I’m not sure if it would add that much. I would argue 3 level paths aren’t worth having at all. Maybe a few 2 level ones. Maybe a couple for the starters and maybe a few other sudo-legionaries could evolve.

Edit: I think I said up somewhere before that All the monsters should be balanced around each other so they’re all usable. I was pretty conservative and based the stats off how what their sprites looked like.


#149

Wow, this is amazing, but I do have some minor nitpicks. Most of them just simply have to do with typing and the rest are acouple of spelling errors.

First, Audiouse would be a wind and/or a normal type since it’s a mouse that can produce loud sound from it’s mouth strong enough to make sound waves and has super hearing.

Pyrant would be fire and earth since it’s based on a fire ant.

Chlorasaur would be just Plant. It’s kinda hard to tell, but it’s tail is tipped with a leaf.

Micrunt would be Normal and/or Plant because it’s a small bug.

Quadra would be spirit as well since it’s a hydra but with four heads, which is from mythology.

Paragrasp should be spirit as well as water since it’s a spirit that drags you to the bottom of the water.

Scrabion is spelled scabion in your sheet, and it would be water as well since it’s a crab and a scorpion.

Okarda would be Spirit and Fire since it’s name is spelled a drako backwards, which means a dragon.

And lastly, Treyebat is spelled treybat in your sheet.

By the way, do you need any evolve versions of these monsters. I have one in mine for Bunnerina called Bunnancer, for Flanine is Fyrote, for Micrunt is Macruff, Frownfish is Crownfish/Drownfish ( which one you prefer), Dribby is Haulkon, Odrion is Foulic, and Cudala is Cudanda.


#150

I’ll make those edits. I think the issue is that evolutions are separate monsters. Each evolution having different base stats. Though that doesn’t necessarily need to be the case. While I was looking at the state table I was thinking that instead of saving the stats for each monster each teir of stat could be saved and then referenced.

So if the all the stats where 90 it could all reference one 90 stat in PROGMEM. Along that line evolutions could be a state modification. Add a parameter for the evolution state. 0 could be the base monster. 1 could be the second stage on the tree. Instead of swapping to a new basestat set the state could be used to raise each stat a level and move to the evolved Sprite and name. Maybe that would save some memory and allow a lot more monsters.

Something like

int statTiers[] = { 70, 80, 90};
baseStat = {statTier[0 + evolutionLvl]};
bitmap = monsterBitmapArray[0 + evolutionLvl];
name = monsterNameArray[0 + evolutionLvl];

Idk If that would actually save PROGMEM, but maybe something along those lines.


#151

Thankyou. Also that sounds like that could possibly save a bit of space at least, though I’m not familiar with C++ nor the Arduboy that much, really. I’m basically just the guy that comes up with the sprites. :smile:


#152

@pharap mentioned something similar along that line earlier, having a couple monsters all share a basestat set. So it’s really just expanding on that.


(Gavin Atkin) #153

When discussing features like evolutions, held items, TM’s, IV’s, EV’s, status effects, and movesets, I think it might help to consider the Gameboy’s specs compared to the Arduboy. The maximum rom size for the gameboy was 8MB or 8,000KB (actual space would vary). 8000KB / 32KB what the Arduboy has is about 250 Arduboy games inside 1 gameboy game cart, or the Arduboy has 0.4% of the space available to the gameboy. A big if I did my math correctly there.

The question is how do we make 0.4% of the space still feel like a full game. Focusing on the core mechanics will result in the best chance for success. For me, the core mechanics are world exploration with approximate detail of Arduventure, monster capturing, monster battling, and battling set collections of monsters.

Some features may be able to remain planned while easily scrapped once space runs out, but others may absorb a lot of space and become deeply tied into the game which would cause issues when trying to remove them.

A good place to start coding may be the battle engine to really determine what is possible for overall scope.


#154

The carts range from 256kilobits-8megabits. Romhacking net has the Japanese version listed as a 512kB cart and the world release on a 1mB cart. Not to belittle you’re point though. Modeling green would still be at only 6% of space available in comparison. They also had access to ~32kB of S-RAM to save to vs the 1kB of EEPROM. (I might of mixed up bits/bytes but I’m fairly certain this is right after digging through a couple of references)

I agree fully that the battle mechanics size will determine everything else that is including and at what scope. So it should be prototyped first before anything else is committed to.

I think one issue is some of us that have been active in this thread aren’t strong programmers, such as myself. As much as I like to contribute the best I can offer is information on the original Pokemon mechanics and balancing / type casting of monsters into rolls. Also pokemon being as popular as it is makes it a bit of a black whole when talking about monster catching games. @pharap mentioned a number of simmilar games I’ve never even heard of before


(Holmes) #155

Wow, there’s a lot of posts in this thread. I was working on mocking up a fighting system for a Pokemon-like game where creatures had 2 “types” like in Pokemon… An elemental typing and a species typing. Creatures would be randomly generated, too. Monsters would have several combat options: Elemental attack, species attack, neutral (weak) attack, defend, and a randomly-assigned attack of a different element/species type to make each creature unique. Some of the elements were things like fire, water, ice, rock, plant, crystal, etc. Some of the creature types were beast, dragon, serpent, fish, bug, bird…

I would still like to visit this idea in the future, but it’s a cool way to include a lot of variety in who you fight. You could even limit the elemental typing of creatures found based on specific location so that only earth creatures appear in a cave or fire creatures appear in volcanos, etc.

You could even do some interesting masking technique to combine an elemental sprite with a species sprite to make something like a wolf that looks like he’s on fire, or a crab that looks electric or something.

Just throwing that idea out there if anyone wants to incorporate it into their Arduboy game. :stuck_out_tongue:


(Sam) #156

So your not working on it now?


(Holmes) #157

Not quite… Haha. I need to finish updating Circuit Dude. :stuck_out_tongue:


(Gavin Atkin) #158

The Arduboy World Editor used for Arduventure has been released. It could be used to create the world for a pokemon style game if anyone is ready to take the lead on the project.


#159

I was thinking about compression methods to pack your party as tightly as possible and came up with a few ideas I wanted to write down.

Ignore this

I was trying to think of the tightest way to pack a monster in a byte. I forget how many monsters we had theorized earlier on but say there’s 16 monsters, That gives a decent variety. That could be packed into 3 bits. That leaves us with 5. If the level cap is 16 that would be another 3 bits. The last 2 could be used for the moveset, determining between 4 preset options.

00    000   000
moves level id

(Simon) #160

Err … 3 bits allows you to store a number between 0 and 7.


#161

You are 100% correct and I have no recourse for my error.
:potato:
I must of originally though 4&4 for type and level and then screwed my math up typing it out, it’s been a few days since I was thinking about it.