OMG HAMSTAPOWAH UPDATE.
I've kept busy the past couple of days with this one. The battle system is in very early development (yes, kids, the new one), and in turn some of the core system has been altered, as well. Active parties can now consist of up to fifteen people, should that interest anybody, consisting of three primary rows of up to five characters each. Beyond this, you can now have as many characters in a party as you've RAM to store stats for, though don't expect this out of anything I generate soon. the fifteen active limit may be hard enough to meet, as, at present, I've maybe 7 or 8 characters in mind that can join your group, five of which are required. I do enjoy a good side quest.
Here's what battle looks like so far. Otherwise… Just getting started here.
Because of this, my concerns with the game having way too much menu time have become all the more justified. I've eliminated individual inventories, as it simply becomes too much clutter in need of organization and fore planning on the player's part. To make up for this loss of storage space, two things have been done: items are now categorized into one of four sections (Item, Weapon, Armor, and Special), and, save for special items, you can now store multiples of an item in one slot. At present, there is no cap for how many of an item you can have at a time, spare the max limit of GM's integers, but that will likely change as I get the scripts involved with adding items more fleshed out. In battle, anyone can access the Item bag and use it's contents on anyone, including themselves, in range. this should reduce menu time considerably. :)And, with that, we now have…
omg… could it be? How manly!
How did you do the move range calculation? I've had trouble with mine, so far I figured out how to make a circle with the radius equal to the move range, then invalidate tiles that have objects on them, and I noticed that if an object is in one of cardinal directions (up down left right) from the unit, only the last two tiles are invalidated, even if the object is right next to them. But I can't figure out how to do it better, or how to plan the motion once the proper tiles are selected.
did that make sense at all?Planning motion, if i'm understanding correctly, would be having them go one direction before another, or just go towards the given point… but obstacles do make that harder, and I never reached the point of animating much anything with the original system. At present, i still need to make it switch to grid movement.
As for the range, I actually generated a tile on the player's position with a variable storing the player's move range, and then it checks for every open space around it. It then generates another tile in those open spaces, and those have the move range minus one, then mins 2, and so on. So if there's an object and the player CAN move enough to wrap around it, it will do so. Then when you give the order where to move, just make sure the player chooses a space with one of those objects. After that, it's a matter of canning those objects and moving the fighter there.hope that helps somewhat.I'd hit it.
… with my +1 Mace of pyromancy. You knew there was a DnD joke coming, don't lie to yourself.Let me role my 20 sided dice to decide if that was funny…
And thanks for the help. If I can make my map run faster than 5 fps I'll try using it.Yikes. 5 fps is pretty nasty. o___o You running a bunch of loops or something?
Keep the active party size at 10,I find it works best.Unless you have more reason for 15?
May want to soften that grad a tad,or are the grad colors customizable?Treasure chests shouldn't be too hard if you use the RoomEditor InstanceCreate code that so many lack the knowing ofYeah, I had a bunch of for loops and arrays in the step event. I moved all those to different key stroke events. It runs fast now, but not very smooth.
@ serpex: The box colors are fully customizable, yes, sans shadow. Text, top and bottom colors, as well as the border can all be set to your liking.
Odds are I probably won't hit fifteen players in this round, but it'll either max the party at 15, 12, or 9, as the three row system and such. But there are downsides to using more people than you need, and I'll get into that later. >:D Once I have me some visual aids and the like. I do enjoy those.The reason ten won't work as it's rather hard to divide the three rows by, unless I make a LEADER position or something, which could work, but iunno. I've actually come up with situations where 15 people is better, but those… are really big fights. XDI just found out about instance creation codes the other day… on accident, in fact. and, while I found that neat, I find a script much neater, and more code-efficient. One line generates a chest with an item from one of the four categories, tells it which switch is its own (thus telling the game whether or not the chest is open), and which sprite to use. So even with instance creation things, that's five variables I'm setting with one command.I say 12 is good.