Sully v1_rpg libraries
Kildorf
need to implement, code-wise? I mean for the library bits, not for
specific maps. Barring that, is there a comprehensive list of all the
things that we /want/, from which we can synthesize a list of what's
missing? And if we don't have that, is there some way we could get/
make one? Maybe a good step would be to go ahead and start a user's
reference for the libraries so we can take a look at it and see what's
missing?
Basically, I just think it'd be great to have a list of all the bits
that need writing so whenever we (or even just "I") had a bit of free
time and a coding itch, we could sit down and write something for
Sully, and it'd be nice to have the libraries done even if Sully isn't
yet. Before I plunge in and start doing stuff, I'd like to know if we
have any resources like this already, and if people have any ideas,
thoughts, or naysaying about the idea.
Ben McGraw
* The level up system needs looking at.
* The battle system needs a better way of triggering graphics and dealing effects (ie, damage, healing, invoked/active status effects (as opposed to passive trigger-based effects))
* The Render Engine needs refurbishing.
* The menu system could stand a full scrub down.
* The shop menus too.
* Gayo is very irked that the marker for a key item is a price of 0. Frankly, I think it's a silly thing to be irked about since you don't want to enable selling of key items, but I understand his irk from an object purist POV.
I probably should make the SVN public, too. I'll do that as soon as one single person who doesn't have access to the SVN already asks me to do it. Ha!
-tacgnoLongcat
halfa...@gmail.com
from everything now that the sprites system does basically the same
thing (to my understanding). In general, the entire game needs to be
disentangled and put into neat little piles. But yeah, honestly the
entire game could stand to have someone go through it -- a lot of it
was not really coded in the spirit of a simple and modular universal
library.
That said, the big NEW piece of code that needs coding is the battle
system and any associated enemy-behaviour-programming structures that
go with it. It would probably not be a terrible idea to do the tidying
part before that, however, and I had an idea for something I'd like to
change in the BS anyway.
My problem with having Key Items priced at 0 was that you couldn't
have unsellable things that WEREN'T key items, which I could see
conceivably mattering at some point. But compared to the other stuff
that needs doing this is an utter non-issue.
crazyazngamer
I'm thinking of a couple of things that could help tidying up if such
an endeavor was made:
* Add more sexual innuendos in the code. :P (vaginas are not ints:
they're floats!)
OK ok, I'll be serious.
* Unify the menu code. Right now, there're two completely different
generic and battle menus. I have actually implemented a battle system
with the original generic menu library (it is unreleased and probably
will not be released. Or maybe it will, if I add some content to it.
Gah! Always the damn content!) I have no idea how hard it would be to
reintegrate the menu systems at this point in development, though.
* Simplify Zip's data parsers. Christ. I know error checking is
important, but wouldn't making the code messy make it harder to find
where the error is happening? (I wish I wish I really wish there was
some sort of generic struct loader. But there isn't.)
* Actually, I lie about the above item. I do it too. But at least put
them all in the same place, if nothing else. That includes the
emulated sprite.vc thingy.
* Merge the execute-lovin' back into some sort of generic Sully item/
skill use thingy.
* Reintegrate some of the newer error-handling back into the error
handling library. Unless you're really trying to make all the
libraries uber-independent, in which case, the error handling library
becomes pretty useless, imo.
* Is McFAIL and mouse interface really necessary? I mean, it _is_ an
RPG library, so why would we need 50 buttons? I think we only _need_
three: confirm, cancel, and menu. Final Fantasy got by with four. :)
* I understand slashys are very special... but eventually, wouldn't it
be nice if slashies and sparklies can live in harmony with a buncha
other stuff under a huge umbrella of animation type effecties?
* Maybe somehow combine the events lib and the flags into some sort of
uber thing? But I dunno, it might be easier to keep them separate.
* There is a gazillion different UI box drawing functions. Which is
the one true box drawer? Who knows?
* And yeah, vecna's animation lib vs. gayo's sprite parser. I think
the sprite parser is better because of flexibility, but hey, I leave
that up to whoever to decide.
There're probably a coupla other things I've forgotten. Whatever.