Nathan Karr wrote:
I'd like to be able to set a lower money cap, though, like 99 or 999. Or 255.
like... zelda!! i like that idea! you could even be able to change it within game, like in zelda, with the giant's wallet and such. could be interesting for adventure games, or add a touch of realism to any game. (seriously, how big can your wallet get before it snaps your arm off like a twig?)
Voltire wrote:
Can't you also raise the price above 32767 with plotscripting?
Spoonweaver wrote:
Not in stores I don't think, but otherwise yes.
true, true... but with the shops unable to exceed the cap, it'll make items easily attainable later in the game. or, not so easily. still, though, i'd like for items to be able to cost more than 32767. this would also create a value curve, both for items AND monsters that drop cash. i always imagine end-game or near end-game items to cost at the very LEAST $1,000,000. plus, 32767 is such an oddly random number to cap off at, don't you think?
Spoonweaver wrote:
well it has to do with the code used to store variables.
I suppose you could just set up some menus and short scripts to handle higher level stores. They've even look like the default stores. Wouldn't really be that hard.
I suppose you could just set up some menus and short scripts to handle higher level stores. They've even look like the default stores. Wouldn't really be that hard.
actually, i have already created stores via menus (try not to get ripped off by the guild fence! cuz he'll do it! he's a dick, kinda!
).
it is easy, i'll give you that. but i'd like to see these features added to CUSTOM in a nice and easy to use format. some people have absolutely NO CLUE what they're doing with plotscripting (ie, my cousin is pretty much dead in the water). so, adding these features and what i mentioned earlier in the thread (such as bridges, equipment slots, etc) would make the OHR easily usable to the everyday-casual-game-maker (oxymoron, anyone?). although, it might just make people lazier as well...
i'm not exactly coming up with these ideas because i don't think there's any way around them, i just want them to be easier to do for people who don't have as much experience with game making, ya know? also, it'd be good to have more flexibility with the engine anyway. so many games are already alike, granted the engine is made to mimic old school SNES RPGs.
EDIT: hahaha. i noticed foul language is censored with the word "slime". awesome.
I have to disagree with changes like these. I think that games can be made within the confines of the current system that are remarkable. Scripting aside, the OHR provides it's users with a load of options to choose from to make the game they have in their head.
At a certain point, every single novice game developer will run into a road block when trying to do something in their game that the OHR can't do without scripting. It would be completely impossible to include each and every feature a game developer might think up into the core OHR program.
In fact a features that has never been done before is the exact kind of feature both novice and eldered game developers want to put in their games. Implementing them wouldn't necessarily benefit future game developers because they too would want a new and original idea.
This is why scripting exists.
When faced with a creative roadblock, novice developers should either developer their skills as a game maker, or work within their limits.
At a certain point, every single novice game developer will run into a road block when trying to do something in their game that the OHR can't do without scripting. It would be completely impossible to include each and every feature a game developer might think up into the core OHR program.
In fact a features that has never been done before is the exact kind of feature both novice and eldered game developers want to put in their games. Implementing them wouldn't necessarily benefit future game developers because they too would want a new and original idea.
This is why scripting exists.
When faced with a creative roadblock, novice developers should either developer their skills as a game maker, or work within their limits.
You also have to consider the amount of time it would take the developers to implement everything on the wish list. Shops are notably one of the last features in CUSTOM to lack any kind of plotscripting ability or adjustable design, making them horribly limited even in 2011. But when you consider that there are only six or seven developers working on it, with only one or sometimes two (three max) working on it actively at any given point in time, you have to expect nonessential updates (like dynamic shops) to get pushed back farther and farther to make room for bugfixes and other essential changes. Doing things outside the box, however much extra work it may involve, does give the developers time to focus on the essential things that would help doing things outside the box run more efficiently (which I believe is what they're working on now).
I guess the moral of the story is that if you know any programmers who need an RPG construction engine to use as a toybox, I'm sure James and the other developers would appreciate the extra hands.
Place Obligatory Signature Here
I guess the moral of the story is that if you know any programmers who need an RPG construction engine to use as a toybox, I'm sure James and the other developers would appreciate the extra hands.
Place Obligatory Signature Here
I also use a fully customized version of shops using custom menues and plotscripting, and I have to agree that while making shops dynamic would be helpful, it would still probably resort to plotscripting anyways. I mean, we have the ability to have NPCs look and act differently based on tags, but we have that for shops too. If we need NPCs to get really 'dynamic', we script it. Same would happen for shops, so people would still have to learn plotscripting.
There are lots of other improvements that I think would take precedence for the engine. Making items accessible to plotscripting has been a big one. Most of the big stuff has to do with the battle engine though, where are still many effects that are actually impossible to achieve (although the strides in this department have been HUGE the past couple years)
I am Srime
There are lots of other improvements that I think would take precedence for the engine. Making items accessible to plotscripting has been a big one. Most of the big stuff has to do with the battle engine though, where are still many effects that are actually impossible to achieve (although the strides in this department have been HUGE the past couple years)
I am Srime
Spoonweaver wrote:
When faced with a creative roadblock, novice developers should either developer their skills as a game maker, or work within their limits.
i concede your point. after all, the OHR isn't the ONLY engine out there. there are much easier ones to use, such as the RPG Makers by Enterbrain. and if you're not cut out for game making, then you're just not cut out for it. and holding your hand through the process won't let you learn anything.
Pepsi Ranger wrote:
I guess the moral of the story is that if you know any programmers who need an RPG construction engine to use as a toybox, I'm sure James and the other developers would appreciate the extra hands.
i, myself, would love to help in the development, especially with all the little things i'd like to see added. unfortunately, i don't know nearly enough to be of any use. plus, out of all the people i know who use the engine, i'm the one who knows the most about it. sad, really.
msw188 wrote:
There are lots of other improvements that I think would take precedence for the engine. Making items accessible to plotscripting has been a big one. Most of the big stuff has to do with the battle engine though, where are still many effects that are actually impossible to achieve (although the strides in this department have been HUGE the past couple years)
i was very surprised and delighted to see how much the OHR has changed over the years since i stopped using it. i hardly recognized it. of course i realize there are many things to be done before even THINKING about little things. there are still bugs to stamp out, and even more whenever a new feature is added. for example, i remember hearing something about adding "buffs" as a seperate string, instead of the old way of just targeting a specific stat with an attack. but, i don't expect to see that any time soon.
all in all, these are just suggestions. that being said, there is ONE more idea i thought of that, at least to my knowledge, does not seem to be possible even with scripting. creating seperate forms of status effects. what i mean is, for example, having seperate "forms" of "poison", "stun", etc. this way, you can create two HP draining status effects, ie "poison" and "burning", which drain HP at different strengths, or "enfeeble", which could prevent physical based attacks, and "mute", preventing magic attacks, both using the mute register. and obviously, they must be healed with different spells/items. right now, as the status effects have only been added fairly recently, you can only have one form of each. now, of course, i have no idea how to do this, if it's possible, or even how long it would take to do it. but, as they say, rome wasn't built in a day. these are just things i'd like to eventually see.
Here are a few wiki articles that are a decent starting point for anybody interested in becoming an OHRRPGCE developer
Improving the Program
Compiling
Guide to source files
Improving the Program
Compiling
Guide to source files
How about simplifying the process needed to make sprite animations? My game would do much better with something that makes it easier to animate. Not quite a fan of constantly tweaking Pepsi Ranger's animation scripts for absolutely EVERYTHING.
HAHAHAHAHAHAHAHAHAHHA.......... No.
HAHAHAHAHAHAHAHAHAHHA.......... No.



