[IF#] A wiki is born
David A. Cornelson
http://if-sharp.sourceforge.net, I thought it would be a good idea to start
a wiki.
For those that don't remember, IF# is a proposed .NET programming language,
library, and WinForms control that will allow you to build IF games in .NET
and Mono. Some of the benefits of this are that with access to the base
classes in the .NET and Mono runtimes, you will be able to use a lot of
general programming things that are not available in any current IF
language. Some of these things may not seem important (XML, database access,
file i/o) and some are doable in current systems but require knowledge of
C++. The .NET Common Language Runtime is strongly-typed and is not
interpreted. It is JIT'd into native code and executed from there.
In any case...
You can visit and make changes anonymously at:
http://www.ifsharp.org/phpwiki
I plan to get user authentication in there at some point but the whole point
of a wiki is to make it accessible so I'm leaving it open for now. I only
ask that you create a wikiname for yourself here:
http://www.ifsharp.org/phpwiki/index.php?pagename=Users
And then reference any changes with that wikiname and a date/time.
Thanks,
Dave
Rexx Magnus
> Although I have the sourceforge project started at
> http://if-sharp.sourceforge.net, I thought it would be a good idea to
> start a wiki.
>
*snippage*
I must have misunderstood when I read the thread before - I ended up
thinking you were going to write something that could make the .net studio
IDE do syntax highlighting for inform - then pass the code to the
compiler, rather than a whole new IF system.
--
UO & AC Herbal - http://www.rexx.co.uk/herbal
To email me, visit the site.
Joe Mason
> On Wed, 20 Aug 2003 03:59:23 GMT, David A. Cornelson scrawled:
>
>> Although I have the sourceforge project started at
>> http://if-sharp.sourceforge.net, I thought it would be a good idea to
>> start a wiki.
>>
>
> *snippage*
>
> I must have misunderstood when I read the thread before - I ended up
> thinking you were going to write something that could make the .net studio
> IDE do syntax highlighting for inform - then pass the code to the
> compiler, rather than a whole new IF system.
That's what he was talking about in the previous thread, yeah - this is
something different again.
Joe
Rexx Magnus
>> I must have misunderstood when I read the thread before - I ended up
>> thinking you were going to write something that could make the .net
>> studio IDE do syntax highlighting for inform - then pass the code to
>> the compiler, rather than a whole new IF system.
>
> That's what he was talking about in the previous thread, yeah - this is
> something different again.
>
> Joe
*headache*
I can tell I'm going to have to read the other thread fully then. :)
David A. Cornelson
news:Xns93DDA83B495...@130.133.1.4...
> On Wed, 20 Aug 2003 03:59:23 GMT, David A. Cornelson scrawled:
>
> > Although I have the sourceforge project started at
> > http://if-sharp.sourceforge.net, I thought it would be a good idea to
> > start a wiki.
> >
>
> *snippage*
>
> I must have misunderstood when I read the thread before - I ended up
> thinking you were going to write something that could make the .net studio
> IDE do syntax highlighting for inform - then pass the code to the
> compiler, rather than a whole new IF system.
>
Well I'm kind of in over my head in _several_ areas of IF software
development. Here's a run down of my thoughts:
I want to implement multi-player IF and I want to see an IF platform built
from the ground up with this in mind. The plumbing for MPIF is not as easy
as it looks. A lot of the code elements are available in something like
TADS3, but the focus is still a singular (prinary character) PC interface.
It's my belief that one of the limitations of the current
VM/cross-platform-centric nature of IF is the real culprit to doing things
like MPIF since what is really needed is a development platform that allows
for any sort of general programming to be added on to the system. So to me,
the lack of the ability to do MPIF in Inform, TADS, or Hugo isn't so much
that they can't do it, it's just how much pain is involved and how much does
the underlying platform support the effort. The same thing could be said for
adding database support to an IF game, using XML interfaces, or any other
general programming practices that haven't found their way into IF as of
today.
To that end, and because I'm a Microsoft advocate, I would like to see a
platform centered on .NET. Despite all the rhetoric about Microsoft as a
corporation, .NET and the related tools and class libraries implement
best-practice development across the board. The fact that Mono's first
release is around the corner is only adding to my interest in developing
against .NET. If the Mono team is successful, my .NET implementation of an
IF platform would essentially be cross-platform with a single game file and
a single WinForms application as an interpreter.
But the underlying ability of the .NET framework is what excites me. Here is
a vast array of networking, graphical, sound, database, and object-oriented
base of classes that will allow an IF developer to implement any damn crazy
thing they want, in any .NET language they want.
Of course I want to create IF#, a new language syntax that will compile to
MSIL (to .NET), but this would only be because through discussions, it has
become clear that IF objects are not the same as general programming
objects. An IF specific syntax is more or less required as a sort of
short-cut to building an IF world.
Along witht he IF specific syntax (IF#), there also has to be a library,
much like Mike Roberts is spending years on the TADS 3 library. In fact,
Mike's development TADS 3 is an excellent example how to go about building a
new IF platform. I plan to emulate that process as much as possible with the
exception that I'm of nowhere near the caliber developer that Mike is.
Along with the syntax and the library, there also has to be a front-end
capable of doing the things I want to do. I think this is probably the
easiest part and the part I feel most comfortable working on myself. I've
taken Andrew Plotkin's Glk specification (with permission) and started
developing a set of classes and controls in .NET that will more or less
mimic the same behavior.
Now the other thread was just an afterthought, although if all of these
other things come true, it would be inevitable that a Visual Studio .NET
implementation of IF# would take place.
After reviewing the licensing, it's clear that the only way to distribute
this potential tool would be to people that already owned VS.NET, which is a
minimum of $100 USD. In order to have a distribution license, you need to
pay $10,000/year. Oh well, it was a nice thought. But maybe they'll change
their mind for what will essentially be a free and open source platform.
Now after all of this is implemented, what can be done with it? That's the
last goal. I think with a platform like this and with the number of OS's out
there with .NET built-in, it's perfectly ligitimate to believe that some
higher end IF could be developed and sold in less time and with greater
agility than is currently possible.
And with GDI+ and DirectX, even more sophisticated visual IF could be
developed.
It's all hot air at the moment. There are people interested in the concept,
but not enough cross-breeding happens between the Microsoft development
world and the IF community. But I like focusing on this as opposed to other
things. I just seem to be more interested in the tools than the games for
the time being, even though I have 80 games in my head that need to be
written.
And after using .NET for the last 2 years, using Inform is painful. And
looking at TADS 3 is pretty interesting, but it doesn't have the abilities
that I want in a platform, namely the openness to general programming
extensions and MPIF.
So there you go. That should explain everything.
Dave
Kevin Forchione
news:ONWdneJHqaR...@speakeasy.net...
> "Rexx Magnus" <tras...@uk2.net> wrote in message
> news:Xns93DDA83B495...@130.133.1.4...
> > On Wed, 20 Aug 2003 03:59:23 GMT, David A. Cornelson scrawled:
> >
> > > Although I have the sourceforge project started at
> > > http://if-sharp.sourceforge.net, I thought it would be a good idea to
> > > start a wiki.
> > >
> >
> > *snippage*
> >
> > I must have misunderstood when I read the thread before - I ended up
> > thinking you were going to write something that could make the .net
studio
> > IDE do syntax highlighting for inform - then pass the code to the
> > compiler, rather than a whole new IF system.
> >
>
> Well I'm kind of in over my head in _several_ areas of IF software
> development. Here's a run down of my thoughts:
>
> I want to implement multi-player IF and I want to see an IF platform built
> from the ground up with this in mind. The plumbing for MPIF is not as easy
> as it looks. A lot of the code elements are available in something like
> TADS3, but the focus is still a singular (prinary character) PC interface.
When you say multi-player IF, what do you envisage? Sure there exist
multi-player text games (muds) and multi-player graphics games ranging from
shooters to sims. No doubt this question has been raised before, but it's
still unclear to me what the basic underlying architecture would look like.
Putting aside the technical details of platform and portability and all that
jazz. What's MPIF going to feel like for a player? What's it going to
involve for the author? These are the things I'd like to know. With multiple
players, how are they interacting with the game environment? I assume each
player command line would be broken down into individual commands. Is the
entire player command line to be single-threaded, or only individual
commands? If Joe and Bob both try to take and eat the magic apple, does the
sequence proceed: <<joe take>>, <<bob take>>, <<joe eat>>, <<bob eat>> or is
it <<joe take>>, <<joe eat>>, <<bob take>>, <<bob eat>>? This may seem
trivial or too low-level, but this is fundamental stuff and you must have
some ideas about it.
Likewise, as an author, for narrative progression, if the apple is something
that is required further along in the game (and really unless you're doing a
pure simulation, then object-interactions must be), then is it to be
first-come, first-served? Or is everyone playing the game co-operating
somehow, so that if Bob takes the apple, then Bob can give it to the troll
and Joe isn't hampered in his gaming because he's part of the band of merry
questers? And what if Bob decides to go off on his merry way and leave the
group, and he's the one holding the golden key to the cracks of doom?
Call me naive, maybe these kinds of issues are already sorted. If not, then
it could be a *very* long time before MPIF materializes. How do you picture
it working, both for player and author?
--Kevin
Andy Leighton
> I want to implement multi-player IF and I want to see an IF platform built
> from the ground up with this in mind. The plumbing for MPIF is not as easy
> as it looks.
I think that this is something everyone can agree on. As someone who has
in the distant past worked on a puzzle based MUD (the closest thing to MPIF
I can think of) - the core for MPIF is more difficult than just for single
player IF.
> It's my belief that one of the limitations of the current
> VM/cross-platform-centric nature of IF is the real culprit to doing things
> like MPIF
Why do you think that? Obviously the current crop if IF VMs are not designed
for multi-player games - but that is because that was a conscious choice.
> since what is really needed is a development platform that allows
> for any sort of general programming to be added on to the system.
Domain specific languages are usually better than general purpose ones
(especially when used by non professional programmers). Obviously some
thought has to be what features you need to add to the VM (or maybe you
would start from scratch in writing a new VM).
> the underlying platform support the effort. The same thing could be said for
> adding database support to an IF game, using XML interfaces, or any other
> general programming practices that haven't found their way into IF as of
> today.
Is there a great demand for databases, XML etc?
Even if you believe a general purpose programming language is needed,
I fail to see why you wouldn't choose something that is cross-platform.
Java, Python, Ruby could all be good choices. Of course there has already
been systems that take this route, namely PUB and PAWS - and I believe that
even their respective authors will admit they haven't set the world on fire
in terms of popularity.
> The fact that Mono's first release is around the corner is only adding
> to my interest in developing against .NET. If the Mono team is successful,
> my .NET implementation of an IF platform would essentially be cross-
> platform with a single game file and a single WinForms application as
> an interpreter.
First release around the corner may not include everything you need.
WinForms support for instance is pretty weak - nearly 50% of the methods
in System.Windows.Forms are missing.
> But the underlying ability of the .NET framework is what excites me. Here is
> a vast array of networking, graphical, sound, database, and object-oriented
> base of classes that will allow an IF developer to implement any damn crazy
> thing they want, in any .NET language they want.
[snip]
> And with GDI+ and DirectX, even more sophisticated visual IF could be
> developed.
The more of these that you use the less cross-platform it is going to be.
--
Andy Leighton => an...@azaal.plus.com
"The Lord is my shepherd, but we still lost the sheep dog trials"
- Robert Rankin, _They Came And Ate Us_
Alex Warren
> "David A. Cornelson" <david dot cornelson at iflibrary.com> wrote in message
> news:ONWdneJHqaR...@speakeasy.net...
> > I want to implement multi-player IF and I want to see an IF platform built
> > from the ground up with this in mind. The plumbing for MPIF is not as easy
> > as it looks. A lot of the code elements are available in something like
> > TADS3, but the focus is still a singular (prinary character) PC interface.
>
> When you say multi-player IF, what do you envisage? Sure there exist
> multi-player text games (muds) and multi-player graphics games ranging from
> shooters to sims. No doubt this question has been raised before, but it's
> still unclear to me what the basic underlying architecture would look like.
I released QuestNet Server Beta 2 a month ago, and I'm not aware of any other
multi-player IF system. You can download it at
http://www.axeuk.com/quest/questnet.htm.
The client software to connect to the server is Quest. Version 3.12 will work,
but version 3.5 beta is more compatible with the new features of QuestNet Server
Beta 2.
The game author codes their game in a similar way to a single-player game, with
a few differences which are detailed in the documentation. QDK 3.5 Beta adds
support for QuestNet so games can now be created in the visual editor as well.
The game can then be hosted on one machine running QuestNet Server, and then
players connect to the game using Quest. Once in the game, players can interact
with it in much the same way as they interact with a single-player game, except
all the code is being executed on the server, with the Quest client acting as a
terminal.
> If Joe and Bob both try to take and eat the magic apple, does the
> sequence proceed: <<joe take>>, <<bob take>>, <<joe eat>>, <<bob eat>> or is
> it <<joe take>>, <<joe eat>>, <<bob take>>, <<bob eat>>? This may seem
> trivial or too low-level, but this is fundamental stuff and you must have
> some ideas about it.
If there was only one apple, then Joe could take the apple, and if Bob was in
the same room a line of text would come up saying that Joe has taken the apple.
Bob can't take it now, because the apple is in Joe's posession. Joe could eat
the apple if he wanted, or he might drop it back in the room, in which case Bob
would be able to take it again.
It would also be possible for the game author to come up with some "fight" code,
for example, so that Bob could attack Joe for the apple. The implementation of
this would be entirely up to the game author.
> Likewise, as an author, for narrative progression, if the apple is something
> that is required further along in the game (and really unless you're doing a
> pure simulation, then object-interactions must be), then is it to be
> first-come, first-served? Or is everyone playing the game co-operating
> somehow, so that if Bob takes the apple, then Bob can give it to the troll
> and Joe isn't hampered in his gaming because he's part of the band of merry
> questers? And what if Bob decides to go off on his merry way and leave the
> group, and he's the one holding the golden key to the cracks of doom?
It all depends on how the game author decides to code the game. Obviously the
considerations of a multi-player game are very different from a single-player
game. The multi-player game may not be designed to be winnable at all - it may
just be a big text environment for players to interact. But if the game is
designed to be winnable, the game author needs to consider how to handle objects
that are fundamental to the progression of the game. And of course the players
need to consider which move to make next so they don't go ruining the game for
everybody else. It may be that people decide only to play with people who can be
trusted not to deliberately go off making the game unwinnable. You can set up
logins in QuestNet Server so that you only play with selected people, rather
than making it a free-for-all.
Alex
--
alex at axeuk, and add .com for email address.
Make adventure games easily with Quest - http://www.axeuk.com/quest/
Analyse web site log files for free with Xlogan - http://www.xlogan.com/
David A. Cornelson
news:U0Y1b.1098$HG5.69...@newssvr13.news.prodigy.com...
>
> When you say multi-player IF, what do you envisage? Sure there exist
> multi-player text games (muds) and multi-player graphics games ranging
from
> shooters to sims. No doubt this question has been raised before, but it's
> still unclear to me what the basic underlying architecture would look
like.
> Call me naive, maybe these kinds of issues are already sorted. If not,
then
> it could be a *very* long time before MPIF materializes. How do you
picture
> it working, both for player and author?
I don't think there is a right or a wrong way to implement MPIF, and "my"
way is still in the design stages.
As for how this fits into IF# and the IF# Library, I would say that building
IF# from the ground up with the intention of have a client/server interface
and the ability to handle single player and cross-player events is the key.
Then "how" you implement the interactions is up to you. from a base IF#
stand-point. Of course I will have open discussions on what hopefully will
be a "mosty-agreed" upon pattern for MPIF and that is what will be
implemented in the main IF# Library.
It's also possible that the IF# Library could branch and that there could be
an IFSharp.Library.SinglePlayer namespace and a IFSharp.Library.MultiPlayer
namespace.
As for "my" view of how MPIF should function, give me a few days and I will
add most of my current thinking to the Wiki at
http://www.ifsharp.org/phpwiki.
And yes, this is not going to happen over night. I doubt any of these things
materialize for at least a couple of years depending upon the support I get
from the open source development community. It's my job to make that as
attractive and as fun as possible.
Dave
David A. Cornelson
news:slrnbkh6dp...@azaal.plus.com...
> On Sat, 23 Aug 2003 17:17:04 -0500, David A. Cornelson <> wrote:
>
> > It's my belief that one of the limitations of the current
> > VM/cross-platform-centric nature of IF is the real culprit to doing
things
> > like MPIF
>
> Why do you think that? Obviously the current crop if IF VMs are not
designed
> for multi-player games - but that is because that was a conscious choice.
Correct. I am making a conscious choice in starting the development of a new
IF platform that will implement some of the things I would like to see.
>
> > since what is really needed is a development platform that allows
> > for any sort of general programming to be added on to the system.
>
> Domain specific languages are usually better than general purpose ones
> (especially when used by non professional programmers). Obviously some
> thought has to be what features you need to add to the VM (or maybe you
> would start from scratch in writing a new VM).
No VM. IF# will compile to MSIL, which is JIT'd to native code. In this way,
any programmer can interact with any compiled IF# code with C#, C++.NET,
VB.NET, Perl.NET, Python.NET, Cobol.NET, JScript.NET, J#, or any other .NET
language that appears.
> > the underlying platform support the effort. The same thing could be said
for
> > adding database support to an IF game, using XML interfaces, or any
other
> > general programming practices that haven't found their way into IF as of
> > today.
>
> Is there a great demand for databases, XML etc?
I hope you're not missing my thoughts here. The thought is that IF is a
specific domain, but there are authors out there that may find some
interesting way to do something that can only be done in a general
programming language. Instead of being frustrated with a closed VM
architecture, with IF#, they would be able to hook into the .NET Framework
and do those things, whatever they are, or build C# libraries that could do
whatever they want.
>
> Even if you believe a general purpose programming language is needed,
> I fail to see why you wouldn't choose something that is cross-platform.
> Java, Python, Ruby could all be good choices. Of course there has already
> been systems that take this route, namely PUB and PAWS - and I believe
that
> even their respective authors will admit they haven't set the world on
fire
> in terms of popularity.
>
> > The fact that Mono's first release is around the corner is only adding
> > to my interest in developing against .NET. If the Mono team is
successful,
> > my .NET implementation of an IF platform would essentially be cross-
> > platform with a single game file and a single WinForms application as
> > an interpreter.
>
> First release around the corner may not include everything you need.
> WinForms support for instance is pretty weak - nearly 50% of the methods
> in System.Windows.Forms are missing.
By the time IF# is ready, Mono will be onto version 2 probably and will very
likely accomodate anything IF# needs. I'm pretty confident of this.
> > But the underlying ability of the .NET framework is what excites me.
Here is
> > a vast array of networking, graphical, sound, database, and
object-oriented
> > base of classes that will allow an IF developer to implement any damn
crazy
> > thing they want, in any .NET language they want.
>
> [snip]
>
> > And with GDI+ and DirectX, even more sophisticated visual IF could be
> > developed.
>
> The more of these that you use the less cross-platform it is going to be.
NOTE: This is my opinion and I do not expect it to be shared....
Cross-platform is not really the major concern since 90% of the desktops out
there are Windows. I know this isn't a popular sentiment in the IF
community, but it's mine. I'm a Windows guy. I like Windows. I have Linux on
two servers and they're great for DNS, POP3, HTTP, and stuff, but to code
against? To play games on? No thank you. Now if I can write code on Windows
that if I tweak a certain way _may_ work on a RedHat desktop, that would be
cool. But I'm not going to be too concerned if that falls apart for more
sophisticated visual and sound experiences. But I'm pretty confident that
the Mono stuff will work for most basic architectures and it might even work
for sound and graphics. It doesn't look too wise rght now to bet against
Miguel although Microsofties are courting him big time these days. Mono is
already in an amazing state and the Mono C# compiler is surpassing the
currently available MS C# compiler in its capabilities. With the Novell
purchase of Ximian, I think Mono is headed for a significant increase in
support.
Dave
Andy Leighton
> "Andy Leighton" <an...@azaal.plus.com> wrote in message
> news:slrnbkh6dp...@azaal.plus.com...
>> On Sat, 23 Aug 2003 17:17:04 -0500, David A. Cornelson <> wrote:
>>
>> > It's my belief that one of the limitations of the current
>> > VM/cross-platform-centric nature of IF is the real culprit to doing
> things
>> > like MPIF
>>
>> Why do you think that? Obviously the current crop if IF VMs are not
> designed
>> for multi-player games - but that is because that was a conscious choice.
>
> Correct. I am making a conscious choice in starting the development of a new
> IF platform that will implement some of the things I would like to see.
I don't see anywhere in that reply that explains why you believe that a
dedicated IF VM is a problem for MPIF.
>> > since what is really needed is a development platform that allows
>> > for any sort of general programming to be added on to the system.
>>
>> Domain specific languages are usually better than general purpose ones
>> (especially when used by non professional programmers). Obviously some
>> thought has to be what features you need to add to the VM (or maybe you
>> would start from scratch in writing a new VM).
>
> No VM. IF# will compile to MSIL, which is JIT'd to native code.In this way,
> any programmer can interact with any compiled IF# code with C#, C++.NET,
> VB.NET, Perl.NET, Python.NET, Cobol.NET, JScript.NET, J#, or any other .NET
> language that appears.
Well apart from the quality of some of the things mentioned above Perl.NET
and Python.NET (are the ones I know there are problems with) I quite
appreciate what you are trying to do. I just disagree with the approach.
> Cross-platform is not really the major concern since 90% of the desktops out
> there are Windows.
For the people who play IF I really doubt this. There does seem to be
a higher number of *nix/Mac/handheld users than normal desktops.
> community, but it's mine. I'm a Windows guy. I like Windows. I have Linux on
> two servers and they're great for DNS, POP3, HTTP, and stuff, but to code
> against? To play games on? No thank you.
Personally I find it much nicer to write code on a *nix system than on
a Windows machine - but I accept it is one of those YMMV issues. It is
just that IF is such a small market that to further restrict your options
seems a little short-sighted. But if you are happy with that then that's
your lookout.
David A. Cornelson
>
> Personally I find it much nicer to write code on a *nix system than on
> a Windows machine - but I accept it is one of those YMMV issues. It is
> just that IF is such a small market that to further restrict your options
> seems a little short-sighted. But if you are happy with that then that's
> your lookout.
>
Well here is where I differentiate myself from the community and probably in
a strong way. I don't believe developing the system in order to write games
for only the IF community is a very wise decision. I think building a
platform for games that can be played on 90% of the desktops out there is
very wise.
I don't want to write just for this community. I want to build games for
_everyone_. With that in mind, the best way to accomplish that isn't to be
cross-platform, but to be at least on the most widely available platform.
Some say a monopoly is a bad thing. I think single vendor solutions make me
more productive and make building for the largest audience possible quite a
bit easier than being cross-platform.
I personally believe that IF# would open up many commercial avenues for IF.
Dave
Kevin Forchione
> I don't want to write just for this community. I want to build games for
> _everyone_. With that in mind, the best way to accomplish that isn't to be
> cross-platform, but to be at least on the most widely available platform.
> Some say a monopoly is a bad thing. I think single vendor solutions make
me
> more productive and make building for the largest audience possible quite
a
> bit easier than being cross-platform.
Cross-platform is not as big a problem as it might appear, really, since if
it does catch on with windows users there will be inevitable ports to other
systems. That's the way it's been with TADS as well. A new release comes out
first for windows, and then other port maintainers play catch-up. It doesn't
really diminish the audience in the long run, only in the short.
"If you build it, others will port..." so to speak.
--Kevin
Andrew Plotkin
> "David A. Cornelson" <david dot cornelson at iflibrary.com> wrote in message
> news:O56dnYqDMuf...@speakeasy.net...
>
> > I don't want to write just for this community. I want to build
> > games for _everyone_. With that in mind, the best way to
> > accomplish that isn't to be cross-platform, but to be at least on
> > the most widely available platform. Some say a monopoly is a bad
> > thing. I think single vendor solutions make me more productive and
> > make building for the largest audience possible quite a bit easier
> > than being cross-platform.
>
> Cross-platform is not as big a problem as it might appear, really, since if
> it does catch on with windows users there will be inevitable ports to other
> systems.
Last I saw, David was talking about tools for the .NET platform.
If Mono works out, what you say will be true.
If Mono turns out to be impossible -- too much work, or nobody
succeeds, or MS undercuts it -- then cross-platform is not a "big"
problem, it's an insurmountable one.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
SimonW
cornelson at iflibrary.com> wrote:
*Snip*
>After reviewing the licensing, it's clear that the only way to distribute
>this potential tool would be to people that already owned VS.NET, which is a
>minimum of $100 USD. In order to have a distribution license, you need to
>pay $10,000/year. Oh well, it was a nice thought. But maybe they'll change
>their mind for what will essentially be a free and open source platform.
>
I don't see why people will need VS.NET? The .NET Framework is free
and comes with it's own CLI compliers.
Kevin Forchione
news:bib22r$481$1...@reader2.panix.com...
> Last I saw, David was talking about tools for the .NET platform.
>
> If Mono works out, what you say will be true.
>
> If Mono turns out to be impossible -- too much work, or nobody
> succeeds, or MS undercuts it -- then cross-platform is not a "big"
> problem, it's an insurmountable one.
So portability is entirely dependent upon the success of Mono? And Mono's
still in future tense. Uh-oh. I may be forced to recant...
--Kevin
David Thornley
>
>I hope you're not missing my thoughts here. The thought is that IF is a
>specific domain, but there are authors out there that may find some
>interesting way to do something that can only be done in a general
>programming language.
Inform and TADS are general programming languages. It is possible
to program whatever you like in them. If anybody actually wanted,
it would not be difficult to build on pre-existing C and C++ things
to interface with XML processors and databases.
However, it isn't clear to me that these have much to offer IF.
With our current understanding, development systems that don't allow
code to be attached wherever are limited, and I'm not aware that
databases and XML will work well with that. They are structured
data formats more than anything else, and handling large amounts of
data doesn't seem to be a major problem with IF.
Instead of being frustrated with a closed VM
>architecture, with IF#, they would be able to hook into the .NET Framework
>and do those things, whatever they are, or build C# libraries that could do
>whatever they want.
>
TADS 2 offered a native code interface a *long* time ago, and I'm not
aware that it's been used in any game in the IF archive.
Until you find a need that's going unfulfilled because of standard
IF virtual machine architecture, I'm really dubious that this idea
is going to go anywhere. The fact that there has been a mechanism
in a major IF language for the past decade to access native code,
and it's basically not been used, suggests that there is no such need.
What you could do is come up with something neat that can be done
with external libraries that would be much harder, if not impossible,
with standard VMs. (You could doubtless save a good deal of time by
doing it in TADS 2, or you could put more work in on your project by
doing it in .NET. Your choice.) That's about the only thing that
would convince me.
>Cross-platform is not really the major concern since 90% of the desktops out
>there are Windows.
Not 90% of the PDAs, to give another viewpoint.
I know this isn't a popular sentiment in the IF
>community, but it's mine.
Which means that you're cutting yourself off from some of the IF
community.
>sophisticated visual and sound experiences. But I'm pretty confident that
>the Mono stuff will work for most basic architectures and it might even work
>for sound and graphics.
In what ways are sound and graphics inadequately supported right now,
in Glk Inform or HTML TADS or Hugo?
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Andrew Pearce
news:bfWcnTZ4TN-...@speakeasy.net...
> Although I have the sourceforge project started at
> http://if-sharp.sourceforge.net, I thought it would be a good idea to
start
> a wiki.
Umm, what is a wiki anyway?
Andrew
Adrien Beau
>
> Umm, what is a wiki anyway?
Somewhat simplified answer: It's a web site that any visitor can
edit.
The first Wiki (by Ward Cunningham)
http://c2.com/cgi/wiki?WikiWikiWeb
Why Wiki works
http://c2.com/cgi/wiki?WhyWikiWorks
For more wikis, search Google
http://www.google.com/search?q=wiki
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
David A. Cornelson
news:3f4913e7$0$155$a186...@newsreader.visi.com...
> >
> TADS 2 offered a native code interface a *long* time ago, and I'm not
> aware that it's been used in any game in the IF archive.
C++ is not a very friendly programming language and requires a great deal of
what I call "out of context" knowledge. The beauty of using managed code and
something like .NET is that you really can avoid all of that extra junk like
pointers, memory allocation, and arrows and stars.
> Until you find a need that's going unfulfilled because of standard
> IF virtual machine architecture, I'm really dubious that this idea
> is going to go anywhere. The fact that there has been a mechanism
> in a major IF language for the past decade to access native code,
> and it's basically not been used, suggests that there is no such need.
I have _defined_ the need. I don't need to go looking for it.
> What you could do is come up with something neat that can be done
> with external libraries that would be much harder, if not impossible,
> with standard VMs. (You could doubtless save a good deal of time by
> doing it in TADS 2, or you could put more work in on your project by
> doing it in .NET. Your choice.) That's about the only thing that
> would convince me.
>
> >Cross-platform is not really the major concern since 90% of the desktops
out
> >there are Windows.
>
> Not 90% of the PDAs, to give another viewpoint.
>
> I know this isn't a popular sentiment in the IF
> >community, but it's mine.
>
> Which means that you're cutting yourself off from some of the IF
> community.
>
> >sophisticated visual and sound experiences. But I'm pretty confident that
> >the Mono stuff will work for most basic architectures and it might even
work
> >for sound and graphics.
>
> In what ways are sound and graphics inadequately supported right now,
> in Glk Inform or HTML TADS or Hugo?
>
Good point - I'll have to make sure that IF# is at least as good at all of
those things and I'll bet I can make it 10 times easier to implement in
.NET.
Dave
SimonW
cornelson at iflibrary.com> wrote:
>Although I have the sourceforge project started at
>http://if-sharp.sourceforge.net, I thought it would be a good idea to start
>a wiki.
>
>For those that don't remember, IF# is a proposed .NET programming language,
>library, and WinForms control that will allow you to build IF games in .NET
>and Mono. Some of the benefits of this are that with access to the base
>classes in the .NET and Mono runtimes, you will be able to use a lot of
>general programming things that are not available in any current IF
>language. Some of these things may not seem important (XML, database access,
>file i/o) and some are doable in current systems but require knowledge of
>C++. The .NET Common Language Runtime is strongly-typed and is not
>interpreted. It is JIT'd into native code and executed from there.
>
*Snip*
I have a few points and questions about your project:
1) Let me get this right you are proposing to write a IF Control that
you can use for developing with .NET ?
2) Compiled .NET programs are not native code they are complied to
MSIL the CLR then takes over using JITcompliers (amongst other things)
to produce native Code.
3) What version of .Net do you have ? As I don't understand why the
users need to have VS.NET for licensing issues when the .NET Framework
and SDK is free to download and programs can be complied into MSIL
using command line compilers on a source file written using a plain
text editor.
4) Even though you do, not every one likes .NET or Microsoft. Some
people do think it's typical microsoft bloat ware.
5) The .NET Framework and SDK is not small.
6) VS.NET with the MSDN documentation is even bigger taking up well
over a 1 GIG of HD space. Where currently the major IF systems use no
more than 10mb
7) IF Authors will also need to learn a .NET language then learn how
to program your controls. Considering the amount of non windows users
and IF beginners how many people do you think will do that ?
8) I have not seen much call for commercial IF programs, in fact a lot
of people think IF is dead and are surprised when I tell them there is
an IF community and people actively writing new games. Even armed with
this knowledge, they still have no interest in IF.
Please understand I do think it's a bold and interesting project, I am
trying to put your project in perspective of the modern IF user and
also make you realize you may be doing all this for little return.
David A. Cornelson
news:njlikv0imavd5q7qc...@4ax.com...
> On Tue, 19 Aug 2003 22:59:23 -0500, "David A. Cornelson" <david dot
> cornelson at iflibrary.com> wrote:
>
> I have a few points and questions about your project:
>
> 1) Let me get this right you are proposing to write a IF Control that
> you can use for developing with .NET ?
That's one part - there will be a compiler and an IF library of code.
> 2) Compiled .NET programs are not native code they are complied to
> MSIL the CLR then takes over using JITcompliers (amongst other things)
> to produce native Code.
Yes.
> 3) What version of .Net do you have ? As I don't understand why the
> users need to have VS.NET for licensing issues when the .NET Framework
> and SDK is free to download and programs can be complied into MSIL
> using command line compilers on a source file written using a plain
> text editor.
They don't and whether an implementation of the IF# compiler for VS.NET
would ever be created is a project that can be thought of _after_ IF# is
created.
> 4) Even though you do, not every one likes .NET or Microsoft. Some
> people do think it's typical microsoft bloat ware.
Those people haven't used it. I can guarantee that anyone worth their salt
as a developer could not discount .NET on technical merits. They may have
political or relgious reasons for discounting .NET and Microsoft, but
technically, .NET is all that and more.
> 5) The .NET Framework and SDK is not small.
It comes built into Windows XP and all future versions of Windows. Who cares
anyway. With broadband and wireless growing the way it is, this is peanuts.
> 6) VS.NET with the MSDN documentation is even bigger taking up well
> over a 1 GIG of HD space. Where currently the major IF systems use no
> more than 10mb
See answer #5.
> 7) IF Authors will also need to learn a .NET language then learn how
> to program your controls. Considering the amount of non windows users
> and IF beginners how many people do you think will do that ?
If we create something that is an effective IF development tool and makes
the authoring process easier, people will use it. If we do not do that,
people won't. I'm willing to put the effort in to do this because I believe
in what I'm tring to create.
> 8) I have not seen much call for commercial IF programs, in fact a lot
> of people think IF is dead and are surprised when I tell them there is
> an IF community and people actively writing new games. Even armed with
> this knowledge, they still have no interest in IF.
One can dream, but we can also try to bring the tools into the mainstream of
"business" development. With something like IF#, it would be much easier to
put into a business plan the ability to create IF stories in an efficient,
testable, debuggable toolset that uses a mainstream runtime. This is not to
knock the abilities of something like Hugo or TADS 3, because those are
viable toolsets themselves, but it's my belief that adding their
functionality to the ability to be extensible into the .NET Framework is a
much needed additional feature.
> Please understand I do think it's a bold and interesting project, I am
> trying to put your project in perspective of the modern IF user and
> also make you realize you may be doing all this for little return.
>
I suspect that opinion is shared by others as well. It is not mine and I
know there are supporters of my efforts. So far, it seems you have to turn
the lights out to find them.
Dave
Harry
cornelson at iflibrary.com> made the world a better place by saying:
>
>One can dream, but we can also try to bring the tools into the mainstream of
>"business" development. With something like IF#, it would be much easier to
>put into a business plan the ability to create IF stories in an efficient,
>testable, debuggable toolset that uses a mainstream runtime. This is not to
>knock the abilities of something like Hugo or TADS 3, because those are
>viable toolsets themselves, but it's my belief that adding their
>functionality to the ability to be extensible into the .NET Framework is a
>much needed additional feature.
The more I think about it, the more you make sense.
First: it is rather amusing that working on a dev system that will run
on the worlds most successful desktop operating system (=most widely
used) is by some considered a rebellious act in this circle of people
who work on a genre that hasn't had a commercial success since the
first Bush was president.
Second: building on the .NET paradigm will make IF at least a little
bit more credible to 'mainstream' publishers. They haven't heard of
Graham Nelson. They have heard of Bill Gates.
I'm looking forward to seeing something of IF# in action, rather then
'just' the discussion about its developments. I keep my fingers
crossed that you keep at it.
Harry
-------------------------------------
"Nostalgia isn't what it used to be."
http://www.haha.demon.nl
(To send e-mail, remove SPAMBLOCK from address)
Alex Warren
> "SimonW" <boz...@lycos.co.uk> wrote in message
> news:njlikv0imavd5q7qc...@4ax.com...
> > 5) The .NET Framework and SDK is not small.
>
> It comes built into Windows XP and all future versions of Windows. Who cares
> anyway. With broadband and wireless growing the way it is, this is peanuts.
It's not actually built into Windows XP - not even SP1, which seems a bit of an
oversight by Microsoft really. I haven't bothered downloading it yet because I
don't have any apps that need it, but this will surely change over time. So
perhaps by the time IF# is ready the need for a few people to download the .NET
framework won't be so much of an issue.
Boluc Papuccuoglu
cornelson at iflibrary.com> wrote:
[snip]
>Cross-platform is not really the major concern since 90% of the desktops out
>there are Windows. I know this isn't a popular sentiment in the IF
>community, but it's mine. I'm a Windows guy. I like Windows. I have Linux on
[snip]
Well, actually cross platform is NOT a problem if you can get
MultiPlayer (or even Single Player) IF# to run on an Windows server
and accept connections from *nix/Mac/Handheld clients. So,
end-userwise you won't have any problems. And I doubt that restricting
servers to Windows family is too big a problem.
BTW, I am at the moment writing a Z-Machine Interpreter that will run
as an ActiveX .DLL extension. The DLL loads and runs Z-Code, and
raises events for output and accepts input through function calls.
Using this DLL, an application programmer will be able to make any
end-user IF interface he wants, running Z-Code with it. Of course,
since ActiveX is on the way out, I would love to instead build a .NET
managed extension.
Mike Robinson
> On Sun, 24 Aug 2003 08:38:55 -0500, "David A. Cornelson" <david dot
> cornelson at iflibrary.com> wrote:
> [snip]
>>Cross-platform is not really the major concern since 90% of the desktops out
>>there are Windows. I know this isn't a popular sentiment in the IF
>>community, but it's mine. I'm a Windows guy. I like Windows. I have Linux on
>
> [snip]
>
> Well, actually cross platform is NOT a problem if you can get
> MultiPlayer (or even Single Player) IF# to run on an Windows server
> and accept connections from *nix/Mac/Handheld clients. So,
> end-userwise you won't have any problems.
Yeah, because all handhelds have a permanent wireless link to a Windows
server.
Boluc Papuccuoglu
Well, if your handheld does not have _some_ net connection, then not
being able to play Multiplayer IF is not a problem for you.
Adam Thornton
Andy Leighton <an...@azaal.plus.com> wrote:
>On Sat, 23 Aug 2003 17:17:04 -0500, David A. Cornelson <> wrote:
>> I want to implement multi-player IF and I want to see an IF platform built
>> from the ground up with this in mind. The plumbing for MPIF is not as easy
>> as it looks.
>I think that this is something everyone can agree on. As someone who has
>in the distant past worked on a puzzle based MUD (the closest thing to MPIF
>I can think of) - the core for MPIF is more difficult than just for single
>player IF.
So, crucially, is the game design.
I actually got a fair amount done on a runtime world-model for an MMORPG
back in 1998. Yes, it's much more complicated than designing a
single-player world-model (because the scaffolding has to be hidden from
everyone simultaneously, and events actually have to be consistent, not
just look consistent), and it basically demands an underlying database
with transactional integrity, but it's certainly a soluble problem.
The thing that isn't is the multi-player part. I don't understand how
MPIF doesn't turn into one of two things almost immediately: one, a
glorified chat room, or two, an MMORPG. Combinatorial explosion means
that there's no way to cope with a narrativist approach to the story, so
what you're left with is the simulationist approach, which ends up
smelling like an RPG.
Please, someone, tell me that I'm wrong, and show me what MPIF--as
distinct from an RPG--really is.
Adam
Adam Thornton
Boluc Papuccuoglu <bolucPERIOD...@REMOVETHISaknet.com.tr> wrote:
>And I doubt that restricting servers to Windows family is too big a
>problem.
Unless you're looking for stability or reliability, that is.
Oh, dear. Me and my big mouth.
Adam
Adam Thornton
Nikos Chantziaras
> [...]
> BTW, I am at the moment writing a Z-Machine Interpreter that will run
> as an ActiveX .DLL extension. The DLL loads and runs Z-Code, and
> raises events for output and accepts input through function calls.
> Using this DLL, an application programmer will be able to make any
> end-user IF interface he wants, running Z-Code with it. Of course,
> since ActiveX is on the way out, I would love to instead build a .NET
> managed extension.
Why ActiveX? Or dotNET? A normal DLL not good enough? When being
non-portable, you create a wall that will crash against your own face after
a while.
--
Niko <realnc--(AT)--lycos--(DOT)--de>
http://members.lycos.co.uk/realnc
Nikos Chantziaras
>
> Andy Leighton wrote:
> >
> > Personally I find it much nicer to write code on a *nix system than
> > on a Windows machine - but I accept it is one of those YMMV
> > issues. It is just that IF is such a small market that to further
> > restrict your options seems a little short-sighted. But if you are
> > happy with that then that's your lookout.
>
> Well here is where I differentiate myself from the community and
> probably in a strong way. I don't believe developing the system in
> order to write games for only the IF community is a very wise
> decision. I think building a platform for games that can be played on
> 90% of the desktops out there is very wise.
How does portability prevent that? Being portable is not hard. You just
must get used to it.
> I don't want to write just for this community. I want to build games
> for _everyone_. With that in mind, the best way to accomplish that
> isn't to be cross-platform, but to be at least on the most widely
> available platform.
I don't see the point. You say "for _everyone_". The first thing that
comes to mind when reading that, is the word "portability". Inform is
portable, Tads is portable, Hugo is portable. I don't think that the
popularity of "the 3 big systems" hasn't at least *something* to do with
their portability.
> Some say a monopoly is a bad thing. I think single vendor solutions
> make me more productive
Like a droid. (He, he... Ahem... ;-)
> and make building for the largest audience possible quite a bit
> easier than being cross-platform.
Not really. Personally, I can't use the "easy" systems because I don't find
them that easy. Why? I'm not familiar with them. As I said before, it's
what you're used to.
> I personally believe that IF# would open up many commercial avenues
> for IF.
Because it isn't portable? A somewhat bogus point of view.
PS:
I don't hate Windows. I just find it lacks basic tools.
OK, maybe I hate it somewhat. Just a tiny little bit though. Really.
[spoiler space]
.
.
.
.
.
.
.
*OK, SCREW WINDOWS!*
Dan Blum
I don't think you're wrong, based on my experience in MUSH use. I spent
a fair amount of time on a popular MUSH, which had a lot of well-coded
areas and objects. However, the few areas in which people attempted to
add narrative constructs tended not to work well. The best areas were
basically scenery, with toys - often really cool toys that you could use
to fly around the landscape, take pictures, have paintball fights, etc.,
but it was all basically simulationist.
One of the wizards of said MUSH really wanted people to develop more
puzzle-based, narratively-oriented areas, and had a little contest
once to encourage this. I thought about entering, but after spending
some time trying to design a robust infrastructure for such a thing,
I gave up. (I had some near-workable ideas for how to give a player
their own personal environment to play in, but while that would have
worked fine for a small adventure inside a huge MUSH, it's hardly
MPIF. Also the thought of doing that much MUSH coding did not appeal...
MUSH coding in general makes me want to poke hot knitting needles
in my eyes.) I don't think anyone else produced anything much, either.
The one workable piece of the whole MUSH that carried off a narrative
at all was a simple CYOA thing, which is pretty easy to do (no room
states, no objects, etc.) - but why bother?
--
_______________________________________________________________________
Dan Blum to...@panix.com
"I wouldn't have believed it myself if I hadn't just made it up."
Kevin Forchione
news:bidiqu$n75$4...@news.fsf.net...
> I actually got a fair amount done on a runtime world-model for an MMORPG
> back in 1998. Yes, it's much more complicated than designing a
> single-player world-model (because the scaffolding has to be hidden from
> everyone simultaneously, and events actually have to be consistent, not
> just look consistent), and it basically demands an underlying database
> with transactional integrity, but it's certainly a soluble problem.
>
> The thing that isn't is the multi-player part. I don't understand how
> MPIF doesn't turn into one of two things almost immediately: one, a
> glorified chat room, or two, an MMORPG. Combinatorial explosion means
> that there's no way to cope with a narrativist approach to the story, so
> what you're left with is the simulationist approach, which ends up
> smelling like an RPG.
>
> Please, someone, tell me that I'm wrong, and show me what MPIF--as
> distinct from an RPG--really is.
These are astute observations. I've been asking the same thing myself.
--Kevin
David Thornley
Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>
>The more I think about it, the more you make sense.
>
>First: it is rather amusing that working on a dev system that will run
>on the worlds most successful desktop operating system (=most widely
>used) is by some considered a rebellious act in this circle of people
>who work on a genre that hasn't had a commercial success since the
>first Bush was president.
>
>Second: building on the .NET paradigm will make IF at least a little
>bit more credible to 'mainstream' publishers. They haven't heard of
>Graham Nelson. They have heard of Bill Gates.
>
credibility to a genre that hasn't had a commercial success since
George II? Isn't this a bit like putting parsley on a plate with
sawdust and gravy?
Not to mention that some of the more promising commercial ventures
have involved IF on platforms that aren't going to support .NET
any time soon.
David A. Cornelson
>
> Please, someone, tell me that I'm wrong, and show me what MPIF--as
> distinct from an RPG--really is.
>
Stop by for a beer sometime and we'll discuss it....or stop by the wiki
often enough to see what I'm up to....but truthfully, we won't know if my
vision is successful or not until it is implemented.
I wrote some today. I will write more later in the week.
Dave
Boluc Papuccuoglu
<for....@manager.de> wrote:
>Boluc Papuccuoglu wrote:
>> [...]
>> BTW, I am at the moment writing a Z-Machine Interpreter that will run
>> as an ActiveX .DLL extension. The DLL loads and runs Z-Code, and
>> raises events for output and accepts input through function calls.
>> Using this DLL, an application programmer will be able to make any
>> end-user IF interface he wants, running Z-Code with it. Of course,
>> since ActiveX is on the way out, I would love to instead build a .NET
>> managed extension.
>
>Why ActiveX? Or dotNET? A normal DLL not good enough? When being
>non-portable, you create a wall that will crash against your own face after
>a while.
Good question. In a nutshell I want to create a component that another
programmer can use in Visual C++, Visual Basic or in an ASP page
without too much hassle to run Z-Code with a simple snippet such as:
Public Function StartGame(StoryFileName as String)
Dim ZM as New ZMachine
ZM.LoadStory(StoryFileName)
ZM.Runstory
End Function
With a plain DLL that would be too complicated to do in VB and
impossible in ASP. If you have any suggestions as to achieve that goal
in a more portable way, I am all ears, tho.
Harry
the world a better place by saying:
>In article <4nljkvgg0puf8nu7v...@4ax.com>,
>Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>>
>>The more I think about it, the more you make sense.
>>
>>First: it is rather amusing that working on a dev system that will run
>>on the worlds most successful desktop operating system (=most widely
>>used) is by some considered a rebellious act in this circle of people
>>who work on a genre that hasn't had a commercial success since the
>>first Bush was president.
>>
>>Second: building on the .NET paradigm will make IF at least a little
>>bit more credible to 'mainstream' publishers. They haven't heard of
>>Graham Nelson. They have heard of Bill Gates.
>>
>So, exactly how does it make sense to try to add a little mainstream
>credibility to a genre that hasn't had a commercial success since
>George II? Isn't this a bit like putting parsley on a plate with
>sawdust and gravy?
>
>Not to mention that some of the more promising commercial ventures
>have involved IF on platforms that aren't going to support .NET
>any time soon.
I think (and I have not a shred of proof to back this theory up) that
a company that hears the .NET name will be more likely to listen a bit
more than when he hears the names TADS, Hugo or Inform. I believe that
publishers are worried about an install-base (=potential sales), which
also explains why so few games are made for Linux and MacOS.
Just .NET or IF# by itself won't do anything for the credibility of
IF, but I think building a dev system based on the most widely used
gaming OS is at least a step towards a more mainstream approach to
making IF.
But this is all theory. What I was basically saying is that I find the
IF# idea interesting and that I hope he will stick to it. Nothing
more, nothing less.
Now for your parsley garnished question: It makes perfect sense if
someone *wants* to have a commercial success with IF. I'm still not
convinced this is possible, but if someone wants to try, he needs all
the credibility he can get.
Gene Wirchenko
Beautiful. AHBOUed!
Might that be supported in ascii E-mail?
ascii
\As"ci*i\, Ascians \As"cians\, n. pl. [L. ascii, pl. of ascius, Gr. ?
without shadow; 'a priv. + ? shadow.] Persons who, at certain times of
the year, have no shadow at noon; -- applied to the inhabitants of the
torrid zone, who have, twice a year, a vertical sun.
Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA,
Inc.
Though not in the usual way, grues qualify.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Adam Thornton
Gene Wirchenko <ge...@mail.ocis.net> wrote:
Wot, again? (The succubus thing apparently got AHBOUed too.)
> Might that be supported in ascii E-mail?
>ascii
>\As"ci*i\, Ascians \As"cians\, n. pl. [L. ascii, pl. of ascius, Gr. ?
>without shadow; 'a priv. + ? shadow.] Persons who, at certain times of
>the year, have no shadow at noon; -- applied to the inhabitants of the
>torrid zone, who have, twice a year, a vertical sun.
You know, you share a first name with the only other person I've ever
known to use the word Ascians.
> Though not in the usual way, grues qualify.
They most certainly do.
Adam
David Thornley
Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>
>Just .NET or IF# by itself won't do anything for the credibility of
>IF, but I think building a dev system based on the most widely used
>gaming OS is at least a step towards a more mainstream approach to
>making IF.
>
with a similar lack of evidence to back it up), but one of the
potential attractions of IF is that it will run on systems with
rather minimal I/O facilities, such as PDAs. I don't think that
.NET-based solutions would ever run on Palms.
>Now for your parsley garnished question: It makes perfect sense if
>someone *wants* to have a commercial success with IF. I'm still not
>convinced this is possible, but if someone wants to try, he needs all
>the credibility he can get.
>
I don't think credibility is the issue here. It's going to take more
ingenuity than credibility.
Shadow Wolf
> In article <3f4b23c...@news.ocis.net>,
> Gene Wirchenko <ge...@mail.ocis.net> wrote:
>>ad...@fsf.net (Adam Thornton) wrote:
>>>The grues support you in email?
>> Beautiful. AHBOUed!
>
> Wot, again? (The succubus thing apparently got AHBOUed too.)
I just submitted your response to that line about kicking dead whales down
the beach. You've been on a roll, recently!
--
Shadow Wolf
shadow_wolf1 at hotpop dot com
Stories at http://www.asstr.org/~Shadow_Wolf
AIF at http://www.geocities.com/shadowolf3400
Harry
the world a better place by saying:
>In article <403mkvkufssj8p4q6...@4ax.com>,
>Harry <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>>
>>Just .NET or IF# by itself won't do anything for the credibility of
>>IF, but I think building a dev system based on the most widely used
>>gaming OS is at least a step towards a more mainstream approach to
>>making IF.
>>
>Perhaps for desktop sales (I disagree with some of your beliefs,
>with a similar lack of evidence to back it up), but one of the
>potential attractions of IF is that it will run on systems with
>rather minimal I/O facilities, such as PDAs. I don't think that
>.NET-based solutions would ever run on Palms.
>
I agree. The future of IF is in PDA's, not the desktop. But if the
desktop is your aim, .NET sounds like a good way to do it.
>>Now for your parsley garnished question: It makes perfect sense if
>>someone *wants* to have a commercial success with IF. I'm still not
>>convinced this is possible, but if someone wants to try, he needs all
>>the credibility he can get.
>>
>I don't think credibility is the issue here. It's going to take more
>ingenuity than credibility.
You have to convince people of IF's potential. You need ingenuity to
fake the credibility that will convince a publisher to take a risk on
IF.
Jeff Mitchell
> Of course I want to create IF#, a new language syntax that will compile to
> MSIL (to .NET), but this would only be because through discussions, it has
> become clear that IF objects are not the same as general programming
> objects. An IF specific syntax is more or less required as a sort of
> short-cut to building an IF world.
A caution here; make sure you don't lose sight of your audience.
Most IF game developers are not programmers; An IF story syntax is
necessarily different than a general programming language, for both
types of languages aim for very different things; an IF language need
not be general purpose, and it needn't concern itself with things like
resource constraints on the same level a general programming language
should. An IF syntax needs to be accessible to non developers, or you've
cut your already small pool of game developers to 1/10th its size.
(This is of course why the interpreter and the compiler are very different
in todays systems.. the compiler translate a simple or complex lanbguage
into a runtime in black-box format; the interpretere can be as complex as
it needs to be).
PErhaps all you need is an emitter module for Inform, TADS,
Hugo, etc, that spits out what you need for your MSIL interpreter; perhaps
those guys can be finagled to have an extension language, just like
embedded SQL (for example) works now.
In this way you leverage an existing (proven) well known language
and yet add the ability to extend through native methods.
What you're proposing is a new language (languages are hard to
design) that sounds like its an extension of C#, and thus you limit your
audience to programmers, and limit your platform to C#. If your frontend
language is Inform or somethign if your own design, then your backend
can be C# or even something else. *shrug*.
ie: An embedded example could be:
// inform code
// inform code
embed-C#:
// C# code
embed-C3 done;
// inform code
It needn't be inform it coudl be somethign else.
Anyway, I've not thought about this at all, but just do not
forget who your writing for.. creating tools means creating them for
non-techies :)
> Now the other thread was just an afterthought, although if all of these
> other things come true, it would be inevitable that a Visual Studio .NET
> implementation of IF# would take place.
I would focus on .net as a spec; avoid assumoing a toolset
entirely, as since Mono is both open and free and cross platform, that
would be your preferred platform.
> After reviewing the licensing, it's clear that the only way to distribute
> this potential tool would be to people that already owned VS.NET, which is a
> minimum of $100 USD. In order to have a distribution license, you need to
> pay $10,000/year. Oh well, it was a nice thought. But maybe they'll change
> their mind for what will essentially be a free and open source platform.
You know Microsoft better than that ;) While it is entirely
possible they may change the license to try and kill java, you cannot
assume it; it would be foolish to embark on a massive project, based on
hope alone. Assume Mono.
> Now after all of this is implemented, what can be done with it? That's the
> last goal. I think with a platform like this and with the number of OS's out
> there with .NET built-in, it's perfectly ligitimate to believe that some
> higher end IF could be developed and sold in less time and with greater
> agility than is currently possible.
There is one OS with .net built in ;) (Win XP?) Other versions of
Windows do not have .net built in, and they're not really "other OSes" :)
You should be thinking from the end first; the goal is to make
something useful; figure out what you want to do *first* and work
backwards. Unless the project is a programming exercise (in which your
goal is to have coding fun), and instead is to produce a tool for
everyone, then you must work in terms of the target.. what Plauger
woudl say is Right to Left.. Output Oriented Software :)
> And with GDI+ and DirectX, even more sophisticated visual IF could be
> developed.
Mmm, big vision; keep it up! Rising complexity limits the
audience of developers even more, though, but it would be very cool to
create a pool of reusable 3d objects and behaviour, for instance. I
suggest you look also into MUDs and such, which have been goign through
this thought process doe decades.. how to share complex objects and
such. But I doubt there is anythign out there yet to help less technical
folks create highly technical things.. but that must be a new thrust
over the next decade.
> It's all hot air at the moment. There are people interested in the concept,
> but not enough cross-breeding happens between the Microsoft development
> world and the IF community. But I like focusing on this as opposed to other
> things. I just seem to be more interested in the tools than the games for
> the time being, even though I have 80 games in my head that need to be
> written.
*g*
> And after using .NET for the last 2 years, using Inform is painful. And
Thats an odd statement; .net is a language, Inform is a language.
Some languages are suited to some tasks, but no language is suited to all.
Inform is not meant to be a File Dialog, just like .net is not made to be
a text parser :) A hammer is an odd thing to build a cake with, too ;)
.net with your IF# on it would be pretyt swank, but right now
C# is as useless as the hammer, so you can't go comparing Inform to it ;)
You must keep your thoguhts clear lest you walk down the wrong path with your
project.
> So there you go. That should explain everything.
Keep it up; you're on to something.
jeff
--
--
"Have you played Atari today?"
Rexx Magnus
> A caution here; make sure you don't lose sight of your audience.
> Most IF game developers are not programmers;
I thought that old chestnut had been ground to dust only recently? The
only IF authors that are not expected to indulge in any kind of
programming are those who write 'choose your own adventure' books.
--
UO & AC Herbal - http://www.rexx.co.uk/herbal
To email me, visit the site.
Jeff Mitchell
> Well I'm kind of in over my head in _several_ areas of IF software
> development. Here's a run down of my thoughts:
If you're opening to a wider group thann just the IF group
(of this newsgroup), and trying to (say) open a commercial option,
and aiming for strong graphics and such.. then really, are you not
just using "IF" to mean "English parser" and "some cool libraries"?
You could really just be trying to come up with a framework
that assists making a certain type of game; ie: Its not going to help
make a new FPS shooter like Quake.. theres already dozens of frameworks
(free and otherwise) for that.
So your particular target is (correct me?) a IF-like system,
where IF means some interaction using text, and output via text, audio,
static and animated asrtwork in 2d and 3d. .net, C, C+, java, python, perl
etc can all do all of these things (with lisp and perl being very good
at the parsing).
So your proposal is really a value add to what we already
have, and your choice is to limit it to .net.
It would almost seem you need to define an API for natural
language parsing (several MUDs and IF engines have this); a regular
and no nonsense API well documented woudl be cool. Also, some sprite libs
and 3d libs.. well, you've got SDL for 2d already, and I'm sure theres 3d.
So at a gut.. perhaps you need to focus on making some cool
libraries for .net and be done at that; or perhaps not make them .net
dependant unless you justy wish to flex your .net muscles.. you could
make them in portable C using wxWindows or GTK or SDL or etc etc, with
.net bindings (and also Python bindings, C bindings, etc).. and thus
make your framework more portable then you imagine, and thus the
end porter could create simple languages (for non techies) or complex
ones like C# itself for tecchies.
Theres definately somethign here, but I'm convinced you need
to define it.
Or, if you just want to get to it, feel free.. it'll be a fun
project, whbere the project is defined in your head.
David A. Cornelson
news:86pti6o...@fw.skeleton.org...
>
> A caution here; make sure you don't lose sight of your audience.
I am my audience, for now. I firmly believe that if I create IF#, the
associated libraries, and the WinForms controls, that it will be used by
people interested in IF that also like .NET.
> PErhaps all you need is an emitter module for Inform, TADS,
> Hugo, etc, that spits out what you need for your MSIL interpreter; perhaps
> those guys can be finagled to have an extension language, just like
> embedded SQL (for example) works now.
One of the goals of IF# is to open up the type of play....currently, all of
the IF platforms are hard-coded as single player models. The VM's were
_designed_ this way.
> What you're proposing is a new language (languages are hard to
> design) that sounds like its an extension of C#, and thus you limit your
> audience to programmers, and limit your platform to C#. If your frontend
> language is Inform or somethign if your own design, then your backend
> can be C# or even something else. *shrug*.
It's not an extension of C#. It will be its own syntax. It will have some
things in common with all C-like languages, like curly braces, but it will
be its own thing.
> There is one OS with .net built in ;) (Win XP?) Other versions of
> Windows do not have .net built in, and they're not really "other OSes" :)
Windows is enough for me, but Mono+Linux/OSX would be nice too.
> I suggest you look also into MUDs and such
I have - it's not the direction I want to go...I think muds are a different
thing entirely.
> > And after using .NET for the last 2 years, using Inform is painful. And
>
> Thats an odd statement; .net is a language, Inform is a language.
Not at all. IF I build a .NET compatible language, then any other components
built in .NET are usable from my system and vice-versa.
Dave
Jeff Mitchell
> On Fri, 12 Sep 2003 15:22:01 GMT, Jeff Mitchell scrawled:
>
> > A caution here; make sure you don't lose sight of your audience.
> > Most IF game developers are not programmers;
>
> I thought that old chestnut had been ground to dust only recently? The
> only IF authors that are not expected to indulge in any kind of
> programming are those who write 'choose your own adventure' books.
Inform coding is certainly programming, but its not so much
programming as writing C code .. its more accessible (at a guess, as
I'm not much of an Inform coder I must admit). Pointers, managing memory,
cross platform cosndierations.. these are serious implementation details
shielded by the traditional VMs and languages.
So while I would refer to Inform game developers as doing
some programming work, it is not the same level as what we commonyl refer
to as Programming. From my experience, IF authors tend to the technical
side, but are from a wide range of backgrounds, many not being hard tecchies.
This proposal if it was more .net language like would be much
less accessible to the IF developer crowd.. they're used to coding for sure,
but not that serious coding.. they woudl rather spend their time building
the game, than managing memory.
However, if the project is about creating a new language, than
if the language is designed well for this target audience, my question isn't
relevent.. but my point is good -- the target audience must be very well
defined, and must never be forgotten in the early design phase.
David A. Cornelson
>
> This proposal if it was more .net language like would be much
> less accessible to the IF developer crowd.. they're used to coding for
sure,
> but not that serious coding.. they woudl rather spend their time building
> the game, than managing memory.
>
> However, if the project is about creating a new language, than
> if the language is designed well for this target audience, my question
isn't
> relevent.. but my point is good -- the target audience must be very well
> defined, and must never be forgotten in the early design phase.
>
I think your second thought there is more accurate. Even though this is a
syntax that will compile to .NET, the syntax will be an IF specific syntax.
The Emitter will be doing more work than a normal .NET compiler because I
will be constructing IF objects into "normal" object and then compiling
them. To the author, this will be seemless and they shouldn't care.
Dave
Jeff Mitchell
> I think your second thought there is more accurate. Even though this is a
> syntax that will compile to .NET, the syntax will be an IF specific syntax.
> The Emitter will be doing more work than a normal .NET compiler because I
> will be constructing IF objects into "normal" object and then compiling
> them. To the author, this will be seemless and they shouldn't care.
So have you broken it down into things yet, so you can determine
what you need?
ie: You're not targetting pure IF folks, and you do want
mtuliplayer, so learning from MUDs and MMORPGs and such is a given..
and I think much of what you need is already being worked on, for
creating game frameworks is as old as the hills :) (example:
You know you need a 3d model editor and rendering system if you want 3d
support, and you know you need 2d rendering (since 2d editting is easy),
and you'll need spline and path management for moving things around, and
you'll need the language defined and turned into a grammar, a parser,
compiler and emitter; you'llneed daemons to handle connections and
authentication (even if pass through at first), handle session detail
maintenance and load/save, etc etc. Lots to do to create a framework.
Its almost like you just want to create somethign that already
exists, but in .net; ie: Theres Dark Basic, a BASIC language for
building 2d and 3d games, and it comes with all the whistles. You could
add a natural language parser, and you're pretty much already done..
though I dunno if they have a .net emitter.
This is why I suspect your project is really just a .net
and natural language refinement of existing projects.. you could
build onto somethign else to save a lot of work, or get a fast
prototype out to experiment with. Really, your addition is the
idea of a natural language parser .. everything else is out there.
(ie: SDL, Worldforge, Quake type renders.. all abound in many forms
for many languages)
You definately need to look into MUDs; like LPC muds.. its
a C-liek language for defining multiplayer games, much like Inform is
a language and compiler for single player games. LPC is very flexible
and offers natural language parsing, and produced a wide assortmewnt
of MUDS.. some even single player.
Theres also the various scheme and lisp derived muds and
MUSHes. Really a MUD is directly descended from IF (from Advent and
Zork and such, really), so they're an excellent source of study.. there
is much material, thesis, essays about MUDs, game design, etc.
Little of this is "new" per se; your particular addition is a
big piece of work -- designing a language to be useful for the target
audiance won't be easy. The rest you can swipe ideas from existing
stuff I suspect :)
It woudl be pretty fun to add a natural language parser even
to something like Neverwinter Nights; I wonder if that is possible..
already a solid and proven platform, popular, and available on Linux,
Windows and Mac :)
David A. Cornelson
> "David A. Cornelson" <david dot cornelson at iflibrary.com> writes:
>
> > I think your second thought there is more accurate. Even though this is
a
> > syntax that will compile to .NET, the syntax will be an IF specific
syntax.
> > The Emitter will be doing more work than a normal .NET compiler because
I
> > will be constructing IF objects into "normal" object and then compiling
> > them. To the author, this will be seemless and they shouldn't care.
>
> So have you broken it down into things yet, so you can determine
> what you need?
>
> ie: You're not targetting pure IF folks, and you do want
> mtuliplayer, so learning from MUDs and MMORPGs and such is a given..
As I've said, I've looked at muds and they multi-playerness of a mud does
not coincide with my view of multi-playerness. In fact, it's completely
different and not re-usable in any fashion.
> and I think much of what you need is already being worked on, for
> creating game frameworks is as old as the hills :) (example:
> You know you need a 3d model editor and rendering system if you want 3d
> support, and you know you need 2d rendering (since 2d editting is easy),
> and you'll need spline and path management for moving things around, and
> you'll need the language defined and turned into a grammar, a parser,
> compiler and emitter; you'llneed daemons to handle connections and
> authentication (even if pass through at first), handle session detail
> maintenance and load/save, etc etc. Lots to do to create a framework.
I don't plan any of graphical stuff....but using .NET, those things could be
implemented. My primary focus is on a new syntax to write traditional IF.
Then changing that syntax to also allow for multiple clients and a single
game server. The compiler will have some forking since some games will be
single executables and others will be a client and a server executable...and
still others may be an interpreter that uses an assembly game file that we
set standards on somehow.
> Its almost like you just want to create somethign that already
> exists, but in .net; ie: Theres Dark Basic, a BASIC language for
> building 2d and 3d games, and it comes with all the whistles. You could
> add a natural language parser, and you're pretty much already done..
> though I dunno if they have a .net emitter.
Nothing IF related exists in .NET and I'm not interested in re-using
non-.NET code to build IF#.
> You definately need to look into MUDs; like LPC muds.. its
> a C-liek language for defining multiplayer games, much like Inform is
> a language and compiler for single player games. LPC is very flexible
> and offers natural language parsing, and produced a wide assortmewnt
> of MUDS.. some even single player.
>
> Theres also the various scheme and lisp derived muds and
> MUSHes. Really a MUD is directly descended from IF (from Advent and
> Zork and such, really), so they're an excellent source of study.. there
> is much material, thesis, essays about MUDs, game design, etc.
A mud to me is more like a chatting environment and not a tightly authored
Interactive Fiction environment. In my view of MPIF, the author controls how
each player (PC) can interact....there is no free-form talking with each
other, unless allowed for by the author. But each player would have to enter
something, their text gets parsed, and an authored response is displayed.
[In Holmes client window]
> TELL SHERLOCK ABOUT MAGIC FEATHER
You cough and tell holmes about your senior year at college when you found a
feather with very unusual properties.
[In Sherlock client window]
Holmes coughs and says, "My dear Holmes. I think I need to confess about a
certain magical feather I once had in my possession. It was a long time
ago..."
Now you may be able to accomplish this in a mud, but mud's don't offer the
type of authoring I want. IF authors don't want to learn the c-like mud
languages of muds. They're much more like general programming. IF authors
want lower hanging fruit and that's what I want to deliver in IF# along with
the ability to create MPIF as shown above.
So I have three major projects:
1. Language and Compiler
2. IF Library
a. parser
b. entry routines
c. grammar
d. base routines for grammar
e. other routines like Save/Restore (NOTE: Save will likely be a simple
Deserialization of the game
assembly at runtime. Restore would simply reload/Serialize back into
memory.
3. Client/Server Architecture or (I/O layer)
Dave
Alex Warren
> In my view of MPIF, the author controls how
> each player (PC) can interact....there is no free-form talking with each
> other, unless allowed for by the author. But each player would have to enter
> something, their text gets parsed, and an authored response is displayed.
>
> [In Holmes client window]
> > TELL SHERLOCK ABOUT MAGIC FEATHER
> You cough and tell holmes about your senior year at college when you found a
> feather with very unusual properties.
>
> [In Sherlock client window]
> Holmes coughs and says, "My dear Holmes. I think I need to confess about a
> certain magical feather I once had in my possession. It was a long time
> ago..."
Have you (or anybody else for that matter) looked at QuestNet? Here's the most
primitive way of coding the above (I say primitive as ideally you would code a
more general "tell" command, but this is the gist at least):
When the player connects we set the "sherlock" and "watson" variables to the
player name, allowing them to choose or perhaps allocating it to a specific
login (I see the two characters in your example are actually confusingly called
Sherlock and Holmes, and Holmes appears to be talking to himself, unless you had
some kind of schizophrenic MPIF in mind where everybody is the same person, but
let's not complicate things :) )
So, #sherlock# might be "player1" and #watson# might be "player2". Then the code
for the command itself could be:
command <tell sherlock about magic feather> {
' This command only works if you're Watson
if ( #watson# = player%userid% ) then {
' This appears on Watson's screen:
msg <You cough and tell Sherlock about ... >
' This appears on Sherlock's screen:
msgto <#sherlock#; Holmes coughs and says "My dear Sherlock...>
}
else {
' If the player isn't Watson then this command is not applicable
msg <You can't do that here.>
}
}
Alex
--
alex at axeuk, and add .com for email address.
Make adventure games easily with Quest - http://www.axeuk.com/quest/
Analyse web site log files for free with Xlogan - http://www.xlogan.com/
Alex Warren
The schizophrenia (<g>) of the example confused me - following my notation where
we have "Sherlock" and "Watson", this:
' This appears on Sherlock's screen:
msgto <#sherlock#; Holmes coughs and says "My dear Sherlock...>
should of course read
' This appears on Sherlock's screen:
msgto <#sherlock#; Watson coughs and says "My dear Sherlock...>
David A. Cornelson
I have downloaded and installed Quest a couple of times. I respect the
amount of effort put into the system and I believe it's a viable platform
for non-traditional and mid-level IF games. However, it is my opinion that
Quest does not meet what I would call "professional" level Interactive
Fiction authoring capabilities.
I believe that only TADS (1, 2, & 3), Hugo, and Inform, Glulx-Inform meet my
criteria.
I intend to develop IF# so that it compares to those systems. I also plan to
use .NET so that extensions can be written easily and these extensions can
use the .NET Framework to do things with databases, xml, graphics, and http
programming.
I appreciate that this comment may frustrate you, and so I will say that
this is only my opinion and I have no idea how Quest is viewed within the
community.
It might be possible to raise the awareness of Quest if some more popular
games were ported to it, such as Dungeon or Adventure since these are often
noted as using almost the entire functionality of a given IF platform and
demonstrate its power and flexibility.
It would also raise awareness if a well-written and highly replayable game
were available for the Quest runtime.
It might also raise the awareness of Quest if games were entered into the IF
Comp (or even some of the mini-comps) that were well written and well coded
and had noticable value within.
For now, I'm determined to build IF# my way.
The mention of other systems, other programming languages, open source,
cross-platform, muds, and everything else that's been proposed are, although
appreciated, probably beside the point.
Comments about language design, compiler theory, natural language parsing,
and .NET are more to the point.
Thanks,
Dave
Jeff Mitchell
> As I've said, I've looked at muds and they multi-playerness of a mud does
> not coincide with my view of multi-playerness. In fact, it's completely
> different and not re-usable in any fashion.
Its something you can learn from; MUDs are well documented, there
lots of thesis and studies, etc. Even if you don't look at MUDS per se,
you should look into MUD and MMORPG communities to poach ideas. ie: You
shouldn't narrow your vision to discount what others have learnt.
> > Theres also the various scheme and lisp derived muds and
> > MUSHes. Really a MUD is directly descended from IF (from Advent and
> > Zork and such, really), so they're an excellent source of study.. there
> > is much material, thesis, essays about MUDs, game design, etc.
>
> A mud to me is more like a chatting environment and not a tightly authored
> Interactive Fiction environment. In my view of MPIF, the author controls how
> each player (PC) can interact....there is no free-form talking with each
> other, unless allowed for by the author. But each player would have to enter
> something, their text gets parsed, and an authored response is displayed.
There are many kinds of MUDs; in LPC and MUSHes, you completely
control the build of the game, from the grounds up. ie: An LPC MUD server
has no game.. it just takes connections and sits there. You must build
the login routine, the player creation, the display, the communications,
the works. Its just a set of routines used to build text games, without
a game. You can inheret form a dozen popular libs (just like Inform
includes libraries by default), but you can start from scratch and just
use the LPC server as a platform. So it is very much what you're doing,
but earlier and using a C-like syntax. There was lots of discussion
about it.. its not perfect, and ultimately had problems.. so you should
investigate to learn what was good and what was bad.
Design patterns, as it were. Inventing from scratch, throwing
away others experiece would be bad :)
> [In Sherlock client window]
> Holmes coughs and says, "My dear Holmes. I think I need to confess about a
> certain magical feather I once had in my possession. It was a long time
> ago..."
>
> Now you may be able to accomplish this in a mud, but mud's don't offer the
> type of authoring I want. IF authors don't want to learn the c-like mud
Well, not in .net anyway. I know you want to play with .net, but
you might see some ideas you like in the above.
> languages of muds. They're much more like general programming. IF authors
> want lower hanging fruit and that's what I want to deliver in IF# along with
> the ability to create MPIF as shown above.
Yeah, for sure. The language is the big one I agree. If you've
never written a compiler, you're going to have fun too :)
> So I have three major projects:
> 1. Language and Compiler
> 2. IF Library
> a. parser
> b. entry routines
> c. grammar
> d. base routines for grammar
> e. other routines like Save/Restore (NOTE: Save will likely be a simple
> Deserialization of the game
> assembly at runtime. Restore would simply reload/Serialize back into
> memory.
> 3. Client/Server Architecture or (I/O layer)
Started a project page somewhere yet? Start up a page, start with
this list, and start soliciting help and ideas and logging them :)
David A. Cornelson
>
> Started a project page somewhere yet? Start up a page, start with
> this list, and start soliciting help and ideas and logging them :)
Note the thread subject and then maybe try going here:
Dave