Welcome, Guest. Please login or register.

  Show Posts
Pages: [1] 2 3 ... 6
1  General Category / General Discussion / Re: the state of the project on: July 21, 2011, 09:41:46 PM
Q_x is right on all counts - project structure, as is, isn't working. On mobile, so I'll , elaborate later, but here's my take. Project needs full-time developers - part-time volunteers just isn't enough any more. It worked in the past because barra was able to take on a huge number of responsibilities and dedicate tons of time to the project, but we can't reasonably expect anyone to volunteer that much time and effort. PARPG is now a huge project as well which needs a full-time staff.

We had an offer to provide full-time developers a few months ago - forgot the name of the organization. Maybe we should consider it.
2  General Category / General Discussion / Re: Since we are moving to component-based structure... on: June 23, 2011, 09:59:49 PM
Good find, that was quite an interesting read. That does seem to capture the core of what component-based design is and how designers use it.

I definitely like the idea of generic body and weapon components. We could implement a VATS-like system for turn-based combat, which would have the benefit of making combat more strategic.

The weapon and generic  design remind me strongly of Dwarf Fortress,  which uses a very similar (though much more complex) system. DF its one of the most innovative games in this area and we'd do well to try an emulate it. Unfortunately DF is closed source, but Toady likes to document and explain everything and I think most of the creature components are scripted in plain-text. I will have to take a look.
3  General Category / Introduce yourself / Re: [programmer] BIAGINI Nathan on: June 16, 2011, 02:59:25 AM
Ah, I remember you mentioning librocket before. I do like the html/css scripting idea a lot, especially since one of our primary issues has been the steep learning curve of GuiChan. I went ahead and downloaded the source and it compiled without issue on my Ubuntu machine and the examples seem to work fine, so it appears like it works on Linux.

I'm actually going to so bold as to propose that librocket be the first GUI library we attempt to integrate with FIFE.

It would be nice to have a Qt interface with all of its extensibility and design tools, but really the issues with using Qt as a game GUI are starting to stack up and I'm no longer convinced that it would be feasible. CEGUI is a tried and true game GUI library, but a lot of users admit that CEGUI is very complex and has a steep learning curve. Librocket looks like an ideal solution, though I will have to see how easy it is to integrate with FIFE.
4  General Category / Introduce yourself / Re: Creative Designer - loved Fallout. on: June 15, 2011, 05:46:42 AM
Hey norchron,

Welcome to PARPG! We're always glad to have new blood in the project Grin.

The Infinity engine is definitely the kind of style we're going for, so good to hear that you've had experience with it. Although we're drawing heavily on Fallout for inspiration we tend to be a bit more nhilistic and grim than Fallout was. Realism is huge theme, i.e. no mutants or plasma guns.

The techdemo is pretty minimal, and was mostly a proof-of-concept. Now we're focusing on developing the core framework and toolset so that we can make some playable content. Our backstory is still being worked out, but the crux of it is this:
  • Setting is Scandinavia and Northern Europe present time in an alternate reality where the Cold War escalated to global nuclear war which wipes out 90%+ of the world's population;
  • The nuclear winter has blanked most of Northern Europe in glaciers and ever-worsening winter snow storms which make survival very difficult and tends to isolate the few population centers left;
  • Ecological and environmental changes due to the nuclear fallout and the Superpower war engines' pollution threaten to create a snowball earth unless the player can find a way to stop it (and there might NOT be a way to stop it).

That's a general overview, but believe me there is a LOT more detail on our wiki. See in particular the writing department wiki (http://wiki.parpg.net/Department:Writing) and the game design department wiki (http://wiki.parpg.net/Department:Game_design). Don't feel like you have to read everything there Smiley.

Do drop by our IRC channel and say hello (http://wiki.parpg.net/IRC), as IRC is pretty much our primary means of communication. Most of us tend to avoid using Skype, unfortunately.

Oh and BTW: are you responding to our recent GDNet advertisement? Just curious.
5  General Category / Introduce yourself / Re: [programmer] BIAGINI Nathan on: June 15, 2011, 04:37:47 AM
Welcome to PARPG Smiley

Your time schedule should coincide perfectly with implementing the GUI code. I should be done refactoring FIFE in a week or so (provided I don't accidentally delete my work AGAIN) at which point it will be a matter of interfacing Qt or CEGUI or whatever library we choose with FIFE and fine-tuning FIFE's refactored GUI code, a job which I could definitely use some help with if you're interested.

Anyway, feel free to ask questions on IRC about the project. Our wiki is full of information as well.

P.S.: I wasn't able to find the links to games that embed themselves in Qt I was talking about earlier, but I did find this thread: http://www.reddit.com/r/gamedev/comments/fxby6/is_there_any_reason_not_to_use_qt_for_games. Apparently Qt might not be a good choice purely for performance reasons, and I can see that potentially being an issue in the long run.

On the plus side, I found this: http://navi.agelessanime.com/wiki/index.php/NaviLibrary_Overview. The Navi GUI library uses an embedded Gecko web browser to render GUIs written in javascript, HTML and XUL. Its a really cool idea since we don't need a specialist GUI programmer to make the GUIs (anyone with knowledge of HTML/javascript could write the GUI). Plus it looks really lightweight. On the flip side it appears as though its an extension of Ogre3d, so I'm not sure how difficult it would be to port it to a pure OpenGL framework like FIFE.
6  Development / Project management / Assembla Hosting Online! on: May 15, 2011, 04:15:01 AM
We now have a functioning set of Assembla.com workspaces  Cheesy.

As discussed on IRC earlier this week, I split up the project into three subprojects:

parpg-core: sources for the core subsystems, configuration, and executable.
parpg-assets: all graphics, music, fonts, scripts, etc. that parpg needs to run.
parpg-tools: utilities and content creation tools that are not required for parpg to run.

To support the new subprojects I scrapped the existing distutils install scripts and wrote a few SCons scripts. The new SCons install scripts allow the user to customize install paths for the Python sources, data files, configuration files and executable ala GNU make using variables supplied to the command line (e.g.
scons PREFIX=/usr EXEC_PREFIX=/usr/local
). Type
scons --help
to list these variables and how they work. All of these variables have sane defaults on Linux, Windows and Mac OS (Mac uses the Linux defaults currently, but this may change). Note: I don't have a Windows executable working yet! You'll have to write your own batch file or simply run parpg/main.py with the path to the configuration file as the first argument.

parpg-core and parpg-tools are versioned in separate mercurial repositories, while parpg-assets is versioned in an svn repository. Each of these subprojects is hosted on their own workspace in Assembla (https://parpg.assembla.com/spaces/parpg-core, https://parpg.assembla.com/spaces/parpg-assets, and https://parpg.assembla.com/spaces/parpg-tools). I don't have parpg-tools up and running yet, but I will have it ready within the next few days.

In addition, there is a main workspace (https://parpg.assembla.com/spaces/parpg-main) which hosts a root mercurial repository containing subrepository links to parpg-core, parpg-assests and parpg-tools. This will be the main workspace where we host our bug tracker and communication tools. Cloning the root repository will automatically clone parpg-core and parpg-tools, and checkout parpg-assets, and the cloned root repository will take care of keeping all three subproject repositories in sync as you work on it and push new changes to the server.

All four workspaces are managed by an Assembla Portfolio (https://parpg.assembla.com/), which will be the main page for developers. The portfolio will aggregate all events from the subproject workspaces and display any tickets assigned to you, so should be the first page you load when you log on.

This is a huge change so it'll take some time to establish our new workflow. I suggest that you browse the workspaces and portfolio page, clone the root repository using
hg clone http://hg.assembla.com/parpg
and play around with scons to get a feel for it. The first clone will take a while since it has to checkout a huge number of assets from parpg-assets, but future pulls from the server will be much faster.

I will be around tomorrow before and after the meeting to answer any and all questions you have about our Assembla hosting.
7  Development / Project management / Re: Mercurial/Git hosting found with Trac support! on: May 01, 2011, 12:29:34 AM
Yup, Assembla looks pretty cool to me. It looks like they've done a lot of upgrading in the past few months, so I would expect some growing pains though. I did run into a couple of bugs, but their technical support staff handled those issues almost immediately so I'm not too concerned.

It looks like Assembla may be open to installing our own custom mercurial hooks on the server if we ask, so that's another nice feature. Haven't figured out the build server yet - not sure if they provide the server or if we have to provide our own external server. I'll have to do more research on that.
8  Development / Project management / Re: Mercurial/Git hosting found with Trac support! on: April 30, 2011, 03:09:57 AM
That sounds like a good assessment. Unfortunately I haven't been able to figure out a good solution to the repository size issue. Apparently mercurial is working on support for shallow clones (http://mercurial.selenic.com/wiki/ShallowClone), so that might be a viable solution for minimizing network traffic once it is implemented.

I found some more information about the free hosting offered by Assembla: http://offers.assembla.com/free-project-hosting. In summary, Assembla offers free hosting for public and open-source projects with an unlimited number of users and 2GB of space (AFAICT repository size does NOT count towards this limit, which is a good thing) and the majority of their tools are made available for free accounts. Perhaps most importantly, they guarantee 1 year of service at the terms you sign up for regardless of whether they discontinue that plan. This means two things: 1) we have 1 year of free service no matter what, 2) we ONLY have 1 year of free service (probably). This is only somewhat comforting, but I suspect that its the best terms we're likely to get these days.
9  Development / Project management / Re: Mercurial/Git hosting found with Trac support! on: April 29, 2011, 11:51:53 AM
After a bit of work and lots of patching, I managed to successfully convert our svn repository to a mercurial repository with a relatively clean history. You can view the results at our Assembla page at www.assembla.com/spaces/parpg under the "Source/Hg" tab.

There are several things to note about the converted mercurial repository:

First, I pruned out all of the old branches in svn except the character_customization sprint branch. These branches were making it impossible to create a clean history due to the non-standard way we structure our branches, and weren't really adding much in terms of history anyway.

Second, I manually merged the character_customization branch into the default mercurial branch and threw away a couple of revisions on the character_customization branch that were mistakenly applied to the branch instead of trunk. For some reason the character_customization branch was not merged back to trunk in svn - rather, trunk was patched. In order to maintain a clean history in mercurial I decided to do a manual merge instead, preserving as much of the original history as possible there.

Third, I pruned out all references to the media folder in older revisions to save space. The media folder, which now resides in a separate branch, was adding ~300 MB to the mercurial repository which came in at about 600 MB total, which was simply unacceptable for a DVCS. Without the media references, the total size of the repository dropped to under 300 MB which is much more reasonable (but still quite high). As such, older revisions which relied upon the media folder may not function correctly (unlikely, but possible).

The media svn branch should probably reside as a separate mercurial repository so that developers don't have to clone the media branch with the rest of the code.

The mercurial repository is still quite large for a DVCS, and we may need to address that issue. We don't want clones to take hours over the 'net, after all. I'm not quite sure how to deal with the large size - the objects folder with the blender renderings are taking up the bulk of that space, with the music being a close second. Its possible that we may want to remove all of the blender renderings and replace them with the actual blender project files, and have the renderings generated as part of the build process. However, this would make blender a build dependency and make source builds quite a bit more complex.
10  General Category / Introduce yourself / Re: Guy with lot of ideas and no job position :) on: April 28, 2011, 07:35:53 PM
Hi Stevan,

Welcome to PARPG! We could always use some more unemployed contributors Smiley If you're interested in working on the GUI you should definitely look at the existing proposals on the forums and wiki (http://wiki.parpg.net/) and talk with Q_x and qubodup who have worked extensively on the GUI. In particular, check out the graphics department wiki and the wiki articles on agile development. Our workflow is fairly complex and we're currently scrambling to organize it all, so don't be dismayed if you find it difficult to get your foot in the door so to speak. Things should die down in a month or two once we've finished the next sprint.

One important caveat: we're currently planning to replace the GuiChan library with another 3rd party library (probably CEGUI, but that's up for discussion). So I wouldn't invest much time in learning GuiChan right now.

Oh, and do hop on IRC (http://wiki.parpg.net/IRC) when you get the chance and come chat with us. We don't bite Smiley
11  Development / Project management / Re: Mercurial/Git hosting found with Trac support! on: April 28, 2011, 03:44:32 AM
Yup, they do indeed have Trac support for svn, git and hg. I was just as surprised as you were to see that Assembla had implemented Trac support for git and hg. However, their version of Trac is really just a front-end to Assembla's custom bug tracker AFAICT, which at least to my eye has been significantly improved since we last looked at it. The query features of the Assembla bug tracker in particular seem much intuitive and user friendly than Trac.

Assembla seems to follow the unix motto of "one program per function" in the sense that they provide a range of modular, semi-independent tools. The type of repository is abstracted and hidden from the rest of the components, so I suspect that is why they were able to get git and hg Trac integration up and running so quickly.

In addition to a bug tracker and repository hosting which supports bug tracker commit hooks like we use with Trac, Assembla also provides a built-in wiki, forum-like messaging software, irc-like instant messaging server, and a configurable build server for use in continuous integration. Its actually quite an impressive array of tools - we could conceivably migrate our entire web infrastructure to Assembla if we wanted.

However, I do worry about the fact that Assembla seems to be geared towards commercial products - I don't want to get sucked into their free hosting only to discover later that we'll need to pay a monthly fee to use the tools we want and need. This apparently did happen with Codesion and yet they still support us, so I might just be overly paranoid.
12  General Category / Meetings / Re: First Developer Meeting Agenda on: April 28, 2011, 01:55:47 AM
zenbitz, are you only unable to attend this particular meeting on Sunday, May 1 or are all Sundays difficult for you? If the later, can you update the doodle with the times that you can attend?
13  Development / Project management / Mercurial/Git hosting found with Trac support! on: April 27, 2011, 08:44:39 PM
While looking for a host to upload my local mercurial repository I ran across Assembla (www.assembla.com). Barra and I had previously evaluated assembla and decided that the bug tracking system it used wasn't sophisticated enough at the time. However, it appears as though assembla now supports both mercurial and git with Trac integration!

I've been playing around with their free hosting option and was able to convert our svn repository to mercurial without too many issues. You can see the results here: http://hg.assembla.com//technopolitica/graph/839/?revcount=480. Mercurial tends to be conservative when deciding when to save branches, so there are a ton of old branches listed that don't really serve a purpose any more, but mercurial does provide some options to ignore or convert some branches and I think that issue is easily solved.

Their Trac hosting is a bit more limited than our current Trac hosting by Codesion, but Assembla provides other well-integrated tools that more than make up for that. Actually, after looking over Assembla in detail I think that their default bug tacker is much more user friendly than Trac even if it doesn't have all of the bells and whistles. In addition, Assembla is geared towards agile development processes and has the tools to support sprints and progress reporting that we currently use (hackish) Trac plugins for.

Assembla really looks ideal in terms of a distributed VCS for us. They appear to offer free hosting to open-source projects with unlimited developers and up to 2 GB of server space. However, I do have a few concerns that need to be addressed before we consider Assembla for our host:
  • Although Assembla claims to provide free hosting for open-source projects, it was somewhat unclear if there will be restrictions on a free account;
  • It was also unclear whether the 2 GB limit was a hard cap, and whether the repository size counts towards that limit;
  • Although Assembla provides a Trac ticket database import feature our current Trac host, Codesion, has purposefully disabled exports of our database so that they can charge $10/month for backups (a rather dickish move on their part IMO);

I will have to email Assembla for clarification on these points, and also see if Codesion would be willing to make a one-time dump of our Trac database without charge. If Codesion is unwilling to do so, I can dump all of our tickets into a csv file and import them from there, but it is significantly more complicated and would require manually formatting the csv file into a form that Assembla can import.
14  Development / Programming / Re: old_man.yaml and dialogue_demo.py on: April 27, 2011, 04:46:14 AM
Hi ysangkok,

Thanks for pointing that out, I went ahead and created a bug ticket (http://parpg-trac.cvsdude.com/parpg/ticket/326). I wrote old_man.yaml as a test script when redesigning the dialog engine and probably didn't bother to update it. The error shouldn't be fatal and the rest of the game should run just fine without the old_man.yaml dialog, but please update the ticket if this is not the case.
15  General Category / Meetings / Re: First Developer Meeting Agenda on: April 26, 2011, 09:49:32 PM
I set up a wiki page for everyone to add to and modify the meeting agenda: http://wiki.parpg.net/Meeting:2011/05/01. We should probably finalize the agenda by Saturday so that everyone has a chance to look at it before the meeting.
Pages: [1] 2 3 ... 6