Daniele C

I have already written the skeleton classes and started to re-format some code, sorry for not updating the community I will try my best to cleanup the current work and show a proof of concept as soon as possible

Google Code's services are now much better than when I originally tried them (about ten months ago); plus, considering that is much better in interfaces than SF.net and that there are not ads, I think that it is the perfect place for OBoE (SF.net might still be better for huge projects, but I think I will be moving a lot of my projects from SF.net to Google Code in future, SF.net usability of user interfaces is getting worse and looking again at Google Code I felt like looking into future). The Google Code project which I started is available at: http://code.google.com/p/oboe/ I will wait *i's answer and other people discussion to define further details. Edit: SF.net's still scores for its integrated web,shell,database services (I do not consider their forums feature usable at all), but Google Code is enough to manage the development side of the project, we might talk about other aspects later (I would like to keep using these forums and maybe later have a proper website for the project, but it does not matter now - if not for organizational purposes).

Quote: Originally written by *i: Quote: Note: by "units" I mean the classes (C++), that still have to be designed (I have designed only those for the "generic" game engine up to now). Remember there is a fine line between elegance and readability. While the BoE code as is can be a hack at times, try not to go overboard with your classes as to make the whole thing unreadable by people without lots and lots of C++ experience. If in doubt, err on the side of readability. It is not a crime to use procedural logic if it is simpler for others to understand. Great advice that I will absolutely follow; note: I am more a C programmer than a C++ programmer, this might be the the 2nd biggest object oriented project in C++ which I contribute to and I am firmly of the opinion that everything has not to be necessarily object oriented. Singleton instances are nice but sometimes overkill. Quote: Also, we should probably distinguish between the efforts in OBoE, which I see as a broad class to describe the various efforts going on. I'm currently making changes to the source code, more in the actual game side of things. If you deal with that at all, make sure you keep things distinct between the two efforts. Keep going on, when I will begin plugging in BoE code I will document my work through SVN: 1. commit original code snippet from BoE 2. modify it to fit into the new engine, where necessary - and that's done (with enough comments on the final modified code) Quote: OBoE specifically is not meant to be forward compatable. In other words things created in BoE will work with OBoE, but not necessarily the other way around. Anything that is still compatable in every way with the old BoE, should just be a subsequent release of BoE. Perfectly logic. Quote: If you want to do something different, I would ask (nicely) that you select some way to distinguish your OBoE project from the one I am doing. It's likely the two would be combined eventually. Since there are compatability issues already in OBoE, (things created in it will not work in BoE) we should distinguish or plan to combine or something. Good that we start to talk about this; as I wrote on the first post, I would like to act fairly since you had already chosen this name and I am absolutely not going to increase confusion. Here's what I propose: I work with the original BoE source to put it into the game engine which uses wxWidgets (it's almost done, luckly!); I will of course ask you and/or I hope you will take some part in the development, because I will need help and since you have already worked with the BoE source that will be useful (we might fix since the beginning some wrong things in the original code). In parallel (and maybe on the same SVN repo? at your option) you will continue working with that modified codebase that you have now, so at some time in future (near, future!) when we have a "pluggable" well-defined BoE-style game engine, it will be easy to plugin your version of the game engine (that would be the actual new OBoE game engine, different from the original one). Here is a question that might arise: Q.: Why to waste all this development integrating first the original version of BoE? Because the base version will have as goal full backward compatibility and original BoE playability, while the proper OBoE new engine on which *i is already working will be our extension to the game engine. It is a matter of having one thing which is classic and one which will be better and not live with backward compatibility constraints. Edit: and I think it is not a waste since it is the only way to have the original BoE in OBoE I really hope we will end up collaborating and I am open-minded to change any of my choice, if we get an agreement

Quote: Originally written by Spidweb: "These added restrictions don't appear to be in the third release of the code, so yay for Jeff for doing that. Also, I see from looking at the license (see the readme) that he released it as GPL "either version 2 of the License, or (at your option) any later version" rather than the less flexible GPLv2 only which is excellent news, as I was worried it would be stuck as GPLv2-only." Both of these are correct. - Jeff Vogel Thanks! Thank you very much! I think the whole community is and will be deeply grateful to you for this choice. Open source project I have re-submited the oboe project (with GNU/GPL license) to the SourceForge.net staff; that does not really mean that the project has to be there...I will also try Google code and see if it offers all the needed services for a small/medium sized project

Quote: Originally written by Andrea: That list of reserved rights is invalid and legally troublesome enough to render the code dangerous to use, even without the CPL. It's certainly incompatible with every known open source license, because it puts restrictions on the end user's right to license his or her own creations as he or she sees fit. Sadly agreeing...

Quote: Originally written by Reve: With regards to code hosting, if it's under the GPL, Google's code hosting might be an option. I am sure they give a faster service than SF.net, I have already used Google code in the past and I remember it was "not bad". Quote: With regards to development, the consensus seems to be the logical: - Make it work on new versions of Windows/MacOS - Fix bugs You are right, these are the topmost priorities, but I would like to start since the first version with a cross-platform maintanable codebase. A question of purity, if you want, but my real goal is to minimize future waste of development (a thing that might kill the project, think about a different fork for each OS...). For now I am developing an OO barebone engine (no code yet taken from BoE) which works with wxWidgets; I am shaping it so that it will offer a generic API that a BoE game engine plugin will hook to make the game really working. It's not as complex as it seems...I will soon let you see a sample. Quote: After that, the following are definite options, in ascending order of difficulty (in getting agreement mostly ): - Linux port, or cross-platform code base - Extensions to the interface, to make it easier to use, without changing the game - Support for more things in scenarios (e.g. new forms of scripting) As I was saying above, my intent is to move the BoE source into various well-defined "units" of code that could be hooked to the generic engine that I am writing. The generic engine will of course be designed while individuating those "units" in the BoE code, and that's why I will not study the BoE source before the re-licensing. Note: by "generic" I do not mean that the engine has to be another reinvented wheel to support any other kind of game, I mean that it will not have design constraints (so it will be enough "generic") for the future extension of the BoE game engine. Basically, the goal is to provide the same playability since the first versions, but - having an OO redesigned codebase - allowing faster forking, customization and extension. Note: by "units" I mean the classes (C++), that still have to be designed (I have designed only those for the "generic" game engine up to now).

Quote: Originally written by Reve: On a side note, hopefully the GPL version will be "GPL-going-forwards" (i.e. GPL(any version), GPL2+ or GPL3+) - being able to use it under the GPL version 3 means we can merge in any code under the fairly popular Apache 2.0 license in the program, which GPL2 is not able to do so. I think that if he would release it under the current GPLv2 http://www.gnu.org/licenses/gpl.txt it would be just fine; when GPLv3 will be out people might be able to put the code under GPLv3. Quote: Also as an aside, I'd like to thank Jeff for listening to the community here and taking time to help make his wonderful contribution of code as valuable to us as possible. I would like to thank him too.

Quote: Originally written by Kelandon: Jeff has indicated that he's probably going to change the license, for this very reason. Thank you for the info - so I hope that he is reading this topic I will meanwhile keep working on the project (mostly the engine), and then publish everything (in a way or another) - but it would be great to start well setup since the beginning Edit: I have read his post. Thank you very much mr Vogel!

Some (bad) news finally. I don't know the exact date (but I have been checking daily) but finally the SF.net staff rejected my project request, here the details: I chose License :: OSI-Approved Open Source :: Common Public License with the following additional note: Quote: The OSI-Approved Common Public License applies (http://www.opensource.org/licenses/cpl1.0.php), with the following reserved rights as appendix: Spiderweb Software, Inc. Reserves the Following Rights: - Right to place any and all applications, game scenarios, and derivative works created in whole or in part from or by the Blades of Exile game/editor source code for download on our web site without prior approval of the author. - Right to place any any all applications, game scenarios, and derivative works created in whole or in part from or by the Blades of Exile game/editor source code on 3.5" disks, CD-ROMs, or similar media for distribution and sale, without prior approval of the author. Fees charged for said media will not be part of or be construed as part of any shareware fees set forth by individual authors. All fees are for production and distribution of the media only. I took that appendix from the BoE source code license. Finally, I got this answer from the SF.net staff: Quote: Greetings, SourceForge.net provides hosting to Open Source software development projects. It appears that your project is developing software, but that you have selected a license which is not an OSI-approved Open Source license. The license you have selected also does not appear to meet all of the requirements of the Open Source Definition provided by the OSI. We ask that you review your license selection; should you wish to use an OSI-approved license or a license which meets all of the requirements of the Open Source Definition, we will gladly review your project registration again, at your request. In order to remedy this situation, modify the license selection in the project's trove categorization and select a suitable license. Here is a link to a summary of the Open Source Definition: http://www.opensource.org/docs/definition.php Thank you, The SourceForge.net Team Very bad. So this type of license does not applies...I don't know if J.Vogel has any intention to extend the license to be OSI-approved (he has already done enough at releasing the source code, now we cannot really dictate terms about his own intellectual property ) in any future... Now I am thinking about using a different open source projects facility, but I also fear about the exceptions of the license: do they imply that my work could be (theorically) patented and sold? So, I'll throw again the dices and start from 0

Thank you for your feedback Jewels, your are right - now the move is to me, and I am already working on this plannned project to tell the truth. As soon as I will have doubts, I will ask to the community here (there is also the original coder here!) - many brains are better than one brain and you might actually help me in design choices (and I hope later in coding too). Regarding your custom editor: maybe you are going to take some role in the "editor" part of the project? Coming soon: setup of SF.net project website and services

Quote: Originally written by Andrea: But Gtk+ isn't particularly portable. It works for X Window and for Win32, and there's an incomplete port to Cocoa. And I mean incomplete -- believe me, I've bashed my head against every free GUI toolkit out there. The only ones that are consistently cross-platform and stable are Qt and WxWidgets -- which are both options. I prefer Gtk+ to both of these, but without a working and stable Mac OS X version, it's worthless for BoE. I was thinking about wxWidgets instead of Gtk+ Quote: In any case, I don't see the point of making a cross-platform version of a program that already works on Windows and OS X -- and runs perfectly in Wine. The Linux version of Exile 3 was ported with winelib, and I think that would be a pretty reasonable method to get a native version of BoE on Linux very quickly. My point in support of a cross-platform version is that future enhancements would be common to all OSes: think about implementing a consistent extension "X" for both versions of the source code...at some point of future development it might get painful! I will try to organize the source code in this way: 1. cross-platform BoE-style graphics/audio engine with OO design 2. easily pluggable gameplay engine (where the actual BoE code goes) In this game I think that the game logic could easily be separated from the UI logic for the benefit of a powerful extensible engine.

Quote: Originally written by Khoth: You've been talking a fair bit about wanting to avoid wasted effort. So why are you proposing a rewrite from the ground up rather than starting from already-nearly-working code? We currently have the Mac version fairly usable, and Jeff's said that the Windows version would probably be easier to fix up, so starting by getting the Windows version up-to-date feels like a better way to be going, that will actually produce results quickly and give something that can be built on. You are perfectly correct. I have not been precise enough: my idea would be to rewrite the OS-dependant parts of code (graphics rendering and file I/O for example) and to make them portable. Since the code has anyway to be updated from Win16 to Win32, I would propose to update it into portable code. Another problem pops up: the BoE source code currently contains hard-coded informations and also gameplay definitions. I think that I will proceed in this way (I will consider ALL your advices of course! I am here for them): --- 1. write a "vanilla" game engine, only viewport with graphics handling features; portable of course (regarding the UI: I am not yet sure about Gtk+, I will consider other choices too) 2. plugin the BoE gameplay engine code; the major effort will be to separate the gameplay code from the other code (at this stage OBoE should be playable) 3. move hardcoded stuff into files for future customizability and extensibility 4. documentation and cleanup/optimization of source code (normal development and extension/fork can begin from here) --- So you can see how I consider a waste to convert the game from Win16 to Win32 only because I am already planning to convert it into portable code. Let's be clear, I am not against this conversion - I have just thought that it would be great to make one step further and get rid of the OS dependency Edit: minor typo fix

Quote: Originally written by Khoth: Actually, it sounds like what you have in mind is different from what's being done so far. At the moment, we've been taking the existing codebase and fixing it up, and are planning to extend it. It sounds like what you're plannig is to rewrite from scratch using the new knowledge of file formats. Uhm... Sorry for not having specified it! You are right, this project can be better thought as an engine rewrite (on Gtk+) centered on BoE gameplay and format (but there could be a proper OBoE format one day, without anyway dropping the support for BoE format). Quote: If that's the case, you might want to talk to Djur about helping on pygmalion, which has something of the sort as a subgoal to a more ambitious project. Very interesting! I will read more and maybe ask him too. However I can already see one problem: ruby. I am not a ruby programmer! And anyway I'd better like to have an engine centered on BoE (but designed so that it can be extended) rather than adapting another engine (there are already so many around, but luckly ours is simple enough to be rewritten). I do not consider this a closed path...very interesting anyway

Quote: Originally written by Kelandon: Whew, I think I understand you now. You intend to re-write the code so that it is cross-platform. I think all of us will agree that this would be a good thing to do, if you can do it, but I'm not sure how much help you'll get from anyone else. Any help would be welcome! Think about development of parts of the source code, UI improvements, alpha/beta testing, scenarios testing etc. Quote: I'd say, plunge right in. If you can do it yourself, go for it. The only thing you need to do is make sure that the end result functions the same (and, in most cases, malfunctions the same) as the original. That's my idea too, the gameplay should be equal in BoE and OBoE. Quote: What specifically do you need from us before you get started? I think it's enough to start it; I just wanted to see if there were major advices about why it would not have been a good thing to start it, but it seems like (and I believe it too) that this project can be a good thing (if developed!).

Quote: Originally written by *i: Quote: I'm not sure that leadership is really what's needed right now. Leading by example is probably the best way to go. I agree 100%. I think you bring a lot of energy to this, and that is what is needed right now. You seem like you are most interested on the PC side of things, which is good, that is where effort is required. Set up whatever you want for the PC stuff. That being said, we should all collaborate and let ideas be thrown around. I think there is a lot to be gained from discussion. Well I will never start it without the community consensus...I also believe in constructive discussion and all your opinions - both negative and positive - are already contributing to make me/us understand more. I would develop it so that it can be portable, but will test it at least on the PC and Linux. Quote: My feelings are close to Djur's. To reiterate what he said, which I feel is entirely correct, too much formality could make this project die out. The whole "bazaar" concept is entirely correct. We want this to be fun, that means people should have the freedom to do what they want. When it becomes formal, the fun tends to stop and it turns into work. Once this happens, the project dies. I see your point and I agree about the fun vs work part. So maybe we are currently in the hack it stage? Quote: Once again, I hope you can contribute a lot to this effort. We all have our own interests and desires where we want to see this to go. Let's discuss some specifics and see what we can work out. Ok! I hope we will now finish this discussion positively (and not reduce it to different POVs debating) so that I can understand more about this project I'd like to start. Next, I will ask you to discuss the details, so that developers will possibly step into development with their own ideas!

Quote: Originally written by Andrea: Hey hey, whoa now. Put the whip down, man. My compliments, these phrases ridiculize my post (if not me) and makes you the "smart guy" of the thread. Quote: What we have here is a very fresh FS project with a very old code base. I think we all agree that the first order of business is to modernize BoE enough to run on modern systems, and the second is to fix the existing bugs, but beyond that you're unlikely to find any permanent consensus. I agree about the first order of business; as you said, I am unlikely to find any other consesus but isn't it worth the try? Quote: What this project doesn't need is a leader. Of any kind. You forgot to add "in my opinion". A precisation: it is not my intent to be the permanent project leader but to give it the kickoff. Quote: We have a few people who are interested in working on parts of the released BoE source, and it'd be a good idea for us to collaborate to the best of our abilities. But our interests are indeed separate, and there simply isn't enough momentum to get funnelled into a formal project. As I said, we have of course separate interests but since we have a common need to modernize the codebase, we might at least be united in the beginning. A "formal" project is as "formal" as we make it, in my opinion. Quote: I'll say this right up front -- I'm interested in an open source BoE, both for what I plan to take from it as well as the application itself. I will be contributing both expertise and code, but I will never join any formal project such as you outline here. I think that level of formality would suffocate the enthusiasm that some of us have for this effort. If the enthusiasm is not enough to contribute to a real open source project, I wonder what type of enthusiasm it is...just to hack the codebase? Not interesting to me. A well-settled open source project would anyway allow hacking with fewer pains. Quote: Here are my specific issues: 1. I have no idea who you are, and I'm certainly not interested in subjecting my work to your review. My review option was only in relation to "conflicting" commits, did you read that? e.g. if Mr.X makes a commit to have 200 towns limit, I would have to ask you why you are making a commit for 100 towns limit and similar. Regarding code review: it would not be me to decide how the code has to be, but a "source code formatting convention" and similar democratically agreed documents. You must be thinking that leading a project is a nice work, well it is not... Quote: 2. For similar reasons, I am not interested in using Subversion. We need a bazaar system, to use the odious ESR's terminology, rather than a cathedral. I like SVN -- I use it daily at work -- but I think it's a bad fit for open BoE. So I'd have to learn more about the bazaar systems, as I don't know. Specifically, would they allow to contribute to a unique codebase to be then released as "official"? Quote: 3. An advantage of distributed development is that we don't need to set up a roadmap or a set of goals. Everyone can work on what they like and the outcome will be the result of discussion and consensus. The outcome will be different software products, without any correlation, duplicate and conflicting features (a lot of wasted development), no standard format to rely on and general lower quality of code. But that's freedom, I know, I have done things on my own so many times! I am just saying that if we join the efforts (and we do not have to necessarily drop our own forks for this, we can contribute to the main project and mantain our own forks) we might make the best present to the community and to BoE lifespan. Quote: 4. SourceForge sucks. It's slow, it has far more features than necessary, it's difficult to get around, and their technical support is half-assed at best. In addition, they're pretty fascist about what you're allowed to put on webspace -- last time I checked, it's a violation of the TOS to upload darcs repositories into your webspace. I see no reason to get into SF's sticky embrace for a wadge of worthless and poorly-implemented features. (I hope SF.net guys are not reading this) I know what you mean I cannot say it is a good place, but it is the place for open source projects. As soon as I will have a better alternative, I will fly off it as fast as light! Quote: Don't consider this a flame. I'm being as measured as I can here, Except the introduction, it's OK We can be polite enemies, even if I'd better like to have smart people on my side Quote: but I see no reason why a centralized development model is anything but bad for the future of Blades. Please, tell me, WHY? If we are all agreeing that it has first to be modernized, it would be great if we could all partecipate to its modernization. But do you want to know how history usually goes? Each interested developer makes on his own (pity!) a fork and the best one - in competition with others - becomes the "living" project while the others become the "dead" projects. I have seen it sooo many times! If I cannot avoid it for BoE, then I will have failed. Quote: To end this on a positive note: I do agree with the goal of cleaning up and documenting the code. That's where my efforts will be focused at first. Good. But think about this: if you also make somewhat radical/gameplay/format changes to the codebase while documenting it, will other people be able to use it? I know that everyone is free to do things as he likes, but it would be another big waste if each developer is going to clean up and document the code on his own. I come in peace.

Quote: Originally written by Kelandon: Yes, it really would be good for someone to be working on the Windows side, too. There's one thread from people who seem to be doing that, but if you want to start tossing in some help in a useful way immediately, that's where to go. I am probably going to cover all OSes with this project, if I even start it. Quote: I'm not sure that leadership is really what's needed right now. Leading by example is probably the best way to go. Yes, that's what I meant. However I'd like to have some consensus first, and help

Quote: Originally written by Khoth: For the Mac version, it seems to me that there's already a perfectly good repository, mirrored at a realiable site, so I see no good reason to move that over to Sourceforge. For the PC version, there's currently, as far as I know, no real work being done on it, so it needs some kind of push from someone who knows what they're doing on that side. The codebases are currently rather different, so there's no real reason to use darcs for it if whoever ends up doing the PC stuff prefers SVN or whatever. It would be nice to eventually bring the PC and Mac versions together, but it doesn't seem like anything like a near-term goal. My idea was to work on a portable codebase (Gtk+ covers almost any OS). Quote: Although it looks like fragmentation for everyone and his dog to produce a darcs repository, it actually isn't, and as far as I know work is not being duplicated. I am not actually addressing any current version of the source code (PC/Mac) as the project I'd like to start is mostly focused on a core engine rewrital (to use Gtk+) + BoE scenario format code.

Quote: Originally written by *i: Beyond that, there are a lot of ideas, but no coherent path yet. I don't want to influence everyone with my ideas, so let's hear yours first.[/QB] As stated above plus one addition: portability.

Quote: There are basically four threads here in this forum that discuss this project. Once you've read them, you've pretty much read everything on the subject. (There's also a thread on Shadow Vale, but it doesn't say much yet.) Thank you for replying Kelandon, I have already read them. I was going to reply here but I have started a new topic about the open source project startup (it was a long post, in the end).

Open source project foundation Please tell me if you agree with what I am prospecting in this post (sometimes the best thing to start a successful thing is to just start it). Please read the full post before replying. I will start a SourceForge.net project called oboe - Open Blades of Exile with the modified CPL license of the currently released Blades of Exile source code; please say if you agree, in particular *i which looks like having already started a project with this name on his own; it is not my intention to conflict with his project but to merge all the efforts and avoid fragmentation (which means waste of development); so it would be great if *i would agree at joining (even if he came first!) I will manage the project (I have some experience with open source) and try to drive it to the estabilished goals (see 2nd part of this post) I will setup SVN there and commit the currently released source code (if I have read correctly it now contains all the necessary files, so we can consider it complete) all developers which have worked up to now to Blades of Exile will be (are) invited to commit their changes to the trunk; I will initially give a hand at reviewing all the commits so that they don't break each other (see 2nd part of the post for more guidelines) but I hope to get some leading developer(s) in the process for the main development (both present and future) GOALSAfter having estabilished the project as explained above (actually, we should discuss the goals before starting the commits to SVN), I will ask for discussion (there will be a mailing list or forums - as we choose) about the following open source project goals, which I have outlined here just to give something to discuss on. They are no way definitive, we can change them whenever we want during the Planning development stage (and I would not have had anyway authority to estabilish them as this will be a community effort): general/gameplay bugfixing and improvements (which do not break with the original BoE gameplay) porting of source code from Win16 to a portable UI toolkit - I can give a hand with this C++ and object oriented redesign (compilation supported under DevC++ and MSVC++) - I can give a hand at designing/booting up this support of BoE scenarios format These above can be the goals for v1.0; I propose to respect the legacy standard up to v1.x (as i* said if I am correct) and to meanwhile start testing format extension in parallel branches in order to prepare solid extensions to the format for future versions. WRITER'S NOTE Please don't flame me! I am offering my help to gather a centralized, organized and strong development for Blades of Exile. Importance of being united If we all join our forces we will make a great work; and also: please note that it is not true that one cannot customize the game in this way. Customization and source code customizability I will explain: each developer which wants to customize the current BoE has first to make the source code more usable (it was probably not written for easy customization or other developers contributes), so the amount of duplicate work is huge. Customization of OBoE BUT, when we will have an estabilished open source software, rewritten/documented most of the code, THEN any developer can customize it and we will also be accepting the customizations because we want to improve the game finally! And, anyway, forking the near v1.x version of OBoe will be much easier. Sorry for the long post, but I had quite something to say.

Hi All, I am an open source developer (see SF.net profile ) and I played Exile when I was a little boy; I have always dreamed to have the possibility to make some improvements to it. Really many thanks to J.Vogel for making it available to the community! This game is a very good piece of history, but has still some potential too (and not only for nostalgic people like me ) Here is my idea: have a well-settled open souce project and organize it so that it will be successful. I have seen you have already started a project, where can I get more informations? I am skilled at C/C++, I could help a lot in development, but for the moment I am mostly interested in organizing the project so that it will get the needed advertisement. The main focus is not to fragment open source development (as far as possible) on the Blades of Exile code but to offer a good project where developers could plug in. Once the project will be well-settled, I will also join development; and I can make some magic with C/C++ Please let me know more, thank you