Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > 1) What is the target date for a 2.0 release? It can't be 'when all the cool > stuff is done', as then it never happens - always something new to add, etc - > some general date has to targeted. I had previously mentioned shooting for > end > of this calendar year. > Well, I think that targeting a general date may not be the best solution, and a better one would be having a feature-based target. Essentially based upon the sort of things you talk about below. We just need to limit the number of "must have" things to be reasonable and wait till we have those, and a few "nice to have" things. > 2) What are the 'must have', 'nice to have', and 'not really important' > features > to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high category? > There is a code cleanup which is high, but I had envisioned that to be a bit > more modest than what is being talked about now. > > Depending on the timeframe would determine how many can really be done in the > targeted time. > I think the real question is, how 'big' do we want 2.0 to be? How much justifies a major version number? The answer to that, affects what features we should target to have in 2.0, and that dictates the timeframe. At the same time though, the timeframe does affect the other parts, it isn't just a one way chain, as we have to also make sure the features are reasonable to complete within a "reasonable" timeframe. What it really is, is not a question of how much can be done in a timeframe, or how 'big' we want it. It is a matter of weighing how 'big' we want it, against what timeframe is "reasonable". Balances are always so much harder to weigh than simple one way relationships ;) Another issue though, is due to the way that crossfire has released in the past, releases with minor version number increments are a mixture of bugfixes, minor features, and major features. One question is, what will make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? Really, I don't see how anything that has happened or is planned for 2.0, will really make the change so much bigger than the difference between 1.7 and 1.8. For an even better example, the difference between the releases where the skills system changed a bunch, is probably much more worthy of a major version change, than what is currently planned for 2.0 IMHO. Personally, the only way I can see things changing enough in a single release to in my opinion warrant a 2.0, is if we start keeping a "stable" branch in CVS and have that used for minor releases, or if something either in code and/or gameplay undergoes a major (in a loose sense) restructure. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit : > To me, the issue for targetting this for a 2.0 release is timing. > > We can come up with a huge list of things that should be done before a > 2.0 list. And we could attempt to do them all, but then 2.0 probably won't > be released for 5 years or the like. > Although I do agree that delaying 2.0 too far away would be a bad thing, I also think that releasing a 2.0 that would basically be a "1.9 with some fixes" would make little sense. > The discussion for a 2.0 release probably needs to be done. Several > questions need to be asked & answered: > > 1) What is the target date for a 2.0 release? It can't be 'when all the > cool stuff is done', as then it never happens - always something new to > add, etc - some general date has to targeted. I had previously mentioned > shooting for end of this calendar year. > That's a question that can only be answered once goals to reach for 2.0 are cleared. > 2) What are the 'must have', 'nice to have', and 'not really important' > features to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high > category? There is a code cleanup which is high, but I had envisioned that > to be a bit more modest than what is being talked about now. > I'd say that there are basically two types of changes to be done: (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. Typically, this is the case for "Game balance" or "Fix weather". Those do not involve creating new systems, but rather work so that the current stuff does its job as expected; (b) Additions to the existing functionality. Two subtypes here: (1)minor changes, that are relatively easy to code, or that are mostly not necessary and (2)major changes, that will require some time to complete, or that change the game experience in a significant way. I'd say that everything that is (a) should be done and integrated as a release of the 1.x series - there is no reason to change the major version number for bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - major changes is what one expects to have when the major version number itself changes. Finally, for stuff belonging to (b.1), I'd say that it depends on the priority we put on it: if it is desperately wanted, then integrate into the 1.x series; if that's just a nice idea but not really top-priority, then push to 2.x. > Depending on the timeframe would determine how many can really be done in > the targeted time. > I think that's a bit backward-thinking: the number of tasks should define the timeframe, not the opposite. > Bugs, both new and current, also need to be similarly prioritized - > fixing bugs is great to do, but can also be a big time sink. > That's true, but I don't think it is realistic to start working on 2.0 when 1.x isn't even mostly bug-free. > 3) Who commits to working on these changes? The wiki above has lots of > things to do, but very people signed up to do them. If there are only a > few people actively working on making code changes, that certainly limits > number of changes that can be done for a release. > > So all that said, if we think end of the year is a reasonable target > date, I think that limits us to trying to take on somewhere between 2-4 > decent sized projects. If we look at the wiki, taking things currently > marked as high, that would be: > > Character creation - new character creation method > Sounds good for inclusion in 2.0 - new feature that's radically different from what we have. > Game balance - fix various balance issues > Looks like a bugfix to me rather than a new feature - so that's 1.x work, IMHO. > improve client ui > Depends on the level of improvements. If that's just fixing/completing the current client, mark that 1.x (that's basically nothing more than minor tweaks); if that involves rethinking the client UI, then mark that 2.0. > code cleanup (but have to be careful this doesn't lead to rewriting huge > sections of code) > If that's only "cleanup" without any fundamental change in the way it works, then that's definitely an 1.x task. > change password command > Agree, although it looks like a rather minor point to me compared to others. > Of which, none of those currently has anyone signed up to do them (I was > personally planning to look at the character creation sometime soon) > I'm not even sure there is a clear document for each of those tasks describing what we are supposed to add/do/design. I mean, everybody understands what "new character creation method"; but there is nothing documenting what has been decided about it, what it should/shouldn't contain, etc. That's basically a "free for all": the first one that assigns itself to the task and submit it to the CVS will get its concept becoming the de-facto choice. I think that b
[crossfire] 2.0 release, was Re: Code restructuring
To me, the issue for targetting this for a 2.0 release is timing. We can come up with a huge list of things that should be done before a 2.0 list. And we could attempt to do them all, but then 2.0 probably won't be released for 5 years or the like. The discussion for a 2.0 release probably needs to be done. Several questions need to be asked & answered: 1) What is the target date for a 2.0 release? It can't be 'when all the cool stuff is done', as then it never happens - always something new to add, etc - some general date has to targeted. I had previously mentioned shooting for end of this calendar year. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. Depending on the timeframe would determine how many can really be done in the targeted time. Bugs, both new and current, also need to be similarly prioritized - fixing bugs is great to do, but can also be a big time sink. 3) Who commits to working on these changes? The wiki above has lots of things to do, but very people signed up to do them. If there are only a few people actively working on making code changes, that certainly limits number of changes that can be done for a release. So all that said, if we think end of the year is a reasonable target date, I think that limits us to trying to take on somewhere between 2-4 decent sized projects. If we look at the wiki, taking things currently marked as high, that would be: Character creation - new character creation method Game balance - fix various balance issues improve client ui code cleanup (but have to be careful this doesn't lead to rewriting huge sections of code) change password command Of which, none of those currently has anyone signed up to do them (I was personally planning to look at the character creation sometime soon) I'd also say that generally speaking, any of these big changes needs to be completed at least a month before the targeted release date, simply so there is sufficient time to find bugs, make fixes, then run the fixed code to see if it works, etc. The end of the year date for next release was somewhat arbitrarily chosen, but some date is needed. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Code restructuring
Hello, here are my 2 cents of €. I'll agree to some points made here and there :) Such a restructuration is a good idea, and will hopefully enable to clean some code. It should take advantage of unit tests currently being added. IMO this should be done in current HEAD branch, having a "stable" branch per Yann's suggestion - after all HEAD is supposed to be unstable ^_- Yes it'll be a non-trivial task, but worth it, for a 2.0 release (which is after all a big symbolic number!). I'd say to put the callback in the archetype itself. But I'd enable a plugin to override such callbacks, to change some behaviours. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Code restructuring
Le mardi 18 juillet 2006 07:10, Mark Wedel a écrit : > Alex Schultz wrote: > > Currently in the crossfire code, how objects behave is intertwined all > > throughout the code, and this is in many ways a problem as it makes it > > difficult to find code related to a type of object. It's current state > > also makes it relatively difficult to add code for new object types. > >While the current organization isn't great, and should be redone, I'd > disagree a little bit about the adding new objects - while hardly simple, I > don't think any method will make it really simple - it can become simpler, > but never really simple. > Well, currently, adding a new object type involves adding small bits of code everywhere. It seems much easier to me to regroup all the functionality specific to an object type in a central place, so adding a new object would basically be as simple as filling a unique source file template. > The current code organization is based more on the function/operation of > the object, and not the object itself (all the apply logic is together, all > the time code is together). Given there are a lot more object types than > operations, it does make sense to organize by type (but even then, I think > some grouping is necessary - I'm not sure I want 80 .c files, each covering > a specific type of object, when some may just be a few lines of code. > > A real case of this is the general armor category - right now, there are > boots, gloves, armor, shields, helmets, cloaks, etc, but all behave the > same way, so it doesn't make sense to have different .c files for those - > just a single armor.c file would be correct (but then in that case, we > start looking at whether all those should be different types, or be a > single type with subtypes, and even the subtypes may be overkill with the > body code, since that was the main reason for all the different types.) > I agree with this - if several types behave the same, there is no need to duplicate code. > Few quick thoughts: > > Unless we allow or plan for these callbacks to be modified on an object > by object basis, I'm not sure if putting that callback in the object > structure makes sense - it probably makes more sense to just have a static > table, eg, apply_callbacks[]. > You misread the proposal, I think. As I understood it, callbacks were to be bound with archetypes, not on a per-object basis. It sounds logical, as the archetype is supposed to be the "model" a given object is based on. > The per type registration code could then > update that. Doing that is certainly easier than going through all the > archetypes updating the ones of the matching type (and if we're just doing > that, what advantage do we get vs just using a table then?) > Updating the callbacks is something you'd do exceptionally - it should normally occur only when the archetypes are initially loaded; so that point really sounds like a non-issue. > This saves some amount of memory (pointer size * number of > callbacks/object, eg, if we have 8 callbacks and running on a 64 bit > systems, that is 64 bytes/object). That probably isn't a huge deal, but > could add up. > No, it would be 64bytes/archetype. 10,000 archetypes would thus give a little less than 640KB - I doubt such an amount can be considered as a problem, knowing the amount of memory most computers now have. > I think that may also be easier to code, or at least transition - in this > case, simple 'if apply_callbacks[ob->type] apply->callbacks[ob->type]() > else ..' if all that is needed. > I don't see how this is "easier" - both solutions look equally understandable to me. > Last thought - the data passed to these functions has to be well thought > out, as all the callbacks of the same type will be getting the same data > passed in (apply_armor will get the same parameters as apply_weapon as > apply_handle, etc). In some cases, these functions may not care what the > extra data is, but there may be others that care what some field is. > Definitely. > Adding such functionality would have to be carefully considered - > specific notes/thoughts: > - If this is an object attribute, then a plugin could modify the callback > structure for a specific object. Problem is how to save/load that callback > information. > Indeed, it is a possible issue. My guess is that we shouldn't allow a plugin to change callbacks "on the fly", to keep things simple. My guess is that either an archetype mentions no plugin (and in that case, the default callbacks are bound to it), or it does (and in that case, the specified plugin is responsible for all callbacks of that archetype, eventually delegating some to the server default ones). Such a system means that you cannot manage an archetype by more than a single plugin - but I hardly see this as a big drawback. > - If this is a type attribute, some form of type reservation is needed. If > a plugin (script) uses type 999, and I don't know that an
