The root level .gitignore file already works for all sub-repositories, so they are all actually unnecessary.
This PR leaves only the gitignore at the root of the repo, removing all others.
As discussed previously, this PR moves the Space Shooter Tutorial to the tutorials folder for direct inclusion in the docs. A few things to note, other than basic grammar and formatting, nothing was changed other than migrating the information to the current tutorial format. This should allow the tutorials.flame-engine.org subdomain to be deleted.
Note: Upon moving this tutorial, I discovered it is incomplete and missing the majority of the game.
Also, I realized that I left the android folder and some files that weren't necessary for the platform tutorial and have deleted those.
This adds a platformer tutorial called Ember Quest. I hope I have done a service, because I am tired, lol. I am sure there will be comments. I just want to say, I did my best. I approached this as someone new to Flame, just like I was about 10 months ago. Are there concepts that can be improved, sure. We can always optimize code, but I didn't want any concepts to be super abstract. I had never coded a game before when I began my journey with Flame this year, so things might be a bit simple for experienced game developers, but for myself, I had never even thought about a game loop or animations, etc.
This PR adds a new event system based on the componentsAtPoint delivery mechanism. These events allow for a proper support of components that implement renderTree() method. The CameraComponent is one such component, with more planned in the future.
Additionally, the following improvements compared to the current tap events added:
- the same component can be tapped with multiple fingers simultaneously;
- a component that received onTapDown is guaranteed to receive onTapUp or onTapCancel later;
- a component that moves away from the point of touch will receive onTapCancel instead of onTapUp (even though the game widget receives onTapUp from Flutter).
Due to the fact that the switch from the current event system to the new event system is potentially a significant breaking change, the new event system is introduced as parallel to the existing one. This way we have more time to test the new system before recommending the switch and deprecating the old one; and the switch itself should feel more gradual.
