Hi, I'm the author of this, but I'm not the person that posted this. I actually wouldn't have necessarily come here to post at this phase of the project. I don't feel like I've reached a version 1 of what the goal of this project is.

So a few things.

Firstly: the goal of this project.

This is not meant to be a super-minimal js boilerplate. In that sense, it is not create-react-app. It does have a fairly comprehensive and complete build process, and in that sense it is. It even will have a pretty nice preprocessing process as well, which can do a lot. I’ll talk more about that later.

I find that with a lot of boilerplate projects for Javascript game dev, there's usually such a spartan setup, that the delta between the 'bootstrapped' project and actually making something is still very great. One of the things that makes a lot of other frameworks useful is that there's some convention in place to help, at the very least, organize your project. I gave a talk about this at the beginning of this month at a conference in Oklahoma called Phaser: How to Draw the rest of the Owl

https://slides.com/jesseharlin/set-phasers-to-javascript

There are the slides from this talk if you're curious.

There are a few things about his project that are opinionated, and they are on purpose. Unity, Game maker and a lot of other tools that are often favored for projects like game-jams because you can get up and running quickly. It means you adopt some conventions in order to work more quickly. I intend for this to be a lot like that.

Here’s some stuff you need to know about this project.

1. It just isn’t done yet. I plan to convert it to a lerna-style scaffold, and a lot of the modules in it will be plugins. That hasn’t happened yet, but it will and is a top priority. This project is to be a scaffold, not a boilerplate in the long run.

2. One opinion is that you are going to use Tiled in some way to make levels if your game needs levels. I consider this project one that ‘relies’ on Tiled. It’s the only sensible open source tool that could even let you compete with a more sophisticated game making system. If you don’t need Tiled, that’s ok, but most games have some concept of levels and enough need them I wanted that to be there. That means:

3. I’ve made some decisions about a good starting point for controlling animations. Too many frameworks start with an overly simple approach, and any complexity quickly becomes unwieldy. I explain this in detail in my slides. I made an animation manager that allows you to chain animations, and I use a Finite state machine to organize transitions (machine.js). I go into a lot of detail here in my talk. And a tiny bit of detail in this other talk from a few months ago: https://www.youtube.com/watch?v=lDNmu_9J2p8

4. This project has a pre-processing step, and that’s something that makes it unique in this space. This currently does a few things for you. It can extrude your tilemaps so they don’t literally cause graphic glitching when you run the game. You can also target Layers from tiled and use a flood-fill to generate polygons that can be used for Physics and Raycasting. The light you see is using this. I just wrote this a few weeks ago. You can also minify images, etc.

5. The file organization also is meant to simplify this workflow, but I need to make changes even now. I’ve realized I need to have a separate concept of biomes and levels. A lot will likely change here. As I said, this project is super new.

6. I intend to encourage systems-music and Html5 audio in future iterations. I think the barrier for entry for these tools is too high, and to be honest, if your game loads mp3/ogg files that’s likely the biggest assets in your game. This means you’d more likely play a MIDI sequence and use Tone.js than load a recording. It is a similar technique to how older game systems managed audio, because it has a smaller footprint and performs better. You're not going to be forced to do this, but I'd like it to be easy to do this.

7. I am prototyping a way to make in-game ui easier, with Html. I know a lot of Html5 game devs that use frameworks like Vue and React to handle things like minimaps, lifebars and other overlay elements. It is just a fact that making something as simple as a form input in canvas is a time consuming nightmare compared to Html + css + js. I discuss this at length in this issue here: https://github.com/simiancraft/create-phaser-app/issues/18 . My plan is to use React for UI and work out some simple bindings so that you don’t spend 4 hours trying to make a start menu or a player-name input.

8. I plan to use the raycasting module and a behavior tree plus the FSM I already included to manage enemy AI. I want something more sophisticated than a simple patrol. Something that acts differently when it sees a player. I have a clear vision of a good pattern to follow here. Remember, this project is about how to eventually draw the rest of the owl. I want to show you a good pattern for this in the scaffold. I’d like you to easily be able to add enemies at certain locations in a map in Tiled, and with some small effort have them perform useful behavior, such as attacking or chasing a player on sight, and patrolling before they see you.

9. I’ll know it is done when you can scaffold a game and make something that’s better than what current Html5 boilerplates afford you and you can actually work close to as quickly or more quickly than someone using something like Game Maker. That doesn’t mean feature parity, but if you want to make a game in Js right now at a game jam you’ll spend way way too much time fiddling with a build system, and if you go ‘ the low road’ and keep it spartan, you’ll find your final products will be railroaded into overly minimal and feature anemic results.

10. I’m not touching anything related to server-side state, nor will I be prescriptive about that. You gotta draw the line somewhere. I am also not going to touch multiplayer with a 10-ft pole. If any of you have ever made a game with multiplayer that requires any sort of meaningful real-time interaction you probably already expected that. This project is going to be about the client-side game.

There are a few criticisms of this project that I think are fair. I’ll address a few I saw.

One is that the controls are "clunky", and to be honest you're right. I think the test map I have made is not a very appropriate size for the player character. It is a bit claustrophobic, but I've not spent any cycles on this. My development time is tight, so I am trying to focus on things I think are more important before I hit a version 1. If you look in the source, the main purpose of the map so far has been to allow someone to organize a pre-processed and post-processed map. Also, I wanted to include some items to modify the mech’s speed and add the jetpack and things like that later. Yes the mech is supposed to feel ‘heavy’, but there’s other problems that make this not feel enjoyable. The main purpose of this mech was to have a player character with many animations states and in-between states. Sliding, Jumping, Boosting, shooting, shooting-while-walking and so on. Look at the way its organized with the finite state machine, and you’ll get why I did this. I wanted something with more complexity than “mario” to teach a user how to organize their work. I think that aspect was successful, but I have more ideas on how to improve it.

I do appreciate the positive feedback on the “graphics system”. I built the raycasting module that makes the light just a few weeks ago, and all the pixelart in the game (player and level) myself. I am far, far, far from done.

Another criticism is that the framework seems very set to the sort of game that it is right now. Yes, it does seem that way at the moment. I needed to pick a common game type that required a lot of common functionality to get started. I promise the final state of this is to not tightly couple you to a platformer, but I can see now that with no context it seems that way. I promise it will not stay that way. If you do still want something dead-simple go check out the other boilerplates or use mine and just delete the sprites and the game scenes. Seriously, just delete what you don’t need, it will still build and work just fine. I will likely have a scaffolding option to account for a super-minimal build when I convert to lerna-style scaffold.

Thank you all for looking at this. Please please remember that this project is very early in its lifecycle, but I still hope you find it useful even now.