What Not to Do

We can talk all day about good ideas, the best examples from games we've seen... but that's only a tiny part of the picture. Since this was the most voted-for subject that people chose from my little poll of what to talk about, and haven't seen it yet... I think it would be nice(?) to hear people's horror stories, things you know for sure never to do because a friend of yours did it in one of their games... yeah, a friend.

What's something you know for absolutely sure doesn't work? What's something you've seen fail over and over? What should we all know not to do?

 

You ever look through the scripting forum? Have you ever seen code that will make you lose faith in humanity with only five lines?

 

Spend all of ones time on a fourm, instead of getting down to developing

 

These are generally the two things I recommend the most to mobile devs, and unfortunately I have seen the opposite of these suggestions happen far too many times:

- DON'T kit out your dev team with only the latest iOS/Android/Whatever hardware. Kit them out with the lowest currently-supported hardware aswell, and get them to test it on both ends of the spectrum.
- DON'T work on a project for months and months and test on your target platforms a week before shipping deadline. Deploy to your target platforms frequently.

You would assume that this sort of stuff would be common sense, right?

 

Don't post a question in the forum formerly known as "Support" without first checking the known issues. I have no idea how many times I refer someone to the known issues thread. Actually had someone ask me to give them the link to it. Seems to me, if one has problems finding the known issues thread, they have a huge uphill climb to making a game.

 

Would you not agree that people rocking the lowest supported hardware, are least likely to spend money on an app or an in-app purchase? In my humble opinion it is better to build for the mid to high end. Then you can use all of the benefits and resources that better hardware offers to create a better experience for your users. So basically follow the money!

 

Agreed. "It works on my machine" is pretty much the extent of my testing & benchmarking phases.

 

I don't know. I'd like to build my games for the largest possible audience. Maybe those people running the lowest supported software might not spend money on IAPs or on the game. But maybe they will. And maybe your game is free, but you offer a "pro" version in an IAP. They may try it out and play the free version, and may like it enough to recommend it to more people who might be more willing to spend, etc.

 

I don't know what not to do, but this site has tons of good tips
https://www.thc.org/root/phun/unmaintain.html
Personal favorite is Dummy Interfaces

 

So to hell with the people who can actually sit comfortably on a phone during their two year contract? At that point, why not exclusively target the market of PC gamers who update their graphics cards every three to six months?

 

This is freaking hilarious

 

What makes you think phones on a two year contract is "lowest supported hardware"? The only way that would be the case is if the user bought the crappiest phone available. Like someone building a gaming rig with Intel HD, it is their fault that they are buying nearly useless hardware.

Which I believe was the entire point. Those who buy the crappiest hardware are least likely to be buying the games as they are probably using their phone as a phone and not as a gaming platform. I'm one of those people. I have a phone I use as a phone and nothing more.

 

If we are talking about a lower tier android phone on the market today (assuming you aren't looking at something that is just barely a smartphone and intended for africa), chances are you're looking at something comparable to a mid tier phone from two or three years ago. My main point was it's probably not a great idea to only target people who upgraded their phones in the last three months.

 

Test your S*** on other people than yourself! And do it long before release and with as many as possible!

 

Pick your platform early and know its hardware capabilities... don't expect a project that needs a certain amount of performance to work out if the hardware just can't do it at a decent framerate. Prototype and do some performance tests early.

Don't worry about pleasing everyone, it will paralyze you. Please yourself at least a bit.

 

Don’t start programming without figuring your goals first. You would think that this should be elementary but I been seen it too many times.

 

IT287 at NJIT is a game production class focused on knowing your goals from your gameplay to your target audience. There's hope for future developers