One of the difficulties with creating tutorials for beginners is that the easiest way isnāt always the best way.
For example with your example of showing the titlescreen and pressing A to start,
the easiest way is to use a switch
+enum class
state machine, it works but that has several flaws:
- it gets hard to maintain if you need lots of states
- itās not very reusable so youāll find yourself writing a lot of the same boilerplate every time you make a new game
An alternative approach involving having an abstract GameState
class is more flexible because you can just write a new class every time you need a new state. However it has problems of its own, like requiring dynamic allocation and potentially being āoverkillā if only a few states are needed.
In regards to the ātimer/pacerā thing, thatās actually not the best solution to the problem of making a bullet move.
In real life bullets donāt move a large amount every few seconds, they continuously move a small amount.
In games thatās usually achieved by giving the bullet a position, a velocity vector and using delta timing to make it move gradually.
As for the Pokitto library not having a timer, itās a bit difficult because thereās no āone size fits allā solution.
The drawing bitmaps over top of each other thing would be true for any system, thatās just how bitmaps work.
Those are the sorts of questions you should ask the forum though. Even if we donāt have many tutorials yet,
if we have people asking quesitons and the questions getting answers,
then the answers become a resource in themselves.
StackOverflow is founded on that principle.
Thereās a good reason for that.
When programming thereās always more than one valid solution.
Every approach has its good points and its bad points.
If there was always a right answer there wouldnāt be so much debate or research involved in finding better solutions.
Also the better answers are often involve more advanced language features and thus require a better understanding of the langauge, or at least require more reading to understand the concepts involved.
People often settle for suboptimal solutions because they either donāt know better or donāt have the time or patience to learn the language features or concepts theyād need to know to understand the better answer.
This is one of the reasons Iām always telling people to please make their games open source and to include the source code along with the binary release.
One of the reasons the Arduboy has done so well is because (apart from one or two exceptions),
the majority of games are open source and their source code is freely viewable on github so its easy to pick apart how the games work.
Iād like to contribute some tutorials when I have time to, but as Iāve mentioned several times lately I still have a lot of stuff to get through before Iām āfreeā again.
At the moment Iām trying to work on a vita homebrew project as well as spending a lot of time helping out on both the Pokitto and the Arduboy forums (I find it nearly impossible to not offer to help if I know I can help or contribute something useful, and I spend a long time typing long answers).
On top of which I recently had two issues raised on my fixed points library within a few days of each other, so Iāve had to handle those as well.