[NoGo] Tutorial ("Beginner Tutorial" in bananas)

[Zuu]

Openttdcoop project: http://dev.openttdcoop.org/projects/gs-tutorial
Hg: http://hg.openttdcoop.org/gs-tutorial

Wording 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:

Hello,

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:

1. 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:

   Code: Select all

   // step 1
   g_menu_view.Open("Some random text that the player should read", ["continue"]);
   g_menu_view.WaitUntilClose();
   
   // next step
   
   // any API call that is wanted etc.
   g_menu_view.Open("Some more text that the player should read", ["continue"]);
   g_menu_view.WaitUntilClose();

2. 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:

   Code: Select all

   function TestGame::LoadBusChapter()
   {
   	this.AddStep(MessageStep("Hello and welcome to the bus tutorial"));
   	this.AddStep(MessageStep("Another message"));
   	this.AddStep(MessageStep("Thanks for taking this tutorial"));
   }

Pros/cons:
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 4308 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.

[Zuu]

Reserved for future use

[MinchinWeb]

Hey Zuu!

Another option (#3, for reference?) for a framework is to use a switch/case tree. For every step, you would call the Chapter function, it would run one step, return, up the counter, and repeat. So something like this:

Code: Select all

function ::Chapter1(Step)
{
	switch (Step) {
		case 1:
			Message("Hello and welcome to the bus tutorial");
			break;
		case 2:
			Message("Another message");
			break;
		case 3:
			Message("Thanks for taking this tutorial");
			break;
	}
}

The advantage to this is it makes savegame loading really easy because all you have to pull up in the chapter and step number. (Although it looks like your sample code makes savegame loading equally simple). The other advantage (I hope) is that by adding a similar switch/case tree to the main file, Chapters could be added (or removed) with the addition of two lines of code. That would make it easy for Chapters to be written by others and then contributed to the main framework.

So I guess I'd be inclined to go with your option #2 before #1. I like the idea of using a class (or subroutine) to display messages, the "menu," etc.

In any case, how do we expand the framework to handle one-off situations? Beyond the messages explaining each step, I fear most other parts of the step will be "one-off" and adding that arbitrary code into two-deep functions will make it harder to write and debug.

[Zuu]

Previously fieari posted this in the NoGo thread. I though it would be valuable to copy it here so it doesn't get lost.

if you don't have a curriculum set up yet, I have some recommendations for a tutorial. I only recently learned to play, using a guide, but I think this would be a good way to start:

Start with basic point-to-point RR between coal and power plant. This should be step by step (build stations, build tracks, build depot), and the two shouldn't be super far away.

Then teach RoRo, and add a second train (to a single lane station).

Then start teaching signals with a second lane in the station, maybe even adding another train to the line. Make it necessary by boosting production. Explain pre-signals! Perhaps cover another industry chain as well.

Then teach about transfers... do it with oil, so you can use oil tankers and trains combined, and teach how sea travel works. For added fun, make them build a canal.

Since oil leads to goods, next might be a good idea to teach about town growth. Also, get a local bus service up (make sure there's a big city in tutorial land).

Next, get forced transfers into play by shipping passengers via bus to an airport, which will take them to a distant city, and explain distance bonuses.

That covers trains, ships, roads, and planes, and gets the basic ideas across. In between these concepts, each of the industry chains should be covered as well, so that by the end of the tutorial, all vanilla industries have been serviced.

[Zuu]

A small update showing the current state of this work.

It gets as far as highlighting the main toolbar and then the road toolbar button for placing a road station. It also centers the main viewport near the town where the user is expected to build.

[Expresso]

Why not start of with airplanes, as those are easiest to deal with (infrastructure consists of airports and pathfinding is a none-issue). Airplanes could be used to explain the basics on how orders work.

Then the game could move on to ships. Pathfinding for ships is a mild issue. This could be used to explain how terraforming works. Ships also need seperate depots biult in order to build ships. As the player already knows how orders work, that doesn't need explanation here.

After that road vehicles and road construction could be explained, some added order flags could be explained too.

After this trams could be explained (making for a transfer to trains).

Trains are the most complicated part of openttd, so they need to be divided in sections.

First teach the player to build two stations and make a locomotive move between the two stations. Then expand the stations and add some waggons to the train.

After that the player should be poked to exand one of the stations and build another station with another vehicle. As the vehicle (expected) won't leave the station, tell the player to build signals.

This should continue to build up, all the while explaining each signal type step-by-step. At this point the player should have built up a network consisting of all vehicle types... so the player should get transfers explained and industries should be involved now. Perhaps the tutorial could diliberately cause the player to get a crash or a gridlock in order to get a point across.

[Zuu]

Sounds like a good plan.

What I think is needed is

1. a plan like yours
2. a scenario that supports the plan
3. a game script that tells the players what to do

I've started a bit on the last point, but to really get the tutorial started we need to settle with a plan and design a scenario which will allow us to teach all ideas in the plan. Going from step 1 to 2 might involve breaking down the plan into a list of requirements.

[Zuu]

So I started to make a detailed plan (maybe too detailed?) for the first chapter

[Zuu]

Alberth suggested to include some more detail in the end of the tutorial:

<Alberth> Zuu: perhaps add clicking at airport/station to see cargoes, and/or at aircraft to see its contents?

I've now done this.

[Level Crossing]

I'm assuming this is a typo:

<wait for user to cluck on Next>

I like it for now! One suggestion: if it's possible, disable all aircraft except the Coleman Count for the purposes of the tutorial, to make it easier to program and use.

[Expresso]

Explaining the catchment area when the player places the first airport would be nice. Specifically why the blue squares have to cover as much as possible of the town.

Having the player manually scroll back to town A would be nice.

As for the example scenario(s). If it's just one scenario, we need to be able to build things up to end up with an actual transport empire. So a small map (128x128) and about 4 or 5 cities and a couple of industries should be present.

On the other hand we could use multiple scenarios (this is less satisfactory, but simplifies things to the player). In such a case each scenario could be tuned to whatever it teaches.

edit: removed terraforming idea, as it should be dealt with during the ships tutorial (which I suggested earlier).

[Zuu]

Explaining the catchment area when the player places the first airport would be nice. Specifically why the blue squares have to cover as much as possible of the town.

The catchment area has been discussed a bit but maybe not to the extent you want to see. Please take the existing text and rewrite it and propose a new text.

Having the player manually scroll back to town A would be nice.

Currently I've written that the user should use the station list, as to make sure that the user finds it ways back. Or do you mean at a different place than before giving orders for airport A? Line numbers or a scope helps.

As for the example scenario(s). If it's just one scenario, we need to be able to build things up to end up with an actual transport empire. So a small map (128x128) and about 4 or 5 cities and a couple of industries should be present.

On the other hand we could use multiple scenarios (this is less satisfactory, but simplifies things to the player). In such a case each scenario could be tuned to whatever it teaches.

Another issue, which I think is more a question for TrueBrain, is how to cope with the fact that savegames/scenarios can't upgrade to a newer game script version? Can we make the scenario without a game script and then later (before testing and before shipping) bind the scenario to the Tutorial GS? So that when the GS script has its version number increased, we don't have to remake the scenario, just bind it to a new GS?


Thanks for your comments. My questions are because I tried to follow what you think, not that I didn't like them.

[Expresso]

Here's a proposal for a scenario. It was a quick edit in the map editor.

[Expresso]

Well, forget about my previous post. That scenario is completely useless for the tutorial where it is headed now.

I've added a chapter on ships and ran it through Zuu before posting it here. Zuu also made some changes.

There is one little snag though: I cannot think of a valid use case for buoys. Anybody got a decent idea for the tutorial?

[Arie-]

Perhaps place an island in the ships ideal lane and make ships take the shortest path using buoys? Perhaps not necessary in reality, but lets people place at least a buoy in the tutorial.

[Brumi]

I've been trying to get your tutorial to work, but it's missing version 18 of the NoGo SuperLib.
So I cloned revision 40 from your hg repository, ran the NoGo translator script, but it's still giving me this error:

tutorial.png (16.12 KiB) Viewed 14566 times

Is there an easier way to acquire the correct library? Or is it a bug?

EDIT: Problem solved now, I had to comment out the imports where the NoGo version didn't exist. And I had to copy over Town.nut from the 19.1 version, as somehow it didn't get translated by the script.

[MinchinWeb]

There is one little snag though: I cannot think of a valid use case for buoys. Anybody got a decent idea for the tutorial?

In my experience, buoys are needed in two cases: when the route is exceptionally long or when the route needs to turn.

The routes probably won't be long enough to need buoys on a straight line, but that should be mentioned in the tutorial, along with a suggested maximum spacing of ~50 tiles to improve pathfinder performance (and resist game slowdown).

For the turning case, you can get that even on a small map if you go around the corner of the map, or if you have to go in and out of an inlet (see attachment).

Bouys Needed for Turning

Bouys_Needed.png (8.36 KiB) Viewed 60522 times

[Zuu]

Is there an easier way to acquire the correct library? Or is it a bug?

EDIT: Problem solved now, I had to comment out the imports where the NoGo version didn't exist. And I had to copy over Town.nut from the 19.1 version, as somehow it didn't get translated by the script.

In the version 18 that I have locally, line 36 is a commented out inclusion of money.nut. So I don't understand why it complains on that. The only reason I can think if is that I've uploaded a too early version 18 file to the location where you got it. But I don't remember now.

The NoGo translator should copy over town.nut as it is in the white list. Mind that it expects town.nut and probably not Town.nut.

Another workaround you could do is to change the tutorial script to use SuperLib 19.

[Kogut]

Buoys

[Level Crossing]

If the route is too long, the player will get bored. After all, the ships are slooow...