Help - Search - Members - Calendar
Full Version: Noob Help with Capture/Storage System Monster Game
RPG RPG Revolution Forums > Game Engines > RPG Maker XP Discussion
dreads94
I am a noob with XP and after spending a few hours have decided to build the game I have been trying to build with various engines over the past year. As such I already have all the map tilesets and sprites. I have over half the battlers but each engine presented a difficulty and eventually killed my project. With XP and the script system and some help I hope to finally finish it.

It is a monster raise/battle game similiar to dragon quest/pokemon. My goal is to have a side view battle system, storage, and a capture system. So far I see 3ways to potentially implement "capture" and to for "storage". I need some help deciding what would be the best and simplest so I can start building it. Any advice with which direction event or script (i am anticipating script) to use.

The first capture is to set up "mercenary vendors" where they sell the monsters similiar to the henchmen in Diablo2. Makes a set event occur when purchased to add to party. Either of the storage methods could work well with this I think.

The second would be to write scripts for inbattle to set it up in a manner similiar to pokemon. Use item percentage chance give a few conditions and add to party. Check for a switch when party is full or not and send to storage or party respectively. This would mean I use a computer/npc to handle storage.

The last way would be to use a quest system where the monsters are npcs that may join party after certain quests or areas are unlocked. When dismissed from the party they would reappear at a designated place until you ask them to join you again. Similiar to the Fallout 3 companions in a way.

I would like to have either the second or last capture method and the second storage but as I am new to the engine my biggest concern is which one will work and be fun too. Sorry if it sounds like I dont have a clue, just trying to figure out which of the methods I have tried before will be best in this engine. Any help is much appreciated and I hope this is in the right spot.. Please move if it isn't sorry if it is.
Tsukihime
QUOTE
as I am new to the engine my biggest concern is which one will work


All of them can be done, and one could even implement all three in one script.
The idea is pretty simple if you think about it: you just need to define what happens when you add or remove characters.

So for example, when you dismiss a character, it might

1. go back to a fixed location (option C), or
2. just disappear (option A)

(of course, #1 is just an over-simplification, but isn't too difficult to manage anyways)

When you add a character, it might

1. Be added to your party, or
2. Sent to storage (option B ), or
3. Tell you that your party's full, and go to some fixed location (option C), or inform you that your party's full and no money is spent (option A)

In the end, all you really need is a script that will allow you to dismiss characters (which is fairly simple to do).
Then the rest of the script would define the add and remove functionality, with various branches depending on which feature you want to use.

The script may be written so that you would have constants that indicate what kind of behavior you want to occur as well, so at the beginning you might be asked to set up some constants

CODE
optionA = false
optionB = true
optionC = true


Note that combining capture and storage methods is completely possible. You could have a "dismiss" feature that sends them back to their fixed location, or a "store" feature that stores them somewhere. But since you want to choose one of them, you could just leave one on and the others off.

Option C does seem to be the most tedious, as you would have to keep track of whether someone is in the party or not, whether they are eligible to join the party, etc.

Then there are some other details that might need to be clarified.
1: can you store duplicate NPC's (for option B )
2: is there any additional behavior if they die?
3: will the game remove them as the storyline proceeds?

Clearly if the game is going to start removing characters, extra functions may be required to make sure that all of the data is updated properly.
Which is basically just you calling a custom defined function "remove_character" that the scripter will write. Scripter's job to make sure nothing goes wrong.

QUOTE
and be fun too


I don't know, I guess some people enjoy writing scripts.
If you're referring to whether it would be fun in a game...well, the games you referred to probably were fun and used such a feature which made it interesting.
Tsukihime
Blizzard's easy party switcher looks like something nice to start with, if someone doesn't want to write a script from scratch.
I don't know most of the classes so I'd probably just build on this.

http://forum.chaos-project.com/index.php?topic=116.0

It provides some useful features that could be added on to allow for the storage system.
For example, the party switch menu provided is pretty much a storage system. All you have to do is make it so that you can only access this menu at specific events (ie: a computer).



All of the actors that are currently in your party will be available for switching.
Actors that are not in your party will not show up.

You can read the kinds of things it does to get an idea of what you can do (basically anything)

I'm rather surprised other game engines don't support the ability to write your own scripts to do absolutely whatever you want.
dreads94
Ok that party switcher looks amazing and helpful. I am definately glad I made the switch to this engine. Ive spent the past year working with so many I was starting to lose hope on ever making my game. Thanks Tsukihime for helping me realize its just around the corner (in a matter of speaking). From what you said I think Ill need to figure out an in battle capture system and use that party switcher like you said with a NPC or something.

You seem really comfortable with the engine any idea what a good side view battle system would be? I have a numerous supply of them such as Minkoff or ATOA but I cant see enough differences to make up my mind. Everyone seems to like one or the other though what's your recomendation?

Sorry for all the questions trying to stay away from broken or only half working assets. Thanks again for all your help I am definately motivated to get my game running and update my project page soon I hope smile.gif. Thanks
Tsukihime
I would find a system that is independent of the rest of your game so that if you do change your mind later on into the development you can swap it in quickly.

I'm not familiar with most of the popular battle systems cause I didn't look at them.
I liked the sound of "Simple side-view battle system" just cause it's supposedly simple.

A lot of the custom systems require additional resources so unless you already have all of the resources for every battle system you have on your mind, I'd just roll dice and pick one.
dreads94
Was wondering about a unique capture system I hope I can explain well enough. Maybe you can give me an idea about how this might get event/scripted? I have done a fair amount of eventing now and completed woodcutting, fishing, stores, npcs, growing plants with changing graphics, pokemon encounter grass.

Well the idea is that there would be areas with traps. By inserting a bait into the trap based on the monster you which to capture a randomly selected monster could be caught. This allows the player alittle control in what they are catching and with traps its random what is caught, and if it is caught.

Doesn't sound too incredibly difficult similiar to the fishing with setting up the wait and random select events. What I need help with is how to add the monster to party or send to storage if party is full when captured and player checks it. Adding an option to keep or release will be simple its after that where I get lost. Any help is much appreciated thank you everyone.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2013 Invision Power Services, Inc.