Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

During your development process, when is the recommended phase to decide what platform to aim for, and what language to use?

I figured that it would be better to choose at the beginning what would be your target platform, as it would affect your design decisions, and limit the language you are supposed to use.

However, I have heard several stories of people developing their game with whatever language they were the most confident with, and then porting it to the various platforms.

So, what is the best moment to choose? Before, during, after? If there is not one best choice, what factors should affect the decision?

share|improve this question
    
I cannot theorize about what I want to develop without choosing language / platform first. –  joltmode Mar 22 '12 at 8:43

4 Answers 4

up vote 9 down vote accepted

You have to make this decision up front, before you start on any sort of development. Until you decide what language(s) and platform(s) to utilize, you can't actually do anything but concepting, design and preproduction.

That said, you may want to allow for future ports or expansion to factor in to your decision. If you want to port to multiple desktop platforms (Mac, Windows for example) it may be better to opt to use OpenGL as your rendering back-end (or some other cross-platform abstraction/rendering engine). Otherwise you will generate more work for yourself in the long run. Likewise with language choices -- Objective-C is weakly-supported just about everywhere but on the Mac, so if you're developing for the Mac, you may want to try and minimize your actual use of Objective-C to just the required bootstrapping bits.

However, do consider that there's generally no amount of up-front agonizing over technological choices that will make porting trivial, so your better off simply making a decision and moving on to creating a real product instead of faffing about over hypothetical porting issues that won't exist until you actually have a thing to port.

Also keep in mind that unless you have the target hardware, porting to it will be difficult. If you don't have or never plan to buy a Mac, don't bother including considerations for Mac porting into your plans right now. Similarly, restricting your language choices to things you know really well (unless you're making a smaller project for the purposes of education) is usually a good idea.

share|improve this answer
    
Didn't take into account the fact that it's better to focus on a device I have... I have only one of the three platforms I was hesitating between, so the choice is done now –  Cristol.GdM Mar 21 '12 at 23:17

your feature set, and requirements should be a determination on any decision you make toward your game design.

the decision of platform that can either be determined on want (I want to make this kind of game for X system), analysis (this platform has the ability to support some really cool features that I want in my game), or cost (in order to develop for this platform I would need to use this SDK which costs Y dollars)

SDK/development environment some systems can only be developed for with specific SDKs, and others there are SDKs specifically designed to port to multiple targets.

For the most part the differences between languages can be viewed as marginal (I know that this can be cause for debate, but some differences are really marginal), but it is mostly based on the SDK being used, and what languages it supports. to develop for Unreal your options are unreal script, or c++ (kinda). for XBox360 your options really are just C#. yes you could probably find a way to do any platform with c++, but sometimes that does throw away possible benefits the platform can offer.

share|improve this answer
2  
The differences languages are not at all marginal. C++ and C# are somewhat similar, but you can't say the same for languages like Haskell, Prolog, Lisp, Forth, etc. –  Pubby Mar 21 '12 at 18:15
    
@Pubby like i said in the answer (I know that this can be cause for debate, but some differences are really marginal) what I was referring to was more on the lines of learning a secondary, or tertiary language. the first one is the hardest after that its just understanding the differences, and limitations –  gardian06 Mar 21 '12 at 18:19

Changing languages is hard, adding support for a new platform is easier, but planning everything out in advance is by far the easiest.

Of course, it is practically impossible for everything to go to plan, and so you should design systems uncoupled from their underlying implementation.

So, what is the best moment to choose? Before, during, after? If there is not one best choice, what factors should affect the decision?

If you are unsure then you haven't done enough research. Figure out everything you need before you begin. It may take days to do, but it's better than spending weeks having to port/rewrite. Eventually you will have to make a decision, but with plenty of research you will have narrowed your choices into a selection that can't go wrong.

share|improve this answer
    
Yeah, I searched enough to end up hesitating between 3 platforms: one traditional gaming platform, and two mobile platforms... But as mentioned by another answer, the fact I have only one of these three platforms will be the final decision making point –  Cristol.GdM Mar 21 '12 at 23:21

I just write the whole thing in perfect pseudo code, then port that.

But seriously, before you start. I don't think porting to another platform after the project is done should ever be part of the original plan.

Beginners should develop in what they're most comfortable with. Those stories you heard of people porting after their project was complete likely didn't plan on that from the beginning.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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