These keys are made for walking
That’s the last time I reference Nancy Sinatra, I promise.
On friday I was thinking to myself ‘Lets get this character on screen and walking around’ to which I quickly realized what I had to do. Cocos2d-x has really shitty PC input support. I already modified Cocos2d-x to handle mouse input more sensibly by posting move events regardless if you’re clicking and to set the touch id to the mouse button id (1-2-3). But now I had to handle input a bit nicer.
Now you can become a keyboard delegate and listen to key up, down, press, and release. It should have been a trivial amount of work but I had a couple hick-ups here and there. Now it’s done and I’m really happy with how it works.
Above (old blog) is a demo of what I did on friday, adding a player MVC. The model can subscribe to input directly in my implementation and move it’s parent (controller) as need be. Because the view is also a child of the controller it can simply listen to the current state of the controller rather then having an idea of what the model looks like. So basically I’ve shuffled some of the roles between the view and the controller. It’s just as organized in my opinion and offers me more benefits with similar constraints as a traditional MVC (if you can say there is one, even). The biggest downfall to my approach is any modification of the controller will result in pretty substantial model and view changes. I’ve encapsulated everything so if I’m careful I can avoid that overhead.
Right now the model is handling input and keeping track of all math required for movement, changing the state of the controller for the view to later listen to and update the player sprite. Because the model will be moving the controller (which is a CCNode) outside observers can see the position and states as needed. So hopefully this will keep things manageable in the long term.
That’s it for this weekend!
Thanks for the read,