Frastlin,
Sorry for the long delay in my response.
The informational window someone can hit next on would work, but would of course require them to press next all the time which some people might not like. I'll think about it though as an option.
I'm not sure how the mud idea helps synchronize sounds when there is a lot of game generated text.
For example in Tactical Battle when the AI takes it's turn it makes sense to play a sound with each action an AI unit performs.
Since there's no way to synchronize sounds all the text would be thrown in the scroll window at once and all the sounds would play at once.
Cool to hear you have some coding experience.
Yes, the menus are still referencing the adventures specifically. It's on my to do list to make it auto load the adventures so the core engine menu files don't have to be changed to add a new adventure.
This would also mean each adventure would need a settings file to indicate which is the first starting location.
Or perhaps just a function that the main menu can call to load it.
Stewie is right about the already used message, it would have to be handled in the scripts you write for the adventure.
For synthesizers I only know how to do SAPI 5 and potentially screen readers as we've discussed.
Yes, I'm working on a better guide for introducing people to the parts of javascript that the engine uses.
Of course you can always look up general tutorials on javascript as it is pretty much the most widely used language in the world, though many tutorials will use it in the context of a web page, defining functions and using if, else if, and else will of course work the same whether it's in a web page or in this engine.
Stewie is correct about not needing to define all the global variables at the start of the program.
His example would work.
At one point the core engine did not handle clearing out variables when reloading your adventure without restarting the game which I think is part of why Nina0116 set all the variables at the beginning.
That can be handled now by calling loadAdventure on it again.
the x in x_name() is not special, that is a naming convention Nina0116 used.
The menu with inspect, take, use, etc. is not currently changeable.
As you say it might be easier for you to just define your own menu. I expect the engine will need to support some extra things like giving you a list of objects in the current location or in your inventory.
The current version of the engine was meant to handle more things for the adventure creator and thus limits what you can do a bit more.
But I don't see any problem extending it so that if you want to abandon the existing menus you can just handle it yourself.
On this same note I'd like to say that if you want to do a text based adventure like the MUD you mentioned earlier but single player I'm open to extending the engine to have that kind of text output and input feature.
That would also work better with a screen reader, though maybe the current adventure game engine stuff would also work fine with a screen reader.
All of it takes time of course and it would be good to find out what is important to the most people so I can prioritize the features.
javascript uses the keywords "else if" instead of the elif that python uses.
You can accomplish most anything in most any language so it is difficult to say that one is better than another without bringing large personal opinion and bias into the conversation.
So I won't attempt to say what advantages javascript or python may have over each other.
I will say that writing your own python program versus writing javascript in this game engine does have pros and cons.
One pro of writing from scratch in python is that you can do anything as you are not limited by what this game engine supports or how long it takes me to add new features.
The pro to writing javascript in the game engine is that you get to take advantage of the location and object file formats as well as simple functions for playing sounds, playing music, and speaking text that are defined by the core game engine.
It's kind of like the difference between writing in BGT or DragonFlame versus Python.
BGT and DragonFlame try to help make a lot of common tasks easier and are focused around making audio games where python needs a lot more infrastructure set up before you would get to the actual game coding.
So it's similar here except that the adventure game engine is much more specific than BGT or Dragonflame which makes it easier to get started in this game genre but also limits the types of things you can do since it is not yet as flexible as BGT or DragonFlame are.
As an example I wrote the engine in C# because I have many years of experience in C#.
For me I preferred the flexibility of using a well known programming language and the comfort of using one I am already very familiar with.
If I were just starting out in programming and wanted to make an audio game I would be better off choosing BGT, DragonFlame or AGE as they'd get me into the game logic much quicker and hide a lot of the complex infrastructure.
Hope that helps.
~ Ian Reed
Visit
BlindGamers.com to rate blind accessible games and see how others have rated them.
Try my free JGT addon, the easy way to play Japanese games in English.
Or try the free games I've created.
...