Another HTML5/Canvas item to be aware of - if you want Canvas only (to get the performance boost that CocoonJS gives with Canvas Only), Text Input directly into canvas is still very buggy, most likely if you want to fully support chatting you will need to include both DOM and Canvas.
I have an example of Text Input directly into Canvas on my Website Play Store App (contact Us).
I got it to work - and wrote a class to support a wrapper class (that somone else wrote for Phaser I think - this wrapper had a few bugs in it as well).
It now supports basic char entry, Swype and predictive text (The initial example only supports basic char entry).
But there are some bugs I just can't work around, e.g.:
There is no way I can currently sensibly detect a long press delete.
The current implementation appears to only allow editing entry data that was created by itself (from when you invoke the keyboard). Therefore you can't edit existing text because the delete button doesn't fire the event!!! This is the real killer for me. Not firing an event means I am completely in the dark and cannot work around the bug.
There are issues, but given time I can work-around them, The 2 above I can't work around, I could take a stab at the delete button, but the not firing an event one is nasty.
So anyway - from everything I have read - You will likely need to include both DOM and Canvas in your game if you want a decent chat experience.
I don't want to turn you off HTML5/Canvas - I think it is great and am using it for a bunch of projects - I guess I just want to let you know of some hurdles I have crashed against so you can either ensure your expectations on performance are realistic - or at least be prepared to allow your game to be a little less polished in certain areas to work around the restrictions you will sometimes get because of it being a browser game.
Sounds like you have a good history/platform. I guess what you need now is the right strategy to both manage your time and also encourage artists to join your project.
I do think a working prototype is a good place to start - it allows anyone (e.g. artists) somewhere to go to see progress and recognise that the project is not vaporware.
To back this up - you should plan the next month or more at a weekly goal level.
E.g. Lets say you start now, you might go.
Week 1: Publish working Prototype online. (maybe something you have done previously).
Week 2: Convert Client to HTML5. ((if not already done)or split this up if it takes more than 1 week).
Week 3: Add Updater system. (e.g. downloads a pack from an online server - and updates the client's graphics/levels. (again, split if you think it will takes more than a week).
Week 4: Testing week, bug fixes + ensuring code is decent quality with reusable objects etc.
...
This list should be made public - that way people can easily see that development is active and progressing rapidly - encouraging envolvement.
But it should be a simple list - one you don't have to spend much time maintaining each week.
Anyway - just some ideas. Start small - and keep hitting regular goals so that you stay on track - have the occassional Test/Code review week scheduled to help manage any slippage - and if your project isn't slipping you can either use it to improve your code or get ahead of schedule.
"As a question though are you talking about making web games?"
The stuff I am making atm is cross-platform, HTML5/Canvas. so yes they also run on a browser.
To distribute to phones you use a 'browser wrapper' i.e. it looks like a normal app - but it is actually part of the browser engine - so you are still limited by certain things like the browser resolution.
I only mention this as he was talking about GameMaker, and game maker can do a similar thing - i.e. distribute to mobile devices via HTML5/Canvas with wrapper.
Your original thought of using existing free graphics is 100% the thing to do.
Please PLEASE reconsider using ONLY existing free graphics until at least an ALPHA version.
Here are the GREAT reasons for doing this:
1) You should design your game so that graphics are easily upgraded - most popular online games do have regular graphic updates so this should be an important part of your design. So use free graphics as a part of testing the upgrade graphic code - at least until your prototype is working.
2) DO NOT try to build the entire game. If you have 1 playable room where you can do all the basics - e.g. multiple people can connect, talk, attack and move (maybe pickup weapons, loot corpses or whatever once you get the basics working), this is an enormous step - you make this 1 room your protoype room, get all the bugs out of it, make it reusable and you have the template for your game.
If you build the above and it is fun. Your game world is ready to be built, and you can seriously consider paying for graphics then.
I don't use gamemaker - but happy to hear that it is all working. :)
btw - if you are referring to my post - android phones do a similar thing. i.e the browser 'resolution' is much smaller than the actual resolution of the phone.
Supporting multiple resolutions is a difficult and frustrating thing to do, so what you are feeling is normal. :)
It is probably best to start a project with a range of devices you want to support - rather than 'support everything' - you simply can't do that with most games because resolutions can get tiny - just think smart watches etc.
I think the minimum you should consider supporting is 480x320 (or 320x480), because thiis is the iphone 3 resolution, and beyond this many other mobile phone browsers use this resolution and upscale the pixels.
i.e. even phones that have a HUGE resolution will not show this in the browser.
So here are some ideas. (Below: just replace 480x320 with 320x480 if you are using portrait vs landscape)
1) Easies: Design for 480x320, and then use scaling.
2) use a viewport so you can 'see more or less' of the game depending on resolution. (e.g. think isometric games - big resolution means you can see more of map etc.
3) use a combination of the above, i.e resize viewport within a supported range, then scale if it is outside this range.
4) design resizable outter areas. i.e inner game area is designed to fit into 480x320 - Have outter edges that fill available space so that the inside game area is always centered. resizable things to put on outter edges might include: Advertising, Help/Hints, Chat zone, Scoreboards, previous scores etc.
I used it in a Demo project for the Tululoo Game Creator (HTML5/Canvas).
Unfortunately this game creator no longer has anyone to maintain it and the community is practically dead.
But I only recently found it and love its simplicity and the fact its pretty much just a Javascript wrapper/helper - so I can dump any useful Javascript functions straight in - or as extensions and they just work.
I put together the isometric example in a matter of hours having never put together an isometric example/demo or game before. (only read about the theory).
Hopefully I can breath some life back into Tululoo. :)
Sounds good.
Another HTML5/Canvas item to be aware of - if you want Canvas only (to get the performance boost that CocoonJS gives with Canvas Only), Text Input directly into canvas is still very buggy, most likely if you want to fully support chatting you will need to include both DOM and Canvas.
I have an example of Text Input directly into Canvas on my Website Play Store App (contact Us).
I got it to work - and wrote a class to support a wrapper class (that somone else wrote for Phaser I think - this wrapper had a few bugs in it as well).
It now supports basic char entry, Swype and predictive text (The initial example only supports basic char entry).
But there are some bugs I just can't work around, e.g.:
There is no way I can currently sensibly detect a long press delete.
The current implementation appears to only allow editing entry data that was created by itself (from when you invoke the keyboard). Therefore you can't edit existing text because the delete button doesn't fire the event!!! This is the real killer for me. Not firing an event means I am completely in the dark and cannot work around the bug.
There are issues, but given time I can work-around them, The 2 above I can't work around, I could take a stab at the delete button, but the not firing an event one is nasty.
So anyway - from everything I have read - You will likely need to include both DOM and Canvas in your game if you want a decent chat experience.
I don't want to turn you off HTML5/Canvas - I think it is great and am using it for a bunch of projects - I guess I just want to let you know of some hurdles I have crashed against so you can either ensure your expectations on performance are realistic - or at least be prepared to allow your game to be a little less polished in certain areas to work around the restrictions you will sometimes get because of it being a browser game.
Oh - and another note, I know HTML5/Canvas can do some cool stuff - I am also using it.
But it still doesn't compare to engines like Unity3d on graphic intensive and complex games.
The game you have linked to in the past looks very graphic intensive, using a large world and many users/objects etc.
(I also read somewhere you also have a Unity3d pro licence?)
I guess the question is - will HTML5/Canvas have the performance you need? Or should you reconsider Unity?
Sounds like you have a good history/platform. I guess what you need now is the right strategy to both manage your time and also encourage artists to join your project.
I do think a working prototype is a good place to start - it allows anyone (e.g. artists) somewhere to go to see progress and recognise that the project is not vaporware.
To back this up - you should plan the next month or more at a weekly goal level.
E.g. Lets say you start now, you might go.
Week 1: Publish working Prototype online. (maybe something you have done previously).
Week 2: Convert Client to HTML5. ((if not already done)or split this up if it takes more than 1 week).
Week 3: Add Updater system. (e.g. downloads a pack from an online server - and updates the client's graphics/levels. (again, split if you think it will takes more than a week).
Week 4: Testing week, bug fixes + ensuring code is decent quality with reusable objects etc.
...
This list should be made public - that way people can easily see that development is active and progressing rapidly - encouraging envolvement.
But it should be a simple list - one you don't have to spend much time maintaining each week.
Anyway - just some ideas. Start small - and keep hitting regular goals so that you stay on track - have the occassional Test/Code review week scheduled to help manage any slippage - and if your project isn't slipping you can either use it to improve your code or get ahead of schedule.
I do have a skype but it is currently not running - I find it very distracting so only start it up when a job requires it.
I have sent you a message/email, so if you want to bounce around some ideas - start us off and I'll start skype if we get chatting. :)
@Saliv
"As a question though are you talking about making web games?"
The stuff I am making atm is cross-platform, HTML5/Canvas. so yes they also run on a browser.
To distribute to phones you use a 'browser wrapper' i.e. it looks like a normal app - but it is actually part of the browser engine - so you are still limited by certain things like the browser resolution.
I only mention this as he was talking about GameMaker, and game maker can do a similar thing - i.e. distribute to mobile devices via HTML5/Canvas with wrapper.
Your original thought of using existing free graphics is 100% the thing to do.
Please PLEASE reconsider using ONLY existing free graphics until at least an ALPHA version.
Here are the GREAT reasons for doing this:
1) You should design your game so that graphics are easily upgraded - most popular online games do have regular graphic updates so this should be an important part of your design. So use free graphics as a part of testing the upgrade graphic code - at least until your prototype is working.
2) DO NOT try to build the entire game. If you have 1 playable room where you can do all the basics - e.g. multiple people can connect, talk, attack and move (maybe pickup weapons, loot corpses or whatever once you get the basics working), this is an enormous step - you make this 1 room your protoype room, get all the bugs out of it, make it reusable and you have the template for your game.
If you build the above and it is fun. Your game world is ready to be built, and you can seriously consider paying for graphics then.
I don't use gamemaker - but happy to hear that it is all working. :)
btw - if you are referring to my post - android phones do a similar thing. i.e the browser 'resolution' is much smaller than the actual resolution of the phone.
Supporting multiple resolutions is a difficult and frustrating thing to do, so what you are feeling is normal. :)
It is probably best to start a project with a range of devices you want to support - rather than 'support everything' - you simply can't do that with most games because resolutions can get tiny - just think smart watches etc.
I think the minimum you should consider supporting is 480x320 (or 320x480), because thiis is the iphone 3 resolution, and beyond this many other mobile phone browsers use this resolution and upscale the pixels.
i.e. even phones that have a HUGE resolution will not show this in the browser.
So here are some ideas. (Below: just replace 480x320 with 320x480 if you are using portrait vs landscape)
1) Easies: Design for 480x320, and then use scaling.
2) use a viewport so you can 'see more or less' of the game depending on resolution. (e.g. think isometric games - big resolution means you can see more of map etc.
3) use a combination of the above, i.e resize viewport within a supported range, then scale if it is outside this range.
4) design resizable outter areas. i.e inner game area is designed to fit into 480x320 - Have outter edges that fill available space so that the inside game area is always centered. resizable things to put on outter edges might include: Advertising, Help/Hints, Chat zone, Scoreboards, previous scores etc.
Good luck
Love this tileset.
I used it in a Demo project for the Tululoo Game Creator (HTML5/Canvas).
Unfortunately this game creator no longer has anyone to maintain it and the community is practically dead.
But I only recently found it and love its simplicity and the fact its pretty much just a Javascript wrapper/helper - so I can dump any useful Javascript functions straight in - or as extensions and they just work.
I put together the isometric example in a matter of hours having never put together an isometric example/demo or game before. (only read about the theory).
Hopefully I can breath some life back into Tululoo. :)
http://percsich.hu/tgmforum/index.php?topic=744.0
Looks great. :)
Pages