Openttdcoop project: http://dev.openttdcoop.org/projects/gs-tutorialHg: http://hg.openttdcoop.org/gs-tutorialWording changes
If you spot issues with how the messages are worded, please post suggestions. When you do so, please post a patch or a complete new string along with the entire string ID which starts with STR_ and can be found in lang/english.txt (attached in next post). Though, you are also welcome to in addition explain what part you changed, but for me to include the changes it helps a lot if I get the string ID to have the context.
Always use the last tutorial release (or even better last checkout from the HG repository) as base for your suggestions.Original post:
I've started to work a bit on a framework for a in-game tutorial for NoGo. As you might remember, I've already done some tutorial experiments using the NoAI framework. However, with NoGo/GameScript we can place the signs as the company that the human player start as. In addition TrueBrain has told us that NoGo will support translations and at some point we might get the ability to highlight buttons in the GUI.
So far I've came up with two basic architectural ideas:
- Each capter is a function call (possible in a separate class) that only returns when that chapter is done. Messages and code is mixed together. Example:
// step 1
g_menu_view.Open("Some random text that the player should read", ["continue"]);
// next step
// any API call that is wanted etc.
g_menu_view.Open("Some more text that the player should read", ["continue"]);
- There is a TutorialStep base class which is derrived into different types of steps. Eg. a MessageStep, JumpScreenStep, CustomCodeStep, .. etc. A chapter is then defined as a sequence of TutorialStep instances in an array. Eg:
this.AddStep(MessageStep("Hello and welcome to the bus tutorial"));
this.AddStep(MessageStep("Thanks for taking this tutorial"));
First method makes it easier to add more scripting. Add numbers/town names etc. into strings. Call whatever API call etc. It should also be less overhead and new concepts to learn, as long as you can write code. A drawback however is that the code is not broken down into steps so save/load will not be as easy to implement.
The second method makes save/load easier as the tutorial is broken into steps and there is a separation between a framework and the tutorial. A drawback could however be that this method means creating lots of extra code just to get this working instead of sticking to simple stupid solutions that in the end might be easier to learn.Feedback
The TutorialAI uses the first approach while the code that I've uploaded here uses the second approach. I'm not really sure myself which way is the best which is why I've published my work already to bring this up for discussion. Also as there are more people who are interested to help out with the tutorial, I think it is fair to let people in.
Tutorial.zip [26.28 KiB]
Downloaded 2104 times
Tutorial text, idea etc.
I'm more focused on the technical details for now, so those who want to work on ideas/concepts/texst for a tutorial should feel free to get started with that. In my initial code, I've made a bus chapter, but if you rather want to work on rail tutorials or whatever, that is up to you.
_________________My OpenTTD contributions
(AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)Junctioneer
(a traffic intersection simulator)