Hi GameDevs and Trainees

In the past I built a small (but fun to play) 3D platformer with a "game maker" tool and used to play that with a partner in crime and some friends at my college. After reading a lot about Unity3D and due to the fact that I'll be learning more C# soon we joked that I could try to rebuild the old game with network capability (up to 8 players via internet). It's basically a small 3D map with blocks to jump on, spikes to fall into and the ability to push someone into a trap (sounds dull written down but as we included some inside jokes, it was fun to play during our breaks).

I did some more reading (especially about people planning to build the next big mmo...) and decided that with spending 95% of my free time learning more about C# and unity, it just might be possible to pull the stunt of and really create the game again (just for the few of us), even if it takes a year to create 8 moving blocks on an empty map. No one of us is a real designer, we are all programmers and business economist and don't mind moving around as 3 colored blocks in a blocky kind of world. I even happen to have the spare bucks and buy the iOS license (when it comes to that) to make it playable via web and iphone. (the controls are simple and should be portable)

The real question (finally):
When putting the game together with Unity3D and C#, are there certain things, I should look out so that I can produce a web and iPhone Client without unnecessary problems.
- What about special iPhone input and output problems I won't know about when working on the web client?
- What do you have to rewrite to create an iPhone client after finishing a web player client?
- Anything special to look out during parallel development of both clients?





Im not looking for a roadmap, just some helpful advice to steer clear from the biggest cliffs.
Thanks in advance.

Okay - i have some limited experience, so don't base any financial decision on this post!

Generally, with IOS unity, key differences are:

-Poly count: probably 38k for the scene, tops.
-Beware of overdraw (especially on ipad, particles) - in general I find I can get a lot of particles in, but a full screen of them will not run well on ipad.
-Touch controls are relatively simple to implement- obviously there is no hovering in touch, and you have to experiment with different event types to best manage multi-touches (you have effectively an array of mice)
-Resolution -> If targeting iphone/ipad, you frequently have to do 2 sets of guis, as the resoutions are pretty much 960x480 and 1024x768. Iphone 3gs and older are half of 960x480 so if you're happy to let it scale, it's not a big issue.
-Webclient can be written on PC, IOS dev must happen on a mac, and you need to be a registered apple developer (only $70 or so, no biggie)
-iPhone textures work better when smaller and have a different format (for efficient textures anyway), so you'll most probably want to convert them in unity to PVRTC 4bit (or 2 if your textures are simple and undetailed). This will materially speed things up on the iphone.
-If performance still an issue, combine textures onto a single texture atlas where possible.

I think there are some esoteric restrictions on programming c# on the iphone ("generics support is supposedly poor" but I've never had any issues)

If you look at network stuff, check out Prime31 (google them) - they have a bunch of plugins that do gamekit, networking etc that are extremely good and pretty reasonable. Also, note that in IOS Basic, you *can* use plugins, despite it not being "pro".

By the sound of things, besides the network side of stuff, everything will pretty much just "work" on IOS, aside from GUI resizing and iphone touch handling.

Rgs,
mike
twitter: @runonthespot

The real question (finally):
When putting the game together with Unity3D and C#, are there certain things, I should look out so that I can produce a web and iPhone Client without unnecessary problems.
- What about special iPhone input and output problems I won't know about when working on the web client?
- What do you have to rewrite to create an iPhone client after finishing a web player client?
- Anything special to look out during parallel development of both clients?

Many of them were covered by runonthespot above, but I'll chime in with my notes:

Mantra: The iPhone is not a PC.
The iPhone is not a PC.
The iPhone is not a PC.
The iPhone is not a PC.
The iPhone is not a PC.

Got it? Recite it frequently during development.


The iPhone has a low power processor, running at 620MHz, with a 16k/16k cache and 128MB of available RAM. Contrast this with your multi-core multi-GHz PC that have multiple megabytes of on-die cache and gigabytes of available RAM. The displays are totally different, the input interfaces are totally different, the storage and networking performance are totally different. Always remember that the computer systems are fundamentally different at almost all levels, going through the lowest levels of hardware all the way up through the target demographics and their expected user experience.

Generally it is easier to develop for the least powerful platform first or as the primary platform. It is much harder to develop the game for the more powerful processor then go back late project to rebuild core functionality, cutting features that you really liked because the platform can't handle it. In your example that would be the iPhone for your primary platform.

Your UI is very different on each platform. You are expected to behave one way on a multitouch device but expected to behave very differently on a pc client. The first generally expects slides and zooms, the second a more traditional windowed interface. One expects gestures and touch/release, the other expects hover and click. One expects multiple simultaneous pointing inputs, the other a single point. If you provide the same UI on both platforms you are likely to disappoint at least one audience.

It is difficult to provide the same set of assets on both and have them look good. Possible, certainly, but very difficult for any significant project to do well. With the small inexperienced team you described it will be much easier to have two different data streams. Your inexperienced team may also find it easier to do the development first on the iphone and then port rather than doing a shared development; if your team were experienced with both platforms already then this suggestion would be different.


The list can continue for quite some time, but it boils down to the mantra: The iphone is not a PC.