Detatch presentation from widget logic

[GoogleCodeExporter]

As explained here: http://guichan.sourceforge.net/forum/read.php?2,2843

My main concern with this bug report is that the Widget class itself has
become rather bloated, and is making it a bit less flexible than it could
be. To address this, presentation details should be split from the widget
logic details. Now, if this issue is addressed the way outlined in that
forum post, or is handled another way is irrelevant. The point being that
drawing logic doesn't need to be widget specific, and that not caring about
the specifics for widget presentation in the base class would give GUIChan
much more powerful base Widget classes.

As always, I'm willing to code up this solution, but I do not like just
coding up a complete solution (or even partial) only to have objections
raised before a design is agreed on. If I code it up, I'll expect us to be
at an agreement first as to how you'd like it done, rather than to
implement this large of a patch 4-5 times, so that you're not wasting my
time (which I consider to be a reasonable expectation).

So, without further adeiu, comment about what you think about this change,
as well as listing any concerns/issues you see with this proposal. Or, if
you have a different idea on how to address this issue, I would like to see
that as well.

Original issue reported on code.google.com by irar...@gmail.com on 14 Dec 2009 at 8:17

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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