I am making a game with web, iphone, and android front-ends. I want to make them all able to interact well through the back-end so that any user can play with any user.

To do this I've decided to make an "API" or really just a Ruby on Rails back-end (with the rails-api gem). Which option fits best:

1. Back-end First

Process would be building entire back-end functionality, one feature at a time until it is complete (can always expand missing features later). Can test it using different types of tests.

2. Back-end alongside one platform (web)

Process would be building one feature in the back-end, then using it in the front-end to make sure it works. Would be easy to build with web because most Rails projects already have views.

3. Back-end alongside each platform

Same as option 2, but building the feature in each platform before moving on to the next one. Would allow fixes for cross-platform problems as you go along, being able to narrow it down precisely.

Essentially I know possible ways to go about it, but have never made an API or cross-platform game

  • \$\begingroup\$ this isn't a how to get started...i've started and built a few games already and i've already had experience with rails. this is for asking the experienced answer. heck it's more answerable than gamedev.stackexchange.com/questions/60329/… which seems to have plenty of votes, eh? \$\endgroup\$
    – Tom Prats
    Aug 7 '13 at 4:35
  • 2
    \$\begingroup\$ I'm voting against re-opening. First, your question edit was superficial; it didn't change the topicality of what you're asking. Second, you want to build a web-based data service. That 1. is not specific to game dev, 2. does not have a "best" method, 3. is open-ended work for which you are asking for get-started advice. Third, you aren't even asking about game data services, you're pondering what order in which to implement its (undeclared) features. Don't seek out fault in some other question. Find a way to improve your own, or wait until you have a specific, SE-appropriate question. \$\endgroup\$ Aug 7 '13 at 7:44
  • \$\begingroup\$ You guys are adorable, ill see what I can do. (My edit was meant to be superficial, I still thought it fell into a correct question area, my apologies) \$\endgroup\$
    – Tom Prats
    Aug 7 '13 at 17:16
  • \$\begingroup\$ Ah. Well for future reference, edits to closed questions trigger reopen votes. I'm not sure this one will be salvageable in any case, but a data service question might fare perfectly well on a different stack exchange site. Afterall, it's a pretty common web application, and rails is meant to build RESTful interfaces easily. But I would recommend asking about the service itself, rather than what order features should be implemented. \$\endgroup\$ Aug 7 '13 at 19:21

If you are like 99.9%+ of people who try their hand at game development (and I am one too), your #1 biggest challenge is getting something playable, followed by #2 getting something other people enjoy playing too.

The problem with simultaneous platform development is that you are putting both of these milestones farther off, in exchange for largely illusory gains; the illusion being that having so many balls up in the air will make the total project time less. If it does its only because something got dropped, and possibly the whole project was scrapped.

Planning for multiple platforms is fine, however. You need to have this in mind when you are picking technologies, as imagine making a game 4 years ago in Flash with a goal being deploying it to iPhones; that would have required a lot more work than starting with a different platform, or cutting it and making it a wish list item for the sequel.

As to what methodology, I would recommend a version of your #2, but with the front-end first. The front-end is the game to the player, and that's what matters. A flawless back-end with a bad front-end is not really a game at all.

So I would suggest picking the platforms you know you want to target (browser [Firefox, IE 7+ only, and Chrome?]), iOS [version 5+?], Android [4+ only?]), Ruby web server as a back-end tech sounds just fine. Make sure what you want to do is seemingly doable on your target platforms; now a days it probably is, but if you are thinking anything tricky with 3D it gets a bit more dodgy.

Knowing your target platforms allows you to intelligently pick engines, design tools, etc.

Then I suggest picking the platform you feel like you'd be most comfortable in for maximum development speed. Prototype a feature on the front-end (the game), probably by faking the server call with a dummy, and when you are happy with the feature and how it works/plays then implement the real thing on the backend.

This way you isolate the source of errors, and you might find that a feature you thought was a good idea doesn't make sense at all when you playtest, allowing you to cut the feature completely and skip having to implement it on the backend at all.

If your chosen technology makes it easy to compile over to a different platform, then at various milestones you might want to give it a test drive on a mobile device and see how it's going. It won't be perfect, but it helps to keep you from designing the whole thing with platform-specific features that flat out won't work on other platforms. I practice this with web development and browser versions, and it keeps endless platform testing to minimum while keeping me realistic about how big of a deal its going to be to support platform X.

You might want to support Android 2.2, for instance, then find out its going to be a huge time sink for some reason and decided to just drop support and save yourself the headache; or maybe its works great and iOS is making you wonder if it is worth it at all, etc.

Once you have a version you are proud of and people like to play in the browser, you can then know approximately how big of a deal mobile versions will be, and whether or not you even want to bother. You will be more likely to finish, less swamped with minutiae (how iOS vs Android handles screen refresh is NOT important to having a successful game on the browser), and probably find the whole experience more enjoyable and less overwhelming.


Not the answer you're looking for? Browse other questions tagged or ask your own question.