Welcome, Guest. Please login or register.

  Show Posts
Pages: [1]
1  General Category / General Discussion / Re: Installation problems on: January 23, 2010, 06:18:53 PM
FIFE 0.3.0 introduced a new build system. All python bindings of FIFE now live within the python site-packages, so you need to adjust your import statements accordingly.

More information can be found here:
http://fifengine.de/2010/01/12/the-build_system_rework-branch-has-been-merged-intro-trunk/

It's also not longer necessary to add FIFE clients to a dir within the FIFE dir structure - due to the changes you can now add your client to e.g. Games\parpg and start it from there.
2  General Category / General Discussion / Re: FIFE, Zero-Projekt, and PARPG on: April 01, 2009, 11:22:04 AM
I googled, not because i was unsure, but to lend some authority to my statements.  ZP clearly does not fit the "the source is available" clause (or words to that effect) that the majority of the definitions have.

If you headed for some authority, some sources (*g) would have been a good idea - plain "googling" nowadays isn't that trustworthy.

Really PARPG is little more than an idea right now.  But it is freely accessible to anyone who wants to read our forum, wiki or IRC Log.

Yeah, but there was a time at the very beginning were no sources were available - and yet the term open source was used in connection with parpg. My point is to discuss if there is a hard limit for the timespan you have to come up with sources if you want to open your software or not.  When the first news arrived about paRPG, all the infrastructure wasn't set up. So technically, this made paRPG a sourceless open source project _at the beginning_. If defintions would be as strict as you describe them here, a project only can call itself open source from the moment on, the source code is available.

I did do a fair bit of looking around the net before posting this topic.  I never found any english statement about the license for Zero.  It was kinda confusing trying to navigate your webspace.  No doubt it is easier in german, but i hit a lot of dead links (on an old site?), and generally wandered around not finding anything but some screenshots, movies, and an explanation of armor.

I realize it takes time to keep all that stuff working.

When did you do so? I'm just asking because we had some troubles with our database the last few days. This may explain the dead links you encountered. Our forums moved to http://forums.zero-projekt.net and works again  Smiley We are also about to relaunch our website and replace it with a multilanguage one this week, which can be found via http://en.zero-projekt.net.

If you want the rest of the world to understand your project a good place to start would be to use the normal definition of "open source".

I stopped trying to "make the rest of the world to understand" - at the end everybody has his own opinions - no matter on how you try to explain your intentions. And I still doubt that the "normal definition" of open source includes to tell authors who are willing to release their work as open source, that they are not open source.

An open wiki, IRC and forums doesn't make open source software. Available sourcecode for available software does (in the combination with the proper license, of course).

Anyway, this discussion took (IMO) the wrong way. I never intended to sound harsh or to make yourself explain wether you googled as an addition or because you are unsure (just as an example). I wanted to clear things up before yet another wrong information is spread.

cheers,
chewie
3  General Category / General Discussion / Re: FIFE, Zero-Projekt, and PARPG on: April 01, 2009, 02:32:13 AM
Let's stick to the facts - these will ease a lot.

From my experience, there are a lot of defintions of open source out there. Some people would agree with you - but I don't. And that basically is also connected to the fact, that you had to google for these statements.

Look, it's simple. I'll stick to the open source path for years now - and it lead me to the point where I was able to start a open source project - no matter on how other people would call it. The name of this project is - Zero. It's may attempt to contribute to the community - to have a nice example game for a very promising 2D engine which hopefully will encourage other people to also join the community around FIFE and start making high quality games with it, too.

All python files of Zero have the GPL header embedded, right after the unicode definition. This isn't because I want to try out wether this looks nice or things like that. That's because this software is open source.

And it's not open source "once it is finished" - it's already open source.

What we are talking about right now is nitpicking - I'd say. When can you call your project open source - when is it the right time? Are you only allowed to call it like this if you released something? Or are you also allowed to call it open source if you head for a stable beta instead of throwing yet another alpha to the public?

How about parpg? You called this project open source right from the start - but there weren't any releases yet - even no code. And still. parpg was advertized as open source project. Do you get my point? Maybe we can meet here - if you can start a project, call it open source before any design docs are finished, or any further concepts which go beyond the idea to make a game, then Zero should also be allowed to call itself an open source project.

You can blame us once we released a binary, but no source code. But at the current stage of the project, this discussion seems to be - at least for me - weird. Or it's like wasting energy ... which could be used to push on our projects. Do the real work, you know?


Quote from: eleazzaar
I understand that you wouldn't want your home server to be accessed by too many people.  But it's not clear, was the COOP content ever made available?  There are lots of free options for hosting open source content.

Yet another misunderstanding. The short version (this post is already way too long):
- Zero-Projekt Team used it's own infrastructure to work on the _creation_ of the content
- All commits for the coop went to the _FIFE SVN_
- FIFE SVN had limited capacities MB wise - my local server had enough store to host all the binaries (images, blends). I don't know if you have an idea on how much content creation will cause - but last time I checked we had 7 GB, and rising.
- Ol' COOP Techdemo is available here -> http://mirror1.cvsdude.com/trac/fife/engine/browser/tags/2007.2
- No one ever cared about the additional contents itself, as the COOP was *snip* canceled - just like that. It was of no interest anymore for FIFE. (just in case _anybody_ wants to blame me or Zero for that)

Quote from: eleazzaar
But I am also curious why your team has adopted the method of not releasing anything until the end.  Again, that's your business, you don't need to justify the project to me or anyone else.  I just can't think of any significant benefits to keeping the source closed until the big release.

Again, let me point out that we miserably failed in terms of marketing. We wrote about that in one of our last news - but seems that no one read it. (like no one read our FAQ :sigh:).

If this would be a perfect world, we all would already have played the zero demo (or not ^^) - because we had a release date for christmas 2008. It was one of this "this year or never"-speeches our project leader held 5 months before the year ended. And we were busy like hell. Suddently, university started for me. Then other RL issues in the team appeared - which led to a complete stall of the demo development. It took us very long to recover from this one - and it was - again - a very hard time Zero had to go through.

So, the end of the story: No demo. No release. No "being allowed to call us officially a open source project". (just kiddin here ^^) No going live for the epydoc server I set up. A lot of wasted work. Shit happens.

But we still stick to our credo "Let's make an open source game by using closed development". Our core team now works together for 3 years - and we became a small family. That's the environment I prefer to work in. Open development has a lot ups and downs in terms of member fluctuation. I don't say this is not true for us - but we don't had that many turnarounds as I experienced it in the FIFE project. (to just mention some of them: Ianout, C++ rewrite, LUA core, ASM and Datasets, Python core + model core ...).

And yet another credo: "We want to create a great game - with own assets and no third party graphics, so that the people say 'Cool - that's Zero' and not 'nice, but I've seen this tile in project X', or '...this weapon in project Y', or 'heared this ambient track in project Z'".

Perhaps our way of doing things isn't understandable for most of you / other people. But it's our - experiment.

Quote
A better phrasing of my quote just above would be, "Why aren't we using any Zero-Projekt content?"

Even if this would be possible because Zero is released and completely open source - I would beg you and (all other) to not use our media. Because this is the soul of our game.

cheers,
chewie
4  General Category / General Discussion / Re: FIFE, Zero-Projekt, and PARPG on: March 31, 2009, 10:50:32 PM
Moin eleazzaar (& all others) Smiley

Thanks for starting this discussion - this shows (to me) one more time that we (Zero) miserably failed in terms of marketing.  Cry

So far, no statement brought here about Zero-Projekt is correct - unfortunately.

Let me point out the most critical parts:

[..]
PZ does not share code AFAIK

This is wrong. (Explanation follows below)

PZ used to be the proof-of-concept project collaborating with FIFE, but their ways parted since PZ was too reluctant to make their content openly available.

This is ... well - totally wrong. There was a time both the teams of FIFE and Zero-Projekt started a COOP to enhance the development of FIFE. Zero-Projekt should take care about the art, while FIFE should do the coding part. This mainly started to give FIFE something to test their code with - as in "Make games, not engines".

Sadly, the COOP was chanceled by the FIFE team - because of communication problems. The game of the COOP itself had a design doc. first art, a simple ruleset, a client - and everything is waiting in my desk to be revived some day  Grin From my point of view, this one went down because of massive communication problems, not because of the points Lamoot mentioned here.

Well, the major point here is: Zero-Projekt wasn't founded because of the COOP - we started a second project besides our own game.

Second, all the content of the COOP was - at every time - Open Source. Zero made the content, but it was donated to the FIFE project.

Third: There was never any deny from our side to "make our content openly available" in terms of the COOP. Lamoot is mixing up two things here - Zero and COOP. We only were "reluctant" to open our SVN for the COOP. Both my tiny little home server and my internet connection can't handle a public access.

The biggest obstacle is that zero is not open source.

Zero-Projekt is - partly - open source. Namely. the python code is. What maybe confuses you is that there are no sources available yet - which is due to the fact that there was no release yet.

Further explanations can be found in our (english) FAQ .

Short summary: Zero-Projekt scripts are open source but not yet released. Zero-Projekt media will be licensed by cc by-nc-sa once the final release is out.

What's wrong with Zero-Projekt?

Again, from my point of view: nothing. Barra knows me since I joined FIFE in 2006, and knows about Zero since I founded Zero-Projekt some months after that. But As far as I got it - Barra wants to make a different game than Zero - well at least if you look into the details. The most important difference would be, that Barra - as a big fan of Planescape Torment and it's dialogue style - wants paRPG to have a similar feature.

That's all folks - hope I could bring some light into this topic.

cheers,
chewie
5  Development / Programming / Re: Proposal:Drag & Drop on: March 20, 2009, 06:54:06 PM
I´ ve a proposal for the drag component:

Instead of pinning the widget to the mouse cursors position (with a x/y offset), you can also use the setDrag functionality of the FIFE mouse cursor. Means, you provide a image file, and combine it with the current mouse cursor (if you like - you can also style the mouse cursor to have no additional image). Doing so, you save some lines of code to sync the widgets position with the event.getX() / getY() methods.

This solution works very well for Zero so far.
6  Development / Graphics / Re: GUI "feel" and design on: March 13, 2009, 01:19:52 PM
that's why the base elements of a GUI should be for example vector-based.

Sounds good in theory, but it doesn't seem to work out in most cases.  Pretty much every GUI is made out of bit-maps bits.  Don't ask me why, i'm sure it's complex.

Yet another approach would be to build the gui in 3D. We @zero-projekt are using a gui construction kit made with blender to store all elements of our gui in one *.blend. This way, resizing or other changes are a very easy task. (and as guis change a lot during development, that's a huge advantage ...  Wink )
7  Development / Programming / Re: Context menu thoughts on: March 06, 2009, 07:28:37 PM
Hey chewie,

Thanks a lot for your comments - I really appreciate your advice.

You're welcome Smiley

For the time being however, we are stuck with Rio - this is the current team decision. Plus, I basically lack any understanding of how FIFE is working in general Smiley and fiddling with Rio is a great way to see how different problems are tackled. It would take me an awful lot of time to build anything without Rio, and since I lack gamedev experience as well, it is really dubious whether I could produce a result that is better than Rio. Last, Rio give all departments something to chew on, and see immediate result of their work.

I see your point about getting more and more resistance while trying to customize things, and I have no doubt that we will try rewrite large portions of Rio's codebase Smiley Still, currently this is considered to be the lesser evil.

Sure, to learn FIFE it is helpful - btw, I always have fife.py open in my IDE - it's a good reference for all the available bindings. (as in "because there is nothing else" ^^)


The Kick, Kiss, etc. actions are just placeholders - proofs of concept to show that there is some infrastructure in place. They will definitely not be making it into any kind of official release Smiley

I wouldn't worry about official releases at this point... *g* But I got it ^^ I thought you were talking about these context actions as part of the parpg context menu, totally missed the "as an example" thingy ....


[..] Working Python code usually beats all kinds of texts in terms of documentation Smiley [..]

Well, as python only is indented text... *scnr*

[..]
My current state of mind is that I will start with a fully loaded context menu, and then remove/hide the entries that the particular object can't handle. As there should not be too many context menu entries, this should be practically the same in terms of speed as starting with a blank menu, and then adding stuff to it. Although removing items feels less natural, it allows us to keep the XML file with a full list of entries + styling information inside.

Speed isn't really an issue here - I'm rebuilding more complex dynamic widgets (inventory) on a regular base, and pychan / python / FIFE never meowed  Grin AI and maploading is a different story, though.

I plan not to hardcode the callbacks tho - I plan to dynamically look for the callback, based on its name Smiley Again, I am not a big fan of introspection, but what I fancy even less is hardcoding the names in two different places (Python and XML).

Mmh... you mean something like this? ->

Code:
(Python)
instance_actions = ['Kick']

class ContextMenu(object):
# ...

def redrawContextMenu(self, instance_actions):
""" redraw the context menu with the instance's actions
@type instance_action: list
@param instance_action: all available actions of the clicked instance
"""
_CONTEXT_MENU_CALLBACK_PREFIX = "onCButton"

self.container.removeChild(self.wrapper)

self.wrapper = HBox()

for action in instance_actions:
mybutton = pychan.widgets.Button()
callback_name = _CONTEXT_MENU_CALLBACK_PREFIX + str(action)
callback = getattr(self, callback_name)
mybutton.capture(callback,"mousePressed")
mybutton.text = str(action)
self.wrapper.addChild(mybutton)

# ...

self.container.addChild(self.wrapper)

def onCButtonKick(self, event, widget):
""" callback for kick context button

@type event: object
@param event: fife event
@type widget: object
@param widget: pychan widget
"""
# ...

In this case you wouldn't need an XML-file. Instead, you can create the context menu container once the client is started and fill a wrapper (e.g. HBox) and map the callbacks accordingly.

Once again, thanks for your feedback chewie! Please keep sharing it whenever you have time.

I'll try to do so as often as possible Smiley There are a lot of pitfalls out there ...

Cheers,
chewie

8  Development / Programming / Re: Context menu thoughts on: March 06, 2009, 03:46:59 PM
Moin Smiley

I've some comments to your thoughts about the context menu - don't take them too serious if you don't agree - they are all based on my personal experience with FIFE.

- Forget about the mechanics used by the rio de hola client (seriously) - they are made to demonstrate on how one _could_ do this - take it as a rough idea
- Context actions should be designed towards your game, adjusting the current system to your game is IMO the wrong way. I recommend a rewrite (not only of this part, more about this on the bottom of this post) after you planned your client design
- Context actions should be added to the client after the basic functionality of your client design is written (adding it now will only cause problems / ugly code / many workarounds to make it work)

As a proposal for the system considerations itself:

- all instances own a basic interaction possibility (like you stated it already - best example would be "examine" to show the description of the interactive map object)
- depending on the role of the clicked instance, the options are expanded dynamicly (e.g. humans: talk, barter; living objects: attack)
- avoid specialised buttons like "kiss", "kick" etc. - I'd say these are things which should should appear in the dialogues - adding these buttons to the context menu will bloat it. (just imagine the player's face if a menu with 13 entries pops up - even 6-8 are already too much IMO - a game context menu should be about quick access to major functions)
- don't forget to sync your context action menu with your (hopefully) intelligent mouse cursor - why adding an "attack" button if the player can click on his weapon and hit the instance without RMB-Select-Click. Fallout had a very nice approach here: RMB somewhere on the map "pre"-toggles the context actions - e.g. one click enables the weapon to be active (next click on a map object would cause an attack), second click enables examine mode etc...

About pychan:
- as I already said, this code is a quick demonstration - and it's also an old one. You are able to just remove the wrapper widget (typically a HBox) from the context menu container, add a new one and add all your buttons you want to display to this new HBox. So no need to iterate through existant buttons and remove them "manually".
- you don't need an XML file - you also can create a container and its buttons on the fly once they are requested (so no need to hardcode anything besides your callbacks for all possible interactions)

About using rio de hola as codebase:
- it's a bad idea *g*
- design an own framework and use rio de hola only as a quick testing platform

I only say this because I've the feeling that you try to stick to the functionality rio de hola provides too much. The client lacks a lot of features and wasn't designed towards a special idea for a game - it was more like "loading a map, having a controlable character and providing some interaction" along with showing some engine features like rotation. So the FSM ai is a very basic one, there are no gamestates etc. - just keep that in mind and don't try to copy / extend this client but write your own one.

Of course - I see the major idea behind this, but trust me - it will do no good if you fiddle around with this client to make something playable like a demo - you will face situations which this design can't handle if your code starts to get complex. Just have a look at the Unknown Horizons SVN to get the idea about the amount of submodules a client should have ... Again, this is my personal experience - I also once used the old FIFE techdemo as codebase - and I tried a long time to make it fit all our needs. (Until the day I started to write a own framework ^^)

cheers,
chewie
Pages: [1]