[closed]

Development of this project has stopped. I apologize, I am now using Inform7.

New post! Multi-argumentative functions done.

ramaraunt.wordpress.com/2017/05 … functions/

You might enjoy this blog post on developing new IF tools. emshort.blog/2017/02/21/if-tool … n-general/

What are the unique selling points of the tool you’re developing?

Its going to be a lot similar to TADS3 than ADRIFT or other IF softwares that have a user interface. You have to just type the code, which is how I prefer it. There will be no fancy GUI for designing how things work, but this means you have more control over how it ends up.

There will be two programming languages working together to get this system to work: Story Script and Ramscript. Story script will be used to handle things like objects, while Ramscript will be useful for doing action stuff with those objects when you type certain things in.

One thing is for certain, this engine is going to be entirely text based. There will be no images, no sound effects, and no buttons in the upper left corner to click on. The user interface is basically done, I just have to finish coding the interpreter of the languages.

You will not be able to compile the games you make into executables, but you will be able to run them from the program i’m making. The way it works, the games you make with this engine can’t be encrypted or anything like that, so when you share your games with others, its really easy for others to edit them. The game will save levels in such a way, that it will create an entirely new game file, with the game at the point where you saved at.

To rephrase my question, what’s uniquely good about your engine? Is your engine good at something that nothing else is? For example, you compare it to TADS. How is your thing better than TADS?

I think you should consider graphics and sound. It’s one of the areas you could be different from, say TADS

tads.org/ov_games.htm
TADS can do graphics and sound.

aha, in that case;

i really think, graphics and sound are more of a must then. Otherwise you’ll be going backwards.

Perhaps I will add sound functionality, and maybe even graphics. For now, I am just focusing on text.

ramaraunt.wordpress.com/2017/05 … 2278120538

i.gyazo.com/bb71130e04492b018e1 … 9c7d67.png

I’m proud to announce that Ramscript now has user defined functions, loops (for, while, dowhile), variables, and many math functions. I’m now starting on Storyscript, which will be required to get this to do what I want. Here is an example of how Ramscript and Storyscript will (hopefully) eventually work together to make awesome games.

pastebin.com/hDYhCv8q

I think you may have overlooked my earlier question: what’s uniquely good about your engine? Is your engine good at something that nothing else is? For example, you compare it to TADS. How is your thing better than TADS?

The script language looks interesting. What’s not clear though, is whether this is a custom language for writing games OR is it a general purpose language that can be customised for games. The latter would be interesting.

For example def Thing(Room, "X") is this a hard-coded construct, or is it a general way to define and construct class Thing as a subclass of Room.

Can i write def Wibble(Thing, "Larry") for example? I think more explanation on the language is needed.

This engine is so new, its not better than tads3, at least yet. Its too early to talk about it like that. I don’t even know yet how far I’m willing to go with it.

Well, the idea behind that syntax, is for all objects and rooms, you go def Thing(type, “name”){}, and for all verbs and other grammar related stuff, you go def Grammar(type, “name”){}. I do plan on making it so you can design your own types of things, but the basis of thing cannot be edited. This doesn’t really matter, because you still have a lot of customization. I plan on making it so you can go like this to make a template, which can later be used as a type from then on out:

def Thing(template(inheritedtemplates), templatename){}

Note that this is just a concept. I might change how it works as I go along.

Alright I am completely changing how this is going to work. Its going to be in golang.

[code]package main

import “goifp”

func main() {
game := goifp.NewGame()
mainRoom := NewRoom(“Main Room”, &game)
mike := NewPerson(“Mike”, &game)
mike.AddString(“Description”, “He is a young man in his early twenties.”)
mainRoom.AddToList(“contents”, mike)
SetPlayer(mike, &game)
game.Run()
}[/code]

right. this way you don’t have to design both a game system and a language.

Well, designing the input interpreter was REALLY hard. But, I managed to get it working. I had no clue initially of how to do this, and there were no guides online that explained it thoroughly enough. So, I was forced to brainstorm an algorithm entirely by myself. I wrote a document full of my ideas:

docs.google.com/document/d/1WDu … sp=sharing

I spent the last two days writing code, patching bugs, and getting really frusterated. Eventually, this is what I got:

pastebin.com/wdTxT5bu

And this is the result:
i.gyazo.com/f176d1654f632fb2d98 … d92bdf.png

Success!

EDIT: I’d like to mention for those who are watching this thread, I changed the first post.

I’ve been there. Writing an interpreter (parser) for text is not easy. Mine is based on an old skool state machine and state transition diagram. It parses the sentence word by word from left to right.
So, in the initial state, 0, it only accepts a verb or a noun. Anything else throws a “I don’t understand…” error. State 0 and noun goes to state 1, state 0 and verb goes to state 2.
In state 1 it only accepts a comma. In state 2 it accepts an article, adjective, adverb, noun or end of sentence. Etc, etc. The state machine has over 50 states.

Like you, I ran into the issue that a word can have different meanings (types). E.g. light can be a verb, an adjective or a noun. I solved it by implementing a recursive parser function. It calls itself for each next word in the sentence. If the state machine detects an error because of an illegal word type for the current state, it will check if the word has another type that goes with the current state. If not, the parser function will return to the previous word and will check for that word if there is another type that leads to a valid state and then continue from there. If not, it will go back yet another level etc.

Here’s an example for sentence “light light light” (meaning ignite the not so heavy lamp)

Light has 3 types: verb, adjective and noun. It parses as follows:

verb -> verb -> error verb -> noun -> verb -> error verb -> noun -> noun -> error verb -> noun -> adjective -> error verb -> adjective -> verb -> error verb -> adjective -> noun -> OK

During the parsing process, it fills a struct with the correct actor, action, subject, etc so the interpreter knows what it has to do.

Cool! I’ll keep this in mind, thanks for the ideas!

Why did you stop development of this project? I understand there was some pressure to add this or that feature and/or explain why your ideas are better than what is out there. Seriously though this was a breath of fresh air and different than the mega development environments out there. This was sort of a grass roots, do your own thing and it’s gonna be missed.