Question: Most Important Features in A Game Creator

Technical Development Development Systems
1

What I am looking to build a full-featured and functioned Interactive Fiction/Text Adventure Game creator. To do this properly, I want to take community input on what everyone believes are the most important features and abilities for a text-adventure maker to have.

Some things that I know will be in the system:

  • Cross platform building & playing - all games made in the system (which will be avaliable for Mac, Windows and Linux) will be playable on Mac, Windows & Linux as well as, with some modification (available in the system) online WITH NO DOWNLOADS (Other than the game file for the offline versions) REQUIRED BY THE PLAYER.
  • Automatic maze, puzzle and NPC AI creators (The system will be able to create NPCs and configure their movement and abilities, create mazes and puzzles based on some basic information inputted by the gameā€™s creator)
  • Conversation Tree support
  • Background and foreground items
  • Character classes, and custom abilities/benefits of each class
  • Difficulty level support, with many ways to regulate and change difficulty
  • Automatic game manual creation wizard (Very quickly create a manual for the game, detailing all the features, goals, information and commands within the game)
  • In game support options (You will be able to create a clue system within the game similar to Infocomā€™s InvisiClues)
  • No coding required by the gameā€™s creator ā€“ the system will take details and automatically create the gameā€™s code and save system.

I would also like to eventually make the project Open Source and it will be freely available.

I will work to include all the features and abilities mentioned here within the system. If you like an idea, feel free to include it again in your own post ā€“ ideas with the most mentions will be worked on first.

Edit: it would be for a parser based system.

Thank you in advance.

2

Would this be for parser-based (Infocom-style) games? Some of those planned features are quite specific, do you have some existing game in mind that would be a good example of what you could create out of the box with this new system?

Also, mazes are pretty much universally hated by everyone so I would consider if itā€™s really necessary to have first-class support for them.

1 Like
3

Thatā€™s an interesting list of features - some are for development issues which are often handled poorly by other dev systems, like cross platform support and conversations, others Iā€™ve never seen requested, like automatic mazes or manual creation.

But, to be a little blunt, the number one thing you can do to get interest in a new dev system is release an excellent game/story to a major comp like IFComp or Spring Thing. We are already surrounded by good dev systems. The way to stand apart is to release a game people love.

Personally as someone involved with the slow maintenance of our existing systems it saddens me a little that so many people spend time on new dev systems that never gain any traction when the old systems need continuing work. But I donā€™t know how to change that.

Donā€™t hear me as saying you shouldnā€™t continue. But please have realistic expectations: people wonā€™t use it unless you release an awesome game first. If working on a project gives you enough enjoyment, go right ahead. But if you get more fulfilment by people using your work, consider helping another project as well, or you could implement these features as libraries for another dev system.

3 Likes
4

Iā€™m sure that the feature I suggest isnā€™t unexpected :wink: but of course for me not only the project should be open source, but also the compiler(s) and libraries used in building the creator. This specific issue is in at least two major parser-based IF languages, and indeed are both not considered by me ā€œfor actual developmentā€

On creator, as opposed to language, Iā€™m watching the effort put into porting ADRIFT into linux (but Iā€™m not holding my breath) so, a fully OS creator should be an interesting, if not welcome, addition.

Best regards from Italy,
dott. Piergiorgio.

5

So, IMO, if you were looking for a project in this space, rather than develop another text game creation platform, a much more exciting thing would be a wizard driven/drag and drop IDE to enable the author to both simplify development and create a modern UI for one of the existing development platforms (Iā€™m thinking specifically Inform). Iā€™d use it in a heartbeat.

As Dannii pointed out there are loads of dev platforms for IF/text adventures but none of them are accessible and simple to engage with. None of them allow me to easily create a modern UI that might appeal to a modern audience more than the current antiquated interpreter delivery format.

As an author, I would love to be able to use the maturity and richness of Inform, and to be enabled to relatively simply create something like StupidRPG or DetectiveLand.

2 Likes
6

Thanks for the feedback. I totally get what you are saying and agree, though Iā€™m not quite yet at the point of say making a game with the system. (I do plan on making a few games down the road and do have a few ideas including for a procedurally generated adventure game and a single or multiplayer competitive puzzler).

As another poster down the thread seemingly pointed out, the biggest problem that I have with current parser game developers is that they require a lot of handcrafting and ā€˜codingā€™ to get to work right. I was envisioning this as a more friendly designed system where you didnā€™t have to deal with the coding and just had to focus on building an engaging game.

For me I get enjoyment in building tools and tinkering with stuff which is my main focus here. But I will do some rethinking and look at ways that instead of just creating another developer, I can add something that makes life easier for developers while not sacrificing what they already know and love. (Though building a Drag and drop for something like Inform is probably currently out of the question until I can examine how that system works closer and see if it is possible to build a coverter that could take input and auto code it into inform-like standards)

Thanks!

7

I think the answer may be for the curators of existing systems to post requests for help in the development category and tag it ā€œhelp wantedā€. Describe the system/tool/project. State the general skill set you are looking for and how people can contribute.

8

You lost my interest with ā€œgame file for the offline versionā€.

For me, any new system would have to substantially improve on the existing systems and my most preferred improvement would be for the creation of standalone game executables (with no player/interpreter needed).

2 Likes
9

What you describe is pretty much the ideal for a game system, and many of those features are sought-after, found in one system or another but not all together in one.

You said you want to make the development easy with ā€œno coding requiredā€ thatā€™s awesome, and Iā€™m a big fan of helpful IDEs like Inform7 and csIDE for ChoiceScript. That said, itā€™s also really helpful sometimes to have a view to see the raw code for any given element and be able to adjust it manually if necessary.

One of my main asks is usually that any system can compile a complete standalone playable game - either an HTML page or a single executable for respective platforms - which the author can submit to a Comp or an appstore and a player can play without needing an interpreter or the creation software nor any other peripheral software except perhaps a browser.

Maze and Puzzle creators I see as less important unless there is a specific way the system presents both of these - such as a physical top-down or 3D walkthrough of certain environments (useful if youā€™re wanting it to be usable for RPG-esques) or if there are some specific graphical representation of certain types of puzzles, such as lockpicking or assembling torn pieces of maps or letters or other images.

When you say ā€œbackground and foreground itemsā€ do you mean graphically? Such as a sprite-based system for images that would remove items from a picture that no longer exist in a room?

Character classes and conversation trees are both great - essentially those would hopefully be elements of a general ā€œcharacterā€ module and optional based on the type of game. If the system handled things such as bringing up a specific interface for characters that had a portrait and the dialogue tree and inventory-trade type windows.

This I see as less critical for IF and important only if there is an included combat system.

A way to assemble progressively accessible in-game hints is great. An in-game manual is also nice, but essentially only need be a button to pull up a text window with screenshots or a PDF, potentially based on the context the player is in.

It sounds as though youā€™re going more toward a general ā€œadventureā€ system that can have elements of an RPG.

If I were to give specific advice, Iā€™d say donā€™t worry about a parser. As much as I love parser games, if you can display a room and objects and inventory and puzzles and characters with dialogue trees, as graphic elements (even systematically, if not visually/realistically) and each of these are text modules with choices and buttons to click and still images, thereā€™s actually very few times youā€™d want the player to type (except for an occasional text input box to name a character or enter a password.)

A parser may actually be superfluous at that point, and Iā€™m thinking some of the items in bullet points work against an all-text format requiring typed commands.

2 Likes
10

@HanonO For background/foreground objects, I mean like items that you can interact with/take (foreground) and objects that are mentioned in flavour text and can be only examined/looked at, to create more depth in the environment.

I do plan on having the ability to create the standalone game, no interpreter required for a variety of systems (Linux, Mac, Windows, with the ability to have an online version). The code will be available in the system ā€“ Press Compile and it will spit out a version of the code that can be easily (with any text editor) looked at and custom-edited if so desired.

For the puzzle and maze creators, I donā€™t mean a graphical look at, rather it will help automatically build the code as well as helping create all the custom variables and reasons required.

Yes, there would be a playable character and a NPC-base character, and then you would be able to add species/descriptions/names and classes to them, as well as allowing various classes and species to access special abilities, commands (For example, you could set certain characters as a Wizard, and then only wizard-class characters could use commands related to spellcasting.

For difficulty, the option would be there. It doesnā€™t need to be used, but you could regulate difficulties, damages, health, and such with the system.

The in-game help would be creatable by the author and then grabbable in game by pressing Help. Then you could see a list of all items that you can get help with (Or this could be included with the manual) - and then you could select that one and then by pressing enter/next, you could cycle through multiple hints for each item.

For the manual, the creator system would allow you to create a PDF/Word version of the gameā€™s manual, which you could have as a separate download beside the game, or could include in the gameā€™s files.

For now the system is parser-based (ala Infocom with improvements), but I could see moving it to a point and click system (ala Sierra) eventually.

11

Could you elaborate on this? It seems counter-intuitive to me, but I could be stuck in an old-fashioned way of thinking. Virtual machine technology was a key element of the commercial success of Infocom, and was crucial for the proliferation of the hobbyist IF movement that emerged in the 90s around Inform and TADS. We are not living in the 90s anymore, though. A lot of things have changed, and if you could pinpoint which of those changes has turned executable files into a viable alternative, that could be very illuminating. To me, it seems like all the relevant roadblocks are still there.

Starting with the matter of platform diversity: Back then, people used Windows, MacOS, BSD, Solaris, BeOS, AmigaOS, PalmOS, and many other systems, all incompatible. Today, people use Windows, MacOS X, iOS, BSD, Linux (Gnu, Android), web browsers, and more. What system(s) should you target? What systems will people use ten years from now? A hundred years? Whatā€™s more, these systems are constantly changing, with APIs and libraries being added and removed (broken, deprecated) all the time.

Yet, remarkably, because interpreters are kept up to date, we still have access to a substantial part of the IF canon from the last 40 years.

For stable platforms, I will concede that executable files are a viable way to distribute new games. By stable platforms I mean platforms that have a track record of remaining rock solid for decades. Case in point: The Commodore 64. A game released as a C64 disk image will remain playable for centuries, simply because this platform provides a well-defined, stable binary interface. Even in the face of dying hardware, thereā€™s a vital community of people who are keeping the emulators up to date. In a sense, then, the longevity of this computer system is ensured by effectively turning it into a virtual machine.

Apart from compatibility and longevity, thereā€™s also the matter of security. It is becoming increasingly difficult to run native executable code, especially when downloaded from the internet. Some platforms require all programs to be signed. Others tend to be equipped with anti-virus scanners that blacklist anything that looks the slightest bit unfamiliar. Users, too, are becoming increasingly careful, which is understandable in a world where harmless bootblock worms have turned into keyloggers, botnets, and ransomware. In a free-for-all IF competition, for instance, would you download and run any executable file from any pseudonymous author? If you as much as hesitate, why would you want to publish your IF in that way?

I can anticipate one counter-argument, which is that itā€™s easier for the end-user (player) to run a game with a single click, compared to having to install a separate application first. This is true, assuming everything works out of the box. As I have argued above, it wonā€™t: Platform compatibility, anti-virus software, and decades of API drift will get in the way. What about web games? Javascript is essentially a virtual machine, where the interpreter (a web browser) is pre-installed on most systems. But itā€™s not a stable virtual machine. It keeps changing, and itā€™s not even implemented consistently across the major web browsers. Twenty years ago, people were putting web games in java applets. Those games donā€™t work anymore, at least not in any pre-installed browsers. Then it was shockwave flash. Those games donā€™t work anymore either. Unless, of course, you recreate a historical browser environment by downloading an interpreter.

So from my point of view, it still seems like a separate interpreter is the most compatible, future-proof, and secure distribution mechanism available. Please tell me what Iā€™m missing.

3 Likes
12

I would like to take the contrary position;

I think the ability to create a deployable game with ā€œrun with one clickā€ is the biggest missing feature of most systems. And thereā€™s nothing wrong with a new system initiative that does not work in the same way as (nearly) all the others, providing it has certain advantages.

Unless you expect your consumer to separately get the interpreter and the story, youā€™re going to have native code there anyhow. Iā€™m not advocating a non-interpreter approach, but only something that looks like a binary from the consumerā€™s point of view.

Letā€™s suppose thereā€™s a coder, an artist and a writer who want to make an IF game. Letā€™s also suppose that theyā€™re hoping that, maybe, they could make a paid app/product from their work. The prospect of, at least, some compensation for their effort is a good motivator.

What system should they choose?

Iā€™m not seeing many systems out there that tackle deployment into a ā€œsingle clickā€ product for desktop and for mobile.

Oh, and it must have graphics and sound too.

Build a new integrated multi-platform GUI and interpreter, supporting a fairly simple game mechanic (eg choices), supporting graphics and sound. Chuck in a whole bunch of settings and options (themes, fonts etc) for people and make it easy for writers and creative people to productise their work - and youā€™re onto something!

13

Oh, I agree that being able to launch a game with a single click would be great. I just donā€™t see how platform-specific executable files provide that functionality.

An executable file is bound to a specific operating system, a specific processor architecture, and a specific period in time (due to changing interfaces). If any of those factors are off, the potential player needs to be strongly motivatedā€”and more or less technically skilledā€”to get the game running.

Well, in that case I donā€™t think youā€™re taking a contrary position. I was specifically talking about executable files, what @Wysardry referred to as ā€œstandalone game executablesā€.

ā€œDesktopā€ is not a single, stable, homogeneous platform, and neither is ā€œmobileā€, and even if they were, they would still be two very different systems. The only way to get the same code to run on two different systems is to use a virtual machine.

But if we only look at the near future (which is kind of parochial), then clearly javascript is the most widely available pre-installed virtual machine. Thatā€™s a bit of an oversimplification, because complex javascript applications often have to poke at their surroundings and try to detect what particular dialect of javascript is understood, and the active set of dialects is evolving over time.

So, yeah, if theyā€™re only concerned about the present, they should choose something that will let them put their story on a web page, powered by javascript. This includes nearly all current IF dev systems.

If they want people to be able to read the story five years from now, or fifty, then they need to put the story in some format that is:

  • Offline, because servers go down.
  • Independent of OS and processor.
  • Isolated from the cutting edge of technology, where everything is constantly changing, by at least one level of virtualization.

Now, a story could still be bundled with a default interpreter into a single file, as long as itā€™s technically possible to separate the two when the interpreter needs an upgrade.

But if that bundle happens to be an executable file, then it will inevitably be built for the wrong OS, or the wrong processor, or the wrong decade, from the point of view of most potential readers.

For a bit of perspective, if your writing is sufficiently good, then approximately 100% of your readership will be born after your lifetime.

14

I am currently more of a game player than game author, so that might be why youā€™re having a problem seeing it from my perspective.

If I want to buy and play a game, I generally go to somewhere like Steam, GOG or maybe the Amazon app store. I expect my download to include everything I need to play the game and for it to be of a reasonable size for the type of game it is.

Your proposed system sounds similar to ADRIFT and Quest. Iā€™m not sure how large the Quest desktop interpreter is as the site only has it bundled with the authoring system, but the ADRIFT player download is over 4Mb. Gargoyle is currently using over 8Mb of my disk space, which is ludicrous for playing games that used to run on machines with 64 Kb of memory.

As a player, I am not going to want to download a huge file to play a small text-based game, especially on a mobile platform where I may be charged for my data usage and/or my storage and memory are limited.

The biggest problem with an interpreter system is that it has to be able to play any type of game the authoring system can make, which means there is a lot of redundancy in the code. For example, it might support graphics, sound and video, which is not needed for a text-based parser game.

If the game source was compiled for each platform, then only code that is actually used for that particular game needs to be included.

A virtual machine is not the only way to get the same code to run on two different machines. You can also write (or use an existing) compiler for each machine.

For example, PureBasic is available for Windows, Linux and MacOS X and it is possible to write source code on one system that will compile on all three systems (possibly with the aid of a few compiler directives). GLBASIC can compile on even more platforms.

15

Itā€™s not fair to claim that Javascript running in a web browser is an unstable platform. Javascript from nearly 20 years ago (conforming to ECMAScript 3) still runs in modern browsers. While it is true that there are new editions of the language specification every year, these changes are additive not subtractive. Bringing up Java and Flash is a non-sequitur; they have nothing to do with Javascript. (Although, I was definitely stung on Java!)

Modern web browsers are getting more consistent in their implementations and coming into better compliance with the ECMAScript specification. Even if they werenā€™t, this would be an argument against the browser, not Javascript. One may always write their own interpreter using the freely available ECMAScript specification, I guess, but why bother? There are several good interpreters (Edge, Chrome, etc.) already available with a wide install base.

Compiling the output of an IF system to human readable Javascript is probably the best future proofing available. Even if the maintainers of the ECMAScript specification lose their minds and break some feature of the language and browsers follow suit, there is such a huge installed base of Javascript applications out there that there will be plenty of tutorials on how to fix your app.

16

Iā€™d agree that if youā€™re not going to native code, JS is a good choice.

For those people thinking JS might not be here in the future; sure it might no longer be a browser thing, but JS as a language will still exist and can be used as part of an interpreter, just as various old versions of BASIC still are.

So, a couple of interesting questions, maybe people can answer;

  • Whats the best way to make mobile apps from JS?
    Used to be Cordova. Anyone used React Native? Being owned by FB, puts me off a bit. Any others?

  • Is there a really easy to embed implementation of JS as a library?
    Something that can be compiled in as part of an interpreter. It would need to cover the basic JS standard, but probably not optional extras, not would it need any special JIT runtime etc.
    Anyone know?

17

For small JS engines, there is Duktape (which Iā€™ve heard is decent), and QuickJS (which I donā€™t know anything about, but Fabrice Bellard usually does pretty solid little projects).

18

Perhaps itā€™s more of a matter of it being easy for the author to deploy some kind of standalone game package for a player, rather than so much as the player needing to figure out (essentially) what ā€œgame systemā€ their ā€œcartridgeā€ will work in - that may be the concept thatā€™s going away as time goes on, especially with non-physical media.

19

@JoshGrams
Thanks for the JS lib links;

A very quick experiment;

Duktape worked right away. Itā€™s only two files .c & .h which is exactly what iā€™m looking for. It also compiled without any warnings on both gcc and microsoft cl.

QuickJS didnā€™t compile on Windows. I think itā€™s mainly for Linux. Claims to work on mingw64, but it didnā€™t. Probably because mingw64 is changing all the time!

+1 for Duktape!

20

(Itā€™s a bit off-topic, but wellā€¦)

As a Cordova alternative, thereā€™s Capacitor, which seems more modern and easier to use.

As a React Native alternative, thereā€™s NativeScript. What great with it is that you are can use it with Angular, Vue, or plain JavaScript, and not only React.

Keep in mind I have near to zero experience with those, I simply stumbled upon them when I searched about the subject.