Posts for ThePoxBox


Post subject: Re: MarI/O Project Extension Ideas
Joined: 3/14/2016
Posts: 2
Location: Eastern Oregon
Masterjun wrote:
ThePoxBox wrote:
d. Carry-able - A Koopa Shell, P Switch, and Trampoline all fit this category. They are all sprites that can be "carried" [...] m. Arm - "carrying" arm sprite
what
yes
@ThePoxBox http://thepoxbox.blogspot.com/ www.twitch.tv/thepoxbox Donate via Paypal to thepoxbox@gmail.com
Post subject: MarI/O Project Extension Ideas
Joined: 3/14/2016
Posts: 2
Location: Eastern Oregon
Howdy to all the Bizhawkians out there. I just stumbled upon this neural network LUA plugin for the program called MarI/O (NEATEvolve), and I'm proposing an expansion of the script. The code is available here: http://pastebin.com/ZZmSNaHX I am a novice at coding myself, with only rudimentary understanding of it all. I routinely code spreadsheets, but this is the extent of my coding knowledge except for some basic syntax for Microsoft Runtime, Java, and HTML. Here are some of my ideas for expanding the script to be able to handle the different parts of the game (Title Screen, Cutscene, Overworld Map, Level.) It would be nice if any of you that know the capabilities of the program could point out if there is a limitation with the technology, or how certain parts of this could be coded or accomplished: 1. Make more "classes" and "sub-classes" of objects - right now there are only two classes of objects (terrain and sprites.) There should be these classes: a. Shell - This is a Koopa Shell in its inert state. Touching it without "carrying" it turns it in to a Moving Shell. b. Moving Shell - these can be stomped and turned into a Shell. It can kill you. c0. Enemy - a class that can kill you. If the "death plane" for pits and lava can be added to this category, that would be awesome. c1. Smashable Enemy - A class that can kill you, but can be stomped on to kill. c2. Bumpable Enemy - A class that can kill you, but you can bump a Bumpable Block underneath them to kill them. c3. Shellable Enemy - This enemy can be killed by a Moving Shell c4. Fireball-able Enemy - This enemy can be killed with a fireball power-up c5. Cape-able Enemy - This enemy can be killed with the cape power-up c6. Invulnerable Enemy - This can kill you and cannot be killed c7. Smashable Boss - Makes the network able to tell some difference between the two Koopa Kids bosses where you play Whack-a-Mole d. Carry-able - A Koopa Shell, P Switch, and Trampoline all fit this category. They are all sprites that can be "carried" e0. Platform - a block or sprite that can be walked on e1. Moving Platform - a Platform that has some kind of ability to move e2. Bumpable Block - These blocks can be bumped to release Coins, Power-ups, Yoshi, or give an O or X for a bonus room, or register a value on Bonus Games f0. Climbable Wall - Vertical walls that can be held onto f1. Climbable Wall Panel - a panel that can switch your side on a Climbable Wall g. Door - a tile that takes you to another place if you push a direction, also could be used for pipes h0. Mushroom - Changes Mario's state to Super Mario h1. Fire Flower - Changes Mario's state to Fire Mario h2. Cape - Changes Mario's state to Cape Mario i. Star - Gives Mario the Star state j. 1UP - Gives Mario an extra life k. Coin - 100 coins collected gives Mario an extra life l. Yoshi Coin - 5 Yoshi Coins collected in a level would give Mario an extra life m. Arm - "carrying" arm sprite n. Advice Box - brings up a helpful tip. The tip can be closed o. Yoshi - Yoshi sprites when not ridden p. Yoshi Sprite - The sprites that make up Yoshi when ridden These classes and sub-classes don't have to be defined, but the have to be "shown" as different from one another. The could be coded to show up as different colored squares on the GUI overlay so the viewer could see there is something different about the objects. The network then would have a lot more types of things to "think" about when considering what to do. 2. Make more Mario "states" - make it to where Mario understands that it is in a different state, which may be able to do different things with the same inputs: a0. Mario a1. Super Mario a2. Fire Mario a3. Cape Mario b. Yoshi c. Star Mario 3. Make the neural network understand different game "states" - Give GUI inputs that make it to where the neural network has different Fitness incentives that will drive behavior in different game states: a. Main Menu - This is pretty simple. Code for when the game is brought to the 1/2 Player menu it receives 1 Fitness. When it selects a game file, 1 Fitness. When it selects 1 Player Mode, 1 Fitness. If it selects 2 Player Mode, -5 Fitness. b. Cutscene/ 1st Time Yoshi/ Advice Box/ Switch Palace Activation - give double the time it takes for the longest cutscene (After one of the koopa palaces) for the neural network to press something that allows it to continue. c. Level - This is already coded in to the script d. Overworld Map - This is a bit complex. Fitness should be gained for entering a new level. New exits should award Fitness, but old exits should not. With these changes the script should be able to complete the whole game (eventually.) If anyone is willing or able to start playing around with this, please let me know. I live with someone that does some coding, so I'll probably be attempting this slowly. Also, let me know if I left anything out when it comes to states or classes. Thanks!
@ThePoxBox http://thepoxbox.blogspot.com/ www.twitch.tv/thepoxbox Donate via Paypal to thepoxbox@gmail.com