next »

[joeyspacerocks]

I'm currently building a 2D game for iOS devices in C and OpenGL (ES) and having already experienced the echoing cavern that is selling on mobile once am getting ready to accept that I should really be targeting more platforms. I just can't face the idea of putting IAP or ads in it.

The game itself is a 2D platformer with, of course, big pixels. To port the game to another platform would be a bigish investment in time, but not inconceivable. Most of the work would probably be time spent just learning about a new ecosystem and build tools without having XCode do all the hard work.

Does anyone have any advice on where such a game may appeal? Steam as a distribution platform is pretty much all I read about these days, so should I just target desktop PC / Mac / Linux and give Steam a go?

For those of you that sell on multiple platforms where do you find your biggest market?

[qwurp]

I would strongly consider PC. Mac and Linux and great to have- but depending on the level of effort needed to port and properly test- may not be worth the sales they generate (unless you're using Unity or similar). It's a very small minorities of gamers on Mac and Linux, even on Steam. They're both outspoken groups of gamers so its easy as developers to always assume that they need to be included but from an economics standpoint, the percentage of sales they make up is generally not worth the effort, especially if youre using proprietary tech or dont have access to the hardware/people needed to properly test on other platforms.

[BishopGames]

What we did for our game (also a 2D platformer but developed on PC and console) was try to compare with similar games. At first we only wanted PC (Steam obviously), but after doing our homework and comparing with similar games, we found out that consoles were a great port (Sony, Microsoft) and that the playerbase was there for this type of game.

How to compare? I would suggest rating your game on 4-5 elements and rate them in importance. Then you check out other platformers, but also games from other genres that share the 4-5 elements you chose and check what they are released on.

Ex: for our game, the elements were the following (in no particular order, can't remember):
Beautiful Art
Immersive Experience
Storytelling (Voice-over narration)
Addictive Gameplay

So we basically studied platforming games with voice-over narration/deep storytelling, appealing art, fun and addictive game mechanics and also that gave the player an immersive experience. Games like Bastion, Dust: An Elysian Tail, Trine, Sly Cooper (the franchise), and several more. We then proceeded to check what their road to success was, the platforms they were on, etc.

Hope this helps!

[joeyspacerocks]

Thank you both - valuable information. I'm figuring that yes PC of course is the main desktop platform to go for.

Really good ideas, BishopGames, for approaching it with more rigour.

Thanks for your time.

[FreelancerFile]

The best advice anyone can give you is whatever market you are thinking about entering, look at the platform games on there that are getting decent downloads (free or otherwise) and ask yourself can you make a game better than that? It's not enough to make another nice looking platform game to go in with the 100s of other similar games, it will make hardly any revenue. The only exception is if you have $$$$$ to spend on promotion then it doesn't really matter what you do, but if you don't, you game needs to stand out on any platform it's on.

[oahda]

fuck your economic standpoint
include me, a mac user, from a nice developer that people actually like, rather than a nasty capitalist, standpoint
then people will like you
and your games will sell
because you're kool

Anyway, I don't see why anyone should not be targeting all three primary PC systems right from the start in 2014, because it's so easy. Not only are there tools like Unity and possibilities like HTML5, but even in something like C++ it is incredibly easy to write portable code right off the bat, using something like SDL or SFML as the boilerplate.

There is very little effort included in writing a portable game today, and unless you're an old company stuck with legacy tools/engine there is absolutely no reason not to write portable code from the very beginning. That way there will be no porting. Porting is an obsolete hassle of olden days when it comes to Windows, Mac and Linux cross-compatibility, and with a good setup (Unity, SDL 2) that may even extend to mobile and/or certain consoles.

[Sik]

There's a catch with OSX, in that to make a program for it you pretty much need to be using OSX itself, and if you can't afford to buy a Mac (and don't want to risk yourself legally by setting up a hackintosh) you'll pretty much have to leave it behind (unless you get somebody else to build it on OSX for you). This is not an issue with the other platforms where crosscompiling is an option at least.

But yes, library-wise you should be able to get away with 100% portable stuff. In Sol (which uses SDL2, PhysicsFS, libpng and libvorbis) the code built on Windows and Linux with practically zero changes (the only issues I ever had was forgetting to add an #include). There's some platform-specific code (mostly filesystem stuff not covered by PhysicsFS), but it's just some #ifdef'd blocks around, and even then I've been trying to push some of the worst offenders into SDL iself just to make things easier in the long term (and those are things where I'm pushing it, honestly).

Unity also should also be mostly safe if you take into account the obvious differences, though just make sure that if you make Linux builds they need to be generated on OSX since Windows can't set the executable flag (if you generate them on Windows you'll need to set the flag explicitly on a *nix system).

[oahda]

That's why a (cheap) Mac becomes your main system to work in. c;

But otherwise you can always ask someone you know with a Mac to test it out. Visit them, or have them come over with a laptop, and get going.

[Sik]

Not a reliable option if you live somewhere like in Argentina where Macs are practically non-existent =P (and if you can manage to get one, it's extremely expensive) But that doesn't prevent just working with another person on-line. The biggest problem is finding somebody who has OSX and is willing to commit to the project (or at least, commit enough to make reasonably periodic builds feasible).

Mind you, if your code is as portable as I described then it probably won't require much changes to work on OSX besides the obvious quirks and maybe some stuff like file paths that isn't handled by all portable libraries.

[qwurp]

fuck your economic standpoint

That may be the most shit idea I've heard this year. The economics of a tiny indie working on a micro-budget are as important to them as the economics behind a AAA game from a Public studio. Maximizing your resources is vital to success and sometimes that involves making "business decisions" on how you develop.

To clarify, I do think you're right that it is FAR easier today with tools available (as I originally stated) and in fact, my game is currently selling on Steam for PC, Mac and Linux so I'm not speaking from some "anti-Mac/Linux" perspective. I'm speaking from experience that the combined %'s of sales from Mac and Linux could be counted on fingers and that allocating your resources wisely should always be taken into consideration.

I'm not saying you make games based on the business factors alone, but telling someone to be smart with their resources and to make a decision based on the technology, skills and resources available to them is not a "nasty capitalist standpoint". It's called rational thinking. Sorry to bust your ideological bubble... economics fucking matter.

[oahda]

did you notice my writing style was different in that part of the post than the one actually posing serious suggestions



I'm just curious as to how indies in charge of themselves and not tied to a company's fixed toolset should not have all they need for cross-platform development from the start available to them. When would it not be an option, you mean?

[qwurp]

I did not notice the difference, guess I should have read slower. In the case of the OP, it appears tools are being developed proprietary so its not a case of clicking a button to also export to Mac and Linux. Cross-platform means primarily time and hardware. QA across 3 platforms can be brutal and gets very time intensive even if you have all the hardware and people to test across the 3 platforms. It all comes down to your goals for your game.

If its being developed as some small title with a 4 month cycle, is it worth adding an extra month or 25% time increase to port over for what will translate to about 5% of your sales? My original point remains the same, its not a blanket statement of "Yes, you need to do Windows, Mac and Linux" or "No, you should just focus on windows." It's all about your goals, talent and resources.

[oahda]

I suppose you're right in that it may add testing time and might require extra hardware depending on one's "home" system.

I'd definitely add that extra month, tho. I care more about – to me obvious – availability than money. But I'm aware not everyone does, and I was never good at running a compay that actually yielded any income. So you're probably right. I just don't like that mindset, I guess.

[joeyspacerocks]

Thanks for the wealth of opinions!

In my case I'm actually developing the main code on a Mac as my first target is/was iOS. So it would be a natural and relatively easy addition (I naively hope) to extend this to support Mac desktop. I can then bootstrap or parallels my way to PC and Linux for testing.

You're right of course that there are lots of tools and libraries that can help target further afield. I've been careful in my development to use standards, outside the few platform integration points, so in theory it shouldn't be too hard to add additional wrappers to integrate with other systems.

After all, I'm only writing a platformer - I'm not exactly using cutting edge tech here, just a few shaders here and there.

From an economics point of view (or resources) it really does come down to the additional testing and fixing time - however that could just mean a rolling release from platform to platform.

Thanks again for the responses - really appreciate the discussion.