Sorry for getting to reply this late! I was with the family and originally thought I’d have more time for this.
I’ll try to reply in one massive post. Apologies if I misinterpret or simplify your points — feel free to correct me.
Many of you pointed out Undum, which I didn’t know about before and I totally should have. They’re not striving for the same thing, in my opinion, but it’s probably still the closest to what I have in mind. It’s criminal that I didn’t find out about them earlier.
How hard will it be to write IF in egamebook?
Matt has a very good point about niche group of authors. Let me walk you through it, though.
Here’s a valid and complete egamebook with some basic scripting.
It’s not a complete disaster (is it better than Undum?), but if anyone wants to write a gamebook like this they are much better off using Twine or pretty much any other system out there. This is not the main use case for egamebook.
For writers, egamebook starts to make a little bit more sense when using a custom library like ZIL (which I built for Bodega, inspired by the classic ZIL that Zork was running on). Here’s an excerpt from Bodega.
Again, maybe not a complete disaster, but it’s more boilerplate and pain than what you’d probably have elsewhere.
This hides the logic for having Rooms with Actors and Actions and Items and Exits. This logic must be implemented somewhere, of course, but the point here is that you have a library for it and you don’t need to do it (as a writer) with the limited capabilities of a domain-specific language (or in pure JavaScript).
Where egamebook hopes to shine is when you want even more than that.
Egamebook didn’t start as a tool to make interactive fiction more complex. It started as a tool to make narrative-based games prose-based (i.e. “more like IF”) and thus (in many aspects) less complex. This is what I failed to communicate. Think about all the pixelated indie games of today — they often have strong narrative, but despite requiring several person-years to build, they still have to resort to pixel art and relatively simple mechanics. What if some of them used prose instead of 2D or 3D graphics?
Making an NPC believably put on a helmet in pixelated 2D takes a day of work. In 3D, it can take weeks. In prose, all it takes is to write “he puts a helmet on”. You can then direct the engineering resources into more important stuff (world simulation, scripting, etc.).
Or so goes my theory.
To come back to the initial question: it will be hard to impossible for a single writer with little or no programming skills to use egamebook — if they want to use its full potential. They can always use it for simple stuff, in which case it’s quite easy, but again — in most cases there will be better alternatives.
Going back to Matt’s niche group — this is either for programmer-writers, or for teams. (This approach is not new to IF, though, is it? Some of the first IF games, like Zork, were — as far as I know — made by either programmers-writers or by teams of programmers and writers.)
“I need a coder to implement my game for me! I’ll do the writing!” trope
Versions of this trope are in every human endeavor, apparently. In startups, for example, it’s “I have an idea for an app and I need some programmer to code it for me”. Ugh.
Two things come to mind:
- Interactive Fiction systems try to make writing software (IF is software, after all) accessible to non-programmers. This is great, but people have to understand this can only work to a limited degree. No matter how “easy” the programming language will be, once you hit a certain level of complexity, you have a problem. When we have so many writers asking for coders — so much so that it’s a trope — then we’re hitting that level pretty hard.
- By trying to make it easy for novices, and by trying to make it easy to start simple projects, many systems make it unbelievably difficult to create anything complex. I’ve seen this outside IF, several times. [rant]PHP started as something that lets you write very simple webs with no boilerplate. It got very popular. Now many complex sites are written in PHP (like this forum, and famously even parts of Facebook) — but many programmers hate it because it trades initial friendliness towards novice programmer for sanity, consistency, robustness and structure. It’s like if Word gave fiction writers pre-filled paragraphs of decent prose but didn’t allow for comments and headlines and sometimes put all your text into Comic Sans. Don’t take me wrong, PHP has its purpose, but many companies learnt the hard way that it’s not the silver bullet and that it pays to use an initially un-friendly, but more professional language.[/rant] This is also why these “I need a coder” cries will probably never get a response — because writing someone else’s ideas in a simplistic programming language is a programmers nightmare. (I think Sequitur’s first post says something to that effect.)
Twist: If there’s a writer who has sci-fi writing experience and wants to help write Bodega, let me know.
Why Dart?
Huge disclaimer here: Dart is a programming language coming from Google, and I work for Google. Not on the Dart team, but still — I’m very biased. (This project, though, has nothing to do with Google — it’s been my side project for a while. By the way, my first language of choice all these years ago was — JavaScript.)
Now that you know the “prose-based game” focus (instead of “complex IF” focus), these reasons why I chose Dart should make sense:
- Dart is similar to programming languages used in games programming. ActionScript, C#, Java, C++. Dart is way more similar to these languages than JavaScript.
- Dart is already being used by game developers. Most famously, @notch (creator of Minecraft) is writing his new games in Dart.
- Dart compiles to JavaScript that is mostly as fast (and sometimes, nonintuitively, even faster) than handcrafted JavaScript.
- I agree that you can do a lot with Javascript. Obviously, everything you can do with Dart, you can theoretically do with JavaScript. But the reality is that programming languages and tools do matter. There are good reasons why, if you search for complex algorithms, you’ll find much better libraries in languages like Java or C# even though JavaScript is easily the most popular programming language ever.
- Dart makes some things that are very hard in JavaScript, quite easy. For example, egamebook is already using threading, which means the game logic can be super complex and still there will be no jerking or freezing of the app. You can run a physics simulation on the background if you want. This is possible through webworkers which are a pain and buggy to implement in JavaScript, but not in Dart.
Bodega: What’s the narrative hook? What are we trying to accomplish? Is the plot more scripted or emergent?
The premise is woefully unoriginal — player is the last man on a stranded spaceship. The other crew members have died from a mysterious illness. The player is slowly dying, too. The initial goal is to survive. There is a twist.
Most of the plot is scripted.
It’s a first episode in a series.
Would it be possible, and if so will it be encouraged, to distribute the stories offline?
Totally. It’s a website, but apart from saving and loading progress “to the cloud”, once it’s downloaded all its assets, it can work offline.
Box2D physics - what would this be for in a choice-based game?
This will not be in the first game, but the idea is to use physics to simulate space combat and then take the results and put them in prose. This allows for completely emergent behavior (fire at one of the maneuver thrusters, disabling it, thus forcing the opponent into a spin until they can recover). It’ll also need a lot of testing before it’s ready for prime time.
Gaah, I didn’t get to answer everything I wanted, and the post is already humongous, and I need to run now.
Thanks everyone for the feedback. Seriously.
PS: @prevtenet: Thank you for you post! It’s amazingly uplifting for me, and your point about “Go to” instead of “Walk to”/“Go to” is a great catch. I’m thinking about ‘congnitive load’ a lot so I feel like an idiot for not having seen this before. Thanks!