I'm starting to build my game. I'm currently getting it started in C++, and I'm doing some initial database interaction with both MySQL and Sqlite3. I'm thinking Emscription to get me into HTML5/WEBGL, as the time may be right for the next jump in browser gaming.
This isn't a new idea; I've been fleshing out game mechanics for a couple of years, but I haven't commited to any actual development because I cannot decide on what platform to develop for.
With the popularity of "apps" for tablets and phones; the introduction of html5/webgl, and of course the standard client/server style, I still cannot decide.
I've been playing around with come C++ to httpd to javascript type libraries, which really fit to my ideas of accessibility, but it seems rather lonely in that area as opposed to using something like SFML. I'm concerned about using libraries that could die on the vine and leave me in a bad place, with no hope to continue.
Starting as a lone developer, whatever I do is going to take a long time. At the point that I may become enouraged that my project could be viable, I'll have to then collaborate with other developers and creatives, which will initiate another period of "long time".
what is the best bet platform-wise to launch an RTS/MMO game 2, 3 or 5 years from now? Should I develop in two different platform styles concurrently as a backup plan? Say, WEBGL and SFML at the same time.
If it wasn't for the handheld market and it was still 10 years ago, I'd probably just go with SFML and do regular client/server. But I'm not sure PC gaming is going to last by the time I'm ready.
Should I not worry about this? To me, the server config and presentation pipline is way more work than game logic and mechanics. I'm not sure about graphics, but they may not necessarily play such a large part of the games' draw so-to-speak.
I don't know... Any thoughts would be appreciated.
Choosing a platform to design for
I'm not sure who plays games without graphics.what is the best bet platform-wise to launch an RTS/MMO game 2, 3 or 5 years from now?
Say, WEBGL and SFML
But I'm not sure PC gaming is going to last by the time I'm ready.
I'm not sure about graphics, but they may not necessarily play such a large part of the games' draw so-to-speak.
PC gaming will be around for many years, probably as long as the windows OS.
My comment on graphics was based on gameplay before visuals.
But will the games be accessed more by web browser and less by standard game clients?
Also, how painful would it be to go from say an SFML library to whatever library takes hold for web based gaming?
I know it's like trying to predict the future, but there are quite a few games that died due to technologies becoming obsolete before a game is finished.
sounds like you need to design the game in two parts:
1. a platform independent game
2. a platform dependent back end
part (1) you can just build once. use today's APIs as an example of the types of APIs you'll need to interface with.
a translation layer translates generic calls from (1) to platform specific calls in (2).
built part (1) and a translation layer to some API for development purposes. select the API you think will be most likely to still be around at the end of the whole project.
once you've done that, or more likely while you're doing that, you can take another look at the APIs and platforms to choose from. select a new API, write a translation layer, and your done.
This way you do as much platform independent development as you can before you're forced to select what platform(s) you'll ultimately support. And the time horizon from selecting a final API to final release goes way down, because the game is already done, except for a new translation layer.
Its possible you might want/need translation layers for graphics, networking, and OS calls.
the project sounds complex but doable. i would urge you to determine to the highest degree possible the best way to build it (best libraries to use etc) before you start coding. this will reduce / eliminate time wasted on sub-optimal solutions due to inexperience, or ignorance of available tools / methods.
i have a saying:
"when building games, you need to worry about what you don't know how to do, not what you do know how to do."
just keep figuring out how to do what you don't know how to do, until you've figure out everything you need to build the game - then build it.
