
mvBarracuda
Members-
Posts
118 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Everything posted by mvBarracuda
-
I'm usually somebody who appreciates all kind of constructive and even somewhat unconstructive feedback; as I'm not a native speaker myself it's simply sometimes hard to judge the intention of a posting due different language skills, usual style of expression, etc. However your post did actually struck me as trolling because I failed to spot the constructive element of the feedback. It's usually a waste of time to get into these kind of discussing because it often ends up in discussions about minor nuances of the connotation of words. But as I started anyway: the wording "This is why in the end this will become vaporware." struck me as quite unconstructive. It sounded like because of a), b) will happen; like it's determined to happen. Furthermore the term vaporware is questionable in this regard. Usually vaporware does apply to software that does never get officially released. Can open source software projects that offer anonymous version control checkout be considered vaporware in this regard? I would say no because everyone can legally get access to our resources and could continue the project even if the currently involved developers decide to abandon it for whatever reason there may be. But I'm quite interested in your position on this topic: how would you define a vaporware open source project? What kind of goals would we have to reach as an open source project to be not considered vaporware according to your definition anymore? To be honest: I've actually set quite some decisions in stone or nearly in stone when the project was founded, see: http://wiki.parpg.net/Key_design_elements http://wiki.parpg.net/Project_philosophy This is the general direction I've set and I'm more than willing to defend it. However there are aspects where I have a personal preference but they're not aspects of my department (project management, that is). E.g. we had a recent discussion how we should implement buildings: rather as separate maps that get loaded once you enter the building or as parts of the outdoor map. Each approach comes with certain pros and cons and while I favoured the 2nd approach, we agreed upon giving the first one a try. IMHO it's part of a healthy project culture to accept these kind of agreements even if your approach wasn't agreed upon because you expect the other contributors to accept all kind of other agreements as well. It could be said that this is a democratic position and maybe it is, but in a very positive sense. Krezack already properly addressed it but let me add one thing. Your logic seems quite flawed in this example. To me your argument sounds like: - There are open source projects - They follow flawed project management philosophies, democratic consensus instead of a clear vision enforced by a project leader - Because of their flawed philosophy they fail As Krezack pointed out: there are a lot of other reasons why open source projects fail and judging from my personal experience lack of time, fading interest and lack of skill of the involved developers seem to be three of the most important ones. Do you know any examples of _open source software projects_ that succeeded (however you define that, what's your definition of success in this regard? see vaporware definition above) and applied your proposed project management philosophy? It's realistic in my opinion to have something playable that you could call "a game" until the end of the year. Open source projects get created in the free time of volunteers so even after this initial release it will take at least about 2-3 years before he can consider to ship anything close to a 1.0 release. We're not magicians: the usual timespan for open source projects to reach this imaginery 1.0 milestone is even longer. But I'm happy to try to prove you wrong by actually succeeding with this project ) Whatever that means.
-
Obvious trolling? How many open source (read: volunteer) source projects do you know that failed especially due the will of a "project lead" that refused to force his decisions upon the team even in fields where he clearly lacks the expert knowledge? I'm with Krezack here: especially if you're working with volunteers you might want to let them decide about specific aspects how things are handled in their department instead of playing all-knowing dictator. You might have simply misunderstood the concept of subsidiarity: it actually means leaving the main decisions in a certain development department to the developers who understand the field best. You usually don't want to let your musicians decide what design patterns to use programming-wise. You don't want to let the programmers dictate all the gameplay elements. You actually got experts for each field, artists, programmers, musicians, gameplay designers, project managers, story writers. Why not use this expert knowledge and leave the majority of the decisions in each department to them? It doesn't mean that they're unwilling to listen to feedback; quite the contrary! It just means that it's a bad idea in general to let the designer of a car decide how the engine of a car should be constructed while he actually knows far more about design than about how to properly construct an engine. The project manager is responsible that each department properly cooperates with each other and that you get a working car in the end. So far - despite some obvious drawbacks here and there that are pretty much what happens to 95% of all open source projects - we seem to be on a quite good way.
-
We appreciate the feedback Krezack ) All of these buildings are work in progress so don't except to see anything "final" in this early phase of development. The plan is to assemble a team of competent developers over the course of the next months and to agree upon a workflow for each department. The graphics department hasn't fleshed out the style of buildings in PARPG in detail yet, but once they've done so you can expect to see some screenshots that are closer to future versions of the game style-wise. As this is a team of volunteers we're not really in a hurry to rush out things as fast as possible. I personally expect that the "experimental" phase of development will have ended around the end of the year. We should furthermore have a more solid idea about the storyline of the game then as well.
-
Heya and welcome to yet another weekly PARPG news update! Let's get started right away ) This week we're proud to report that the first audio track found its way into the game. New programmer on the team meggie implemented random NPC movement as well as switching between different maps. Maximinus was hardworking again as well, annotated the existing code in place via Epydoc, proposed a list of features for an first official release of the game and created a first simple build interieur map. 3d artist Zimble slightly updated the tile creation tutorial for users who would like to use an alternative sampling method and we're still looking for 2d & 3d artists who would like to contribute as the vast majority of our artists is currently rather occupied with real life commitments. Last but not least we finally agreed upon a date for the for the first official PARPG developer meeting: Monday, 22nd of June, 5-7PM GMT. Read the full news update at the PARPG development blog. And here's your visual teaser: I wonder what might be inside this building? You can actually find out by either taking a peek at the news update or simply grab the latest version from our SVN repository and try yourself )
-
Heya and welcome to yet another PARPG news update; this time actually delivered on schedule! There are a couple of things to report: the programmers implemented a first version of an ingame settings menu and added visual highlighting of objects as well as floating text descriptions for them. The graphics artists overhauled our ingame GUI plans and compiled an image gallery that features all previously created pieces of concept art. To coordinate our efforts in the following weeks, we furthermore decided to arrange a first official developer meeting at our IRC channel. Of course community participation is appreciated as well ) Read the full news update at the PARPG development blog. On a related note: FIFE developer Cheesesucker recently rewrote major parts of the map editor tool that comes with the engine. I've personally tested it over the last couple of days and I'm truly impressed by the improved workflow and new easiness of map creation. To applaud his efforts, we've fired up the editor, loaded our PARPG test map into it and took a screenshot ) Enjoy:
-
Heya and welcome to yet another PARPG news update. Three full weeks have passed since the last one and I'm truly sorry for the lack of updates lately. I've been really busy with university and although I know a lot more about the reconstruction of the failed state Liberia with the help of the UN now, I rather would have liked to post an update or two in the meantime instead of investing so much time into a presentation I had to give at Friday. Anyways, now that I'm done with it, I got some free time on my hands this week so here's your promised dose of PARPG news. This time it's more a newsflash than anything else. While I've been busy with real life, the others - especially the graphics department - has been hardworking and there's simply too much to report to do so in detail. Feel free to browse the forums to read about all the details. Read the full news update (with lots of pretty images )) at the PARPG development blog. And to address the ongoing rumours: no, I haven't been struck down with one of these improvised weapons - that our new concept artist zeli created - and have been in coma for the last three weeks. I was simply busy )
-
Heya and welcome to yet another weekly PARPG news update! There is a whole bunch of visual material to cover in this update as the graphics department has been quite hardworking. Furthermore the combat system proposal has been overhauled and large parts of the Python code have been refactored. We've played around with possible ingame inventory concepts and our trac system seems to run stable again after spammers invaded it a couple of days ago ( While a couple of new graphics artists joined the project lately, there is still a lot of room for additional contributors. We're currently especially searching for talented artists who would like to help us with creating ground tiles for the game. Check out the full news update at the PARPG development blog. And if you want to know what all of this has to do with an upswing, here's a little pointer for you:
-
Heya and welcome to yet another PARPG news update! This week we got a number of interesting topics to cover: an updated roadmap for the programming department, some first guides for the graphics artists, new work in progress 3d models as well as progress in the writing department. You can check out the whole update at the PARPG development blog. And as special feature for this week's update: a mistery teaser ) Want to find out what PARPG has to do with crates? Check out the full update at the blog!
-
Heya and welcome to yet another PARPG news update! As promised: now delivered weekly again. An important advantage of blog updates on a weekly basis is that the number of topics to cover can be usually kept rather low. This time we
-
Heya and welcome to yet another PARPG news update. This one has been in the pipeline for several weeks and I would like to apologize for the massive delay. The original plan was to bring it to you around the 1st of April but a lot of unforeseen events occured. This time there are a couple of good things to report but we've also encountered setbacks. Our lead programmer icelus decided to step down from his position; therefore the plans for the rather sophisticated story engine / AI system are on ice for the time being. Fortunately a new programmer decided to get involved in the project and is now actively working on PARPG. One of our graphics artists came up with some first concept art and the programmers continued to explore FIFE and took a couple of testing screenshots while doing so. Zenbitz wrote down his ideas about encumbrance, inventory and clothing and I've made a personal promise ) You can read about all details at the PARPG development blog: http://blog.parpg.net/2009/04/dont-look-back-into-the-sun Here's a little teaser:
-
Yes! It's Monday again, that means it's time for yet another news update ) As always: lots of progress over the course of the last week so I'll keep things short and you simply click through the various links if you find a topic of interest. This time we're looking out for graphics artists and musicians who would like to get their hands dirty by contributing to the project. To give them something to do, the proper infrastructure needs to be in place as well, so our graphics artist Lamoot created a first Blender rendering setup as starting point. Furthermore we decided to set up an asset repository to find out if it offers any advantage for contributors who would like to avoid wrestling with SVN and other VCS solutions that are more geared towards tech-savvy users. There are some new starting points for interested programmers and some reinforcements have already arrived as well. We're currently working on a playground for the writers to test the story format while trying to retain an overview by maintaining a per milestone ToDo list. Zenbitz got his hands dirty again as well and elaborates on use and study-based learning and the next (prolly rather short) news update will already arrive at Friday as I'm traveling to The Hague at Saturday. Interested in all the details? Check out the full news update at the PARPG development blog )
-
Concerning the whole target audience discussion. I think the project will attract the following types of gamers: * Open source enthusiasts who either run Linux or some kind of BSD distro. * More mature win32-based players who are fans of old school isometric (2d!) RPGs such as Fallout, Arcanum, Planescape: Torment. Basically everything pre-NWN. * Pen and paper RPG players who don't mind complex mechanics but rather appreciate the love for these details. I personally like playing games that are set in parts of the world I didn't know much about. I hope others enjoy it as well but the setting is set in stone so moving it elsewhere is no option at this point anymore. We'll give our best to make it a fun an entertaining game but I somehow doubt that the majority of the players who are scared away by a game playing in Scandavia would appreciate the gameplay we have mind.
-
Yep, at the moment we're considering a "nature is the enemy"-plot. If you don't mind spoilers (it's not set in stone at this point anyway), feel free give it a read: http://forums.parpg.net/index.php?topic=35.0
-
Yep, we actually plan to introduce survival elements. Here are something starting points: * Food, water, endurance: http://forums.parpg.net/index.php?topic=19.0 * Realistic encumbrance as survival element (no way to simply loot everything, have unlimited food with you): http://forums.parpg.net/index.php?topic=77.0 As Morrissey said: America is not the world. These are the forums of an US-based publisher so I can understand that an US setting would appeal to the most people here. On the other side: if you got for isometric 2d graphics, survival elements, choice and consequence, complex combat mechanics, realistic encumbrance and wounds, you don't really care to appeal to the largest target audience anyway. Our lead mechanics designer comes from the US, another important writer on the team is from there as well; both are fine with the setting. Exploring PA America was already done in Wasteland or Fallout so why not mix it up a little? That sounds a bit ignorant. Of course we care about US players, actually we care about all players regardless where they are from. But if you follow your logic, Fallout would have been just popular in NA. If you look into the facts, you'll see that Fallout is quite popular in Germany, Poland and especially Russia. So why would a PA game set in Europe scare away the NA audience while it didn't happen for Fallout the other way round?
-
Please enlighten us about the poor choices so we shall learn from our mistakes )
-
Heya and welcome to your weekly dose of post-apocalyptic development news. Looks like we are picking up quite some speed lately - at least the number of topics to cover in each news update is growing and growing. I'll keep things short this time and you simply click through the various links if you find a topic of interest. We got covered at the freegamer blog some days ago and agreed upon a first license for the assets we'll create. PARPG got it's own top level domain now and zenbitz was on a game design spree last week again. Icelus came up with a proposal for a story format and suddenly a lot of writers popped up and filled up the writing board of the forums. Last but not least we're currently discussing how the game can be challenging while avoiding universal frustration. Feel free to jump into the permadeath thread at the forums right away. Interested in all the details? Check out the full news update at the PARPG blog (now featuring subdomain candy!).
-
Heya and welcome to yet another weekly PARPG update! This time we
-
We're now looking for a talen for a talented writer, preferably a native speaker. Interest in post-apocalyptic fiction is the most important and only real requirement besides that. If you always wanted to get involved in the development of a game that aims to feature a sophisticated story and you like to work with other dedicated people who enjoy non-cliche RPGs, here is your chance ) We are also looking for people with experience writing for dialog trees and those familiar with Denmark, Norway, Sweden, Finland and other areas near the Baltic Sea.
-
Huh? What aspect of Arcanum did you dislike? One game mechanic of Arcanum was the crafting system that I really appreciated; so something similar is planned for PARPG as well. Furthermore steam punk was quite unconvential so that was great as well, though PARPG will feature a post-apocalyptic setting.
-
Heya and welcome to yet another PARPG news update. In the course of the last week we've agreed on a bunch of setting-related aspects as well as game mechanics: branching tree dialogue, real isometric projection, rivaling factions, crafting use cases and post-game slides that show the consequences of your actions. We're currently searching for interested Python and C++ programmers who would like to help us with engine evaluation for PARPG. Furthermore we're looking for a writer with passion for post-apocalyptic settings for the story department. Zenbitz and qubodup started to compile lists of engine requirements and Lamoot collected information how other isometric games implement graphics-related features. Last but not least qubodup overworked the look of our blog, wiki and forums. If you would like to know more about it, feel free to check out the full news update at the PARPG blog.
-
It's time for a little news update ) We've boiled down possible setting and game mechanics aspects in the last week. So far we've agreed on a nuclear winter setting; furthermore the game will take place in Northern Europe / Scandinavia. In case you're interested about the details, feel free to check out the full news update at the PARPG development blog.
-
I appreciate critical feedback and there is much that can be criticized about the announcement in its current form. However I think calling FIFE vapourware and the pretty dumb comment about project management vs. programming department and their value is a bit over the top. My main reason was receiving early feedback and that worked ) I can deal with it and the majority of criticism is well grounded so that helped me to see where more work is needed before I should announce the project at other places. Recruitment won't start officially before early March. There is already some public interest and I think the people who got involved lately can boil down possible setting and gameplay options and once we've agreed on something more solid, we'll go to the public again for a second round of feedback. That's a bit black and white view in my opinon. The aspects that are already decided are: * Python programming language. * Turnbased, tactical combat. * PA setting (though no decision about any details yet). * Open source licensing for code and assets. * Open development: public wiki, forums, SVN repository. * (Meaningful) Choice and consequence. * Isometric 2d look instead of going for a real 3d engine. * Emphasis on well-written detailed dialogue. * No carbon copy of the Fallout ruleset to avoid legal problems. Furthermore this gives us the chance to come up with something unique. While this is not near a completely fleshed out game concept, it's not totally vague either. I've got no detailed plan for setting details and story; that's part of my concept: to leave these kind of fields to the people with the talent in them. I think I got the skills and the requirements to fulfill my tasks in the project management department. Delegating tasks to the specific departments is not an emergency solution but a vital key element of the project philsophy: http://parpg.fifengine.de/mediawiki/index....ject_philosophy The engine proposal is a pragmatic one. I think that FIFE is _prolly_ best suited for the purpose; taking into account that isometric 2d graphics are set in stone. But there are other engines around and GemRB seems like a valid option too. Enforcing a certain engine decision against the informed opinion of the programming department would be foolish. They are the experts so why not let them take a look into FIFE and see if the engine would be viable for PARPG? I'm confident that FIFE is viable but if not we'll need to think about alternatives anyway so why be stubborn and set something into stone instead of considering all options? It's not that we would need to decide on an engine within a week. The writing department can flesh out setting and story elements in the meanwhile, the gameplay designers can discuss ruleset and gameplay elements; that leaves the programming department with enough time left to not make a hasty decision just because of last minute panic.
-
It's a pity that these are the Obsidian forums and not RPGcodex because they would prolly give you a nice custom title there for your intelligent reply. A project with 7 major public releases and over 55.000 downloads can't be vapourware. Furthermore there are two promising games based on FIFE currently in development. That's not overwhelming but considering the status of the projects and their steady progress it's not bad either: * OpenAnno: http://www.openanno.org/site/ * Zero-Projekt: http://zero-projekt.net/ It sounds like you've got no prior experience in game development and project management. While there is always room for improvement, the developers who worked together with me were quite satisfied with the way the project was coordinated. I didn't get the comment about not waiting to use our own engine; looks like I'm not the only one who has failed a reading comprehension check. I clearly stated above that FIFE would be my prefered engine of choice for the project but as I'm not a programmer this is only a suggestion for now. Interested programmers will check all viable engine options and we'll decide together what would be the best choice. We won't need to decide immediately so I'm surprised that you can already say now that we won't use FIFE. I'm personally quite positive that we'll end up using it or maybe GemRB but let's see what the programmers say.
-
Concerning FIFE: while it can be said that development of the engine is pretty much stuck at the moment, the project showed solid progress over the course of the last 3 years. So while this might not be a perfect example of a project that succeeded in the end, it's a not a role model of a vapourware project that never took off either. EDIT: To clarify my role in the project and prior (game) development experience: http://parpg.fifengine.de/mediawiki/index....da#Why_PARPG.3F
-
I already tried to clear up the situation at the PARPG blog today: http://parpg.fifengine.de/wordpress/2009/0...n-check-failed/ The original project announcement draft didn't feature the large amount of Fallout references. When I created the draft I asked for feedback and it looked like my first version was actually too vague, missing vital settings and story information. So I decided to close all the gaps that were unfilled with material from Fallout. Which was a definite fault and I should have refrained from doing so. Anyway, here's the difference between the early draft and the final version that was posted: http://parpg.fifengine.de/mediawiki/index....9&oldid=387 I don't have an informed opinion about details of setting and story yet so everyone is invited to contribute with suggestions. See the contribution wiki article linked above. I'll update the project announcement at the wiki and just post the updated version in the future. There was already some negative reaction concerning too many Fallout references at RPGcodex and I think this criticism is well grounded. Thanks for the feedback )