16:36:59 <prock> #startmeeting 0.3.0 postmotem
16:36:59 <fifer`> Meeting started Sun Jan 24 16:36:59 2010 UTC.  The chair is prock. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:36:59 <fifer`> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:37:24 <prock> alright here we go
16:37:38 <prock> Topics are listed here: http://wiki.fifengine.de/Meeting:2010/01/24
16:38:10 <vtchill> excellent you want to be the moderator prock?
16:38:40 <prock> yeah.. we'll start from the top down as listed in the meeting agenda
16:39:17 <prock> #topic License / Agreement paper
16:39:40 <prock> This topic was brought up the other day in #fife
16:39:47 <prock> vtchill do you want to take this one?
16:40:25 <vtchill> well the idea spawned from confusion about what licenses we currently operate under
16:41:03 <helios_> hi :)
16:41:09 <prock> welcome helios_
16:41:19 <vtchill> i don't know that an agreement paper is needed, i have committed some things to boost for instance and they ask me if i am ok with their license header and they credit me in the source file
16:41:24 <vtchill> i think that is good enough personally
16:41:40 <prock> sounds reasonable
16:41:52 <vtchill> as long as we have our licenses clearly laid out on our source page and in any source we distribute i think thats the way to go
16:42:15 <chewie> one special situation popped up these days
16:42:34 <vtchill> now to extend this a little bit what do we do with files such as stuff coming from client projects
16:42:36 <chewie> CheeseSucker said that parts of the editor signal code is a direct copy of Djangos codebase
16:42:57 <chewie> Following our current policy we would just add there our license header as well
16:43:11 <chewie> But basically there is no work done from our side...
16:43:18 <vtchill> well what is their license?
16:43:21 <chewie> (if I understood that correct CheeseSucker )
16:43:42 <vtchill> usually you need to ask permission to copy their code into your project
16:44:04 <CheeseSucker> http://fife.trac.cvsdude.com/engine/browser/trunk/tools/editor/scripts/events/signal.py
16:44:11 <vtchill> depending of course on their license
16:44:30 <prock> http://code.djangoproject.com/browser/django/trunk/LICENSE
16:45:20 <prock> sounds like we need to add the copywrite notice
16:45:20 <CheeseSucker> http://wiki.fifengine.de/Python_coding_standards#License
16:45:21 <vtchill> yep so we need their copyright on our file
16:45:31 <prock> copyright even
16:45:34 <CheeseSucker> *  If you directly copy and paste code from another project the original copyright header needs to stay in place! Don't add a FIFE header to the file in this case.
16:45:36 <CheeseSucker> * If you used portions of code from other projects and integrated it into project files, add the FIFE header at the top of the file but add an additional remark after it that states the origin of the copied code parts.
16:45:38 <CheeseSucker> * You can use this example as a template in this case:
16:46:05 <CheeseSucker> that's what our coding standards say about the issue
16:46:09 <vtchill> ok thats good cheese
16:46:44 <prock> so basically we should remove the FIFE header and add the Django copyright notice
16:46:51 <vtchill> yes
16:47:08 <prock> what files does this affect?
16:47:17 <CheeseSucker> signal.py and saferef.py
16:47:18 <vtchill> i know signals.py
16:47:18 <prock> signal.py and one other
16:47:20 <prock> okay
16:47:47 <vtchill> also what should we do for files in the fife repository that came from a client application, such as the editor plugins
16:48:09 <chewie> well..
16:48:10 <prock> #agreed we should remove the FIFE header from signals.py and saferef.py and add the Django copyright notice found here: http://code.djangoproject.com/browser/django/trunk/LICENSE
16:48:23 <prock> one more thing.... who will be responsible for doing this?
16:48:41 <CheeseSucker> I can do it
16:48:49 <chewie> I'd say fife ships some generic plugins - and in the long run we should collect additional plugins somewhere else
16:48:51 <CheeseSucker> It's only two minutes of jobs
16:49:13 <vtchill> i guess we should take the same approach and put the copyright of the project even if from a client
16:49:14 <chewie> e.g. linking them on the homepage or something like that
16:49:16 <prock> #action CheeseSucker will remove the FIFE header from signals.py and saferef.py and add the django copyright
16:49:30 <vtchill> well if a plugin can be used across clients it would be nice if clients would contribute it back to fife
16:49:39 <chewie> yes
16:49:41 <vtchill> so we can maintain it
16:49:49 <prock> if they contribute it back to fife it becomes FIFE's code
16:49:57 <chewie> in that case we would put the lgpl header ?
16:50:02 <chewie> yep
16:50:08 <vtchill> yes but there should still be a credit given, but have the fife header
16:50:11 <prock> but we could also put a notice of who contributed it
16:50:21 <chewie> good enough I'd say
16:50:51 <vtchill> and the clients don't have to contribute it back if they are not comfortable with the license
16:51:26 <prock> #agreed any client code contributed back to fife should have the FIFE header and also credit given to the contributor
16:52:09 <prock> okay I think that basically covers everything for that topic
16:52:11 <vtchill> ok i think that is it for that topic
16:52:17 <chewie> yip
16:52:28 <prock> #topic recap FIFE 0.3.0 release
16:53:07 <vtchill> well to start this topic a big thanks to prock for heading it up and making sure things got done
16:53:16 <prock> no problem at all
16:53:19 <prock> :D
16:53:25 * chewie applauds
16:53:27 <prock> thanks for your support also
16:53:30 <CheeseSucker> yes, you got us to the finish line =)
16:53:43 <prock> As it was the first release ever there were a few problems
16:53:43 <vtchill> hehe mile 1... of a marathon is more like it
16:54:19 <vtchill> but anyhow i think a lot of things went right, mainly we stayed focused and didn't let things creep in pushing the release out
16:54:41 <prock> so I would like to apologize for missing a few things.    First I should have spent a little more time filling out the CHANGES file  (thanks CheeseSucker for doing that)
16:55:04 <prock> and of course the whole win32 scons building issues
16:55:22 <prock> did I miss anything?
16:55:36 <chewie> I'd say those things had to come up - at least there wasn't a release for ages ...
16:55:48 <vtchill> having a well defined set of goals was a huge help and let us stay on our goal
16:56:10 <CheeseSucker> yep, also this release was delayed for far too long
16:56:24 <CheeseSucker> we should've had this release out for over half a year ago (at least)
16:56:31 <chewie> yep
16:56:49 <CheeseSucker> I think we should aim for more frequent releases in the future
16:56:49 <prock> vtchill: agreed
16:57:06 <prock> thats exactly what vtchill and I have been talking about
16:57:12 <chewie> Also we lack some progress documentation - as far as I got it you went through the trac changesets / tickets to spot them ?
16:57:27 <prock> we should probably fill you in on the plans we were talking about for 0.3.2 and 0.3.3
16:57:30 <prock> er
16:57:32 <vtchill> yes and i think we are heading in the right direction, the editor took a huge leap in aesthetics and usability and the build system is much easier to use and supports more targets for future fife expansion
16:57:34 <prock> 0.3.1 and 0.3.2
16:57:49 <vtchill> was going to save ethat topic for the future topic
16:58:05 <prock> k go ahead vtchill
16:58:14 <prock> lets try and stay on one topic
16:58:15 <prock> hehe
16:58:20 <chewie> ^^
16:58:29 <vtchill> ok so have we noted all the open issues with 0.3.0
16:59:09 <chewie> perhaps we could add that parpg missed the release at all - but there is not much we can do about that
16:59:44 <vtchill> i talked with one of the developers today and gave him the run down about how to upgrade parpg and he said he would do it later this week
17:00:16 <vtchill> i also told him to stop by the fife channel if he has questions
17:00:29 <chewie> yes, I also posted at their forums as one of their devs had install problems
17:01:01 <vtchill> so the issues i know about are the problems building in debug mode in mingw for python clients
17:01:01 <prock> here is the list of open problem we indend on fixed for 0.3.1 --> http://fife.trac.cvsdude.com/engine/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&milestone=0.3.1
17:01:01 <chewie> yip, so it's up to them to stay in touch with fife
17:01:47 <vtchill> unfortunately the link fails under mingw when building the debug version of fife python library
17:02:00 <vtchill> it affects not only mingw, but using code::blocks projects as well on win32
17:02:16 <prock> because we do not have the debug versions of the python libraries
17:02:28 <CheeseSucker> code::blocks uses the mingw compiler, doesn't it?
17:02:49 <vtchill> it doesn't really "use" anything anymore... it just calls the scons files which use the mingw compiler on win32
17:03:06 <vtchill> as opposed to msvc which doesn't use scons at all
17:04:38 <prock> I cant think of any other issues that aren't listed in the above link I posted
17:04:44 <CheeseSucker> how should we deal with progress documentation?
17:04:48 <vtchill> also although codeblocks is cross platform, the projects for fife don't really support linux builds at the moment, it was a little confusing on how to set that up when i was going through it
17:05:04 <vtchill> i haven't tested it though so its possible that it would work to build under linux, not 100% sure
17:05:22 <prock> perhaps a ticket should be made
17:05:37 <vtchill> hmm what did people have in mind for progress documentation?
17:06:10 <CheeseSucker> Some kind of documentation of what we have done, so we can easily fill in the changelog =P
17:06:22 <chewie> CheeseSucker, perhaps releasing more often would already help solving that issue
17:06:32 <CheeseSucker> probably
17:06:37 <vtchill> my fear is duplicating what is done by trac in some sort of user modified file would not work well
17:06:49 <chewie> So extracting all closed tickets from the milestone should cover the most important issues
17:07:00 <CheeseSucker> we could create a trac ticket for all tasks except minor ones
17:07:15 <vtchill> if we stick to what major projects do, a ticket for every commit, it should track quite well
17:07:19 <prock> basically thats teh best way to do it..  all changes should be documented with trac tickets.
17:07:27 <CheeseSucker> even typos?
17:07:35 <chewie> CheeseSucker, jep - so far features aren't trac tickets (as long as they don't have bugs)
17:07:43 <prock> no.. but you generally doing put typos in the change log
17:07:50 <vtchill> well does that warrant a spot in the changelog CheeseSucker ?
17:07:59 <CheeseSucker> yes, it does
17:08:07 <CheeseSucker> under the line: * Plus lots of minor bugfixes
17:08:12 <chewie> heh
17:08:18 <prock> lol
17:08:33 <vtchill> haha goal would be to eliminate that line from the changelog since it doesn't say much
17:09:17 <prock> so we agree...  make trac tickets when you feel they are necessary and we will use them to track completed changes for the next release
17:09:32 <CheeseSucker> yep
17:09:42 <vtchill> and in case some are unaware as i was.. you can put for example [t:407] at the end of your commit line in subversion commit line to have it automatically comment on ticket
17:09:44 <chewie> we could add a "feature" component to trac
17:10:10 <chewie> mmh.. - that works?
17:10:21 <chewie> cool :)
17:10:21 <vtchill> yea prock and i have use it
17:10:38 <prock> #agreed make trac tickets when necessary and we will use them to track completed changes for next release
17:10:52 <chewie> How about branch merging etc.?
17:11:08 <prock> branch and merge should have a single ticket
17:11:09 <chewie> Should we create tickets therefore as well?
17:11:17 <chewie> oki
17:11:28 <vtchill> yes merging a feature or enhancement branch should be tracked by a ticket
17:11:29 <prock> you would close the ticket when you merge back into trunk
17:11:41 <prock> thats what we did for the build_system_rework branch
17:11:51 <chewie> so if e.g. helios_ starts a shader branch, he opens the branch, creates a ticket etc...
17:12:00 <vtchill> you only need tickets for things going into trunk... you can commit freely to a branch, but the merge back to trunk should be a ticket
17:12:32 <chewie> jip, sounds good
17:12:41 <prock> and try and keep track of your changes
17:12:45 <prock> in the ticket itself
17:13:13 <chewie> that's where "my tickets" comes in handy
17:13:52 <prock> #agreed for branching there should be one ticket that will be closed when the branch is merged back into trunk.  All changes should be kept track of in that ticket.
17:14:13 <prock> okay next topic?
17:14:16 <vtchill> ok any other 0.3.0 comments before we move on
17:14:37 <chewie> not from my side
17:14:47 <CheeseSucker> nope
17:14:50 <prock> I believe CheeseSucker took care of the CHANGES file so we wont need to talk abou that
17:14:55 <vtchill> alright, lets do it
17:14:59 <prock> FIFE 0.3.1
17:15:06 <prock> #topic FIFE 0.3.1
17:15:27 <vtchill> so first proposed release date?
17:15:43 <vtchill> well i guess a little overview first...
17:15:58 <vtchill> 0.3.1 is intended to be a bug fix release for stability
17:16:07 <vtchill> no real new features or enhancements
17:16:37 <CheeseSucker> what is the status of phoku's optimization branch?
17:16:51 <chewie> unchanged
17:17:09 <prock> CheeseSucker: It has bugs... so as of right now we cannot merge
17:17:09 <chewie> phoku is MIA and there are 2 (?) visual bugs
17:17:28 <CheeseSucker> would his branch fit in a minor release?
17:17:29 <prock> and we have slated it for 0.3.2
17:17:32 <CheeseSucker> ok
17:17:39 <CheeseSucker> that answers the question =)
17:17:54 <prock> I hope we hear from phoku before then
17:17:59 <chewie> jip, me to
17:18:00 <prock> but it buys us some time
17:18:07 <CheeseSucker> there are a lot of bugs in the editor, but noone has created tickets for them
17:18:08 <vtchill> even if we don't i think we can handle the bugs
17:18:44 <vtchill> well CheeseSucker is that a volunteer?
17:18:45 <prock> vtchill: agreed
17:18:48 <CheeseSucker> So I will have to go over the editor and look for bugs and add them to trac
17:18:55 <chewie> CheeseSucker, jip - I guess the editor isn't used that often from UH / parpg
17:19:13 <CheeseSucker> UH doesn't use it, but I think parpg does
17:19:15 <vtchill> that is something we want to change, but we will address that later in another topic
17:19:21 <chewie> I know about some bugs as I'm writing plugins for it, but I was MIA, too ^^
17:19:50 <chewie> vtchill, oki
17:19:56 <chewie> so - talking about the release date?
17:20:09 <vtchill> i was thinking march time frame
17:20:11 <CheeseSucker> march?
17:20:12 <prock> I would propose 3 months
17:20:25 <prock> seems we are all in agreement there
17:20:30 <chewie> jip, sounds better then "some weeks"
17:20:36 <prock> late march?
17:20:42 <vtchill> so we want to go end of march, around the 20th or so
17:20:45 <prock> say around the 20th
17:20:48 <vtchill> :)
17:21:04 <prock> sounds good to me
17:21:07 <CheeseSucker> around March 20th 20:31 GMT
17:21:10 <prock> lol
17:21:19 <chewie> hehe
17:21:54 <prock> #agreed FIFE 0.3.1 - tentative release date is March 20th, 2010
17:22:02 <vtchill> so any bugs that are not assigned or the owner is FIFE feel free to assign it to yourself and go after it
17:22:16 <chewie> I also think that some of the tickets aren't bugfixes at all..
17:22:28 <vtchill> and you can click on Active tickets by milestone and that will separate them nicely
17:22:29 <chewie> like our pychan hide/show ticket ...
17:22:52 <prock> chewie: they dont ALL have to bug fixes.. :P
17:23:25 <prock> those are the tickets we chose to include in 0.3.1.
17:23:31 <prock> mostly bug fixes
17:23:34 <vtchill> we do need to be careful with the release though to not drastically change the interface or inner workings of a module
17:24:06 <prock> true.. the idea behind a minor release is to fix any bugs introduced in the major release
17:24:49 <chewie> jip, that's why I'd say #375 is a feature request
17:24:52 <prock> however in this case we decide to move some enhancements to a minor release
17:24:59 <prock> 0.3.2
17:25:18 <prock> basically these are all things we want to take care of before moving to 0.4.0
17:25:39 <prock> kindof a transition to the major.minor release schema
17:26:47 <prock> chewie: You can move it to 0.3.2 if you wish
17:27:30 <chewie> I'll have a look into it first - maybe our "hack" solution works
17:27:41 <vtchill> also if you find that a bug in 0.3.1 is starting to be a major change feel free to comment on the bug stating this, and we can talk about it as a group and decide what to do about it
17:27:46 <prock> I would prefer thre wasnt a hack fix though.. hehe
17:28:04 <chewie> well.. to me it's not a hack, it's a solution :>
17:28:19 <vtchill> but is it THE solution :-p
17:28:28 <chewie> hehe
17:28:46 <chewie> it's basically the solution I could offer - for everything else I'm lacking ideas for the implementation
17:28:53 <prock> but you are right chewie... we are changing the interface with that ticket.. perhaps we should move it to 0.4.0
17:29:24 <vtchill> i don't have a problem with that
17:29:24 <chewie> If there is any chance I'll discuss it with phoku
17:29:36 <prock> make sure to add your solution as a comment so you dont have to do all the research again
17:29:48 <vtchill> yes definitely comment on the bug
17:29:50 <chewie> I could imagine that he goes mad if I'm implementing that hack ^^
17:29:58 <CheeseSucker> haha
17:30:21 <vtchill> well a hack can always be implemented properly in a later release that will include more drastic changes
17:30:43 <chewie> prock, yep, I attache the irc snippet to the ticket
17:30:54 <vtchill> so anything else on the 0.3.1 topic?
17:30:56 <prock> in any case...   the changes CheeseSucker was talking about regarding the editor
17:31:08 <prock> where should those tickets go?
17:31:18 <CheeseSucker> what changes?
17:31:24 <prock> bugs
17:31:29 <chewie> there is a component for the editor... or what exactly do you mean?
17:31:37 <vtchill> i will leave that to CheeseSucker, but if they are truly bugs (defects) i say 0.3.1 for now until we have too many
17:31:41 <prock> do they go in 0.3.1, 0.3.2, or 0.4.0
17:31:52 <CheeseSucker> I would say minor releases
17:31:54 <chewie> ah, I see
17:32:02 <prock> if they are defects put them in 0.3.1... if they are enhacements put them in 0.4.0
17:32:20 <CheeseSucker> there are some tasks (like making the history manager pretty) that would probably go to 3.2 or 4.0
17:32:23 <prock> CheeseSucker: are you going to report them all?
17:32:33 <CheeseSucker> the ones I find
17:32:38 <vtchill> sounds good
17:32:40 <prock> okay
17:32:48 <vtchill> i will try and mess around with the editor some as well
17:33:43 <vtchill> next topic?
17:33:48 <CheeseSucker> has the components been renamed in trac?
17:33:52 <prock> #action CheeseSucker will report any bugs he finds in the editor and use his discretion as to which release to put them in
17:33:57 <CheeseSucker> AFAIK, the editor component was named clients/editor
17:34:01 <chewie> there is clients/editor
17:34:04 <chewie> yes
17:34:09 <prock> CheeseSucker: no they haven't
17:34:15 <chewie> but now it should be tools/editor I guess...
17:34:17 <CheeseSucker> yep
17:34:27 <prock> I'll do that
17:34:54 <chewie> fixed it
17:34:58 <prock> #action prock will rename the trac components corresponding to the editor and rio.. etc etc
17:35:06 <chewie> should I rename clients/rio as well?
17:35:11 <prock> lol
17:35:11 <chewie> heh
17:35:14 <prock> okay you do it then
17:35:14 <chewie> sorry
17:35:16 <chewie> :D
17:35:25 <vtchill> yes demos/rio
17:35:26 <CheeseSucker> hahaha
17:35:45 <prock> next topic...   future FIFE development
17:36:00 <chewie> done
17:36:01 <prock> #topic Future FIFE development
17:36:13 <prock> We can probably talk for hours about this
17:36:20 <vtchill> well this is meant to just be high level
17:36:22 <prock> but I'd like to keep it relatively short
17:36:31 <chewie> Any major ideas behind that?
17:36:32 <vtchill> things we want to see and just to get ideas in peoples heads
17:36:35 <prock> I was telling vtchill about a dream I had
17:36:39 <prock> a vision
17:36:42 * chewie listens
17:36:51 <prock> about FIFE's future
17:37:24 <prock> FIFE should become truly (f)lexible
17:37:53 <prock> I can see it as a fully featured 2D engine... with a build in pysics and collision detection system
17:38:04 <prock> physics even
17:38:24 <prock> to make it suitable for all sorts of 2D games
17:38:51 <prock> thats all I got
17:38:52 <prock> lol
17:38:56 <vtchill> :)
17:39:01 <vtchill> so i will add some things i would like to see
17:39:43 <vtchill> (1) better pathing using something like navigation meshes with nice integration with the editor for creation
17:39:59 <vtchill> (2) particle engine to simulate effects such as fire, explosions, etc.
17:40:28 <prock> the particle engine is slated for 0.4.0
17:40:30 <prock> :D
17:40:46 <chewie> let me show a small video ...
17:41:03 <vtchill> (3) more flexible map saving/loading, i think this should be implemented like a fife engine plugin so that users can override this if they choose to, but this would allow for different languages to use fife
17:41:43 <prock> aye... right now we are tied to python because of the map loading.. and pychan for that matter
17:41:58 <prock> which brings me to another idea.......   wait for it......
17:42:12 <prock> get rid of guichan and write our own gui interface
17:42:21 <vtchill> thats a later topic! :){
17:42:24 <chewie> -> http://www.youtube.com/watch?v=ut0SqBeAy1Q
17:42:43 <chewie> per pixel lighting :)
17:42:48 <helios_> :>
17:43:11 <vtchill> very nice looking effects there chewie
17:43:16 <chewie> So about the vision - that all sounds great :)
17:43:40 <vtchill> (4) clean up the coordinate system in fife and provide a nice easy to use api
17:43:41 <chewie> We @zero have some too... although they are "smaller"
17:43:47 <helios_> yep i like the idears too
17:43:55 <helios_> ideas
17:43:59 <chewie> (1) movie support
17:44:12 <chewie> (2) introducing basic lighting into trunk/
17:44:23 <vtchill> that is on my list as well
17:44:46 <chewie> (3) improved pather that allows AI development
17:45:49 <chewie> physics and collisions would be very nice - as well as the particle engine
17:45:52 <CheeseSucker> I would like to see some samples that will be shipped with FIFE
17:46:04 <CheeseSucker> small snippets that shows how things can be done in FIFE
17:46:08 <vtchill> speaking of samples, i started a tutorials for fife
17:46:20 <CheeseSucker> f.example: 3D sounds, a basic platformer, board games, etc
17:46:22 <vtchill> i need to update it to the trunk
17:46:31 <chewie> a demo branch is definately needed CheeseSucker
17:46:46 <vtchill> the tutorials are meant to be short and to the point
17:46:52 <vtchill> such as here is how to control user input
17:47:02 <vtchill> here is how to mess with the camera and viewport
17:47:21 <vtchill> etc.
17:47:27 <CheeseSucker> do you have a link?
17:47:28 <chewie> vtchill, good idea - I also started a pychan tutorial a long time ago - maybe we can join forces there
17:47:35 <CheeseSucker> IIRC you had a website
17:47:52 <vtchill> http://code.google.com/p/fife-tutorials/
17:48:04 <vtchill> its in c++ as well which is driving the need for a more flexible map loader/saver
17:48:33 <vtchill> i am hoping to have several tutorials each with a wiki page describing what the code is doing
17:49:55 <prock> I think I may help with some of the tutorials
17:50:07 <CheeseSucker> I need a password to checkout the tutorials?
17:50:12 <vtchill> absolutely
17:50:13 <vtchill> no
17:50:18 <vtchill> you can checkout anonymously
17:50:30 <prock> but for now I'd like to concentrate on getting 0.3.1 out and 0.3.2
17:50:42 <vtchill> Use this command to anonymously check out the latest project source code:
17:50:42 <vtchill> # Non-members may check out a read-only working copy anonymously over HTTP.
17:50:42 <vtchill> svn checkout http://fife-tutorials.googlecode.com/svn/trunk/ fife-tutorials-read-only
17:50:43 <prock> perhaps the tutorials can be released with 0.4.0
17:50:51 <CheeseSucker> failed: Could not authenticate to server: rejected Basic challenge (https://fife-tutorials.googlecode.com)
17:50:56 <vtchill> yes i a thinking 0.4.0 for tutorials
17:51:06 <CheeseSucker> ok
17:51:06 <vtchill> it won't work currently with fife CheeseSucker
17:51:39 <vtchill> also i was waiting till we completed the build system rework b/c i couldn't build fife properly for a static lib in linux
17:51:57 <prock> those are C++ tutorials
17:51:59 <vtchill> so currently on win32 and msvc support for the tutorials
17:52:03 <vtchill> yep
17:52:27 <chewie> We also have this thread here -> http://forums.fifengine.de/index.php?topic=73.msg1358#msg1358
17:52:29 <prock> also...  I dont know if we mentioned this before... but we want to re-introduce the ability to use FIFE as a C++ library for C++ projects
17:52:51 <chewie> (Request for Tutorial)
17:53:31 <CheeseSucker> is there anything stopping this from being possible?
17:53:33 <chewie> prock, yes - I remember that one
17:53:36 <CheeseSucker> except the serializers?
17:53:51 <vtchill> well not anymore the build system now supports it
17:54:02 <vtchill> i wrote a c++ map loader for fife
17:54:06 <vtchill> its still in its own branch
17:54:49 <vtchill> but it works for loading a file saved from FIFEdit
17:55:52 <chewie> So, can we summarize the future of FIFE somehow?
17:56:13 <vtchill> a page on future fife features might be useful
17:56:26 <chewie> Tons of features and additional language support?
17:56:28 <CheeseSucker> General purpose 2D C++ game library?
17:56:30 <chewie> :>
17:56:57 <vtchill> haha
17:57:19 <vtchill> well we can slide down to the next topic which really goes hand and hand with a lot of these features
17:57:22 <chewie> And one question - are those visions pure dreams or are we able to achieve them?
17:57:36 <CheeseSucker> I think we should be able to achieve most of them at least
17:57:36 <vtchill> i think they are all achievable
17:58:00 <chewie> :)
17:58:10 <CheeseSucker> physics and particle engine are the ones that seems hardest
17:58:11 <prock> the problem with these dreams is we do not want to change the API that much as to make parpg, uh and zero mad at us
17:58:35 <vtchill> well at some point its going to happen
17:58:36 <chewie> We might want to listen to the other projects and generate some kind of roadmap as well
17:58:54 <CheeseSucker> UH would probably be angry if we turned FIFE into an engine for board games =P
17:59:01 <prock> so the short term goal is to make FIFE as it is very usable
17:59:15 <vtchill> we are pushing for stable releases so hard so we can change fife in the future and projects that don't want to updates can stay on a certain version
17:59:23 <chewie> From my point of view as zero programmer, FIFE still needs some love in order to let us a create games
17:59:35 <prock> vtchill: well put
18:00:28 <prock> the idea is to make FIFE as stable and useable as possible as it is right now...  try and get a 1.0 release out there.. and start working on major features/re-writes
18:00:47 <vtchill> personally i would like to change the architecture of how fife stores objects and instances drastically, but i would certainly hold off on this until fife is a stable engine for those that like the features the way they are now
18:01:09 <chewie> mmh... it's not so much about likings I'd say...
18:01:39 <vtchill> well we certainly understand that a lot of code depends on the api fife has now, we don't want to break that
18:01:41 <chewie> If we e.g. rewrite the gui, there is a lot work destroyed for UH and Zero
18:01:59 <vtchill> but we want to evolve fife, but provide support for clients using past revisions
18:02:01 <prock> chewie: which is why we cant to that until the future
18:02:12 <prock> to = do
18:02:31 <chewie> so future visions = post 1.0?
18:02:38 <prock> exactly
18:02:45 <chewie> ah, now I get the idea :)
18:02:53 <vtchill> i am thinking we will have a fife 2.0 and that will be where all the magic happens
18:03:06 <vtchill> everything fife <= 1.99 is the old code with enhancements
18:03:10 <chewie> Okay, so Zero 2 then has physics and particle effects :o)
18:03:27 <vtchill> and possible a rewritten internal fife architecture and much different api
18:03:32 <vtchill> just to warn
18:03:55 <prock> maybe just a complete re-write...  :P
18:03:59 <chewie> XD
18:04:13 <vtchill> the problem is clients started writing code to depend on fife before fife has really matured
18:04:13 <prock> we really have to sit down with all these enhancements and decide if they are feasible to implement in FIFE 1
18:04:15 <chewie> an irrlicht core with some additions? ^^
18:04:33 <vtchill> hehe if we could support what irrlicht does that would be impressive
18:04:55 <prock> but I think thats about it
18:05:03 <prock> anywone else to add?
18:05:06 <prock> er
18:05:12 <chewie> vtchill, it´s not a problem - that´s why FIFE is where it is now :)
18:05:20 <chewie> Just remember: Make games, not engines :)
18:05:27 <prock> lol
18:05:27 <vtchill> i agree completely
18:05:45 <prock> anything else to add?   I'll close the meeting if not
18:05:58 <vtchill> anything else on the meeting topics?
18:06:12 <chewie> mmh..
18:06:20 <prock> nope.. looks like we touched on just about everything
18:06:23 <vtchill> just a quick note about FIFEdit
18:07:17 <vtchill> it needs to be fully featured, most other engines out there provide everything through the editor and the client then rights gameplay code only, they don't have to much with programatically doing things that the engine should really be able to handle up front
18:07:56 <vtchill> this goes with the idea of providing a nice standard game engine and toolset for clients
18:08:23 <chewie> mmh - is that even possible in terms of flexibility?
18:08:39 <vtchill> well other engines do it successfully
18:08:58 <CheeseSucker> examples?
18:09:01 <chewie> I only now genre-focused toolsets like e.g. rpgmaker
18:09:09 <vtchill> unity is a good one to look at
18:09:35 <vtchill> unreal engine is free and it provides a ton of features through the editor
18:09:36 <CheeseSucker> mass media fusion has a lot of impressive games, but they don't write any code at all
18:09:39 <chewie> the Löve engine is flexible as well, but needs a lot of programming IMO
18:09:44 <prock> vtchill: I think thats a little too restrictive
18:10:00 <CheeseSucker> unreal engine?
18:10:25 <prock> FIFE should be flexible and not limiting
18:10:50 <vtchill> its the one used by a lot of commercial companies for 3d games made by epic games
18:11:00 <vtchill> unreal tournament, gears of war, etc.
18:11:07 <vtchill> its got a nice editor along with the engine
18:11:08 <prock> I would define flexible being the ability for clients to extend/override the default behaviour of FIFE
18:11:10 <CheeseSucker> yep, I have made a couple of levels for UT2004
18:11:18 <CheeseSucker> but their editor needs a little love too =)
18:11:25 <CheeseSucker> (haven't tried the one for UE3)
18:11:38 <vtchill> well its not flawless, but it provides much tighter integration with the engine i think
18:11:52 <prock> Okay.. I'm going to end this meeting.. these are all topics we should perhaps start forum posts for
18:11:59 <vtchill> whats limiting about the way unity does things prock
18:12:14 <chewie> mmh.. maybe I lack the understanding right now - but if I compare UH and zero ... I couldn't imagine a basic client which would allow that
18:12:42 <vtchill> i dont see them as that much different really from the engines point of view
18:12:48 <prock> all in favor of ending the meeting and taking these discussions to the forums?   or back in #fife?
18:12:56 <vtchill> sure
18:12:56 <CheeseSucker> yep
18:12:59 <prock> #endmeeting