Talkin' about developing for the UDK (iOS)

adam

Hello! I don't want this thread to get too technical, so if you guys are down for it I'll keep it out of Tech Talk for now and in GD.

I have some rather high-level thoughts & questions about developing for the UDK (iOS) and am hoping a few of you might have the answers.

First off - When, if ever, is programming needed? My understanding is much core function implementation can be handled with some reading from their developer wiki and using their more-user-friendly-than-coding interface. Is this true? Could an artist or designer set up core functions? (Movement, locked camera/perspective?)

What about AI? Has anyone worked with AI within the UDK iOS? If so, I'd love to hear about it.

What I am essentially looking to learn about is this: Could an artist, designer, or a pairing of the 2 make a game for the iOS market without the need of a programmer? And if so, when and where would that programmers help be needed?

Thank you!

Dan!

I think it's feasible however there may be a few things that would need to be coded instead of kismet. you've seen these right
[ame]http://www.youtube.com/watch?v=R5IxyZ_hj54[/ame]

that's almost everything you need

adam

1 iOS UDK developer on Polycount?

Xoliul

I don't have much iOS experience, but I do know a bit about UDK, so:

it depends. It depends on how far you want to go with your game, what exactly you want to achieve. You can actually view all the Jazz Jackrabbit nodes used for the complete version with AI, so it shows that a whole lot is possible. I'd say the chance is pretty big that you will need some Unrealscript coding however...
It also depends on how technical you are, how well you get along with Kismet, though some things just can not be done no matter how well you know Kismet.

Jesse Moody

Adam: I would say it all depends on the scope of your game. Last year while working we used UDK (not for iOS mind you) with zero programmer support. Myself and 4 other artists (with little UDK experience) were able to create custom anim sets, animations, movement controllers, camera controller system, have a character go from robot to vehicle form and auto target enemies in the scene. Game play was setup a lot like Lego Star Wars type games and camera was much like the Bounty Arms one.

Having played with the iOS stuff recently and without knowing what you are looking for in terms of programming support it is hard to make a clear yes or no. If you want something that is already done in UDK you are good to go. If you want to break away and start doing crazy stuff then you might require some support. There is a lot of info on the forums and take a look at the UDK Gems area. Lot of goodies in there to really help ya out in the start.

Ged

I looked into udk for work but it really doesnt look easy, lots of workarounds, unity seems easier to use to me, plus you can publish to android etc

ambershee

For the record, that 'No programming required' Jazz kismet game is a lie. They had to program bespoke kismet nodes in order to make the example work.

Jesse Moody

Having worked with both Unity and UDK I can honestly say. FUCK UNITY

That is all.

Showster

Hi Adam

If you want anything other than the crudest behaviour you will need a programmer for AI. In my experience the default out of the box options in UDK mobile are pretty poor. The scripting side of things for AI on UDK Mobile is pretty tricky for example most folks have found a performance limit of 12 characters on screen with 7k tris diffuse only and simple collision.

You can as the Jazz game shows make shoot em ups fairly easily but as Ambershee said there is custom stuff in there.

Any advanced game mechanics side and connection with the Game Centre / do multiplayer aren't documented too well so plan lots of time for R&D

It all depends on the genre of game you want to make etc.

All the best

Greg

oXYnary

Can I ask a question as well I have been wondering about i0S and Android. Someone thought it would be possible on Android, but unsure on iOS.

Having a running program that is a invisible "layer" ontop of any other currently running program. Where this other program will become visible on parts of the screen at certain time points and gesture interaction will work in that portion of the screen without effecting the underlying program.

Parnell

Jesse Moody wrote: »

Having worked with both Unity and UDK I can honestly say. FUCK UNITY

That is all.

Care to explain what you hate about Unity? I'm using it now, and haven't tried UDK but Unity is ridiculously easy, has a helpful community, an Asset Store where you can buy starter kits, and plugins as well as free stuff.
I'm just curious because if there's some big issue I'd like to know now before I get too deep into Unity.
Thanks!
B

Jesse Moody

Not to sidetrack Adams thread but I guess I am spoiled with the workflow / features of UDK. Unity does seem pretty easy to pick up and quite adaptable to many things and out of the box looks quite nice if you know what to turn on and what to use.

I am running into issues because we can't have multiple people working on the same level/scene at one time. Due to how our game is handled and the programming support (although it will hopefully change in the near future). So currently I have to build all my stuff and then hand my scene off to a programmer who then will integrate it into the game.

So far it has not been smooth. I hand off a nice looking scene and then when I see it in game the lightmaps are broke, materials have been changed and all kinds of other issues. Now granted this is most likely not a "Unity" issue but the muddlings of a programmer trying to "optimize" what he thinks is not up to par.

I do like some of the features though and there is a wide user base so finding some answers is quite easy but like I said. I'm just spoiled from UDK / Unreal.

achmedthesnake

Hmm...looking to step into this kind of development - interesting to see where this thread goes..
+ slight off-topic'ish question - regarding iOS, do we still need an mac to be able to publish it (with the whole apple sdk stuff?

Ged

achmedthesnake wrote: »

regarding iOS, do we still need an mac to be able to publish it (with the whole apple sdk stuff?

as far as I know yes you still need a mac and always will, I guess apple will not let people who have not invested in apple products use their store and services.

Jesse I feel your pain, we have resorted to using prefabs with the entire scene contents inside with all materials and textures and give that to the programmer, this seems to maintain all links to correct mats and textures. Still unity seems very game programmer friendly and we can try out little scripts nice and quick.

Maph

I thought UDK compiled straight to a binary. No need to go through the XCode path then, unlike Unity where do you need a mac for publishing on said devices.

Isn't multi user editing/ASCII file format of levels on the roadplan for Unity 3.5?

Ged

Maph wrote: »

I thought UDK compiled straight to a binary. No need to go through the XCode path then, unlike Unity where do you need a mac for publishing on said devices.

Isn't multi user editing/ASCII file format of levels on the roadplan for Unity 3.5?

apparently you can compile the game on ios devices but you cannot publish to the store
this is from the udn page.

"A: Mac hardware is not required to develop iOS applications with UDK. Submitting iOS applications to the App Store requires Mac hardware. "

Yeah unity is currently working on some collaboration solution dont know if it will happen in 3.5 but I hope so!

hobodactyl

Don't have enough time for a big post right now, but I'm working with UDK iOS, and it has a LOT of limitations that aren't apparent up front. Documentation for UDK is bad, and for mobile it's even worse. Usually, even if you have the real commercial license, the documentation is non-existent and any help you ask for is answered with "you should be able to figure this out."

My quick review of it is: don't expect to make something that feels like a professionally-made game without at least doing heavy scripting. There's a lot of advantages, but personally I find Unity to be a lot more usable, although I haven't used the Unity iOS stuff (I'm also fairly comfortable with scripting).

WillMac

I think you might need 3 people: art person, game designer (for the game mechanics and simple scripting) and coder (for all harder coding e.g. deployment, scoreboards and system stuff). Triangle formation!

Not used UDK iOS, this an interesting topic.