2D framework with MVC and TypeScript

[AnimateDream]

I'm looking to continue my 12 year off and on hobby of game development. I'm a professional web developer now, but I have yet to make a web game. 

I'd like to make things a bit more modular and isolated than my previous work. I think MVC will help. I'd like to have the Model (the game simulation with all game logic, physics, etc.) in it's own web worker. The View would get a feed of basic state information out of it for rendering, camera, audio, etc. The Controller would react to the user and send information back to the Model. The View would have no information to send to the Model. 

I'm planning strategy games more than twitchy action games, so I think having the Model in a separate web worker, will actually be better for performance. A bit of input lag is more acceptable than a low frame-rate. If the Model -> View communication includes velocities, the frame-rate of the view can even be decoupled from the frame-rate of the Model.  Plus if I move to start working on multi-player networking, the Model -> View communication can just be more or less duplicated for Server -> Client

My favourite language has always been Python, and I used to loath JavaScript, but the newer ECMAScripts are correcting my biggest gripes, and ultimately I'd really like to work more with Typescript.

Finally, I think I'm going for 2D because I'm not working with any 3D animators and my game play ideas are not really enhanced with by a third dimension.

So I have a few concerns

• It seems there's a lot of poor opinions about MVC in games around here, but it seems perfect for strategy games to me. Is my approach really ill founded?
• I might find myself working against a broader framework like Phaser or Kiwi. Should I just stick Pixi in the View and a physics engine in my Model, or would a broader framework solve more problems than they create for me? 
• It seems like Phaser is the popular choice, but I wonder if perhaps my use of Typescript and MVC might make Kiwi or something else the better choice?

[Jacolaisen]

I agree that MVC is well suited for strategy games since the load on graphics in many cases are lower and thus you can take advantage of dom manipulation instead of canvas. If this is the case for your game I would also ditch the physics engine. In a strategy game I am developing in a similar vain, I am using angularJs with great gains from two-way-binding, a nice clean cut between view & model and promisebased ajax-handling. In angular2 you also get Typescript fully integrated.

Best of lucks with the game. I am looking forward to hear more about it.

[ivan.popelyshev]

Even if you start with MVC, after some time it will start to look as Entity-Component system. Having models in separate web worker is difficult, I failed to do it, so I wish you luck!

You can take latest PIXI (+pixi-spine +pixi-display +pixi-tilemap) and extend Container class to create your Entities, add your components inside "entity.physBody = new PhysBody(entity);".  Register specific components in your own managers, like PhysicsManager or NetworkManager. 

[dimumurray]

I too support using the Entity-Component-System paradigm for your game. MVC is great for enterprise applications; games not so much.

Check out the following articles on Entity-Component-Systems; they'll give you a better feel for what this approach to game development offers:

What is an entity system framework for game development?

Why use an entity system framework for game development?

 

[mattstyles]

There is an alternate view that MVC is ill-suited for all programs, two-way data-binding is currently taking a proper battering in the JS world, partly as it tends to be inherently linked to the DOM.

If you want to approach it with fresh eyes (so to speak) then its probably worth objectively looking at the methodology you use daily from all angles, even if you come full circle and decide MVC does work for you.

Remember that JS is JIT compiled so many aspects that make MVC seemingly attractive actually make little sense, take, for example, this small extract from the GoF regarding favouring composition over inheritance:

Quote

Object composition lets you change the behaviour being composed at run-time, but it also requires indirection and can be less efficient.

The second part of this sentence is moot in JS since everything is forced down this route so this 'downside' of composition is irrelevant, and hence, one strength of inheritance (a key part of both MVC and Entity-Component) also becomes irrelevant. Interface inheritance is also useless in JS as there is no reliable and clean way of enforcing or harnessing it, ditto for polymorphism.

I'm not bashing any paradigm here, everything has its uses, I'm just trying to encourage objectivity.

[AnimateDream]

Thanks to everyone for all of the thoughts.

 

@dimumurray Extra thanks. Those links were a great resource.

@mattstyles  Don't worry, I did not propose two-way data binding in the description of my architecture and MVC doesn't really imply it. Perhaps I gave a poor explanation, but I certainly said that all communication between the model and the view is one-way, to the view. MVC is really just about a separation of concerns and responsibilities. Two-way data binding is usually between the DOM and the Model and came along way later when people tried to apply MVC to front-end frameworks, and came up with something kind of new and different in my honest opinion. I'm considering using regular html inputs for some of the UI for the game so the controller in my architectural plan could make use of two way data binding, but it would still be binding to a kind of view model that isn't even in the same thread as the actual Model. Much of the View's job would be dedicated to rendering to canvas or WebGL where binding isn't really two way, because you're just pushing out frames, not interactive html elements with user manipulable data.

 

The Entity-Component-System paradigm sounds useful. I wouldn't say it is 100% antithetical to MVC either. Basically to apply it to my idea some of the systems would exist in the Model and some of them in View, while the entities, and a subset of their components, get passed from the Model to the View, once they're finished there.

The Entity-Component-System paradigm is elegant, but really does little to address the difficulty of parallelizing work in JavaScript. Sure JavaScript makes concurrency easy, so you can keep the thread busy without waiting on anything external, but as I understand it, without web workers, the interpreter is still only ever working on one thread at a time. That means all of those Systems are going to be waiting on each other. Alternatively each System gets it’s own web worker but the required communications involved could outweigh the performance gains. Maybe just some of the systems get their own web workers, but the paradigm provides no real prescription for how to split that up and how that data flows through the stages of processing and ends up as a rendered frame. My earlier ideas address that, and lay down a simple path to handling network communications for multiplayer.

I don’t mean to suggest that the Entity-Component-System is bad. It just sounds better for a single threaded solution or a language that has traditional threads (which do multicore processing on shared memory). It doesn’t seem like it really seeks to solve the all of the same problems MVC does either. It’s not really clear how user input fits into the paradigm from the articles I read. Looking at the asteroids example for Ash I saw checks for key states going on in “control systems” which also directly modified velocity and rotation. I would guess for a bigger game with things like AI players, and networking you would have some additional components providing a layer of abstraction.

I still haven’t gotten around to solving my original problem of what game engine would be compatible with the architecture I have started. My ambitions have been redirected towards some home improvement at the moment, but I’ll update when I make some progress. On the game dev that is. 

[Roy Bregman]

Hey,  still waiting to hear what have you chosen. Which pattern and which game engine .

[d13]

On June 30, 2016 at 9:30 AM, AnimateDream said:

Sure JavaScript makes concurrency easy, so you can keep the thread busy without waiting on anything external, but as I understand it, without web workers, the interpreter is still only ever working on one thread at a time.

I wouldn't worry too much about Web Workers.They don't really work properly, will worsen the concurrency state management problems that JavaScript already burdens you with, and multithreading is possibly a really bad idea anyway: http://stackoverflow.com/questions/93834/when-is-multi-threading-not-a-good-idea