Which engine to pick?

[hicotech]

I see.. lets see what we get in the future.. for now I will play with current Phaser

[mattstyles]

Yeah, deffo, see how you like the api style, docs and community, those things shouldn't change much (at least in the short-mid term).

[sleepypeepee]

I'm tying myself in knots trying to find an optimum and comfortable starting point to develop a game I've got an idea for, and simply cannot decide which frameworks to use.

Because I'm a front-end dev, with experience of JavaScript, I thought it would be best to write a game using JavaScript and canvas, rather than learn something like C# from scratch. My plan is then to convert my game to multiple platforms using Phonegap.

I want to develop a game with an 8-bit graphics look that is very menu-driven, similar to Game Dev Story. I need to handle some very basic sprite animation and maybe a bit of tweening, but that's about as complex it will get visually.

The main problem I've got is that most frameworks seem to want to force you to make a side-scrolling game, or one involving collisions and physics, yet all I want to do is draw a background image to the canvas, overlay a few animated sprites on top of that, have clickable buttons and menus, and have a 'tick' I can easily create to simulate the passing of days in the game.

I want to use something light and not bloated with graphics features I don't need. I'm leaning towards using Phaser at the moment, but I can't help but think it's maybe a bit overkill, so maybe pixi.js is a better option. Can anyone recommend a framework that would suit my game type?

[mattstyles]

16 hours ago, sleepypeepee said:

Can anyone recommend a framework that would suit my game type?

If your game is menu driven then DOM (and its many many many libraries for manipulating it) makes perfect sense in a browser environment and saves you the headache of reimplementing many of its features for a canvas-only env. Use DOM for your UI and a canvas element for your game screen, Phaser would be fine but I'm not sure you'd need all of it, possibly if you want access to its state management functions, quite possibly if you want audio stuff, you'd probably not need its input helpers (but maybe you do, for keyboard shortcuts maybe).

Keep your UI dumb, so your UI dispatches actions and you have something listening (basic pub/sub) then somewhere you set up a tick, this is also an action with (at least) 2 listeners, one to perform a render and one to perform logic updates each tick, if you're setup like this you might find you don't want Phaser to manage high-level game states for you (with its own tick and methods) and you might want to create your own.

I've done a number of little POC's and demos (similar in requirements to you, a rendering layer and a menu-driven UI) using React for my UI and app state management and Pixi for rendering (I didn't need Phaser for those projects, I just needed a rendering layer, I preferred to write my own state management stuff and I was happy using Howler for audio and my own keyboard entry helper lib for shortcut stuff).

[sleepypeepee]

8 hours ago, mattstyles said:

If your game is menu driven then DOM (and its many many many libraries for manipulating it) makes perfect sense in a browser environment and saves you the headache of reimplementing many of its features for a canvas-only env. Use DOM for your UI and a canvas element for your game screen, Phaser would be fine but I'm not sure you'd need all of it, possibly if you want access to its state management functions, quite possibly if you want audio stuff, you'd probably not need its input helpers (but maybe you do, for keyboard shortcuts maybe).

Keep your UI dumb, so your UI dispatches actions and you have something listening (basic pub/sub) then somewhere you set up a tick, this is also an action with (at least) 2 listeners, one to perform a render and one to perform logic updates each tick, if you're setup like this you might find you don't want Phaser to manage high-level game states for you (with its own tick and methods) and you might want to create your own.

I've done a number of little POC's and demos (similar in requirements to you, a rendering layer and a menu-driven UI) using React for my UI and app state management and Pixi for rendering (I didn't need Phaser for those projects, I just needed a rendering layer, I preferred to write my own state management stuff and I was happy using Howler for audio and my own keyboard entry helper lib for shortcut stuff).

 

Thanks for the reply and for all the great information. As a front-end developer using the DOM is my bread and butter, so I'm definitely fine with this approach. Will this cause any issues in Phonegap though, if I translate the game mobile platforms?

 

Also, the main interface of my game is a smartphone screen with clickable icons, all drawn in 8-bit. The clickable icons on the phone screen act as links to other game screens, all within the phone interface. 

 

The phone interface isn't always on screen, and sometimes the game will cutaway to scenes with characters walking about and other things which wouldn't be shown on the phone screen, but the bulk of the game will take place clicking things within the phone interface.

 

Would it be best to draw the 8-bit image of the phone to canvas and then use anchors containing <IMG> elements absolutely positioned over the phone to house the icons for the phone screen, then handle a click event on these anchors, or alternatively would it be best to draw the icons for the phone screen as sprites onto the canvas then handle click events on these sprites?

 

By the sounds of it I don't think I'll need Phaser and I think Pixi is exactly what i need, so thanks very much for giving me some direction. I've also been looking at Crafty as it looks quite straight forward, but i think things like good docs and community make Pixi the better choice.

[mattstyles]

12 hours ago, sleepypeepee said:

Will this cause any issues in Phonegap though, if I translate the game mobile platforms?

Nope, phonegap/cordova is just a webview, using the exact same engine as the browser app on your phone does (actually, this is not strictly true, iphones still use a slightly older version, although their is a plugin to use wkwebview, don't look at the abomination which is the code that makes that work, hack hack hack! and some slightly older versions of Android also use an older version of Chrome—something like 37 off the top of my head, its old anyways—again, there is a plugin that will use a newer version, crosswalk does it too I believe).

12 hours ago, sleepypeepee said:

Would it be best to draw the 8-bit image of the phone to canvas and then use anchors containing <IMG> elements absolutely positioned over the phone to house the icons for the phone screen, then handle a click event on these anchors

If the phone graphic is static then use an image tag for that too and do the whole lot in DOM.

Canvas is good for moving around lots and lots of sprites really quickly, although you'd likely be surprised how far just regular old image elements can get you.

Keep things as simple as possible, if its image buttons, use the DOM, if its a static image, use the DOM, if its input fields, use the DOM, if its a complex animating tilemap, maybe canvas would be best, if its complex drawing ops you need, use canvas, if its a 2000 element particle emitter you need, use the canvas.

[sleepypeepee]

8 hours ago, mattstyles said:

Nope, phonegap/cordova is just a webview, using the exact same engine as the browser app on your phone does (actually, this is not strictly true, iphones still use a slightly older version, although their is a plugin to use wkwebview, don't look at the abomination which is the code that makes that work, hack hack hack! and some slightly older versions of Android also use an older version of Chrome—something like 37 off the top of my head, its old anyways—again, there is a plugin that will use a newer version, crosswalk does it too I believe).

If the phone graphic is static then use an image tag for that too and do the whole lot in DOM.

Canvas is good for moving around lots and lots of sprites really quickly, although you'd likely be surprised how far just regular old image elements can get you.

Keep things as simple as possible, if its image buttons, use the DOM, if its a static image, use the DOM, if its input fields, use the DOM, if its a complex animating tilemap, maybe canvas would be best, if its complex drawing ops you need, use canvas, if its a 2000 element particle emitter you need, use the canvas.

Thanks again for the quick reply and great information.

I'll just do the bulk using the DOM then. All of the phone screen views will either be text-based or static with clickable elements, so all DOM-friendly. 

My only slight reservation is a screen where you can see your character and all associated character stats. The character will have a very basic subtle 2-step animation to them while they stand there looking pretty (so they look alive), and the character's hair and clothes can be customised on this screen. For this I could maybe use a canvas absolutely positioned above the phone graphic just for the purposes of drawing the required sprites (hair, clothes, accessories) and animate them.

Then when the player leaves the phone interface, I can get rid of the DOM-based stuff (the phone) and show a canvas, where I can animate/tween the player's character sprite doing stuff in a scene, and show other animated sprite characters in the same scene. These will just be non-interactive scenes I think, similar to the ones in Game Dev Story. When the scene is over, I can hide the canvas, then load the static phone graphic back in with the DOM interface.

Does this sound like a good approach?

[mattstyles]

15 hours ago, sleepypeepee said:

Does this sound like a good approach?

Absolutely does.

If you liked Game Dev Story have you checked out Game Dev Tycoon by Greenheart? It's a node-webkit game too so if anyone says you can't make a successful game using the DOM (or even relying heavily on jQuery!!) then show them that!

[sleepypeepee]

On 22/02/2017 at 8:11 AM, mattstyles said:

Absolutely does.

If you liked Game Dev Story have you checked out Game Dev Tycoon by Greenheart? It's a node-webkit game too so if anyone says you can't make a successful game using the DOM (or even relying heavily on jQuery!!) then show them that!

Brilliant, thanks for all your advice... I finally have some direction. Ironically, this is probably the direction I'd have taken if I'd just used the "stick to what you know" approach and dived straight in, but now I have a good understanding of how to approach different game content and why.

I may use some jQuery for the odd transition animation, but then again, I may use Angular to handle the different phone views so I may as well take advantage of ngAnimate.

I've not checked out Game Dev Tycoon but I just loved the simplicity of Game Dev Story, but it's good to know other successful games use the DOM. I use Node for Express stuff, and of course the Node Package Manager, but I've never used node-webkit... sounds interesting, but I'd rather get on with some creation now for the next few months using what I know... as a developer you could spend your entire life learning all the new technologies that appear.

[mattstyles]

4 hours ago, sleepypeepee said:

as a developer you could spend your entire life learning all the new technologies that appear.

Yeah, JS particularly you have to be very careful about not getting sucked in to a hole! It's good to keep abreast of all the amazing stuff thats out there but at some point you have to pick and choose if you're actually going to get anything done.

I'm not a fan of any of those techs you mention though! I'm in the functional camps rather than Angular, so React or Vue more so, I did a fairly involved POC using Angular 2 a while back but its a bit of a mess and I'm not sure its really improved much in the last few months since I touched it. Instead of node-webkit I'd advise Electron and I don't really see the point of jQuery now as there are better alternatives (usually given to you by the browser or the language) to all of its features, but, as with all these things, it depends on your own standpoint (and that of your team) and what you need for each project.

A good engineer picks the right tool for the job, irrespective of whether its a 'fashionable' or 'hyped' tool.

Good luck with your project/s, I enjoyed Game Dev Story (and a few other Kairosoft stuff) too, there was a dungeon one and a racing one I played for a bit, both a similar formula, easy to get in to, easy to pick and put down and enjoyable, a good formula for casual gaming I think.

[nicloay]

Do you need html5 game support? because regarding your list you want to publish on mobile and desktop.

If so, you can try http://defold.com/ it use lua for scripting, but in active development and has all features which you need (sound, tile map, spine animation, particles, shaders, native plugins on iOS and android)

with html5 right now there is one big issue is that they don't have integration with javascript, but they said that they will release it soon (in 2-3 release so it means in month or two)

 

and to be fair =) this engine is acquired by King =).