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