Author Topic: Thinking of making an easy-to-use, text "game maker" (aimed at non-programmers)  (Read 579 times)

Solstice

  • Emaciated
  • *
  • Posts: 4
  • Karma: +2/-0
  • Lightweight
    • View Profile
Hey all,

I can't believe I ever went so far as to create an account here, but whatever, here's the deal. I've noticed there are a LOT of people here who have ideas and can write stories and would love to get creating. But, I've also noticed a distinctly small programming talent pool (especially when compared to the amount of people who are more in it for the writing and creating).

As a solution, I propose the following. What would you all think of an "rpg maker" type application that required absolutely NO programming knowledge to use to create your ideas? I mean it would be three-year-old levels of easy to use. That would allow all of the people here who don't have the programming knowledge to still bring their games to life.

The caveat would be this. Because this is geared towards all the people who CAN'T or are not willing to program their own games, it will remain strictly for text-based games. That also means that, because the creator would have zero assumed programming knowledge, the game engine would not support advanced logic of any sort. At all. Introducing logic means introducing programming, and, if the goal is to allow non-programmers to make games, this is a no-go.

So, this would be ideal for writers who want to create a game that plays like a visual novel, but maybe not so ideal for people with grand ideas of combat or even something as complicated as a full-fledged inventory system (though a paired-down version would still be very doable). Think simple-stupid levels of game play.

What the engine would support though is complex routing systems for making decisions that influence the story, allow for multiple endings, and overall offer deeper dialogue and story options to creators. As well, you could still do things like have decisions influence player and npc stats. I.e. if you decide to eat the cake during a story decision, then you pay the consequences. Similarly, you can have things like your characters appearance and such update dynamically as your stats change. Also, your stats can effect what dialogue options you have, and don't have, and there will be support for things like only allowing or disallowing dialog options if you already did another dialogue earlier.

As a quick sample as to how easy this would be for literally anybody to pick up, here's a quick sample of what something you, as the writer, might make. Syntax isn't set in stone (I'd make a custom text-parser to make the syntax as easy as possible).


dialogue_one{"Hi there!"}
->dialogue_two


dialogue_two{"hello to you too!"}


Hopefully it's pretty obvious with this little snippet does. It just starts you at dialogue one, plays the dialogue, then takes you to dialogue two, and plays that dialogue. I didn't include anything in this snippet about updating player stats or anything, though that would be only marginally different than the above. I only included the above snippet to give an idea of what the syntax itself might look like, just so you can see that it's not all that daunting.

All of that said, is that something you guys would want (there, I put it in bold. I would like a yes or a no answer to this)? Please don't just say yes to be nice either. If you wouldn't use it, or think other people wouldn't use it, please say so. It would be a lot of work to go through just so nobody benefited. I don't charge anything, it would be completely pro bono. I would do this because there's a lot of people with good ideas, and, in truth, I want to play your games myself :)


Here's a small section just to pre-empt some questions I'll probably get.

Who are you?
I won't say too much about myself, but I've done a lot of programming on both games and otherwise (currently in the process of becoming an embedded systems developer).

Who long would this take?
Frankly, I don't know. My best guess: anywhere between a few weeks to a few months. Don't quote me on that. I'm a human as well with a LOT of stuff going on. Working for free on a pet project does not rank high up on my list of priorities, sorry. Plus, programming is notoriously difficult to estimate. A feature you thought would take a day can sometimes take weeks, and sometimes (perhaps more rarely) a feature you expected to take a few weeks, only takes a few hours.

Can I help?
Maybe. Depends on what your qualifications are. Depends on what stage of development we're in. If the want is there, and people want this to be made, we'll revisit this topic.

Can you add <x> feature?!
Again maybe (but probably not)... Suggest it anyway though, and we can figure it out. The thing is, the more features you add, the more logic you insert. What's hard about programming is thinking like a programmer. That is, to say, algorithmically. The more logic you add, the more algorithmically you force game creators to think. If non-programmers are going to make games, only features that make sense on a very intuitive level can be even considered. In other words, if your feature idea means the game creator has to juggle more logic/syntax, chances are it'll be a tough sell. Beyond that, the architecture I have in mind does not lend itself to mindlessly adding features. Of course the architecture is still in flux, but just adding features mindlessly is almost never a good idea anyway.

Anyway, thanks for making it this far in the post, please reply and let me know what you think of this idea!
« Last Edit: October 27, 2017, 12:30:06 PM by Solstice »

dingotush

  • Developer
  • Chubby
  • *****
  • Posts: 127
  • Karma: +43/-0
    • View Profile
    • Yaffaif
First up, I am a programmer, so I probably wouldn't use this myself - unless I wanted to knock something up quickly. However, I did have some thoughts:

As this is a weight gain focused board it would be great if it made making weight gain games easier. Things that are hard in other engines are keeping track of body sizes as you eat or are transformed, displaying your current size, and describing how the player (or NPC?) looks in a mirror, and having the player (or NPC's) size affect the gameplay. These things currently have to be done by scripting in one form or another - which requires some familiarity with programming, and makes them inaccessible to the target group you are aiming at. If these things aren't built in, then any new engine doesn't really have many advantages over existing ones.

I wonder if it might be more useful to add these as extensions to an existing engine?

The other thing I'd try to avoid is programming-like syntax. I know the example you gave is just that, an example, but using braces as delimiters makes it look like code (probably something to be avoided), and will lead to mismatch errors which will frustrate non-programmers. If they are writing in a regular text editor (rather than something designed for editing code), which is likely, then a failed compile/interpret due to a mismatched brace will result in errors they aren't going to be able to easily find, unless your parser's error handling is really, really good.

Not that looks-like-ordinary-language based parsers are much better. If you've ever tried writing for Inform (which is probably the best of the bunch in this respect - it does a fairly good job of hiding that you are writing in an OO language) you'll quickly find that the way it handles errors in the input can be quite bizzare at times.

Anyway, just some thoughts. It would be great if you can build something so that fun games can be created by those whose talents don't include programming skills.

Solstice

  • Emaciated
  • *
  • Posts: 4
  • Karma: +2/-0
  • Lightweight
    • View Profile
You are right in that I did oversimplify a bit, and I appreciate your thoughts.

To address the parser itself, you do present some interesting ideas. I guess it'll require some tweaking. When I started programming, I remember being frustrated that programming teachers always talk as if they assume you know how to program already, and I guess I'm already guilty of that same thing in the syntax that I thought was "easy" at the time that I created that example. Despite the increased difficulty, I suppose a natural language  based parser is the only real route available. Though, that's part of the reason that I'm wondering how hard this might be to implement as an extension to an existing engine. Because an existing engine will already have its own scripting language built in, which could perhaps cause confusion or end up being redundant by building on top of that existing system.

As far as users dealing with parser errors, that's an inevitability of making anything on a computer. Whether it be Unreal Engine, making a typo in Microsoft Excel, or anything else, the best anybody can hope to do is make it easy for users to identify the errors and to allow them to quickly fix them.

At the end of the day, it is impossible to hide all of the programming and logic from the creator, because they need to create the game after all. What I suppose the true goal would be is to hide the programming specific things such as scope, object-oriented thinking, state lifetime, etc.

In reality, you would still need to be able to reason your way through at least an if-then type statement and to understand, at least on a rudimentary level, the concept of graphs (e.g. conversation trees). Without those skills though, you wouldn't be able to write so much as an interactive story on writing.com though, so I feel like that's an acceptable baseline to assume. Not saying they even have to be an expert on the topic, but just to be able to grasp the concept would be enough.

On a similar note, I agree in that, without building into the engine certain features specific to weight gain games, then this would be a useless endeavor, because it would require a lot of legwork on the programmers part (like you mentioned, things like checking weight or affecting NPC size). Essentially, my thinking is that this is really just a glorified text parser to construct dialogue trees for users. The entire game would be, effectively, the user making a choice at each tree node that traverses the tree. When you arrive at a node, you play the dialogue for the node, and prompt a response. The only thing for the game creator would need to do is define what the dialogue is, what choices you can make, what happens for each choice.

In the background, the "engine" (if we could even call it that) keeps a block of data with accessible members for each character and NPC such as weight, fullness, body shape, body descriptions associated with weight ranges, etc. Then you design some simple macros that invoke these commands (such as "increase weight" or "show description"). Again this would rely on the game creator to define these parameters before the game was launched (such as creating a list of characters, their data members, and default state is), but I don't think that's any less un-intuitive than creating a D&D character sheet. Though, if this seems like it's expecting too much still, it would be easy enough to hard-code these variables engine-side, and just have game creators essentially supply a list of character names.

And if a creator still wasn't interested in doing things as "complex" (as relative as the term is) as accessing data for, say, the main character's weight (or even going so far as to define it), then it would still be possible for the creator to simply... not... They could simply create a something that looks and plays like an interactive story, where there's no state at all. It's entirely optional how "programmer-ish" that any given creator wants to be.

Anyway, that's my take on it at least. Maybe that sheds a bit more light on how I thought this idea might be implemented. As always, feel free to add anything or let me know if I missed the mark on anything. Thanks again for the feedback.
« Last Edit: October 28, 2017, 04:14:26 AM by Solstice »

PeachClamNine

  • Chubby
  • ***
  • Posts: 174
  • Karma: +42/-5
  • Lightweight
    • View Profile
Please, no. Natural language parsers trick the user into thinking they can use all of English to develop their game, but in reality it only accepts some subset of English. Probably with rigid grammar rules as well.

Programming is programming, don't try to hide it. But do look at something like Basic for how it can be approachable. Simple verbs like ' SAY "Hello world!"' and 'FATTEN Goblin' can go a long way towards reducing the amount of stuff to memorize to get a working game.

Combine this with an intellisense-like autocomplete and documentation, in addition to a well explained syntax parser and debugger should give you what you hope to achieve. At least in my opinion.

Solstice

  • Emaciated
  • *
  • Posts: 4
  • Karma: +2/-0
  • Lightweight
    • View Profile
My bad, I might not have been as precise as possible. The idea of a "natural language parser" I had in mind was more akin to what you were citing here with a sort of (<subject>) <predicate> <object> format, where each has a distinct and well-documented number of possibilities (e.g. as per your example "FATTEN Goblin", "SAY hello", etc.).  I agree that building anything that pretends to be a true natural language processor is an awful idea in general.

As for a auto-completion/text-highlighting goes, that's something to be done on a per-editor basis afaik. Option one would be to choose an editor and extend it with a bunch of new functionality. Or, option two, roll my own text editor. Given the small domain over which it operates, still might be doable. And, if we're going to rewrite so much functionality anyway, might as well make a native app.

Personally, I'm not a fan of intelli-sense/auto completion systems in general, but I can see how it would be valuable given the audience.
« Last Edit: October 31, 2017, 04:35:48 AM by Solstice »

PeachClamNine

  • Chubby
  • ***
  • Posts: 174
  • Karma: +42/-5
  • Lightweight
    • View Profile
I agree that building anything that pretends to be a true natural language processor is an awful idea in general.

One of the most popular IF systems, Inform, had a version that was exactly that. Parsing full English sentences. It was awful.

Grotlover2

  • Developer
  • Emaciated
  • *****
  • Posts: 45
  • Karma: +19/-0
  • Lightweight
    • View Profile
First a quick disclaimer: I am a programmer, so I would not use this myself. While the idea may not interest me, it does not mean there are not people who would be interested in this. Also, I do not do text biased games so some of my argument is conjecture.

I question how helpful something like this might be. I am sure there are a few engines/languages that are already on the market that might do what you are offering already. While this is not for text games one that comes straight to mind is ReníPy. It may be for visual novels, but it is really simple to use and allows the users to write a game like a book (note that while I have looked at ReníPy I have not used it, so I could be off base here).

It might be more beneficial/wanted if instead you wrote a program that implanted a flow chart based editor over an existing language, or creating a library or extension for something like ReníPy that is weight gain/expansion centric.

If you are just looking at developing a language though I say go for it! Some of my favorite projects in college was Lexers, Parsers, and assemblers (we didnít go into linkers sadly :( ), and they are so much fun to make! [Nerd out over]

 PS. If you feel like going forward with this I think I have a generalized Lexer and Parser laying around that I made that I can give you. All youíll need to do is translate your FSM into an excel spreadsheet and export it as an .xml, load it up and youíre good to go. The Parser may need more modification though.

Good luck with your project!

akhara

  • Developer
  • Emaciated
  • *****
  • Posts: 9
  • Karma: +2/-0
  • Lightweight
    • View Profile
Long time ago, inspired by noone text rpg, I was doing meta scripting language capable of creating description based on input variables. The premise is simple: sentence is build from fragments, each fragment is declared as pattern matching (a tree of clauses, selected until something is valid). Fragment can reference other fragment and can introduce some probabilistic selection from one of prefabs. It is written in python, and can be played around at http://desc.titancomplex.com/

If someone is interested, I can share source code or help porting to other languages. But the latter is a little complicated, as the engine is actually parsing incoming text via LR-parser

Solstice

  • Emaciated
  • *
  • Posts: 4
  • Karma: +2/-0
  • Lightweight
    • View Profile
So quick update, decided to go ahead with this anyway.

But, to make it actually usable, at this point, it seems like it's probably not a good idea to go with any text parsing at all, and make it purely graphical. Otherwise we end up with a situation like Inform, which offers a sort of quasi-friendly scripting experience. Text parsing has a lot of its own pains that don't seem to justify the added complexity (both for me and users). Sucks, because I actually decided to do that after writing the text parsing engine, so kinda sucks that I lost a bit of work, but it was a pretty fun side-project anyway. Obviously, abandoning scripting altogether, makes it rather difficult to keep the engine flexible, as it becomes hard for creators to specify attributes for the elements in the game, and scripting transitions and modifications becomes difficult. In general, graphical interfaces sacrifice flexibility for ease-of-use.

Well, my solution to this has been to take a highly data-driven approach to this. Almost all of the data is stored in POD style. Almost all of the game data format is both declared and defined at run-time (basically I threw in a bunch of empty Maps and Lists wherever there should've been a data field. That presents its own set of issues, but it's carefully designed so that it's not ambiguous and works well so far).

As a quick overview, It's currently being written in Java because performance isn't much of an issue, and I don't want to have to deal with the added development time associated with C/C++ development. In the engine, I only defined two types of entity that can exist. Items and Actors (couldn't use character because Java already named that class unfortunately). Each of those only has a handful of members. These members are generally all Maps. So, for an Actor, say, we have that the only fields are Map< String, Double > numericData, Map< String, String > stringData, etc. These maps are defined by objects called descriptions. Descriptions are defined in the editor, where you can add fields to these maps and add values, and, on game launch, these descriptions are turned into objects. (the full-object is slightly different because it has a globalId that is instantiated at runtime and some other things). Save state is easy to manage as well, because we just convert the object back to a description when we save, serialize these objects to a JSON file format (which is easily human readable as well, which offers some built-in "cheat-codes" for those who are so inclined :) ).

Traversing nodes in the game graph can be set to be dependent on one or more of these data fields, and it is also possible to set flags for game events, depending on prior decisions made. As far as modifying the data at run-time, certain in game decisions can have consequences/verbs/etc. attached to them that modify state. I broke these modifications down into a series of categories, i.e. value setting, delayed value setting, and a few others. In theory, this allows for infinitely customizable character archetypes, item archetypes, and a rather flexible scripting system for having impactful decisions.

For example, you could define a character to have a field called "cash." Then, you could arrive at an instance that allows you to choose a special option to, say, add an item your inventory if you have the required "cash" value. Then after the transaction, your cash would be subtracted and the item added, and you'd traverse to the next node (or, perhaps in this case, we'd flip some sort of "item bought" flag and then return to the same node in the graph).

That's a bit of a simplified look at it, but hopefully I conveyed the essence of it pretty well, and I think it'll maintain a lot of the flexibility this way, while providing for a lot of different types of experiences.

Maybe I'll toss together a quick mock-up pretty soon and see how it goes. It was actually pretty quick to code up the core once I had an idea of how it would work. Currently no graphic interface, but i'll probably work on the editor pretty soon after I work out some bugs and run a bit more testing. One drawback is, when you try to straight-script it outside of a graphical application, it is VERY verbose. to look at.

Grotlover2

  • Developer
  • Emaciated
  • *****
  • Posts: 45
  • Karma: +19/-0
  • Lightweight
    • View Profile
I may have a simple solution for your scripting issue. In the dotnet and mono frameworks I think you can compile C# files at run time into memory and run them, and I think there is a built-in interpreter that will allow you to use C# as a scripting language. I remember doing some research on it for work but that was a year ago, so I donít remember a lot about it.

It might work for your project though as it would allow more advanced users to use C# scripts to extend the system while the majority of your users would use the graphical system.

I look forward to seeing how your project turns out!  ;D