2
\$\begingroup\$

I'm creating one for my game and I'm confused a bit. I made special TutorialManager class and a number of steps to pass for player first time entered the game.

The problem is that tutorial steps are N separated classes, and each has some logic to lead the player. The problem is that I had to open (make public) a lot of private methods of UI and field to give TutorialStep classes ability to operate with objects I need, and it's an awful solution as far as I can see. But I have no idea how to organize it in other way.

I'm not sure I've described the problem clear enough, so any questions will be answered.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Hi and welcome to the site. There's really no way to tell you what you should do.. it depends a lot on your architecture. If you have to make private members accessible solely for your tutorial, then you might want to rethink your architecture? \$\endgroup\$
    – bummzack
    Aug 11, 2013 at 10:00
  • \$\begingroup\$ Hi, thank you for answering! Ok, I see, the quastion is too abstract. I'm not sure if it's possible to make some global changes in architecture at this moment. Well, I'll try to rethink the part with tutorial, maybe I'll find a new solution. \$\endgroup\$
    – Nbooo
    Aug 11, 2013 at 10:18
  • \$\begingroup\$ But anyway, if someone can point me on some related articles or discussions it will be a great help. \$\endgroup\$
    – Nbooo
    Aug 11, 2013 at 10:26
  • 1
    \$\begingroup\$ BEST BEST BESSSSSSST!? It's not clear whether your question is about building tutorials, or about sharing data between classes. If you want some tips on tutorial building, check out this Extra Credits video. \$\endgroup\$
    – bobobobo
    Aug 11, 2013 at 17:37
  • 1
    \$\begingroup\$ If you need access to access component implementation details, then you need to rethink your implementation of those components. \$\endgroup\$ Aug 11, 2013 at 17:47

1 Answer 1

2
\$\begingroup\$

You need to more clearly separate how your individual modules work. Tutorial code should not need to reach into UI code, but the UI code interfaces should expose all the data necessary for an external source (like game logic or a tutorial) to drive it.

For instance, every UI element might have a way to enable/disable it, hide/show it, or highlight it. The code that decides which elements are visible or such is not in the UI itself, it's in a separate game logic system. This system can then query a ruleset about which actions should be available and what to do in response to a UI event. These rules can describe different game modes or tutorial states.

The nuts and bolts of game play should also include an abstraction to allow game events to flow from these rules. You'd have a submodule for moving units, attacking, whatever concrete actions you can perform or the AI can do. In typical game flow you might want an AI module driving decisions of non-player characters and attacks which request random damage amounts. In tutorial mode you probably want purely scripted "AI" with pre-determined attack values.

It's all just a matter of layering. Make each module responsible for only one thing and then have "glue modules" for logic that can either simply be different implementations for different game modes or the tutorial or which is completely data-driven if you have the time to build that.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .