Open GoogleCodeExporter opened 9 years ago
Personally I don't really use Guichan anymore. For me it's an old project that
I
don't have much time for. If you want to implement these changes I don't really
have
a problem with it, perhaps it should be a new branch like Guichan 2.0 or
something,
but I do think Björn should have a saying in this, The Mana World uses Guichan
a
lot.
One thing I do find a bit strange is the usage of the word model. For me a
model is
simply a class which holds data, nothing more nothing less. The fact that a
model
contains presentation logic seems a bit odd to me. Also, by having an inherited
structure for presentation doesn't really solve skinning in a neat way, every
user
still have to add the model to every new widget or inherit the widget setting
the
model in the widget's constructor. I think presentation logic should be
decoupled in
a more static fashion, or at least where a static fashion is the default
solution so
the only thing a user has to do is setting the skin module to the Gui object
(and
perhaps overload the presentation for special widgets by passing a special
presentation unit to a widget).
Original comment by olof.nae...@gmail.com
on 20 Dec 2009 at 9:49
Alright, not really attached to the name. Guess I thought of it as a
simplification
of presentation model. Maybe it could be called a View (ick), Display (might be
confusing, IMO, but who knows?), Presentation (too long of a name, IMO), Design
(that
could work, maybe), Look (meh, not a real fan of this one, but again, could
work),
Layout (again, not a bit fan of this one, but this might work), or anything
better
that someone could come up with. Out of that list, I'd probably go for Design or
Layout, personally, but I'm open to other ideas.
However, on a side note, I will also admit that while I have used GUIChan a
lot, my
own project has already decided to drop it in the future for two main reasons:
one,
uptake here has been slow for fixing bugs which we've found (for instance, the
recursion issue with hide and shown events), so there's been a lot of
discouragement
from even posting bugs and solutions here at all, and two, given the rate at
which we
are going now, GUIChan is more of an obstacle to us and not developed enough
yet for
it to be useful to us, and we're already at the point where making our own
library
from scratch would be more beneficial than contributing back at this rate (sorry
about that. However, it's the uptake problem there that's caused issues. GUIChan
simply hasn't been moving fast enough for it to be more beneficial). Naturally,
because of this, we ended up evaluating some other options, and already drafted
up
what we will be using, but will at least attempt to finish up our current cycle
before jumping ship to another library. So that decision's already been made,
and am
not about to rescind the agreement.
However, I don't mind continuing to work on a GUI toolkit, since I personally
love to
do low level work, but some of the ideas that I have, like this one, might keep
to
the spirit of the library, but likely would be rather different from the current
expectations. I've even chatted about how once we do switch our libraries and
after a
little while after that, about how I probably should make a GUI library for fun.
GUIChan's definitely been a really nice and simple library out there with some
great
ideas, and is a welcome sight in the world, where there are plenty of libraries
out
there that aren't as easy to pick up, read, and extend, since it's been my
experience
that most GUI libraries out there don't try to make their internals easy to
read to
outsiders. So kudos on that.
Also, should Bjorn decide that he would like to go in on your proposal, Olof,
and
create a new branch, I have about three conditions that I would like to see for
joint
contribution and reserve the right to impose more if I feel that the spirit of
the
rules is being ignored or trounced on. Those are as follows: One, if we did
contribute together, he'll only have my cooperation if he keeps problem coders
out of
the main tree, and won't be accepting in commits to the main tree until patches
can
be agreed to be good between him, me, and others who have proven themselves.
Most of
the real coding should be going on in separate branches to development, and the
trunk
should not be used as a catch-all to ignore the hard work of keeping bad
commits out.
I'm not necessarily asking to be a trusted committer, but if we don't agree
over who
is trusted, and he adds in someone who I already know is a problem coder,
that'll
probably be the day that I either cease contributing back here (since I will
then not
be able to trust the code anymore), or just manage my own branch from then on.
If he
really wants to, he could be the only person committing, and be responsible for
cherry-picking and merging, but I expect that the commits be controlled, not
blindly
merged, and not allowed to become a mess situation. That's what branches are
for. For
a library, I would much rather see things controlled, than having a lot of
speed/hack
committing. Think of it this way: if we're to joint work on a graphics library,
I
prefer to take the Linus route and use git in a similar manner to how he
manages the
Linux kernel itself. The second condition would be that I do not want him to be
the
overriding decision maker, and to respect the opinions of code brought into the
library based on the overall quantity/quality of the commits which have made
their
way into the trunk library, so in other words, the impact which the developer
has
made to the overall library. And, lastly, the third condition would be that we
go
through proper software engineering routines, and will discuss ideas in the
abstract
first, come to an agreement on the basics, then work our way down to the
implementation once we (we referring to the major GUIChan developers) have
agreement
all the way down in the process. That way, we aren't fighting on design issues
when
we're ready to implement, and can more easily address the issues raised without
wasting any of the developer's time creating solutions which aren't going to be
accepted in the first place, especially when the solutions are rather large in
scope.
If he could do these three things, then I think that I could see more eye to
eye with
him and be able to work with him, but I doubt that we'd get too far
co-contributing
here without at least these three conditions. Also note, Bjorn, that only
applies to
here, where we might at least have a common vision/scope. This does not apply to
other places, where there are different over arching goals.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 1:40
How about just going for a full a Model, View, Controller (MVC) setup?
Original comment by jaxad0...@gmail.com
on 21 Dec 2009 at 3:29
Any specific reasons why you'd like to go MVC rather than Model, View,
Presenter (MVP)?
Personally, I'd prefer that pattern instead, and which seems to be more in line
of
this idea, and isn't too much of a stepping stone away from it. And, in that
line of
thought, if a widget is already simple enough that it wouldn't have much use of
a
Model, then we just don't need to make a Model for it. For instance, currently
the
ListModel, after a bit of adapting to this change, would fill the complete
Model need
for the current widgets IMO, but it would be nice to add another class which
would
inherit from the ListModel to provide Tables in GUIChan. This is already in
line with
what GUIChan is currently doing, although extended a bit, while MVC doesn't
seem to
be as good of a match, or, if you do see it as a match, it could be argued that
the
Controller bits are already done with the two Input classes, and, as far as I
can see
(prove me wrong if I am, since I don't mind being wrong here), the proposal
given
here would already do everything you're asking for anyways. So, if I'm missing
something, it would be nice to explain exactly what you're proposing to do
differently, especially since Model, View, Controller can be implemented in a
variety
of ways.
Now, while I'm talking about input, I would personally rather see a new
InputManager,
which would act as an intermediary between the key, mouse, and other input
device
events and the widgets themselves, and have events be added to it in a triplet
of
(input action ID (represented as a string), key/mouse event, function pointer
to use
on action). Then all that a widget would need to do would be to hook its
specific
input action ID, and then send input events only to widgets subscribed to those
events, then, if there is an event to handle once all of the widgets are
handled, to
then just execute the action. I would also provide a special block to be
provided
which would generically cover all printable characters, which would be used in
certain widgets where the player could type, so that if an action is assigned to
those keys, then the user won't have that action occur from just typing like
they're
supposed to on those widgets. This system would have the benefit in being able
to add
in actions which can be handled without needing to have a widget for them, and
remove
the need to hand configure out a logic loop for all key handling events the user
wants to make, as well as also help prevent programmer errors that can occur
from
mismanaging those loops, since all that would be needed on the programmer's part
would be to make a handling function, subscribe their event to the
InputManager, and
let the InputManager figure out how to handle the event. Think of it as a
signal/slot
sort of key/button event subscription model for input management. But that's a
different issue, and is a huge departure from how things are currently done
(but is
one which can be done in a reasonable amount of code, makes programming and
linking
input code in the library a lot easier, and which I think would be a great
addition
to the library). I'll likely bring it up again at a later date in a proper issue
report if Bjorn would like to go with Olof's proposal, but for the moment, I
dunno
how well it'd fit in with the current GUIChan.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 5:35
Well like Olof, I am not really into developing Guichan further. For me the
reason is
that after much exposure to Qt, anything I would do with Guichan feels like a
duplicated effort. Hence, personally I would base the next version of The Mana
Client
on Qt rather than improving Guichan to a level that allows us to move forward.
So
from my point of view, do what you like with Guichan.
Features that Qt has that I certainly do not look forward to do in Guichan
include
handling of text selections, copy/paste, an animation framework, GUI layout,
rich
text, proper object ownership, unicode, system fonts, etc.
Original comment by b.lindeijer
on 21 Dec 2009 at 10:18
Oops. Both creators of guichan don't really use this anymore, so further
development
seems to be at halt. Well...
When I started to use guichan, I was impressed by the fact that it is so
lightweight
(and cleanly designed). So I'm using it in my game(s) now, based on allegro and
OpenGL. At some point, don't know which CL it was exactly, but before
introduction
of the Text class, I stopped following the changes, which for my feeling did
more to
make guichan heavy weighted instead of really improving the library. So what
I'm
using is a spinoff of 0.8.1 plus a few changes from the depot plus some more
changes
made by me. If anything, I would like to see guichan stay the lightweight game
GUI
library that it is, in contrast to other, more heavy weight UIs. If you need
more
features or widgets, it might be best to use another, really complete library
instead, like Qt or wxWidgets or whatever.
That said, maybe it's time to move on somehow? What about somebody else taking
ownership of guichan to drive further development? This is up to Olof and
Björn, of
course, but I think that there are some people here who would like to continue
developing guichan in some way...
Original comment by tobias.s...@gmx.net
on 21 Dec 2009 at 11:18
I certainly agree that in its current form (maybe as of 0.8.2), Guichan is very
useful for adding some simple GUI elements to a game. I am in fact not one of
the
creators of Guichan, I only contributed a bit to it since I use Guichan for the
project I am on (formerly called The Mana World, now further developed as
Mana).
However, our current wishes for a GUI library go far beyond simple GUI
elements,
including everything I mentioned in my previous post. Instead of adding all
that to
Guichan, I think it would be more suitable for us to switch to a more
featureful (and
certainly more heavy weight) GUI library instead.
It would of course be nice to see Guichan developing further and become even
more
suitable as light-weight GUI library that is easy to embed in a game. In my
opinion
it would still need some way of doing simple layouts, well defined ownership
(like
parent widget owns child widget, so that you don't have to delete childs
separately),
and an easier way to style widgets. For all these things I would personally
look at
Qt for an example.
Original comment by b.lindeijer
on 21 Dec 2009 at 11:42
This is a really interesting discussion. I don't have a problem giving away
ownership of Guichan. I've been developing Guichan for more or less 6 years
now, and
I've come to the same conclusion as Tobias, that 0.8.2 should be Guichan 1.0.
As for keeping Guichan lightweight I think that was one of the main reasons we
developed Guichan. If I were to develop a GUI for games today I would do things
very
differently (and who knows, I might) like adopting an even more lightweight
aprouch
with more of a composite pattern than inherited pattern, where the global gui
state
is passed to renderers and where function pointers are prefered to listeners. A
game
GUI usually consist of a start menu and perhaps some kind of configuration menu
anyway (at least in my games).
I think the death of a game GUI library is somewhat inevitable when unicode,
text
selection and stuff Bjorn mentioned is implemented (or efforts are made to try
to
implement it). Functions like that are better left for "real" GUI libraries,
such as
the excellent QT library.
Perhaps we should agree that 0.8.2 should be version 1.0 and that irarice is
free to
do whatever he wants to with the Guichan code base?
Original comment by olof.nae...@gmail.com
on 21 Dec 2009 at 12:31
I'm alright with this. I've subscribed to the mailing list, so that should it be
agreed for me to take the reigns of the code base, I'll be able to be in
contact with
the mailing list.
Also, if there is interest in developing a general purpose game library, then I
might
eventually create a second project, perhaps called GameChan, which would
attempt to
be a lightweight toolkit to make designing and developing a game easier. If
people
want to have widgets to use, they'll just need to rely on a different GUI
library or
use GUIChan itself. I think that the heavier game network can be left to
ClanLib:
http://www.clanlib.org/ . However, I think that I would prefer to take a
different
approach to ClanLib and try to make the library accesible with a generic SDL,
with a
minimal amount of needed wrappers. But it would be interesting to see where
exactly
developers and the users of GUIChan might want to take GameChan if that ever
does
come to fruition.
On a side note, since I already have prior commitments with another open source
project, I would manage GUIChan as a side project, and if my main project has
a critical need at the time that requires my attention, it will get first
priority.
However, given how development has been here for the last little bit, I don't
think
that will be too noticeable. However, I think it's fair to lay that upfront
here.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 6:08
Oh, and Tobias, if I am handed over the reigns, I would be interested in
working out
some of your issues. I am interested in keeping GUIChan a featherweight, but at
the
same time, I would like to be in a position where people can do more with less
(as
in, I would like to make the code provided as powerful as possible by keeping
everything as modular as possible. If that means that some people have to have a
wrapper layer over GUIChan to make it more friendly to the way they would like
to
program in it, so be it). So, ideas like this that would make the core library
more
powerful without causing a lot of bloat I'm for. In fact, I think that this idea
itself will definitely increase the number of files for GUIChan, but it should
keep
everything around the same size, if it doesn't reduce the number of lines of
code.
In any case, the InputManager that I mentioned earlier will probably be a bit
inappropriate to GUIChan as set up like this, but I can see it being a part of a
GameChan library. However, before making any committments as to what would be
included in GameChan, if there's enough interest in it, I think that we should
be
soliciting requirements, and figure out what users would expect or would like
from
such a library. But again, I personally would like to see such a library
develop in a
similar spirit to GUIChan itself, and remain lightweight, yet powerful.
Sorry for not appending these thoughts to my last post, but I didn't think of
them
until afterwards.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 6:27
Interesting to see how this thread has been derailed...
One of the strengths of guichan has been the independency of a specific
backend, so
it can be used with SDL, allegro, OpenGL and a few others, seems that there
have
been contributions of an Irrlicht and OGRE backend, too. This should not be
corrupted, if you ask me.
So if you talk about a game library or toolkit, there are many of these already
here, why another one? I ask this because for any new project to work on, there
should be a good reason to make a new one instead of using something existing.
When I started with my own game development, I opted for allegro, because
that's
particularly easy to use and quite complete, seen as a game development
toolkit. So
even if Irrlicht or Ogre can render better graphics, all the support for
packfiles,
timing, ini files, bitmaps and so on from allegro make that a premier choice.
SDL
has similar good support for all these game related tasks...
Which doesn't mean you don't need some sort of game development framework. I
made my
own, like so many others, for a number of reasons. Most important is that I
have
some specific needs, and I couldn't find an existing game framework that
fulfilled
all these needs (an which was based on allegro, for 2D game development).
One of the most crucial points to consider about a game framework or toolkit is
that
games can be so very different, with different needs, and different matters of
taste, when it comes to the use for development. I'm absolutely sure that most
of
the readers here wouldn't like my game framework, for this reason or that, and
mostly because of its intermixed use of a specific set of libraries (ft2, lpng,
glyphkeeper, allegro, allegrogl, loadpng adapter, some of my own extensions).
Different developers tend to use different libraries, so this is a tricky
issue.
Which gets me back to the elegant solution found for guichan: just use a
different
backend. I guess that it might not be that easy in other cases...
Having a style class that does the rendering of widgets seems to be a good
idea.
Introducing a timer abstraction which could be used for blinking caret in
TextBox or
TextField is certainly another good idea. Implementation should be done by the
backend in that case. Having some more widgets to choose from, fine. Reorganize
the
widget class and hierarchy, also fine. Introduce XML for a layout... no fine,
because that adds a dependency to some XML parser. Different people different
tastes
here, and why forcing some specific parser library upon someone who doesn't
want to
use XML at all? Or is using an XML parser of his own choice? Similar argument
applies to all external dependencies, so they simply should not be added.
Just a few thoughts...
Original comment by tobias.s...@gmx.net
on 21 Dec 2009 at 6:59
Well, I think you hit the point right there. You ended up making your own
framework,
because you didn't find anything out there which fit your framework needs. My
experience is that there are not a lot of open source game framework libraries
out
there, unlike good GUI libraries. It would be nice to have a game library to be
able
to push interesting and useful ideas which don't fit as well within the
GUIChan's
graphical framework idea, but would simplify the use of GUIChan itself.
What I think I'd be interested in, personally, would be a good game framework,
which
stays lightweight, easy to understand, and simplifies game development in
general.
Some of the crucial bits that I can see would be providing a sensible input
manager,
which would simplify key binding and key management, a generic backend writer
and
reader, which could follow a similar pattern to how GUIChan handles Graphics,
and
allow different bindings to backends like XML, plain text, SQL, etc., providing
a
sensible resource manager, which will end of life resources (and have resource
as a
bindable class, where you can wrap your own resources to it), and provide
mechanisms
within the resource manager itself where you can mark a resource as being a
permanent
resource, or being tied to a specific game instance (so that you can tell the
resource manager when it should dump all specific game instance resources),
sprite
and animation classes, bindable and extendable game state management, and frame
rate
throttling/limiting. It might also pay to have a good viewport as well to add
sprites
and animations as well, but I currently am not too about how independent that
could
be made. Maybe I will need to share on that end with GUIChan itself, but I
think that
a better solution could be found.
What I would see as the main intention here would be to provide a generic
framework
for game development independent of any GUI library, and which you can hook
what GUI
library you would like to use, like GUIChan into it. I would like to keep the
same
spirit of GUIChan inside of it, and allow for it to be lightweight, yet
powerful.
There happen to be quite a few tasks that I think that every game developer (or
at
least most), will eventually end up making for themselves, and it would be nice
to
provide those separately. The closest that I have ever found to implementing
this
sort of library would be ClanLib and ika (http://ika.sourceforge.net/news.php),
although QT does as well to some degree, although QT itself is a rather
heavyweight,
and is geared more towards general system and business type applications,
rather than
games themselves, so it is lacking in some areas.
If you have any thoughts, comments, or suggestions on this, I would be really
happy
to hear them. I've been rather geared in one specific end of the game
programming
spectrum, which is a bit different than what Olof has done for all of his
games, but
I think that we should be able to start with a small subset of classes to
manage, and
work our way out, like GUIChan has, when a need or shortcoming has been spotted.
However, I think that the overarching requirements for such a library would sum
down
to this:
GameChan would be a generic game framework library, which would be extendable to
different game types ranging from simpler games like Tetris to games which
require
maps, as well as providing bindings . It should also stick to what seems to have
become the GUIChan philosophy: be lightweight, yet flexible and powerful, and
allow
for specifics to be handled through external bindings to outside libraries. It
also
will not concentrate on widgets, etc. but attempt to concentrate on the internal
management chores. However, as to what specific management chores should be
covered,
I would differ until I know a bit more about what the needs of the community as
a
whole are.
So, I think that right now, it's a mistake to think of it as a larger widget
library
wrapped around GUIChan, but as a separate, yet helpful library which focuses on
the
next step chores for game development. I hope that helps, and would love to see
your
thoughts on this approach.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 8:12
Making a separate game framework library in the spirit of guichan, but not
dependant
on it, sounds good. It's a huge task, for sure! So good luck with this.
For me, personally, it's a different story. We don't know hte community using
guichan, or if there's any mentionable community at all. I'm interested in
making
games, but not in making a general purpose game framework library, so I just
get
together what I need and put that into the framework I'm using. Staying small
and
lightweight is a general principle of my development, but I don't hesitate to
add
what I think I need, like true type fonts for easy rendering, or LUA for
scripting.
Making decisions like that, which all fix some point and do it one way and not
another, is good for me, but not for a real general purpose use.
Contrary, making a good general purpose library of abstractions to be used in a
game, but be flexible to implement those abstraction in different ways (and
without
incurring too much overhead), is really a challenge. Maybe it would be a
different
and easier approach to start with a tools library, and maybe even on top of
guichan,
which includes stuff like resource management, or animation handling? I guess
that
might work, at least for starters, and be useful enough to be adopted by
guichan
users.
Original comment by tobias.s...@gmx.net
on 21 Dec 2009 at 8:34
Alright. Like I said, I'd only be interested in it if there is enough interest
in it
from the guichan community. However, there have been plenty of times throughout
my
own game development where I had run into walls in development where I had
wanted
some of these sorts of tools already developed in order to simplify my own
development. You're probably right in that it might not be as interesting for
people
who are already have their own solutions coded up, and which work as well as
what
it'd provide, but I still think that it could be a rather unique library in its
own
right for the reasons that you said. Game frameworks are hard and a real
challenge.
But so is GUI development, like GUIChan, and that should be a good reason as to
why
there should be a library to help with it in the first place.
It's also a nice place in which we could develop ideas that aren't as
appropriate for
GUIChan itself, being a general purpose GUI toolkit, but which the users of the
library have a large need for. From my understanding, GUIChan is mostly used in
games
at the moment, so a GameChan should be useful to most new users starting up
with the
library. However, I still think that before anything is cemented into what
should go
into it, that we should first see if there is enough interest into having it,
as well
as determining what the needs are. I think that if it does get developed, then
we
should share the same external graphics, input, and image binding classes (as in
GUIChan-SDL, GUIChan-Allegro, GUIChan-OpenGL, etc.), but start out piece by
piece,
and be extended as the community needs for the library become more and more
established, much like how the GUIChan library itself has grown into what it is
now.
Also, if we do go down this route, even if you don't use it, would you mind at
least
critiquing, or even making suggestions on it from time to time? I think that
the more
game inputs we get, the better it could be, since if we get a bit too lopsided
towards one specific game or game type, then the library wouldn't be as general
purpose or useful. Always interesting to see and merge different ideas on how to
approach different gaming problems which most of us end up encountering at one
point
or another, and knowing the different approaches can help make a healthier
library.
Original comment by irar...@gmail.com
on 21 Dec 2009 at 9:08
Count me in for discussions, critics, and as much use as I can see fitting my
development.
Original comment by tobias.s...@gmx.net
on 22 Dec 2009 at 8:47
An all purpose clean game framework would be nice, but I think it can never be
accomplished because making games is often quite complex. My experience is that
the
games I've finished have always been developed with a specific game and a
specific
genre in mind, whenever I've tried to do more general stuff (even for a
specific
genre) I have failed. Guichan is even to generic for my taste these days!
Development of a game framework will in no doubt lead to a lot of work put into
trying to make a framework and very little work put into making actual games,
but if
that's your thing then you should go a head and start coding! However, such a
framework should not be associated with Guichan and is more suitable for a
project
of its own.
If you do start working on a game framework I'll happily check out its progress
and
at time perhaps give critical feedback.
Original comment by olof.nae...@gmail.com
on 22 Dec 2009 at 11:06
Yeah, unlike a GUI framework, a game framework is a lot more open ended, and
when
we're talking about 2D games, it's a fairly unexplored area, for the most part.
If I
was to do it, I think that it would be best to try to stick to the basics, and
not
try to get genre specific with class elements (so, although I put down a
viewport a
bit ago, I was rather iffy on that, and thought at first that I should leave
that
out, although I thought the list was a little incomplete without it, since I do
think
that the library would need to provide some place for animations and sprites to
be
drawn to). As it is, I think that the current list I made would be a good
start, and,
from my experience, should be abstract enough to be useful to practically anyone
making a 2D game. And some of what I have listed has been some gotchas that I've
noticed and encountered over time, and I think are some common growing hurdles
that
any game will encounter some time when they are growing.
Also, I would disagree a bit on it not putting a lot of work into making games,
since
I think that it would be critical to the success of a library like this to be
used
intensely by at least one game or a few in order to be able to reaffirm that
solutions are robust enough and thought out well enough, and be able to use
those
project's experiences into what portions are the most difficult to design in or
fix
later are. IMO, a good game framework library shouldn't be decrease the amount
of
work put into making actual games, but instead make developing the games
quicker and
easier, and be about providing some more robust and time-tested solutions so
that
they don't need to go through the same growing pains that other game developers
have
encountered. I can say, however, that doing some elements like providing mapping
solutions, or scripting solutions are likely to be elements which should never
be
considered for part of such a library, due to the fact that they can't really be
genericized completely from my perspective, as everyone will have different
things
that are important to them for mapping (and being a catch-all would make maps
too
large in size and scope, and is a never ending battle on what people need or
want),
or in the case of scripting, there is simply no way to genericize it, since
anyone
would inevitably end up coding towards one scripting language, or a family of
scripting languages. So, the two criteria for inclusion that I would see as
being fit
would be first off, is it generally useful, and something which can both be
sufficiently abstracted and generic enough to game development to not have a
lot of
variance from what should be provided, and two, is it something, which if left
to
invent yourself, has a lot of gotchas which might inevitably lead you to
rewriting
that portion later if you don't understand it as well as you should. I think
that in
general, anything submitted to the library should be able to meet these two
criteria.
Now, to back up my reasoning as to my choices based on that evaluation, a good
resource manager becomes a must have feature, since I've personally seen just
how
quickly this can go bad without proper foresight. Animations might not be too
tricky
in and of themselves, since it's a series of images which are processed in a
stately
order, and a sprite is just a mapping of animation names to animations, but
where I
see a failing, or at least for the code I work on, is the internal relation
between
image files themselves and image sets based off of them. So while it isn't a
hard bit
to code, I've seen it be snowballed into having far more complex relations
between
everything than there should be, and leading to leaks within the
ResourceManager. FPS
probably should be scrapped, although animations will need to have a running
timer on
them where they can keep track of what state they should be in, so the framework
library would be a good place to place simple timers instead of in GUIChan
itself.
StateManager's aren't too difficult to do correctly, but providing one would be
a
good way of hiding some of the internal details of such a library a bit better,
as
well as being a hook/extension of the resource manager, so that resources can
be tied
to a running game instance, and be dumped on switching to a new game instance.
While
this probably isn't such a problem for games which have a static set of
resources, if
you need to get them dynamically, or if you do send resources dynamically,
having a
difference between current/upcoming running instance and whole client life to
the
resource mananager becomes critical, since otherwise you might use some
resources
which you were not supposed to, especially if it's just a newer version of a
file, or
if it's a completely different one altogether that just so happens to share the
same
attributes you're tracking through the ResourceManager. Also, a defined
StateManager
helps encourage game developers to develop good core strategies earlier in their
production cycle, rather than later, where it might become more difficult to go
back
and change. The input manager, out of all of these other features so far, might
be a
bit more of a frills addition, but at the same time, is another choke point
I've seen
quite a bit of problems with, mostly when the number of key shortcuts gets
large, or
when the shortcuts weren't well thought out to begin with. Just like the state
manager, this helps encourage some good habits earlier on, as well as making
input
code easier to maintain when you start going large. And finally, for the
generic file
reading/writing, that definitely falls on the side of a frill feature, but
having a
common parser for your own stored formats, and having the ability to be able to
migrate between different solutions as you need to/want to, can be rather
useful to a
larger project, but doesn't get realized until when making the change can be a
bit
difficult. It isn't a substitute for good structuring of your own internal
data, but
I don't think that anything really can be abstracted for that. For now, those
are the
main focuses that I could see a need for. Also, I think that the key to success
with
anything is having good, well established core design principles. If you have
them,
then everything else falls into place. So, given the current criteria, I think
that
this is something which could be made to work out rather well.
In any case, if something isn't fit for the main library, but still fits at
least the
first requisite, but not the second, then it could always be pushed to a contrib
folder, like GUIChan does currently.
Also, thanks for the input on not associating the two names.
Original comment by irar...@gmail.com
on 22 Dec 2009 at 7:49
Oh, I also forgot to mention that I brought up the generic game library idea
because
I initially misread something earlier. So sorry about derailing this discussion
with
it. However, despite that, it has led to a rather interesting side discussion.
Also,
sorry about the long winded replies, since when I tend to get with a thought, I
tend
to like to follow it to completion, out of old habit.
Original comment by irar...@gmail.com
on 22 Dec 2009 at 7:54
Original issue reported on code.google.com by
irar...@gmail.com
on 14 Dec 2009 at 8:17