TextFyre Interpreter - Request for Proposals
ChicagoDave
In the course of developing my business plan, I had made arrangements
for an interpreter to be built. Those arrangements have changed in such
a way so that I now no longer have an interpreter to work with. I have
always had a "Plan B". In case "Plan B" falls through, I am requesting
proposals from the IF community, thus my "Plan C".
I am asking the developer community to send me proposals to build a
Glulx/Glk interpreter in C#, preferably as compatible as possible with
the mono C# compiler and libraries.
The requirements are:
- Must be built using Microsoft C#.
- Must be contained in a WinForms application.
- Must be compatible with Inform compiled Glulx game files.
- Text Window must be implemented using System.Drawing and not a
RichText control.
- Scrolling must be inline with I/O.
- I/O must be optionally contained in a single window or in separate
windows (separate input textbox).
Preferable, but not required:
- Compatible with mono C#.
Alternate scenario:
- Glk is replaced with an I/O system that is based on the native
System.Drawing API in the .NET framework and still compatible with
Inform compiled Glulx.
Functionality that is _not_ required:
- Standard Save/Restore
- Menu to open files.
- Manual font alteration.
- Manual screen coloring alteration.
All source code will be copyright assigned to WCP. This is not an
open-source project.
Developers will be paid on 1099 and be responsible for their own income
taxes.
I can only hire US citizens or legal US workers for this project.
Thanks,
David C.
Poster
Doesn't look cross-platform. Boo. Hiss.
-- Poster
www.intaligo.com Building, INFORM, Seasons (upcoming!)
vaporware
> ChicagoDave wrote:
> > I am asking the developer community to send me proposals to build a
> > Glulx/Glk interpreter in C#, preferably as compatible as possible with
> > the mono C# compiler and libraries.
> >
> > The requirements are:
> > - Must be built using Microsoft C#.
> > - Must be contained in a WinForms application.
> > - Must be compatible with Inform compiled Glulx game files.
> > - Text Window must be implemented using System.Drawing and not a
> > RichText control.
>
> Doesn't look cross-platform. Boo. Hiss.
Turn that frown upside down! C# is indeed cross-platform, via Mono,
although Mono's WinForms support still has a little catching up to do.
vw
Nikos Chantziaras
> [...]
> Turn that frown upside down! C# is indeed cross-platform, via Mono,
> although Mono's WinForms support still has a little catching up to do.
Byte code? We don't need no stinkin' byte code.
ChicagoDave
>
> Doesn't look cross-platform. Boo. Hiss.
I have every intention of pursuing multi-platform deployments. C# via
mono should allow Linux and eventually OS X products. Another benefit
of using C# is that it's likely I will be able to develop products for
the XBox too.
David C.
-
In light of the recent Novell/Microsoft quid pro quo, it's quite likely
that many Linux distros will drop or fork Mono. See
http://boycottnovell.com/2006/11/22/open-letter-to-novell
Cheers,
hbf
ChicagoDave
> In light of the recent Novell/Microsoft quid pro quo, it's quite likely
> that many Linux distros will drop or fork Mono. See
> http://boycottnovell.com/2006/11/22/open-letter-to-novell
I don't see the Novell/Microsoft as anything but an agreement from
Novell's perspective that legitimizes the Mono Project and gives Suse a
leg up on providing a stronger development environment.
The fact that the other distributions won't have the same protections
for Mono is simply about competition, not about free software. Each
distribution competes for dollars somehow. Adopting Mono and then
getting allowances for protection from Microsoft was the way that
Novell went. It's neither right nor wrong. It's just Novell's way of
being able to market Suse better.
I'm sure there are other competitive differences between the Linux
distributions.
And finally, even though the other distributions may not have Mono as a
package, there's no stopping anyone from installing it themselves. Even
Microsoft can't stop that.
David C.
Andrew Plotkin
> ChicagoDave wrote:
> >
> >
> > I am asking the developer community to send me proposals to build a
> > Glulx/Glk interpreter in C#, preferably as compatible as possible with
> > the mono C# compiler and libraries.
>
There are lots of single-platform interpreters.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the
President does it then it's legal") is contemptible.
villagedweller
Andrew Plotkin wrote:
> Here, Poster <poster!nospam!@aurora.cotse.net> wrote:
> > ChicagoDave wrote:
> > >
> > >
> > > I am asking the developer community to send me proposals to build a
> > > Glulx/Glk interpreter in C#, preferably as compatible as possible with
> > > the mono C# compiler and libraries.
> >
> > Doesn't look cross-platform. Boo. Hiss.
>
> There are lots of single-platform interpreters.
>
And, for the market Textfyre seems to be targeting, Windows first makes
good sense. Although to get current market buy-in, linux would be a
plus.
Richard Bos
> In the course of developing my business plan, I had made arrangements
> for an interpreter to be built. Those arrangements have changed in such
> a way so that I now no longer have an interpreter to work with. I have
> always had a "Plan B". In case "Plan B" falls through, I am requesting
> proposals from the IF community, thus my "Plan C".
>
> I am asking the developer community to send me proposals to build a
> Glulx/Glk interpreter in C#, preferably as compatible as possible with
> the mono C# compiler and libraries.
Does this mean that you'd need to download and install the .Com
framework in order to use it?
> Functionality that is _not_ required:
> - Standard Save/Restore
> - Menu to open files.
> - Manual font alteration.
> - Manual screen coloring alteration.
Ow. Have some sympathy with your users, please! Being able to change
fonts and colours to my preferences is the least I demand in any 'terp.
Richard
Mike Snyder
news:4597da4e...@news.xs4all.nl...
> "ChicagoDave" <david.c...@gmail.com> wrote:
>
> > Functionality that is _not_ required:
> > - Standard Save/Restore
> > - Menu to open files.
> > - Manual font alteration.
> > - Manual screen coloring alteration.
>
> Ow. Have some sympathy with your users, please! Being able to change
> fonts and colours to my preferences is the least I demand in any 'terp.
>
> Richard
It stands to reason that power users wouldn't have to use the TextFyre
interpreter.
--- Mike.
ChicagoDave
>
> Does this mean that you'd need to download and install the .Com
> framework in order to use it?
If you don't already have it, you're one of the few Windows users that
doesn't. In XP SP2 it was built-in. If you upgraded, it was an
automatic (though optional) download.
It's 22mb. In todays world of DSL and Cable broadband, that's pretty
much a drop in the bucket.
If you purchase a hardcopy of a TextFyre game, the framework will be
auto-installed.
However, If Mono works out, I may pursue using a tool they've developed
that allows you to package the required framework elements into the
executable and not have any other dependencies.
I'm only marginally sensitive to this issue since my target market is
unlikely to even know what a .NET framework is and they're highly
likely to already have it installed on their PC.
>
> > Functionality that is _not_ required:
> > - Standard Save/Restore
> > - Menu to open files.
> > - Manual font alteration.
> > - Manual screen coloring alteration.
>
> Ow. Have some sympathy with your users, please! Being able to change
> fonts and colours to my preferences is the least I demand in any 'terp.
My target market won't care about these things. I may allow the font to
be made bigger or smaller like some web pages do now, but I won't offer
a font-changing mechanism.
Besides, I plan to develop a theme for each game and the font will
likely be a large part of that. It will be a readable font, but it will
be a part of the overall look and feel for that particular game.
The one thing I will do is make sure that the games have accessibility
capabilities, which of course Windows happens to be very good about.
David C.
L. Ross Raszewski
While I find it no hassle to download and install it, I will note
this:
Number of downloaders of my first .NET-based program: 6
Number who had the .NET framework installed at the time: 0
In fact, I have *never* tried to run a .NET application on a computer
for the first time and found that the framework was already
installed. Just yesterday, I tried to install a .NET program on my
girlfriend's brand new factory fresh laptop, and found that it didn't
have .NET.
So I call shennanigans on "One of the few".
Jeff Nyman
news:_TSlh.973$NO5.391@trndny01...
> In fact, I have *never* tried to run a .NET application on a computer
> for the first time and found that the framework was already
> installed.
For some more anecotal evidence, I work for a company that, as part of its
product line, develops .NET applications and people not having .NET is not
necessarily common, but I wouldn't say it's rare either. Our bigger problem
comes in with people missing certain components of .NET (or only having .NET
1.0 when they needed .NET 2.0, which may continue as .NET 3.0 rolls out).
Mono development tends to lag behind Microsoft's so that also can become an
issue.
Certainly everything Microsoft does at this point will include .NET so with
WinXP and the upcoming Vista potentially dominating the market (in terms of
Windows apps anyway), this problem will probably start to become less and
less of a problem.
- Jeff
ChicagoDave
> Number of downloaders of my first .NET-based program: 6
>
> Number who had the .NET framework installed at the time: 0
>
> In fact, I have *never* tried to run a .NET application on a computer
> for the first time and found that the framework was already
> installed. Just yesterday, I tried to install a .NET program on my
> girlfriend's brand new factory fresh laptop, and found that it didn't
> have .NET.
>
This isn't a market penetration analysis and neither was mine. I guess
if I have to go dig up the numbers, I can. Any detailed browser market
share analysis will show whether the framework is installed and which
versions.
I'm very confident that most new PC's will have it and if they don't,
I'm really not concerned that the user will have to download and
install it.
And there are other reasons. The marketing methods I use will be very
targeted and minimum requirements will be a footnote.
The benfits of using .NET far outweigh using anything else. Ease of
development is the primary reason. Broad platform availability is a
very close second. Mono's potential is third. A large developer pool is
fourth. Strong customer support is fifth. And on and on.
David C.
villagedweller
ChicagoDave wrote:
]
>
> My target market won't care about these things. I may allow the font to
> be made bigger or smaller like some web pages do now, but I won't offer
> a font-changing mechanism.
>
I think your target market might care about this. I am a windows user
with not-so-great eyesight, and being able to change size and type face
is *extremely* helpful to me. There are ways I can improve the
situation without program support, but it's a pain in the butt, and
makes me quite grumpy toward the developers.
Text-based games have a huge opportunity with the visually impaired
market--leaving them in the cold is not a good idea, as they are one of
the few populations who isn't already addicted to graphically oriented
computer software (even an avid sighted book reader expects nice
pictures when they surf and play games). At a minimum, I think that
means including several font types, sizes, and color combinations.
ChicagoDave
> I think your target market might care about this. I am a windows user
> with not-so-great eyesight, and being able to change size and type face
> is *extremely* helpful to me.
I certainly will make the software accessible by text readers and
similar equipment, make sure that all mouse clicks have a standard
keyboard equivilent, but the visual aspect of the UI is important to
me.
I believe the ability to make the product look professional,
attractive, and consistent is critical to repeat sales.
All I can say is that I will do my best to make sure that everyone can
comfortably play TextFyre games.
David C.
villagedweller
ChicagoDave wrote:
That's all really good, but there are those of us who are in between
comfortably sighted and sufficiently impaired to invest in screen
readers and such (which can be extremely expensive, slow, and have a
steep learning curve, all of which keeps me from going that route for
now).
For example, I7, with its one font fits all, is frustrating, because I
can't easily switch to a larger, more readable font (serif and small
sucks).
> David C.
-
Agreed. I'm saddened that there is no overall .css file for the
documentation.
A complete PITA workaround is to edit the source files and add your own
rule for the BODY selector in the CSS style sheet in the <HEAD> section.
body { font-family: "tahoma"; }
This will, of course, break w/ each update & is completely unsupported.
It seems that IE complains when you edit the currently open file, so you
might have to restart Inform 7 when editing a file that you're currently
viewing.
You'll have to use the browser's font increase/decrease settings as the
font sizes are embedded in the source text.
Could the doc authors please consider using classes to allow certain CSS
overrides as described by the OP?
d.ki...@btinternet.com
> For example, I7, with its one font fits all, is frustrating, because I
> can't easily switch to a larger, more readable font (serif and small
> sucks).
This is due to the Windows version not yet having a proper options
dialog. In the meantime, the font can be changed by the (somewhat
unpleasant) mechanism of setting registry values:
If the registry string value
"HKCU\Software\David Kinder\Inform\Window\Font Name"
is set, its value is used as the application font.
If the registry DWORD value
"HKCU\Software\David Kinder\Inform\Window\Font Size"
is set, its value is used as the application font point size.
This will affect all the I7 UI, including the documentation (unless,
as another poster has done), you've edited the HTML files ...
David
James Cunningham
Are there plans to add a finer-grained ability to change fonts and font
sizes? But I suppose that's a question as much for Mr Hunter as for
you, since I use Macs more than fifty percent of the time. Do you guys
plan to keep some sort of configurability parity?
I am rather particular - and capricious! - about what fonts I use;
right now it's painful to use the I7 Mac IDE and be forced to choose
between a proportional font I don't like and a fixed-width font I don't
like, in font sizes that are too tiny, too large, and *far* too large.
(I'm curious why the ability to manage this stuff has been so
restricted and pushed into a preferences dialog - isn't this a standard
Cocoa text widget? But I'm speaking beyond my knowledge.)
And that sort of brings me to one of the things that disappoints me
about Mr Cornelson's plans: the two mouse clicks it takes to change a
font size is too advanced for your target audience? Ach, no wonder I'm
not in it! (Three clicks is *my* limit.) No ability to change the
color? I suppose my Adrift Runner nightmares alone would push me out of
that audience.
Best,
James
L. Ross Raszewski
I'm not sure I see how the one follows from the other. In what way
does the possiblity that an individual user could change the
appearance of the game on his machine imply a lack of a "professional,
attractive, and consistent" look?
I mean, do you seriously imagine a scenario where a user says "This
looks great! But I can't read it. Yet I will buy more because it's so
attractive! Oh. I've changed the font size. Now
I can read it! But it looks terrible! I shall not buy any more!"
Do you think people will go and *look* for a way to make your game
less attractive so they can dislike it?
I've never understood this "It looking the way I like will make it
reach a larger audience than making it look the way the audience wants
it to look" philosophy. By allowing users to render the game
playable, you're reaching *more* players, not fewer. The only people
for whom this feature would be useful are people who *WOULD NOT BUY
YOUR GAMES IF IT WERE ABSENT*. Those who can read it just fine won't
mess with the settings, so it's not like anyone is going to see the
game in anything other than your preferred display style unless they
*need to*.
Jon Rosebaugh
> I've never understood this "It looking the way I like will make it
> reach a larger audience than making it look the way the audience wants
> it to look" philosophy. By allowing users to render the game
> playable, you're reaching *more* players, not fewer. The only people
> for whom this feature would be useful are people who *WOULD NOT BUY
> YOUR GAMES IF IT WERE ABSENT*. Those who can read it just fine won't
> mess with the settings, so it's not like anyone is going to see the
> game in anything other than your preferred display style unless they
> *need to*.
Uncle Jim (not a real person) has vision problems, so he'll be playing
these games with large font sizes, high contrast colors, etc. His nephew
Stan comes to visit, and is curious about what Jim's playing. But these
text games look so gosh-darn ugly! He certainly wouldn't pay for
anything that looked as unprofessional as that!
Yeah, it's a contrived example. And the number of people who decide
whether or not to buy one of Dave's games based on seeing someone else
play it with a modified interface is likely to be small. But I'm sure
there will be _some_.
Andy Leighton
Jon Rosebaugh <jonathan....@mnsu.edu> wrote:
> L. Ross Raszewski wrote:
>> I've never understood this "It looking the way I like will make it
>> reach a larger audience than making it look the way the audience wants
>> it to look" philosophy. By allowing users to render the game
>> playable, you're reaching *more* players, not fewer. The only people
>> for whom this feature would be useful are people who *WOULD NOT BUY
>> YOUR GAMES IF IT WERE ABSENT*. Those who can read it just fine won't
>> mess with the settings, so it's not like anyone is going to see the
>> game in anything other than your preferred display style unless they
>> *need to*.
>
> Uncle Jim (not a real person) has vision problems, so he'll be playing
> these games with large font sizes, high contrast colors, etc. His nephew
> Stan comes to visit, and is curious about what Jim's playing. But these
> text games look so gosh-darn ugly! He certainly wouldn't pay for
> anything that looked as unprofessional as that!
Yes but surely Stan knows that Uncle Jim has vision problems and may
have seen him using a word-processor or browsing the net with a massive
font and high contrast as well.
--
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_
d...@pobox.com
On Dec 29 2006, 8:29 pm, "ChicagoDave" <david.cornel...@gmail.com>
wrote:
Much of this is specifying a solution instead of your requirements.
It's a classic way to fail.
drj
d...@pobox.com
But note, in order for this scenario to work against the proposed
business, Stan must have purchased a game in the alternate scenario
where Jim couldn't change the size and color. It seems to me that if
Jim can't change the size, then Jim won't buy, Stan won't see, so Stan
still won't buy. In either case Stan doesn't buy. No customer has
been lost.
drj
ChicagoDave
> Much of this is specifying a solution instead of your requirements.
> It's a classic way to fail.
That's a loaded comment and I don't see how it relates to my request.
Creating a Glulx interpreter isn't rocket science. This isn't really
"new" development. The design is mostly already there (or at least the
Glulx and Glk specifications are already there). I'm simply planning on
having an interpreter that is entirely WCP's to own and modify
accordingly.
In order to fail at having an interpreter created, I would have to stop
trying.
David C.
ChicagoDave
> I'm not sure I see how the one follows from the other. In what way
> does the possiblity that an individual user could change the
> appearance of the game on his machine imply a lack of a "professional,
> attractive, and consistent" look?
Here's how I look at the products I will be creating and this is very
important. I see these games more like comic books or Nancy Drew
stories. Although they are games, I won't market them as games. I will
market them as educational entertainment. If you go inside Borders and
BN, they are starting to catch on to "interactive" product lines. I
plan to make a serious push to get on shelves in the children's and
teen reading areas of those stores because that's where my market will
be looking for new content.
You'd think that download sales might be the bigger portion of revenue,
but I think that's a huge gamble and I'm unwilling to go that route.
There is simply no way to anticipate the market for downloads. In order
to produce sales, I need to get on shelves and in front of real people.
It's going to be a long hard battle, but it's the only way I believe I
can make this work.
The reason I want the games to be so tightly constructed is because I
think that's how book retailers will accept them. I might be wrong, but
that's the way I'm going into the field.
Now. With that said, I will be doing test marketing at schools, which
I've discovered is a very easy thing to do. If my test marketing comes
back with a lot of complaints about not being able to change fonts and
colors, then I will adapt. But if my target market is completely silent
on this issue, I will leave the product as it is.
An alternative I've considered that isn't too difficult to implement is
to mimic the hobbyist interpreters as an alternative download and call
it something like the "Hobbyist Version".
In the end, productizing this stuff seems to be one of the most
critical aspects to making sales happen. It has to be a solid package.
I actually think brick and mortar book retailers will be more inclined
to look at something that looks _less_ like a game or your average
piece of software and something that's _different_.
But the proof is in the test marketing and eventual sales. I will
either be proven right or proven wrong. As stubborn as I am about this
topic, I will adapt if I need to, when I need to. I will also make sure
that adaptation is an easy and seemless process. There is always a Plan
B for all aspects of my business plan and the risks associated with
both Plan A and Plan B.
David C.
Jeff Nyman
news:1167749139....@k21g2000cwa.googlegroups.com...
>> d...@pobox.com wrote:
>> Much of this is specifying a solution instead of your requirements.
>> It's a classic way to fail.
>
> That's a loaded comment and I don't see how it relates to my request.
I think maybe he was saying that there is emphasis solely on C# and .NET
(and specifics therein), where requirements wouldn't indicate that. That
would tend to fall to a design decision made based on the nature of the
requirements.
Where I think the "solution-requirements" discrepancy lies is in recognizing
that there are different level of requirements. I read this list as your
*design* requirements and not necessarily your *business* requirements, the
latter of which have already been established. In that case, your
implementation details make sense at the level specified, in my opinion.
- Jeff
Jeff Nyman
> Now. With that said, I will be doing test marketing at schools, which
Yeah, I've done a lot of this. I've found schools (for younger kids) are
very amenable to this concept of "interactive fiction." I've talked to a few
schools and I had to meet with their administrators in order to show what I
was talking about. Usually the results were positive. I really played up the
angle (particularly for the younger set) regarding how parents can work with
the children to create stories and how the kids can collaborate to tell
different stories.
I'm not sure of the money-making potential there because I'm not going that
route, but that could also serve as an introduction to part of the market it
seems you are targeting. At the very least, maybe it provides another way to
make sure you get the eyeballs-on-product effect that can then be translated
into kids knowing where to get this stuff (either online or in a store).
In any event, I like the approach you are taking and I'm very curious to see
how things develop for you.
- Jeff
L. Ross Raszewski
I don't disagree with anything you say here. I disagree that the one
follows from the other. You have made this bizarre link between "You
can customize the display" to "It looks unprofessional and hobbiest".
The reason that books come in only one font isn't because it would
make the book look less goodfor users to be able to change the font;
it's *because that's not feasable for a book*.
The option existing does NOT AT ALL make it look less professional.
All you need to do is ensure that when the player first sees the game,
it looks the way you want it to look. If he chooses to deviate from
that later, it's his own look out. What you're saying is like
claiming that people oughtn't to be allowed to read a book through a
magnifying glass, because it'll look sub-optimal.
It doesn't hurt you to have this capability. It doesn't make it look
less professional to have this capability -- in fact, it DOESN'T
CHANGE THE LOOK AT ALL unless the user needs it to!
d...@pobox.com
On Jan 2, 3:11 pm, "Jeff Nyman" <jeffnyman_nospam@nospam_gmail.com>
wrote:
> "ChicagoDave" <david.cornel...@gmail.com> wrote in messagenews:1167749139....@k21g2000cwa.googlegroups.com...
>
> >> d...@pobox.com wrote:
> >> Much of this is specifying a solution instead of your requirements.
> >> It's a classic way to fail.
>
> > That's a loaded comment and I don't see how it relates to my request.
> I think maybe he was saying that there is emphasis solely on C# and .NET
> (and specifics therein), where requirements wouldn't indicate that. That
> would tend to fall to a design decision made based on the nature of the
> requirements.
The great thing about being terse and cryptic is that there is always
someone who can come along and explain clearly and precisely what I
mean. In other words: Yes; what Jeff said.
Specifically regarding the requirements of C#, .NET, etc, etc (which
were the ones that most obviously made me roll my eyes with the all too
familiar recognition of Doomed Project), I can see that behind the
scenes there's some sort of requirement about how easily WCP can hire
programmers to continue to develop and maintain the interpreter when
their main guy burns out on crystal meth'; some sort of requirement
about how easy it should be to create bundled customised versions of
the interpreter for each individual title (so that individual titles
can be published stand-alone and not as interpreter + glulx file); and
some sort of requirement about how easy any given title should be to
install (by the illiterate parents of a 12-year old).
But if that's so, why not say that?
- Should be implemented is such a way that WCP can easily hire
competent programmers to continue to develop and maintain the product
at prevailing market rates (whatever those are in the US, USD 80 per
hour?). Because of this, implementation in C# using the .NET framework
are likely to be preferred.
- Should be implemented in a way that the interpreter can be extended
and specialised to produce custom version for an individual game title.
Such customisation shall not take more than 120 FTE hours.
- The interpreter shall form part of a finished game product, the
entirety of which can be installed by the illiterate midwestern parents
of a 12-year old in less time than it takes to drink a bud'.
I think it pays to be very concrete and specific in your requirements
sometimes.
The mistake of specifying a solution instead of your requirements is
that you miss useful solutions (or potential solutions). Even if you
end up discarding other solution (approaches) having thought about them
can throw useful light on what you really want. For example, what if
there was a version of Inform 6 that produced .NET binaries directly
(not completely infeasible; from what I know about Inform 6 and what
I've done with other languages and VMs my first guess would be about 3
month's work). Would that be acceptable? If not, why not? Because
WCP don't want the burden of maintain a custom version of Inform 6?
Then say so.
> Where I think the "solution-requirements" discrepancy lies is in recognizing
> that there are different level of requirements. I read this list as your
> *design* requirements and not necessarily your *business* requirements, the
> latter of which have already been established. In that case, your
> implementation details make sense at the level specified, in my opinion.
This is often regarded as a hierarchy of requirements, as Jeff says at
different levels, with each level having potentially many different
approaches that could be used by the level below. What joins the
levels is justification.
At the top, the requirements (often called Mission or Goal) of WCP
might be to Make Money (or it might not be, it might be to promote IF).
Solution: produce IF. Requirement: make profit. Solution: identify
unexploited market. Eventually you get down to: Requirement: display
text in Garamond 11/13. Why? because the game asked us to produce some
text and display it. Why Garamond? because we identified that as the
best font available for this genre given concerns of readability,
availability, and attractiveness. Why this genre of game? because that
was identified as likely to be popular with the target market. Why the
target market? because they were identified as being interested in the
product and having control of a budget to spend on it. And so on.
drj
steve....@gmail.com
> In order to fail at having an interpreter created, I would have to stop
> trying.
In order *not* to fail, you would have to *start* trying. So far you're
just producing bullshit on top of bullshit. You have not tried
whatsoever, and I seriously doubt you are capable of trying. It's a
damn shame anyone is behaving as though they're taking you seriously.
This all reminds me of a story...
<quoting from "News of the Weird">
London's Steve Bennett continues his quest to become the world's most
successful amateur rocket engineer, with all systems go for launching
himself into space in a "test flight" (to an altitude of 10,000 feet)
in 2003 on a venture that most professional engineers called foolhardy,
according to a June story reported by the BBC. The more that is known
about Bennett's mission (e.g., he recently said it would be a rocket
capsule made from a cement mixer, with modest installation and a small
computer), the more rocket scientists believe his launch will result in
instant death. However, the louder the criticism, the more certain of
himself Bennett professes to be. He still rejects conventional
preparations such as wind-tunnel tests and g-force tests: "That is what
the test flight is for," he said. [BBC News, 6-26-01]
</quote>
...the only difference being that Steve Bennett is a rocket scientist.
Cornelson is not by any means.
ChicagoDave
> <quoting from "News of the Weird">
Isn't this like the pot calling the kettle black?
David C.
Richard Bos
> > Richard Bos wrote:
> >
> > Does this mean that you'd need to download and install the .Com
> > framework in order to use it?
>
> If you don't already have it, you're one of the few Windows users that
> doesn't. In XP SP2 it was built-in. If you upgraded, it was an
> automatic (though optional) download.
>
> It's 22mb. In todays world of DSL and Cable broadband, that's pretty
> much a drop in the bucket.
Fuck that; I'm on dial-up.
> If you purchase a hardcopy of a TextFyre game, the framework will be
> auto-installed.
Fuck that; I don't even trust _you_ that much, let alone Micro$haft.
> > > Functionality that is _not_ required:
> > > - Standard Save/Restore
> > > - Menu to open files.
> > > - Manual font alteration.
> > > - Manual screen coloring alteration.
> >
> > Ow. Have some sympathy with your users, please! Being able to change
> > fonts and colours to my preferences is the least I demand in any 'terp.
>
> My target market won't care about these things. I may allow the font to
> be made bigger or smaller like some web pages do now, but I won't offer
> a font-changing mechanism.
Fuck that; I want to be able to be comfortable reading the text.
Let me guess: you're going to use Comic Sans as your main font, because
it looks comfortingly amusing to school children.
> The one thing I will do is make sure that the games have accessibility
> capabilities, which of course Windows happens to be very good about.
Except that not allowing me to change the font and its size to
_precisely_ what is comfortable for me is not accessibility, but exactly
the opposite.
Ah, never mind. You've just lost 1 (one) potential sale - for good.
Richard
ChicagoDave
> > It's 22mb. In todays world of DSL and Cable broadband, that's pretty
> > much a drop in the bucket.
>
> Fuck that; I'm on dial-up.
This is why I will offer games on CD.
> > My target market won't care about these things. I may allow the font to
> > be made bigger or smaller like some web pages do now, but I won't offer
> > a font-changing mechanism.
>
> Fuck that; I want to be able to be comfortable reading the text.
You will. After I market-test the games, readability and usability will
be very important issues and addressed very seriously.
> Except that not allowing me to change the font and its size to
> _precisely_ what is comfortable for me is not accessibility, but exactly
> the opposite.
No. It's restrictive, but not inaccessible.
> Ah, never mind. You've just lost 1 (one) potential sale - for good.
>
I accept your challenge.
David C.
The Wanderer
>> Richard Bos wrote:
>>
>>> It's 22mb. In todays world of DSL and Cable broadband, that's
>>> pretty much a drop in the bucket.
>>
>> Fuck that; I'm on dial-up.
>
> This is why I will offer games on CD.
Which will make exactly no difference if he refuses to allow the
auto-installation of the .NET framework (re the section you snipped).
>>> My target market won't care about these things. I may allow the
>>> font to be made bigger or smaller like some web pages do now, but
>>> I won't offer a font-changing mechanism.
>>
>> Fuck that; I want to be able to be comfortable reading the text.
>
> You will. After I market-test the games, readability and usability
> will be very important issues and addressed very seriously.
Readability and usability under what screen resolutions?
I habitually run under 1600x1200, for the increased screen real estate,
and frequently have to increase default font sizes in (say) various Web
pages in order to be able to read them without squinting. At work, I
sometimes also have to work with computers running at 640x480, and the
default font sizes on those displays are frequently uncomfortably large.
What is a good font size under one set of circumstances is not
necessarily a good font size under another. How do you plan to
accommodate potential players on both ends of the screen-resolution
range?
Further, even when I increase the font size of the unreadably-small
pages to something reasonable (significantly reducing effective screen
real estate for that window in the process), almost all of the fonts in
question look off-puttingly ugly at any point size large enough for me
to actually read. It's adequate for, say, browsing through a news site,
but not for reading fiction - which is the primary non-mail/non-news
thing I do with my online time, and which is just about exactly what
you're asking potential players to do. Combine that with the fact that
different people may have different ideas about what constitutes "ugly"
in this context, and I somehow doubt that there *is* any adequate single
compromise font which will work well regardless of resolution or of
point size.
>> Except that not allowing me to change the font and its size to
>> _precisely_ what is comfortable for me is not accessibility, but
>> exactly the opposite.
>
> No. It's restrictive, but not inaccessible.
Trust me, for some of the Web pages I've seen (including some fairly
well-known ones I could point out if I'd bothered to remember them by
name), the default font size - despite being, I'm sure, quite legible
under a resolution like 800x600 - is so unreadable as to render those
site completely inaccessible at my resolution.
>> Ah, never mind. You've just lost 1 (one) potential sale - for good.
>
> I accept your challenge.
I probably wasn't a potential customer in the first place, for various
reasons too complicated to get into briefly, but I must say that the
combination of your "my way or the highway" approach on fonts with your
requirement of the .NET framework is leaving me somewhat skeptical at
best about this venture.
I honestly don't see any harm in allowing users to change the font if
they want to; if they choose to shoot themselves in the foot, let them.
(The only potential exception I've seen mentioned so far is the "Uncle
Fred" example, but that's a matter of not of changing the font but of
changing the font size - which you've already said you'd consider
allowing.)
If, as you've said, your target market won't care, then they won't
bother changing anything. Those who *do* care would not buy your games
without the option, but might with it; they therefore represent a
potential addition to your market.
Unless you think that there will be absolutely zero overlap between your
target market and people who care about what font is used?
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Jeff Nyman
news:8KudncdROLmj1APY...@comcast.com...
> Unless you think that there will be absolutely zero overlap between your
> target market and people who care about what font is used?
I agree with the points you bring up here. Responding to the one above, this
is definitely where some sort of usability test should be done with the
target market. That can actually be done right now. We have interpreters and
we have games. I would imagine it would be possible to at least test some of
those out with the target market. Ask for responses. Find out what people
would want, on average.
Speaking more to David, I might consider doing that before deciding too many
of my hard-and-fast design requirements.
Obviously it depends on the age bracket being sought, but studies with
relatively young kids (in the five to seven year old range) using blogs and
Web pages have shown that changing fonts (not just sizes, but the types) are
important things to them. Remember that many kids are coming from
applications that allow them to do just this, so they are, in many ways,
used to it. More kids are getting into Web development earlier these days
and that is definitely a place where changing fonts is done and means they
are at least potentially familiar with the concept. (Early alphabet learning
programs for children also allow changing fonts: sizes, styles, and colors.)
Studies with 9 to 11 year olds show similar findings, in terms of
familiarity and desire. I recommend checking out the findings on this by the
Software Usability Research Laboratory. (They do routine series of studies
called "Which Fonts Do Children Prefer to Read Online?")
Just some things to consider, perhaps.
- Jeff
David Whyld
(except retro ones) where I haven't changed the font size at some
point. A good deal of games seem to use a very small default font (12
or even 10 in some cases) which can look tiny on a monitor with
1280*1024 resolution. Readable? Yes. Easy on the eyes? No. If I started
playing a game and the font wasn't to my liking and the option to
change it wasn't there, I'd quit and make a point of not buying
another game until the restriction was removed.
ChicagoDave
> Obviously it depends on the age bracket being sought, but studies with
> relatively young kids (in the five to seven year old range) using blogs and
> Web pages have shown that changing fonts (not just sizes, but the types) are
> important things to them.
I agree. My daughter has done book reports on the computer and always
asks me to help her review fonts for different things. She's 8 years
old, so she's already becoming font savvy.
My intent was never about the ability to change fonts and I think I got
away from my point early on. I don't want to clutter up the interface
with menus and options and such. I want the UI to be _the game_. the
vision I have of the UI is going to be radically different than
anything we have today in the hobbyist community. The UI won't have any
need for you to select a game since the game file will be embedded into
the executable. It will allow you to select saved games to restore. It
will have an interface conducive to IF game play. It will have graphics
related to the game itself as borders and backgrounds. It will have a
help system that's external to the game itself. The only functional
items that need to be placed on the screen somewhere are: Save,
Restore, Quit, and Help. So where does "Change Font" fit into that? Do
I add "Options" as a button? I'm uncomfortable with that, but it's the
most reasonable possibility.
What I'm more inclined to do is think of a way to seemlessly allow the
font to be manipulated. But again, that has problems too. There are
people here with sight restrictions and so they need the "Options" to
be easily located and manipulated.
I think everyone's "point" has been taken. So I will probably develop
several different ways for the font and screen color to be manipulated
and do my usability testing there. Hopefully I can figure out a way
that satisfies my original vision, while allowing for this option.
Now...the .NET Framework thing I can't help. My original intention was
to build the UI using a cross-platform GUI toolkit and in C, but
resources and the expenses exceed my budgeting constraints. If the
first half dozen games sell well enough and I get into the black early
on, I may specifically target this as an important change to make, but
the initial set of games will be built on a .NET UI. It's just easier,
cheaper, and with mono may allow me to package for OSX and Linux.
If anyone here wants to send me a proposal to build a cross-platform
C/C++ based Glulx interpreter, feel free. It can't have anything to do
with the current interpreters since I will require the source code be
closed and owned by WCP, but other than that, I'm absolutely open to
this course of action. I just haven't been able to find a resource that
I trust with a proposal that's within my budget.
For now, I'm writing the UI in C# by myself with guidance from the
ifMUD gang. This is clearly the least expensive option, although it
will take more time.
David C.
Jeff Nyman
> with menus and options and such. I want the UI to be _the game_.
...
> What I'm more inclined to do is think of a way to seemlessly allow the
> font to be manipulated. But again, that has problems too. There are
> people here with sight restrictions and so they need the "Options" to
> be easily located and manipulated.
...
> help system that's external to the game itself. The only functional
> items that need to be placed on the screen somewhere are: Save,
> Restore, Quit, and Help. So where does "Change Font" fit into that? Do
> I add "Options" as a button? I'm uncomfortable with that, but it's the
> most reasonable possibility.
This makes sense. What most studies tend to show is that children do much
more readily welcome and adapt to standardized interfaces that require them
to invest little time in learning or playing around with "extras." The other
side of this is that children, like adults, want to be in control of their
experience. So the key is providing just enough of the control abilities
that they desire in such a way that it allows them to invest more time in
the game itself rather than in setting up the game+UI.
With what you've said, I can see why you would want to go away from the
traditional menu concept. If you're going to wrap the game in the UI, as it
were, then the ability to alter the UI can possibly flow out of how the UI
presents itself. Maybe a slide-out tab that contains the relevant controls?
Maybe a "panel" on the UI itself (at the bottom?) that can be clicked and
when it does the panel "opens" and "underneath" the panel are the controls?
The key (it seems) would be to not force the opening of a dialog box.
Another key point to consider though (and you probably have, so I'm not
insulting your intelligence here -- just thinking out loud) is how much your
target market is your sole target market relative to how you see your
concept expanding. Designing the interface too much for one target market
may lock you out of another. On the other hand, some adults (at least in
game playing venues) may really have the same needs as your target market.
If it helps, the "Workshop on Game Design and HCI" often publishes very
interesting notes and studies about how interfaces are designed for both
children and adults where the interface doesn't "get in the way", as it
were.
- Jeff
d...@pobox.com
On Jan 5, 5:23 pm, "ChicagoDave" <david.cornel...@gmail.com> wrote:
>
> Now...the .NET Framework thing I can't help. My original intention was
> to build the UI using a cross-platform GUI toolkit and in C, but
> resources and the expenses exceed my budgeting constraints. If the
> first half dozen games sell well enough and I get into the black early
> on, I may specifically target this as an important change to make, but
> the initial set of games will be built on a .NET UI. It's just easier,
> cheaper, and with mono may allow me to package for OSX and Linux.
>
> If anyone here wants to send me a proposal to build a cross-platform
> C/C++ based Glulx interpreter, feel free. It can't have anything to do
> with the current interpreters since I will require the source code be
> closed and owned by WCP, but other than that, I'm absolutely open to
> this course of action. I just haven't been able to find a resource that
> I trust with a proposal that's within my budget.
Ah. So now it comes out. .NET _was_ a solution pre-selected on the
basis of a budgetary _requirement_. This is exactly the sort of thing
I was driving at when I said "tell us your requirements, not
solutions".
drj
The Wanderer
> My intent was never about the ability to change fonts and I think I
> got away from my point early on. I don't want to clutter up the
> interface with menus and options and such. I want the UI to be _the
> game_. the vision I have of the UI is going to be radically different
> than anything we have today in the hobbyist community. The UI won't
> have any need for you to select a game since the game file will be
> embedded into the executable. It will allow you to select saved games
> to restore. It will have an interface conducive to IF game play. It
> will have graphics related to the game itself as borders and
> backgrounds. It will have a help system that's external to the game
> itself. The only functional items that need to be placed on the
> screen somewhere are: Save, Restore, Quit, and Help. So where does
> "Change Font" fit into that? Do I add "Options" as a button? I'm
> uncomfortable with that, but it's the most reasonable possibility.
Hmm. How about a context menu? Invisible unless you go looking for it,
but ready to hand when desired. Doesn't even require a mouse; almost
every keyboard I've seen in quite some time, with the exception of those
on some comparatively outdated laptops, has had a "context menu" key.
> What I'm more inclined to do is think of a way to seemlessly allow
> the font to be manipulated. But again, that has problems too. There
> are people here with sight restrictions and so they need the
> "Options" to be easily located and manipulated.
I agree that that would be desirable, but I'm not being able to think of
a good one off the top of my head. Font size manipulation is simple
enough - Mozilla's standard of Ctrl-Plus and Ctrl-Minus to move to the
next larger or smaller point size, respectively, is intuitive,
convenient, and unobtrusive - but font face is more of a challenge.
The only thing I can think of is to have an external (and perhaps
optional) config file in which a font can be specified. Not the most
convenient way of doing it, particularly since it would require either a
"reload config" command in the game (perhaps a meta-verb?) or that the
user restart the game to see what the new font looked like, and it's
certainly not seamless - but it would equally certainly work.
> I think everyone's "point" has been taken. So I will probably develop
> several different ways for the font and screen color to be
> manipulated and do my usability testing there. Hopefully I can figure
> out a way that satisfies my original vision, while allowing for this
> option.
I'm glad to hear that. The stance you've described in this post is much
more reasonable than the one you had appeared to be presenting, even if
it may lead to the exact same results, and I'm much more comfortable
with it on that basis.
> Now...the .NET Framework thing I can't help. My original intention
> was to build the UI using a cross-platform GUI toolkit and in C, but
> resources and the expenses exceed my budgeting constraints. If the
> first half dozen games sell well enough and I get into the black
> early on, I may specifically target this as an important change to
> make, but the initial set of games will be built on a .NET UI. It's
> just easier, cheaper, and with mono may allow me to package for OSX
> and Linux.
I don't actually have fundamental strong objections to .NET, although I
dislike Microsoft's attempting to create yet another de-facto (and
proprietary) standard. In practice, .NET looks at a brief glance to be
little more than a (comparatively comprehensive) set of libraries for a
program to call, and there's certainly nothing objectionable about that
beyond the potential for dependency requirements; I've got several sets
of such libraries installed on my (Linux) system already.
I do have philosophical objections to C#, but I've managed to block most
of what I knew about the details of C# out of my mind well enough that
I've forgotten what they are. In any case, one does not have to be
exposed to the language a program is written in in order to use that
program. <grin>
vaporware
> ChicagoDave wrote:
>
> >> Richard Bos wrote:
> >>
> >>> It's 22mb. In todays world of DSL and Cable broadband, that's
> >>> pretty much a drop in the bucket.
> >>
> >> Fuck that; I'm on dial-up.
> >
> > This is why I will offer games on CD.
>
> Which will make exactly no difference if he refuses to allow the
> auto-installation of the .NET framework (re the section you snipped).
Frankly, I wouldn't worry about that happening. What are you going to
do if a potential customer refuses to allow the auto-installation of,
say, the MFC libraries, or the VB runtime, or the Rich Edit control
libraries, or some custom DLL you've written yourself? Write him off
and focus on everyone else, or dance around various choices of
compiler, library, and deployment structure just to appease rare,
random nuts who have an irrational objection to certain binary modules?
vw
The Wanderer
<shrug> That's as may be; per my other post, I don't actually have
strong objections to .NET myself except on practicality and
proprietarianism grounds. I was primarily just pointing out that the
solution is not adequate for the problem for which it was proposed.
I have no intention of getting into the "binary modules" debate here, or
for that matter anytime soon. I think I know roughly on which side of it
I would fall, but I have not paid enough attention to previous
iterations of the debate to be able to argue either side with much
facility.
Andrew Hunter
> On 2007-01-01 03:52:54 -0500, d.ki...@btinternet.com said:
>
>> villagedweller wrote:
> Are there plans to add a finer-grained ability to change fonts and font
> sizes? But I suppose that's a question as much for Mr Hunter as for
> you, since I use Macs more than fifty percent of the time. Do you guys
> plan to keep some sort of configurability parity?
>
> I am rather particular - and capricious! - about what fonts I use;
> right now it's painful to use the I7 Mac IDE and be forced to choose
> between a proportional font I don't like and a fixed-width font I don't
> like, in font sizes that are too tiny, too large, and *far* too large.
> (I'm curious why the ability to manage this stuff has been so
> restricted and pushed into a preferences dialog - isn't this a standard
> Cocoa text widget? But I'm speaking beyond my knowledge.)
Yes, it is, but the standard font chooser probably isn't appropriate,
as font changes need to be appropriately applied to the documentation
and the interpreters as well, so it needs to be something set as a
global preference.
The reason for the present design is that there are rather a lot of
different fonts and colours that can be used by the IDE (about 16 for
syntax colouring, plus another 16 for the Z-Machine and 12 or so for
Glk - and then there's the documentation, index and skein). It wouldn't
really be practical to have a control that lets you choose all of these
independently, so I chose to implement something that simplified the
situation. I wanted to avoid producing something like the advanced font
tab in Zoom's preferences (which gives you total control but is pretty
much unusable in practice)
The default font set is based around the OS X system font in standard
sizes: because you see this everywhere if you're using OS X anyway, and
most things won't let you change it, I thought it would not be a
controversial choice.
There is, I think, some scope for a custom option for the font set and
font size, so I'll add this to the TODO list. It's going to require a
custom panel, though, as the standard OS X font panel is modeless which
isn't really appropriate for the preferences dialog.
(Sigh, I also see that the Intel font manager weirdness that was
affecting Zoom is also affecting the 'Stylised' font set: it's choosing
a light font variant where it should be choosing a medium one)
Andrew.
Andrew Hunter
> Hello All,
>
> In the course of developing my business plan, I had made arrangements
> for an interpreter to be built. Those arrangements have changed in such
> a way so that I now no longer have an interpreter to work with. I have
> always had a "Plan B". In case "Plan B" falls through, I am requesting
> proposals from the IF community, thus my "Plan C".
>
> I am asking the developer community to send me proposals to build a
> Glulx/Glk interpreter in C#, preferably as compatible as possible with
> the mono C# compiler and libraries.
This does look like a solid plan overall, but I do have some comments:
Nobody seems to have said it yet, so I will: .NET is probably a good
choice for what you want to achieve and your target market. Though I'll
add that you probably still want to target .NET 1.1 at the moment:
though a lot of people have 2.0, enough don't that you'll still lose a
noticable amount of business if you require it, at least if you're
releasing something this year.
> The requirements are:
> - Must be built using Microsoft C#.
> - Must be contained in a WinForms application.
> - Must be compatible with Inform compiled Glulx game files.
> - Text Window must be implemented using System.Drawing and not a
> RichText control.
If it were me writing this specification, I wouldn't be so definite
about System.Drawing being the solution, though the .NET RichText
control is indeed very inappropriate for a Glulx text window.
(It's going to be a lot of work to write a full renderer using
System.Drawing, so it would seem to be a good idea to allow the
developer the opportunity to choose something better if they know of it)
> - Scrolling must be inline with I/O.
It's not clear what you mean by this.
> - I/O must be optionally contained in a single window or in separate
> windows (separate input textbox).
>
> Preferable, but not required:
> - Compatible with mono C#.
>
> Alternate scenario:
> - Glk is replaced with an I/O system that is based on the native
> System.Drawing API in the .NET framework and still compatible with
> Inform compiled Glulx.
This isn't really possible: the gi_dispatch layer that Glulx uses to
communicate with the outside world is pretty much just the Glk API:
you'll end up implementing it anyway. (It's probably possible to have a
completely custom IO subsystem, but you won't be able to run standard
Inform programs)
> Functionality that is _not_ required:
> - Standard Save/Restore
> - Menu to open files.
> - Manual font alteration.
> - Manual screen coloring alteration.
Here, I'd suggest that what you actually want is three separate
products: a display library (with a Glk interface), a glulx interpreter
that uses that display library, and an application that uses both. This
would give you maximum flexibility in terms of the way the games are
presented, as well as the underlying interpreter that they are based on.
Andrew.
Richard Bos
> > Richard Bos wrote:
> > > It's 22mb. In todays world of DSL and Cable broadband, that's pretty
> > > much a drop in the bucket.
No, I didn't. You wrote that.
I wrote this:
> > Ah, never mind. You've just lost 1 (one) potential sale - for good.
>
> I accept your challenge.
It wasn't a challenge. That you don't understand that is a good
indication of why you've lost me.
You obviously understand the wishes of your audience (pre-school
children, as far as I can make out) perfectly. You don't understand mine
in the least, and the way you're going about it, never will.
Richard
villagedweller
Richard Bos wrote:
I have to agree with vaporware on this; some people aren't worth having
as customers. The costs have to be worth the gains, and this seems like
a no-win situation that isn't worth bothering with. I bet there are
plenty of people out there who have suggestions but haven't made up
their minds and will wait for the product to see if it works for us. At
least one (me), anyway.
> Richard
ChicagoDave
> It wasn't a challenge. That you don't understand that is a good
> indication of why you've lost me.
>
> You obviously understand the wishes of your audience (pre-school
> children, as far as I can make out) perfectly. You don't understand mine
> in the least, and the way you're going about it, never will.
I understood you perfectly.
My target market are kids between 8 and 15 years old or thereabouts. In
general, any kid that loves to read and whose parents are looking for
enteraining, educational, and "decent" software. Go look around. There
is a sizable absence of said software.
I'm going about my business as if it were a business. The primary
purpose of a commercial IF user interface is to present the game being
sold in the most attractive manner possible for the target market.
Optional features are important and will get added as required by the
target audience. Even if you're not in the target audience, your
comments are recorded and weighed appropriately. I have already stated
that the Font and Color options will likely be added to the UI. The
question I recently posted was in how to do this seemlessly outside of
using the traditional menu structure. There were excellent responses to
this question.
If your wishes don't align with that path, then at this point in time
all I can do is listen and record your feelings, which I have done. If
I've lost you as a secondary market customer, that's unfortunate.
David C.