Interest in a "C"-based IF authoring system?

Technical Development Development Systems
1

Hi all,

Last year, in a fit of madness, I wrote a (very rudimentary) IF authoring system for the CBM64:

https://dodoif.wordpress.com/ Dodo was written in BASIC*), and an author would have to extend the framework with his own DATA sections and BASIC code to create a complete scenario.

Now I lately came across the cc65 “C” cross compiler (http://cc65.github.io/cc65/) which also can target the CBM64, and provides a reasonably capable API.

So, I was wondering, would there be any interest out there if I used a concept similar to Dodo with cc65: Provide an authoring framework where the user would have to provide his customized code in “C” for special actions etc.? It would target primarily the CBM64, but the resulting code should run on most other platforms as well.

I know that “C” is far from being the best-suited language for the job, but I think the advantage of this approach over systems like Inform or TADS, which invent their own languages for the authoring, would be that any author wouldn’t have to learn a completely new language, but could employ an already established system which he may know, and/or for which he would find loads of information and tutorials on the web. Plus, it would run on retro-machines like the CBM64.

What’s your take on it? Would there conceivably be any interest? (I know that the overlap between IF authoring and retro computers is small enough…)

Cheers,

syzygy

*) Commodore BASIC V2.0 being notoriously fickle and difficult to handle

2

Hi! This is cool.

It’s nearly xmas, which means it’s time for me to once again “waste” time on building things for retro computers.

I’ve been targeting z80 to ACTUALLY RUN on retro machines and not (just) emulators. I assume this is the same gig here with the c64. For the z80, i did a lot of compiler evaluation and found sdcc to be the best (by a long way). However, it does not support the 6502, so that’s where your c65 comes in. but…

I would say, you should give it a bit of a test first. The problems i had with compiling C to 8 bit computers was making sure that you could do stuff like;

unsigned char i;
for (i = 0; i < x; ++i) …

And it would use BYTES and not 16 bit ints. I did similar tests to passing parameters to functions etc. On the 6502, the question is; does c65 make good use of zero page, because otherwise it’s code will be pants. That’s something really important to check. Elsewise, your c64 will be like a C8, after the FAT code has filled it. :slight_smile:

turning to your project,

If cc65 code is good, i would totally recommend cross compiling from C rather than BASIC. It was an experiment of mine for the z80 to see if this worked better than basic or some other intermediate form. compiled C wins hands down, and it rocks speed-wise.

one of my projects: github.com/voidware/trek14

It’s not IF, but i was vaguely thinking of compiling the Scott interpreter for the Trs80, since it’s about 1 page of c code and would work a treat. then recompile those Scott Adams adventurers - or change them :slight_smile:

So, then you could err revive dodo and even consider a C128 edition.

:slight_smile:

3

I’d guess the general interest in a C-based IF system would be pretty low.

From time to time, IF enthusiasts come to the table with alternate IF authoring systems in which authors can develop IF in a “real” programming language, typically one of the top 20 languages on the TIOBE index or at least a language that ranks highly on StackOverflow’s “most loved languages” list. insights.stackoverflow.com/surv … and-wanted

But none of the most popular IF systems require authors to use a “real” programming language. Instead, since most IF authors see themselves as writers first and coders second (if at all), all of the most popular systems use a domain-specific language for IF, ideally one that makes it easy to write extensions in another “real” programming language (typically JavaScript).

For comparison, Undum github.com/sequitur/raconteur

According to the StackOverflow survey, C is a language more dreaded than loved. Many people who can develop working programs in higher-level languages like JS or Python fail to accomplish anything at all in C. I would not expect a C-based IF system to be a big hit.

Having said that, if this scratches an itch for you, it could succeed anyway, if you’re prepared to do a lot of work on it.

Overall, the language that an IF system uses is arguably the least important factor in making it popular. The most important factor is to implement an entire complete “admirable” game. Most people decide to use an IF system because they see a game that they admire, and they say, “I want to make a game just like that! Whatever system the author used to make it, I’ll use that system, too!” Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

If you build an IF system that helps you to develop an admirable game for the Commodore 64, and you demo it on real C64 hardware (and maybe a few other legacy platforms) at expos, and then also make your game available on other more, ah, accessible platforms, you might be able to parlay your C64 compatibility into some attention in the press, which could develop into a real movement over time.

But if you’re asking: “if I just build a C-based IF system, will lots of great IF authors get excited about it and build great games in it?” I think history shows that the answer is no.

4

Hey, what about ChoiceScript for the C64? or the TRS-80. Would you donate some games?

5

I’m not personally super excited by it, not least because I have no access to legacy C64 or TRS-80 hardware, but if someone demo’d me a working prototype ChoiceScript interpreter (cross-compiler?), I could probably talk to one of my partners about making Choice of the Dragon available.

I assume that for any ChoiceScript game of non-trivial size, someone would have to add UI like, “please insert floppy disk number 4 side 2” or whatever. I have no interest in doing that myself!

6

BTW, I note that Rust is at the very top of the “most loved” languages list, and I understand that it has excellent cross-compilation facilities.

I’m sure that a Rust-based IF tutorial would rank highly on Hacker News, at least, and if you or someone else figured out how to use Rust to target 6502 processors, that would be a starting point for implementing Rust games for a bunch of beloved old devices.

7

You’re right about that. I think a CS interpreter could fit in a 64K machine, but then there’s the ~300k word story.

The idea would be that each scene would have to fit on a floppy disk and the disk swapping would be at a scene granularity. The scene files would be the original CS pre-processed to have some kind of index. CS variables would have to fit in memory.

it’d be a crazy project :slight_smile:

8

More than a few times I’ve fallen down the trap of thinking “well, there’s no modern technology going on under the hood of a ChoiceScript game that a vintage machine wouldn’t be able to hack, is there?” but of course yes, they do contain rather a lot of text. But compression of in-game text is a lost art that was perfected by eg. Level 9, so surely resurrecting its peak efficiency could get us closer to the pipe dream of a COG game on period hardware.

(Who am I kidding, just get them hosted on QuantumLink and have the C64 owners play the games online through that service!)

9

Thanks everybody for your comments and thoughts, it’s much appreciated.

Just to clarify two points:

  • cc65 already exists and AFAICT is a venerable “C”-compiler with good pedigree. It can produce executables for a lot of 6502-based platforms, among them the CBM range of machines.
  • The idea wasn’t so much to run the executables on real hardware (I wouldn’t have access to any), but using an emulator like VICE. (A few tests I ran with the cc65 and VICE showed that that team works quite nicely.)

Writing a ChoiceScript interpreter for a machine like the C64 sounds like a challenging task. I presume it would be feasible when one drops some of the CS features, but as others have noted, the limited amount of RAM in general would require disk swapping. I’ve checked out the COG website, is there a formal definition/documentation of CS anywhere? I’m curious.

Cheers,

syzygy

10

Back to dodo, I’ve lost track of the objective. is it;

(1) to write IF in dodo BASIC for 64.
(2) to convert dodo BASIC into “C” and make a new C-based dodo IF system for modern machines.
(3) to convert dodo BASIC into “C” and cross compile a new C dodo IF system for 64.
(4) to extend dodo BASIC to call out into “C”, write IF in C and run under modified C64 emulator, although it wouldn’t actually work on a real C64.
(5) to find a C64 BASIC interpreter in C and thus run BASIC dodo IF games on other machines.
(6) dodo is dead but inspires a “dodo2” new BASIC IF system.
(7) dodo is dead but inspires a “dodo2” new “C” IF system.
(8) make a dodo-based, or otherwise IF system for C64.
(9) make a dodo-based, or otherwise IF system for C64 and other retro platforms
(10) make a dodo-based, or otherwise IF system for modern platforms.
(11) something else.

11

Sorry for creating confusion.

The original idea:

(7) and (9): Creating a “C”-based IF authoring system for the C64 (real hardware or emulator) and possibly other retro machines.

The concept would be similar to Dodo by not inventing a new language to write the scenarios, but by providing a framework/engine (in “C”) to which the scenario author adds his game-specific data (in “C”).

The “C” compiler of choice would be prolly be cc65, since it’s meant to target 8bit machines.

Later, the idea was brought up to write an interpreter for ChoiceScript in “C” for 8bit machines, which got me sidetracked. (I’m easily distracted. :slight_smile:)

Cheers,

syzygy

12

[rant=musing probably unhelpful to OP]IMHO, I think authoring systems that are aimed at authors are the ones that will garner the most interest.

When you draw the Venn diagram of “people who want to write” and then circle “people who want to write IF” within that, you’ve already whittled the audience down a lot. Another circle in there “people who can code in C/JS/python[insert any language]” is naturally going to be teeny. It’ll be a circle, but a very specific one, probably without the wide appeal you are asking about. (I won’t even go the level of making another tiny circle for “on retro systems that aren’t widely in use anymore”, which I know is basically a hobbyist-labor of love-preservation thing. Mainstream IF authors aren’t going to write for a “dead” system, no matter how popular with enthusiasts - we want our stories to be read.)

The first question that is always presented to (and likely infuriates) anyone who asks “would people use a system based in [X]?” is “What does your proposed system do that Twine or ChoiceScript or Inform doesn’t already do?” If you cannot answer this without falling back on “Well, you can do it in C!”, then I refer you to the Venn diagram we drew above.

I’m a dummy who doesn’t have extensive coding knowledge. But I like to write IF. I’m going to gravitate toward systems that get out of the way and let me write without tinkering too much with the greasy engine parts. If I was a C guru or a JS whiz, then I’d probably do that. There are more people who can write a short story than who can debug C. To have broad appeal, that is the audience you should aim your system at. Exposing the engine parts and allowing an author who does know C to get in there when necessary can be a useful feature, but unless your spec efforts are for your own edification and enjoyment, you run the risk of attempting to re-invent the word processor. If you know how to make the best word processor, then go for it.

Please don’t get the idea that I am trying in any way to quash your ambition - there are hundreds of small obscure systems that do very specific and impressive things, often built on separate coding languages. If you have a unique type of game you want to create, and the best way to do it is in C on a VIC-20, then more power to you! Even better if you want to benevolently share the codebase so people can try it themselves following your model. The best way to accumulate interest in your system is to show people something they don’t recognize but like - I’m the first one to go “How did they do that? I want to do that!” when something impressive hits. If you can solve an age-old problem or frequent request (like reliable object/location-based world model inside of a choice engine, for example, especially without making me go elbow-deep in a language that requires two-inch thick paperback reference manuals to learn) please proceed!

TL;DR - Write the game/engine you want and make it a labor of love, or write your own system for public use if you will really enjoy doing so. If it does cool things or solves problems people have, you’ll get an audience. If you need the audience to bother creating it in the first place, you’re not going to enjoy doing it merely for other people.

STL;DR - What dfabulich said.[/rant]

13

I was wondering what’s already out there in terms of C based small IF systems. No need to write one if one already exists.

Marnix’ XVAN is in C, but i took a look at memory usage; although small for PCs, it’s over budgets for retro 8 bit. eg COD ~ 33k, not including interpreter.

What else is there?

Admittedly, it wouldn’t be too tricky to write a small system (parser based?) together with a few library verbs and a simple world model. Actually, this would be quite a fun exercise.

Dodo philosophy: keep it small and keep it simple, good for learning.

Perhaps add a bit of procedural text generation too, spice it up and give it something different for people to chew on.

14

XVAN started on my Atari 1040ST with Megamax C compiler about 25 years ago. The Atari had a stunning 1 MB of memory, way more than the C64. I wrote XVAN to be low on memory usage. It uses no external libraries, just plain C code. The compiler uses dynamically created (malloc) linked lists rather than reserving maximum size arrays, so it only takes the memory it needs. The interpreter has a mechanism for swapping locations and objects in and out of RAM so it can handle games that don’t fit in the available memory. Flags are 1 bit in size and grouped in 16 bit words (could be easily changed to bytes). However, I must say that with the functionality I added in the last years on windows/linux, I got a bit lazy with limiting memory usage :slight_smile:

One more thing. XVAN uses almost everywhere int32_t type of integers for ids, opcodes, etc. But when I think about it, in many cases an unsigned byte would also do which would reduce size of the stories/games as all identifiers and opcodes would go from 4 bytes to 1.

But the difference with what you want to achieve is that although XVAN is written in C, the stories/games are not written in C. XVAN has it’s own language with a complexity level somewhere in between Inform 6/TADS en Inform 7.

15

Hi Marnix!

Thanks for the inside info on XVAN. You’re right that Xvan is really good with memory, the 33k i measured is actually very low compared to the megabytes things use today.

What i did is change all your malloc() to xmalloc() and all your free() to xfree(), and made the “x” versions call the original versions but also keep a memory usage counter. That’s how i measured the usage.

You’re right, there were no large chunks of memory allocated, only bits and pieces. The usage would rock on old Atari ST or Commodore Amiga machines, but for the C64, not quite there.

It’s because xvan is too good! I think for this project something simpler and more “poor man” will have to suffice.

Was worth checking out tho’

16

I think your idea could work. I have not used cc65, but I know some people have used it to write programs for NES/Famicom (although I think ca65 is more commonly used), so it could work. (But, even if BASIC is in use, it could be possible to write your own BASIC compiler, I suppose.)

I should think that the program should be designed so that it can work on real hardware, even if you don’t have any and even if mostly only emulators are being in use anyways.

I have designed my own system TAVERN (which is Forth-based), but have not ported it to C64. I would expect it should be possible though to port it to a computer that Z-machine programs could also run on. (But if you do, there is no need to use the standard Hamster-archive-based file format.)

I do not know ChoiceScript, so I do not know how well it can work on C64. (And again, converting to a new file format may be helpful.)

(Note also that I do not know much C64 programming; I am more familiar with Famicom.)

Perhaps another thing that might be mentioned is that one advantage of a VM-based system is that implementing save game is easier to do, than with modern native codes.

17

Have y’all seen this?

linusakesson.net/software/zeugma/index.php

Discussion here:

I bet this could be ported to NES/Famicom; it would probably be reasonably playable on the Famicom keyboard.

18

Thanks for posting this. I hadn’t seen it before.

it looks really cool, except i understand that it requires a 512K expansion unit. Pity, it would be nice if instead it could load the story from floppy disk. Also, you can’t save game.

For it’s objective of being high performance and compact on the C64, it’s written in assembler, which works. But is unfortunately not portable.

What’s coming out of this discussion is that there appears to be no small, portable “C” (or otherwise) IF system for small machines. Obviously, I’m not expecting such a thing to be THAT powerful, but i do think, conversely it could be not THAT bad.

For example the Scott interpreter could be easily ported to C64 and 8 bit in general. So that represents, at least a minimum standard.

All along, I’m expecting someone to pop up and say, “hey, what about wombat-if” or something like that, which written ages ago and fits the job 100%.

You know, otherwise, the idea of writing something could become a reality. shockingly!

19

Thanks everybody for your input – gives me a lot to ponder. :slight_smile:

Cheers, and happy holidays everyone,

syzygy

20

Many years ago (early 90s) I worked with an alternative Unix called Coherent available from the Mark Williams Co. It had the most efficient x86 C compiler I have ever seen. The executable files were less than half the size of other C compilers of the time.

The Coherent System and the C compiler are archived here: github.com/joedemo42/coherent

It could be useful. ?

I still have a couple of the manuals they supplied with the OS. They are still a useful nix type manual.

v/r
fos1