Jump 6 map generator

[kaladorn]

And yet... FireFox, Thunderbird, Linux, Ethereal, Apache, etc....

I was thinking of something higher level than I believe what you refer to. I'm not talking about you working with others to do H&E (though I direly wish you lot that weren't selling the stuff for cash would open-source the code, just so that if one of you gets in a car accident, we wouldn't be bereft of all possibilities of future improvements...).

What I'm thinking of here is more like a sort of mini-consortium approach. Stuart goes off and does H&E, Trevor does Universe, Mert does Navigator, etc. But maybe we can find a way to define a common way to embed the bits of software into each other in a useful way, to export and import each other's data, etc. Essentially, defining interface standards to allow extensions to be developed by others, defining interchange formats to allow data sharing, etc. And finding ways to let others contribute their own little bits to the larger projects.

I think every major developer has conceded they have schedule restrictions and can only do X much over a certain period. Having the ability to farm out some parts might just be very useful.

Case in point:
You guys working on system generators... mapping of a system is a very time consuming process involving graphics, etc. So, let us say you are spending a lot of time on the generation system, the database interface, etc. If you could parcel out the generation of J-6 maps or system maps and get a 'slot in' component (a COM component or a .NET assembly for instance or a Java jar), that might take some of your load off and allow you to accomplish different things.

It is just an idea I thought might be interesting to discuss. I'm not trying to force a philosophy here... I just see two things I think would be nice to do something different with:

1) Core developers can only do X much in a certain time, so they have to pick and choose, and often the needs of a particular important feature may drive the development, leaving others they could be working on sit (when they could farm out one or the other set of that and maybe get both done).

2) If a Core developer has an unpleasant fate or real life interferes or he loses his net connection or he decides he hates RPGs, etc... then we've already seen several good bits of gaming software over the years become unmodifiable and the author drops out of contact. If there was some way to repository this code more generally, even if it is only some form of escrow until the person declares they have no more interest in it, it might be better for the overall gaming community

I guess I'm just a big believer in proces improvement, facilitating wider contribution, and the power of teams. I realize the shortcomings, the difficulties, and the different requirements this can sometimes introduce. But I think the net effect is a big plus. YMMV.

 

[kaladorn]

And yet... FireFox, Thunderbird, Linux, Ethereal, Apache, etc....

I was thinking of something higher level than I believe what you refer to. I'm not talking about you working with others to do H&E (though I direly wish you lot that weren't selling the stuff for cash would open-source the code, just so that if one of you gets in a car accident, we wouldn't be bereft of all possibilities of future improvements...).

What I'm thinking of here is more like a sort of mini-consortium approach. Stuart goes off and does H&E, Trevor does Universe, Mert does Navigator, etc. But maybe we can find a way to define a common way to embed the bits of software into each other in a useful way, to export and import each other's data, etc. Essentially, defining interface standards to allow extensions to be developed by others, defining interchange formats to allow data sharing, etc. And finding ways to let others contribute their own little bits to the larger projects.

I think every major developer has conceded they have schedule restrictions and can only do X much over a certain period. Having the ability to farm out some parts might just be very useful.

Case in point:
You guys working on system generators... mapping of a system is a very time consuming process involving graphics, etc. So, let us say you are spending a lot of time on the generation system, the database interface, etc. If you could parcel out the generation of J-6 maps or system maps and get a 'slot in' component (a COM component or a .NET assembly for instance or a Java jar), that might take some of your load off and allow you to accomplish different things.

It is just an idea I thought might be interesting to discuss. I'm not trying to force a philosophy here... I just see two things I think would be nice to do something different with:

1) Core developers can only do X much in a certain time, so they have to pick and choose, and often the needs of a particular important feature may drive the development, leaving others they could be working on sit (when they could farm out one or the other set of that and maybe get both done).

2) If a Core developer has an unpleasant fate or real life interferes or he loses his net connection or he decides he hates RPGs, etc... then we've already seen several good bits of gaming software over the years become unmodifiable and the author drops out of contact. If there was some way to repository this code more generally, even if it is only some form of escrow until the person declares they have no more interest in it, it might be better for the overall gaming community

I guess I'm just a big believer in proces improvement, facilitating wider contribution, and the power of teams. I realize the shortcomings, the difficulties, and the different requirements this can sometimes introduce. But I think the net effect is a big plus. YMMV.

 

[zakrol]

Undoubtedly, if such a project could be got off the ground then there would be significant benefits. The difficulty is that you would tread a very fine line between over-regimentation and a free for all.

Agreement would be needed on development system and to some extent features. The danger on the one hand is that it might turn into a dictatorship run by one or a small group of individuals making arbitrary decisions about the direction of things. On the other hand, without a strong leadership it could meander aimlessly or turn into a mish-mash of ill-fitting features.

I'm not saying it can't or shouldn't be done but I suspect that successful projects have had a very able and obvious leader (Linus Torvalds for Linux for instance), or a very well defined and agreed specification of what was being aimed at.

And then there's always the rogue individual who comes along and wants something out of spec (like jump6 maps with UWPs for instance) and wants to write it in what they consider to be the best language ever, such as PHP.

It all depends whether there's somebody out there with strong leadership qualities, bags of spare time and an asbestos coated skin. You never know, though......

Chris

 

[Hemdian]

I like the idea of a collaborative venture very much, it makes a lot of sense ... in theory. However, I've already provided a limited potential for this though the database used in Universe: someone could have written their own trade analyser (for example) based on common data. No one did. I also put out a request some time back for help with a data cleaning exercise ... but no help came.

I think the reason why open source projects like Linux et al work is that they draw on a much larger pool of talent. The size of the online Traveller community has produced only a few people at any one time who have the time committment, and they with so few its harder to find those who's visions mesh.

I will, however, make sure there is a backup of the Universe source code placed with someone in the event of my loosing an argument with a car (or similar incident).

Regards PLST

 

[kaladorn]

I agree with the comments people have made about the problems. Even in the larger OSS community, a lot of nascent forkings of projects and new projects fail. It turns out that just starting one isn't in itself sufficient to guarantee success

Yes, there are personality issues. Different OSS projects have different management techniques.

I guess for me, it is kind of an integration issue too. We have all these wonderful tool, but no master framework that ties them together. No easy way to import and export and share data. (Yes, I agree some preliminary steps have been taken and the discussions of good system representation formats is a nice step). No common tool from which I can access Navigator, Galactic, etc. and clip data back and forth, etc.

I missed the request for a trade analyzer. Sorry about that. I might have taken a crack at it. But I can see a problem - most people will want standards based metrics, and the metrics are not open standard (a la RFC). BTN stuff is proprietary GURPSian Traveller. So in order to do a tool up to produce BTN analysis, I'd think you'd need permission.

This is part of the issue - that the data representation and rules mechanics (equivalent to protocols and algorithms in the larger computer world) are actually proprietary products, not *just* the setting. That's actually quite annoying.

The OGL makes common rules available for many systems, but it doesn't delve into things like economic rules or world generation rules, etc.

Some of the recent discussion on the What If? thread here at COTI suggests it may be possible to negotiate some 'mechanical' licensing with Marc and Hunter for just such situations, if not with SJG (though they may be amenable too).

Maybe one of us computer folks should put in a petition for a similar mechanical license for producing computer utilities (not just adventures or supplements). They might actually be amenable to that. Hmmmm....

Anyway, call it wishful thinking. I'd just like to see a way where the great efforts of core developers could be harmonized. And where people with less time could do smaller contributions that integrated, plug-in like, but that were not vital so consequently their schedule or their failure to produce would not damage core functions, but if it was available, would add something.

I like to dream...

 

[BeRKA]

I agree with a lot of the discussion above. I am probably one of the people that only can make small contributions if I have some time to do it, and I find it interesting.

The latest example was making the dotmap generator (from some code I already had made a long time ago) for Flynn, who requested something to make dotmaps.

I should also thank people who has allowed me to use their code. Like the subsector viewer by Jo Grant.

So I think some cooperation seems to work already...

Anyway, back to subject. Here is an example of the printable J-6 Map from Universe:
http://zho.berka.com/data/foreven/fessor/fessor/

 

[robject]

In this case, it's better to do something than to talk about it. Especially when there's no control. Popular solutions will get used, but first they have to be written. Also, success can attract momentum. So stop talking and start coding...


I think what might work according to Kaladorn's thoughts would be something like where individuals write Traveller framework or infrastructure code that is generally useful to other Traveller developers but not particular to one application.


By infrastructure I mean classes, or modular code (or data objects?) that handle units of Traveller data in a helpful way. For example, I've been writing perl scripts that fool around with UWP data. Finally, I wrote a package that makes it portable and uploaded it to CPAN. Now anyone who knows a little perl can use my package to parse UWP data painlessly. Anyone who wants to do a project that involves parsing UWPs just got a leg up. The only reason I haven't ported my code to a Java class yet is because I haven't got around to it.


Frameworks or toolkits are often related to presentation and persistence. To date, noone has written a generic Traveller GUI framework, and noone has written a generic Traveller persistence framework. They're a bit more nebulous in scope, and hard to pin down, so they might not be as useful as simple infrastructure.


So I'd say a library of documented core classes would be a good start. Start with the basics - UWP, UPP, USP. Add in a calc module, for distance and time calculations, perhaps. Add yet more classes to describe skills, speculative trade goods, and solar system details, and Algorithms/States for chargen, combat, trade. But start with the UWP, UPP, and USP.

 

[kaladorn]

That's a good post Robject.

Class libraries for common item handling would be good. What I'd like to see with them is a *ML (UML?) model description of the library that would thus make implementation in other languages a matter of matching that UML description.

And these kind of things would make great 'chunk work' that people could do bits on and contribute.

I wonder what good libraries would be for this respect? I would gladly take a stab at making up some small libraries for this kind of work over time, that others could embed.

UWP - You seem to have that covered. It might be worthwhile to port your code to Java and C/C++. Or create a windows DLL or COM object that implements it.

UPP - What would this do? (UPP being so simple...?)

Trade - Great topic for a library on. There'd be a lot to implement, different versions, and questions of what API to expose.

Skills - Another great library topic.

USP - Yikes... there's one for the gearheads.

Yes, I think I might have to see about starting some of these. Maybe to distribute the effort, I should start with something simple like porting your CPAN code to C++ or something like that.

Can you link to your Perl package?

 

[Hemdian]

Originally posted by robject:
I think what might work according to Kaladorn's thoughts would be something like where individuals write Traveller framework or infrastructure code that is generally useful to other Traveller developers but not particular to one application.

For data persistance, I made documentation available on the database structure in Traveller Universe because I hoped people would use it as a platform for other developments.

Meanwhile, I have been looking closely at the internal structure of Traveller Universe itself for the past couple of weeks, with a view of exposing many of the classes in Release 2. As the original internal structure is quite poor I am considering rewriting the whole thing in C# (using Visio's UML templates).

The first is available now, the second will be available later (possibly the end of the year, RL permitting). Hopefully this will meet everyone's requirements for an extensible framework. Any comments best be made now before I've gone too far down this road.

Regards PLST

 

[kaladorn]

Hemdian, is said documentation on your site or with the product?

I'm going to look into it. You had good arguments for using Interbase. With the proper DBI layer, it should be possible to abstract the details of the database from the higher level software also.

Two comments:
C# does leave out a lot of non-windows users. I'm not sure if WINE or any other *NIX Windows emulator supports the CLR based functions of .NET (which I assume you would use if writing in C#).

I think what someone was suggesting is more platform portable solutions that anyone could import and use. For underlying library classes, this should be feasible.

It would be nice to have a program like universe properly split into 3 layers - data, application logic, presentation. By doing so, one could install it on top of a variety of DBs (for the DB layer), use a variety of presentation forms (windows UI, CGI/PHP/ASP from the net, etc) and use the same application logic.

Lots of good ideas to mull about here. I may have to explore creating a place that is specific to traveller related software, even moreso than this forum. Hmmmm.

 

[robject]

Aye, there's the Main Point, kaladorn, I think you've hit it: a common repository would be nice. Maybe we should talk to Swordy on Downport and see if he's got a place for source code.

It would be very nice if he had space for a Java package tree. What IS a likely package tree for Traveller, anyway?

rpg.traveller.fw for component classes (like UWP.java)?

rpg.traveller.app for applications (like TradeWar.java)?

rpg.traveller.util for utility classes (like DistanceCalculator.java)?

 

[robject]

Originally posted by kaladorn:
What I'd like to see with them is a *ML (UML?) model description of the library that would thus make implementation in other languages a matter of matching that UML description.

That's a very good idea. I've been trying to get the Eclipse UML plug-in for awhile now... maybe I'll try again.

The more I think about it, the more I agree with you. Component design artifacts might be more valuable to developers than completed, documented code.

UPP - What would this do? (UPP being so simple...?)

Trade - Great topic for a library on. There'd be a lot to implement, different versions, and questions of what API to expose.

Skills - Another great library topic.

One UPP project could be the basis of a character generator: a thing which provides accessors to characteristics and the skills, and maybe can roll up a set of characteristics, too. Add a Career Resolvable interface, and someone can take it and write career resolution modules for it.

Speculative Trade goods make good Flyweights. They might make great parametric classes as well.

Skills may be best kept as Flyweights, and perhaps even parametric: they might be created and owned by a Manager (or Factory?). Any way they're done, they at a minimum need a name and description.

If you wanted to brave my source code (trial by fire, I guess), it's on CPAN... well, yesterday's version (v0.9) is. The latest and greatest (v0.91) is in the pipe, and will be available shortly, actually.

 

[kaladorn]

Sorry, I meant the UPP by itself isn't much. Yes, with other things, it could form all sorts of things.
But the only things I can think that map directly to the UPP are MT Hits/Life, MT Determination, Carrying Capacity, Skills Limit (Int + Edu).... that's about it.

As to package, tradition puts it in the corporate world. Would it be something like

com.farfuture.rpg.traveller.fanware.<insert appropriate bit>

I'd suggest this package naming convention out of respect for their IP and to show who holds the IP. But at the same time, I don't want to imply that it is put out by far future itself, hence the inclusion of 'fanware' though I'm open to other characterizations.

I wonder if we could get the FFE copyright statement expanded to include not-for-profit software? It makes specific textual statements for fanzines and websites. Perhaps we can get it extended to software that is open source or not for profit (for profit implying a license from Marc/FFE or Hunter/QLI).

I'd feel happier if I was sure developing these kinds of things wasn't some sort of problem for them. I mean, I find it really just encourages players, but then again I'm not sure they'd take the same view.

Hmmm....

I think the idea of providing defined interfaces, pseudocode, and the like and some sort of structural definitions and interrelationships (what a class diagram hopes to capture) to the various projects would have a great value. Then it is not tied to an implementation, and others can freely implement *something compatible from an interface/classmodel PoV* in their own language or on their own platform. What's more, they can probably do so more easily when they have working code in another language to study as well as the API and class or API definitions to go with it.

I think *that* might be the best way to achieve reuse and a 'creative commons' sort of aspect.

But I do think at some point I want to talk to Hunter and Marc to see if there are any gotchas here - they may have genuine IP-lawyeresque concerns about this kind of things. I'm not sure. I mean, I don't want them to risk getting a diluted Trademark because that means those willing to just trade on your name can pop up and try to sell product as if it was them. That's not where we want this to go.

So, I think there are a lot of useful ideas, but I also now have some concerns.

 

[Hemdian]

Originally posted by kaladorn:
Hemdian, is said documentation on your site or with the product?

I'm going to look into it. You had good arguments for using Interbase. With the proper DBI layer, it should be possible to abstract the details of the database from the higher level software also.

Documentation includes:
- Logical Database Design document for the database
- Static Data list

A port of the database to MS SQL Server 2000 (MSDE 2000) should be out in the not too distant future. With ODBC it should be possible to move Universe to be non vendor-specific as far as underlying technology is concerned. A port to Oracle should also be feasible.

C# does leave out a lot of non-windows users. I'm not sure if WINE or any other *NIX Windows emulator supports the CLR based functions of .NET (which I assume you would use if writing in C#).

My understanding is that .NET (yes I did mean C#.NET) was multiplatform. For Linux look here. From what I have read it should also work on FreeBSD and Mac OS X 10.2.

Originally posted by kaladorn:
I wonder if we could get the FFE copyright statement expanded to include not-for-profit software? It makes specific textual statements for fanzines and websites. Perhaps we can get it extended to software that is open source or not for profit (for profit implying a license from Marc/FFE or Hunter/QLI).

Don't forget the GURPS crowd, Steve Jackson Games have their own software policy.

One of the reasons Universe is sold through BITS is because BITS already have agreements in place with all interested parties. I've heard it said that Marc wants to explore the commercial aspects of software with big companies ... products like Universe are acceptable only because the number of copies sold is relatively low and thus wont impact any negotiations.

Regards PLST

 

[kaladorn]

I'll do some review on your stuff when I have some cycles. Thanks for the link!

I'd still like to see Universe capable of being deployed over postgres or mysql. They are some of the most prevalent open source technologies. I know that mysql isn't mature enough (or at least wasn't the last time we spoke on this matter) but it is also incredibly common as a web front end, and it would be lovely to get a db that one could then establish a web presence for, with gaming groups often being distributed these days.

As to the whole computer software thing:
Nature abhors a vaccuum. Why Marc or Hunter would want to pay somebody to develop software (I doubt there would be a market to justify interest from a commercial entity, but I could be mistaken) would be beyond me. I made specific reference to not-for -profit software.

I believe this is a philosophical thing, but I believe that those involved should look at the big picture and see how others have made software business models work.

In this case, I think that the product is a background, a ruleset(or sets), and new supplements. Software could be viewed as a potential profit center, but I think this is a very limited view and isn't really that forward thinking. Software can instead be viewed as a lever to sell your game books - the ruleset and the setting. To that end, allowing people to freely develop software to drive this market would make sense - character generators, system generation, etc. This is part of the bait to suck in gamers. Viewing as a profit center just insures that it will be done sub-rosa by someone anyway.

The problem with a commercial venture here is it *won't* be flexible enough or adaptable enough for all the needs that are out there. No one has the kind of $$$ to drive that. Fan enthusiasm is free. If fans are willing to devote the time, shouldn't the IP owner see this as a great chance for some free labour? Essentially, that's what those of us who think we should contribute are offering. But in order to make this a reality, certain legal/IP release needs to be provided.

Commercial software will do 'a particular thing'. But what about all the players who want to do their vehicle design a slightly different way, using different tech, or using Malenfant's revised system generation, or an alternate chargen? Is a commercial software product going to support that? No. And the fact people want it will cut down the market for commercial software.

However, an open framework in which various fans can contribute part of what fires their passion, that lets a wide variety of things be provided, without tying the provision of capability to the IP holders' ability to fund it or convince a for-profit company to produce it. But the end result could be a wide, but perhaps integrable, collection of objects, classes, and eventually applications - far broader than what commercial software ventures could provide.

Trying to keep this 'in-house' or 'under wraps' may prove to be an IP law necessity for Trademark reasons. If this is *not* the case, every attempt should be made to open up this area and let the various developers here contribute their efforts, knowledge, and differing interests. The net result would be pretty good for the community.

And cynically, you might as well go with the flow, not only because it is a good idea, but because stopping gamers from writing and sharing things they find cool would be like trying to squeeze a handful of water. The harder you squeeze, the faster it leaks out.

I hope for an enlightened policy here, to the limit protecting the IP that matters and trademark allows. I think that such an open policy and some good development efforts could result in significant additions to the community and perhaps ways to hook in more new players and inpsire them. And *that* would be the way to economic success, wouldn't it?

YMMV, but that's how I see this. I'm no 'software communist' but their are advantages to harnessing the passions of a devoted following and the flexibility of an open environment far exceeds that of a proprietary one. And that strikes me that it would be good for QLI and good for FFE.

 

[Hemdian]

Originally posted by kaladorn:
I'd still like to see Universe capable of being deployed over postgres or mysql.

I had a quick look on the web and it looks like the newer versions of mySQL now supports triggers. That being so, feel free to reverse engineer a Universe database from InterBase to mySQL. If it can be accessed via an ODBC link then Universe should have no problem (TUmanager is a different matter). If it works I'll host it along side the other Universe stuff and patch TUmanager accordingly.

Originally posted by kaladorn:
As to the whole computer software thing:

I agree with a lot of what you say, I'm just passing on (a) the SJ Games software policy link (if you disagree with it take it up with them), and (b) a comment made to me from BITS. I am not privy to any of Marc's specific plans ... but I suspect if any commercial software was produced it would be more in the line of games rather than utilities anyway.

Presently, the "powers that be" seem to turn a blind eye to individual software projects and small collaberations that "fly below the radar". Asking for an official ruling as a prelude to defining an 'official' software framework might force Marc's hand if he really does have concerns about this. (On the other hand it might all be a misunderstanding and not really an issue after all.)

Regards PLST

 

[kaladorn]

The only problem with not reaching an understanding is that it leaves the situation ambiguous. It also leaves an opportunity for a subsequent assertion of rights to invalidate a (potential) large amount of work already completed. That's why I was suggesting we breach this topic up front.

I mean, it would be nice to know where Marc and Hunter stand, or even if they stand anywhere in particular. Are they open to thinking about this in various ways? Do they feel penned in by Trademark law and IP considerations? Do they have a personal philosophical objection to the idea of an open-source approach? Do they envision the game growing a different way or do they feel this would dilute interest in the printed products?

These are the kinds of things it would be instructive to know.

As for your suggestion about mySQL, I'll look into that over the summer (at least eyeball it and see if it is feasible). I knew they were working on triggers. My thought is if we could get the DB working on mySQL, then we could easily use it as the backend to some interesting related PHP and Perl apps for the web.