Anyone have any thoughts on writing if in C++?
Jamey Lloyd
C++. I'm still learning C++, and I would really like to program games some
day. I thought a good place to start would be with IF. I downloaded a TADS
compiler, and documentation, and read through a good part of it. I played
through ditch day drifter, and a couple other IF games written in TADS too.
I experimented to see how the parser would react under different situations
to have a better idea of how to implement my parser. Now it's really
starting to come along. At this point I'm looking into TADS game source
code, and seeing objects being defined, and instantiated at the same time.
In C++ I haven't been able to think of a convenient way to duplicate this. I
am currently coding a unique class type for every single object in the game
pretty much, with a few exceptions. Does anyone have any experience doing
this? I would love to hear your thoughts, or see some source code.
Jamey
David Betz
system rather than a class/instance system. In a prototype system there is
no real distinction between an class and an instance. An object can inherit
from one or more prototype objects and override any of the inherited fields
or methods. This can't easily be done with C++ or Java. Of course, you could
just define a single class called GameObject and make every actual object in
the game an instance of that one class. To work like most IF systems you'd
have to add some sort of property list facility to that class to make it
possible to dynamically add properties. Another problem you'll run into with
C++ is that it's hard to create complicated interlinked initialized data. A
game world is an intricate web of objects that refer to each other. You may
have to write code to initialize these references at runtime rather than at
compile time like most IF systems do.
"Jamey Lloyd" <intr...@idirect.com> wrote in message
news:WmDr5.5785$lE6.1...@quark.idirect.com...
Larry Smith
> "Jamey Lloyd" <intr...@idirect.com> wrote:
> > I was just wondering if anyone here has attempted to write an IF game in
> > C++.
> Attempted, perhaps. I've never heard of one being finished...
I'm afraid I have to be blunt, here. No one should ever
write _anything_ in C++. Even Fortran would be better, at
least there's an existence proof.
--
.-. .-. .---. .---. .-..-. | "Bill Gates is just a monocle
| |__ / | \| |-< | |-< > / | and a Persian Cat away from
`----'`-^-'`-'`-'`-'`-' `-' | being one of the bad guys in a
My opinions only. | James Bond movie." -- D Miller
Magnus Olsson
Larry Smith <lsm...@redhat.com> wrote:
>I'm afraid I have to be blunt, here. No one should ever
>write _anything_ in C++. Even Fortran would be better, at
>least there's an existence proof.
Sigh. School's started and troll season has begun. Too bad that
I'll have to killfile a perfectly good thread.
Seriously: Please, please, please don't start any more religious
"my language is better than yours" wars. *Especially* not when
the languages aren't even IF languages.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Jonadab the Unsightly One
> >Furthermore, if what you want is to write IF, then learning
> >one of the IF languages (which have parsers already written
> >for them) will take a LOT less time than writing a parser
> >in another language.
>
> I don't necessarily agree here. It depends on your reason for
> writing the game. If you want a game to distribute, and have
> a wide number of people be able to run it, then yes using Inform
> or something like that makes sense.
>
> If you want to game to be a fun an interesting project to sharpen
> your skills in the language of choice, then it can be quite
> useful. You'll have to deal with a number of things, console
> I/O, disk I/O, data objects, game state, memory usage, etc.
Yes, absolutely. If your reason for writing the parser is
as an advanced exercise in the language in question, great,
it's an *excellent* exercise, so go to it. One caveat is
that it is a rather advanced exercise, so you should probably
have a solid working understanding of the basics of the
language first. If you do "hello, world", work your way
up to a while loop that calculates successively large
factorials, and then decide your next project should be
an IF parser, you're getting in WAY too deep WAY too fast.
Especially if you have to build the world model too while
you're at it. You should probably implement some simpler
things first... a binary search tree, a couple of standard
sorting algorithms, a hangman game -- you know, the usual
first-semester exercises -- to get familiar with the
basics of the language before heading full-tilt into
a project that will have you writing thousands of lines
of reentrant code that has to go all the way from the
bottom level (characters) through several layers of
abstraction to finally decide on exactly ONE very specific
action. A freshman in his first drafting class does not
start with blueprints for a working space station. He
starts with a boxes and brackets. It's weeks before
he ever draws even a front-view of a house, much less
complete blueprints with electrical wiring, plumbing,
and the works. Sure, if you're a quick study and don't
mind making and correcting some mistakes along the way
you might start a major project before you are 100%
comfortable in the language, but you should at least
have a basic working knowledge of the fundamentals of
the language first, IMO.
--
Forward all spam to u...@ftc.gov
Jonadab the Unsightly One
> I agree with not writing IF directly in C++, there are plenty of decent
> development systems out there (Inform, TADS, Quill, etc).
> But Fortran!?
Hyperbole, I think. Fortran is not a good choice for IF either.
It is good for certain things... especially big-time serious
heavy-duty number crunching, the kind of thing you do on a
computer that costs more than the annual budget of most
small nations. The little experience I had with Fortran
was mostly positive, sans some problems with an incorrectly
installed compiler that were not the language's fault. But
it's not well suited to IF unless they've made some serious
changes to the language that I don't know about.
Chris
> In article <39b135c4...@news.bright.net>,
> Jonadab the Unsightly One <jon...@bright.net> wrote:
> >"Jamey Lloyd" <intr...@idirect.com> wrote:
> >
> >> I was just wondering if anyone here has attempted to write an IF game in
> >> C++.
> >
> >Attempted, perhaps. I've never heard of one being finished...
> >
[snip]
> As far as the parser, that can be tricky. Probably you won't
> have one as robust as Infocom style games, but you can do better
> than a VERB NOUN type one as well.
>
> C++ has some advantages over C, of course. The class hierarchy
> is a natural for describing objects in a game. Also, the STL
> containers help a lot, since managing the objects is easier.
>
> When I took OO programming as a grad student, I did a C++ game modeled
> on MUDs, although for one player (SUD?).
[snip]
It IS possible - as I've done it. Implemented a parser using what purists
would probably dismiss as a kludge, using the object orientated-ness of C++.
But also as mentioned above, it is a bit unfinished - due to lack of time -
but the 'engine' is there, and is able to match Inform's parser in terms of
performance (the only thing that is unsupported, and it could be, when I get
round to it, is the 'it' word, referring to the last thing mentioned, and
'oops'.)
However, to write the actual game using the engine is time consuming and
boring, compared to writing the engine, so I stopped. The beauty of Inform
is that it you compile your game using the Inform language, and this is far
easier than having to do the same for every game using your class
definitions, constructors and the like for every object in every game that
used your system. Takes ages for a small game, and is quite confusing.
The reason I did it at all was that I wanted the game playable over the
internet, with teams of players trying to solve the game, rather like a MUD
but with less of a competitive aspect. Also, as mentioned above, it is quite
interesting to actually attempt the parser. Mine grew from drunken code, as
all my sober attempts were rubbish! So get drunk, and start coding...
Chris
P.S. If anyone wants to write the actual game for the above idea, let me
know...
--
Chris Lund
Jesus College
Cambridge
Chris Sargent
lot of sense.
The object-orientated paradigm of C++ fits neatly with IF, indeed several IF
development systems provide some form of OO - objects, inheritance, methods,
attributes, etc.
But I think you're right - writing an entire IF game in C++ is a bit dumb, for
these reasons:
C++, by it's very nature, is a generic language, whereas IF is a specific (and
complex) application, and therefore probably warrants a development environment
and/or language of it's own, which could be implemented 'under the hood' in C++
of whatever.
When developing, any compilation errors are going to be C++ specific rather than
IF specific. A more IF-orientated system should provide better debugging
support.
But I think the main nail in the coffin for a C++ based IF language is that IF is
largely text-based, whereas most programming languages are logic / maths based.
i.e. an IF game generally involves large amounts of text which are tightly
coupled with a smaller number of objects, game logic, and of course the parser.
C++ doesn't lend itself to this very well at all.
I've been toying with various ideas to resolve these issues using a Java-based
game engine and a proprietary IF language, with varying degress of success.
Defining and implementing the language, the parser and the game engine has been
relatively easy. The hard part has been to try and reduce the amount of logic
developers have to implement to make even the most basic game. Using an
inheritance hierarchy of pre-defined object classes helps (i.e. all the
'standard' code is contained in the base classes), and I've come up with various
other tricks and clever ideas to reduce the workload of the developer, but it
still seems to take ages. Bah!
Has anyone else worked on a similar theme? Have you come up with any cunning
plans to reduce the workload on the developer?