eugeneloza / castle-editor-tutorial Goto Github PK

I think it would be good for the user to know what he will create. Simple introduction at the beginning with game rules, screenshot, download button is motivating for hard work user need to do to get the game ;)

I think some readers may not be familiar with this term and feel unnecessarily worried about it.

The tutorial spends time showing how to setup Lazarus build modes, "3.3. Set up Debug Mode". I would say to remove it:

1. Because Lazarus build modes, while useful, are not really critical for simpler CGE projects.They do not control how the CGE units are compiled (only how project units are compiled), so likely there will be no difference between "Debug" and "Release" Lazarus build modes performance. I would advise to just enable "assertions" in the "default" mode of your applications. For simple applications, this is simple and reasonable.

   If we ever change our decision about this, we can anyway add the default "build modes" to the LPI generated by default. Or Lazarus may decide to create debug / release build modes by default. So in any case, this should not be a step performed by user. For simple applications, the default LPI should be suitable.

2. Engine (build tool) has debug / release modes (switchable in editor) that work automatically, and matter more (they affect both compilation of user code and engine).

@michaliskambi @eugeneloza Maybe this should be fixed in CGE in some way?

Basically I want to ping @eugeneloza about this work :)

The article is great, and I'd like to publish it ASAP. We need this kind of documentation for CGE. But first we need a few simplifications to the text -- as we simplified a few things on the CGE side (in particular editor) to make creating new applications more straightforward for users. So some sections can be now happily just removed. The tasks are in https://github.com/eugeneloza/castle-editor-tutorial/issues .

Once the text is ready on https://github.com/eugeneloza/castle-editor-tutorial/blob/master/clicker-game-tutorial.adoc , I'm prepared to finalize it, by putting nicely on https://castle-engine.io/ (in the "Documentation" section as just "Tutorial", split into a number of pages), so it will look like an integral part of the CGE docs (but still can be further edited by editing this repo and AsciiDoc sources).

Most used:

• TCastleVerticalGroup - Alignment
• TCastleLabel - LineSpacing
• TCastleImageControl - FullSize
• TCastleUserInterface - FullSize

There are also some Custom* properties form TCastleButton but I think they should stay only on "All".

This was spotted by @and3md . I'm submitting an issue before I forget :)

The sentence:

""""
We’ve also added if GameRunning then condition to avoid possible rare bug in case two popups will fire simultaneously.
""""

seems too alarming. It may suggest that there's a mysterious bug in game code/engine code. Especially if reading this sentence "on its own", without previously reading explanation about what GameRunning does ("... The game starts running and stops after "Game Over" "). What "possible rare bug" do they mean?

As far as I understand, the point is just that you detect "game over" in each Update, and the point is illustrated by the code snippet right above the sentence with

if GameRunning then
  TUiState.Push(StateGameOver);
GameRunning := false;

I propose to change the sentence to:

"""
We’ve also added if GameRunning then condition to avoid showing the "game over" popup repeatedly in each Update after the game ended. The line TUiState.Push(StateGameOver) should execute only once per game, not in every Update call.
"""

As with folders, we need a template without creating a default state. I think it's hard to come up with a name for the state that will be appropriate. Requiring the user to "clean up" an empty project right after creating it, in my opinion, means that we need a really empty project template. Such a template would definitely be useful for tutorials and advanced users. Perhaps not a separate template, but an option displayed when creating or selecting Empty template.

How many things user need do presents 4.1 Section of tutorial. I think that it can be deleted if we add such template or option to not create default state.

Add game state screenshot before start designing it in 6.1 section. I think It's good to show ready state before start doing it - it's easier to understand then IMO.

After:
Now what we want to do is to have our UI organized in the following way:

• Score: 99999
• Gameplay area with 3x4 buttons
• High Score: 99999

add:

It will look like this:
screenshot

I think this can simplify some code - pointers (^ and @) can be difficult for newcomers :)

After rereading the tutorial, I noticed that we are telling users to rearrange pascal modules in the default project template. If it is useful in such a simple project, in my opinion we should not require it from users but improve our project templates. If we do that 4.2 tutorial section (Moving units) can be deleted.

After playing some time with editor I agree with @eugeneloza that moving all pascal modules to code directory make navigation in project easier and looks better to me.

@eugeneloza @michaliskambi How about make this change in editor? Maybe this issue should go to CGE repository.

Prerequisites: none.

It's not a big deal, the Anchor buttons are missing.

In sections:

• 5.4. Create Logo Image
• 5.5. Create Menu Buttons

Maybe in 7.1. I thinking about a little introduction about two ways to change state:

• Current - make current state
• Push/Pop - shows state on top on other.

I think after selected text (This will create a simple dummy project we can start filling with our game-specific code and assets.), there should be editor screenshot with resized/selected files section. It would be cool to see how empty project looks like here.

Let’s open freshly created ButtonClickerGame.lpi in Lazarus. We can immediately compile and run it. - I think this should be after project files description and project file description should move reader attention from editor to files something like that: On the bottom of the editor we see all project files. It's a template but it’s a fully functional minimalistic project, that we can compile and run. Template will show us an empty dark gray window with a lone FPS counter. Empty project is not actually empty, but it contains: