Why it is so difficult to really get started with UDK

[Alan47]

Good evening, everybody.

I consider myself to be a dedicated and motivated hobby game developer who is willing to learn as much as he can in order to achieve his goal: creating the game in his mind. During the past ten years I've been working with various game engines, starting off with a very simple 2D engine in early 2000. When the first affordable (or even free) 3D game engines hit the world wide web, I also managed to learn how to work within a 3-dimensional environment with textures, traces, euler angles and what not. Things were looking good these days, and then I discovered UDK. Excited about what might be possible with an engine as powerful as this, and even to get the chance to use it for free, I downloaded and installed it and went through all the awesome video tutorials provided by 3DBuzz. I could not have been any happier back then, because the editor proved to be amazingly powerful and yet easy to use at the same time. Whatever my goal was - there seemed to be a special sub-editor for that just as if Epic knew that I was comming this way. I was really happy with UDK. Well, until I tried to actually *program* anything. Lacking a real script editor for the very specialized language of unrealscript (it is not like they would have used any more common language!) it was quite a hassle to actually find and install a working development environment for UnrealScript.
Then, finally with everything set up (and with a bad feeling too, call it intuition if you want), I set out to find a beginner's tutorial. I've found some, however, either they were outdated, UnrealTournament-Related, or incomplete in some way. So basically I've been able to figure out most of the syntax of Unrealscript (which at least enabled me to understand parts of epic's UT code) and what classes you need to even GET STARTED with a project. But until today, I haven't seen one single tutorial for unrealscript which I would call "beginner-friendly, easy to understand, and complete". No way. And by "complete" I mean that the tutorial should not only explain "You need a GameInfo class, a Pawn class and a PlayerController class" and leaving the rest up to the reader, but going a little further, maybe creating a simple game prototype.
In the forum, when a beginner asks where to start with unrealscript, the advice to read through classes like "Object" or "Actor" is often given - but to a beginner who has not the slightest idea of what's really going on in code and probably never worked with object orientation before, this is not very helpful (I think we all agree on this point). Even for me, having a good idea about how object orientation works and having a good amount of experience with java, it proved to be a huge challange to really understand every line of code in there. Providing a built-in demo version of UT3 was probably the BIGGEST mistake Epic could have *ever* made with UDK. The reason for this is simple if you see it from a beginner's view. As a typical newbie, you want your reference code to be as easy as possible, right? After all, you want to learn the basics when reading it and maybe copy a function here and there.
But - and again, I think you will all agree here - UT3 code is *highly* specialized code geared towards best functionality (sacrificing simplicity at times), written by professional developers. There's network-stuff like server-client-connections, there are a heck of a lot of classes, there's a good deal of native code we can't look at, there are UT-specific things like replication info classes and so on and so forth. This NEVER ENDS. And the worst part of it all: some UT classes and mechanics are tightly connected with some classes quite high in the class hierarchy, which turns "getting rid of all UT-realated code" into a real nightmare. So basically if you extend... let's say... UDKGameInfo, then you will already have inherited UT-related code, allthough the name "UDKGameInfo" itself does not imply that at all. Epic always likes to claim that UDK can be used for each and every type of game - then why do they lay stones in our way? In other engines I worked with in the past, if you did not set up anything in your code and ran the executable, it would give you a black screen (after all, you did nothing) - in UDK, it gives you a full picture-perfect first person shooter, including all special twists and turns. What the hell.
So far, getting into programming with Unrealscript (because of the reasons mentioned above) became literally impossible for me, despite all my patience and training in java, despite the fact that I can work in other engines without any troubles with the scripting languages themselves (at least not as grave as with UnrealScript). Therefore the question that I have to ask myself (and Epic!) is: If I have such troubles getting started with UDK, how does someone feel who has never touched the field of game engineering ever before...? In case that I am not part of the target audience of UDK - then who is? On the main page, Epic answers the question "Who it's for" with "Anyone. Everyone. You." - to me right now, this couldn't sound any more sarcastic. It is entirely possible that really advanced game developers and indies will enjoy UDK and have a good time working with it and the product as such is as awesome as can be, however, if Epic wants the UDK to be for "everyone" then they still have a lot of work to do.

So far, that's everything I have to say regarding this topic right now. Sorry for sounding a little depressed, but it is true that I don't see any solution for the above mentioned problems for me - and the truth sometimes hurts. I hope that my arguments are enough to start a good discussion and maybe - maybe! - Epic will listen.



Greets,



Alan

[Wizzard~Of~Ozz]

I think some of us are getting along just fine.

If extending UDKGame makes you feel as if you are hauling UT Code into the fray, then perhaps extend from GameInfo. The absolute beauty of the way the classes are laid out is that you can hack in at any given point and use that as your base. I believe you can even hook in lower than Gameinfo, but I haven't tried.

The support for this engine seems far superior to any other engine and I really found no problem getting started. Sure there is a learning curve where you start figuring out ini files, the relationship and build structure but is that any different than any other engine?

There are no real rules with how much of the code you need to use ( if any ), it's mainly there as a reference and a tool.

[carlb]

I found it quite easy to use. Much easier than many other game and graphics engines that I've used in the past. Then again, I do almost everything directly in Unrealscript.

Disclaimer: I didn't read what you typed as it's basically a big wall of text.

[Alan47]

If extending UDKGame makes you feel as if you are hauling UT Code into the fray, then perhaps extend from GameInfo. The absolute beauty of the way the classes are laid out is that you can hack in at any given point and use that as your base. I believe you can even hook in lower than Gameinfo, but I haven't tried.

Of course you could start digging deeper and deeper, even down to object, but that results in a lot of re-coding things that basically already exist. Besides, it's not like you could code in every way you want, because you are then always risking incompatibilities with existing structures or even the UnrealEditor itself. Here, I miss some kind of a guidline which class has to provide what functionality/information in order to work well with existing classes and the editor.

The support for this engine seems far superior to any other engine and I really found no problem getting started.

If you mean improvements in the engine itself, then yes, support is good. But as far as tutorials are concerned, I feel kind of left standing in the rain. It's like Epic giving a brand-new Alpha Romeo to us "Here take it, it's for free!" but keeping the key.

Sure there is a learning curve where you start figuring out ini files, the relationship and build structure but is that any different than any other engine?

Definitly, yes, it is different. Comparing to another engine I know: "You use command 'ent_create(String name, Action action)' to place an entity (mesh or sprite) in the level, command 'ent_move(Vector abs, Vector rel)' to move it around, and you can check the value of the engine variables 'key_a' to 'key_z' to listen for keyboard input" Most of this (most basic to 3D game programming) stuff is part of the first 5 tutorials in the other engine (25 are provided by the engine authors) - and those already are three things I would have no idea how to do in UDK. Or another thing: in the other engine, you place enemies (for example) as meshes in your level and assign them their script action (that's the standard procedure, there are other ways, too). Can you imagine how long it took me to figure out that in UDK it is just vice-versa, with the action script actually generating the needed mesh all by itself? Other example: the other engine has a "main" file with a "main" function which is called once the game starts. Important to know: this is the *only* function called by the engine and the only one the developer *has* to provide in order to get things up and running. That's the "entrance point" for your own code. Any other "function call networks" have to be set up by the developer, therefore it is always easy to tell how the engine will behave and what will happen. You don't have any "hidden calls" from the engine or classes you derive from, potentially causing unwanted behaviour. I miss that clear structure in UnrealScript - a lot. That's not a very big difference but only one of many, which, in sum, can be daunting if no one explains it properly. Again, I really can't stress this enough, UDK needs more tutorials.

Greets,


Alan

[Wizzard~Of~Ozz]

You are comparing it to "another engine" and "another engines way". That is where you are hung up. I came into this from CallOfDuty Scripting. It's entirely different, only a few similarities. Forget about how it's done in the "other engine" and you'll find things easier.

Yes, the support for this engine is great, regular updates, plenty of Documentation ( hint, look up at the Documentation button ), plenty of support from the general public, tutorial videos if it's your cup of tea to sit and watch.

Yes, go right down to Object, apparently in the "other engine" that is what you start with ( maybe even less ).

Programming is not a weakness of this engine, nor is it a limitation. It's quite functional and well laid out. Sorry you don't agree, but that is my opinion and considering how many people have made a "start", I think you are wrong to think it's that hard. Sure, it isn't like playing ball in the playground, but it sure isn't rocket science.

[Snufkin]

Sorry but i didn't read all that. However if you read all the uscript info on the UDN site and follow some uscript books, UDK will become much clearer and all you will really need to do is learn the visual side of things like models and animation etc.

[Crusha K. Rool]

UDK is for everyone - means it has something for everyone in it, not the whole pack is suited for a single person.
There are parts for the level designer, parts for the sound creators, parts for the environment artists, modelers and for the coders. It's pretty hard to nearly impossible to create a whole complex game if you want to do everything on your own. That's why you search a team for the things that you can't do. Maybe UnrealScript is nothing for you, but level design (doesn't mean that you are a bad programmer, but maybe you just have problems with understanding how this language works) - then you search someone for your team, a skilled coder that knows his job, and you do some other stuff yourself.

Nobody can teach you coding, they can only give you hints "this is the syntax, these things are imported, here are some veeeery simple examples", but every coder needs to find his own way through the code, that's how it has always been in any programming language, at least as far as I know. Here are many coders who can help you - if you can ask a concrete question and maybe provide your own approach.
And there are tutorials about how to create a simple gametype and such stuff. Don't know how much you expect to consider them not "incomplete", maybe you also just found the wrong tutorials.


And yes, UnrealScript is NOT supposed to be something you should learn as your first OOP language. Experience in Java or similar is pretty much inofficially required, you can try to teach someone the very basics of the concept, but imho should someone who has never programmed before not start to do a programmers job in UDK and instead do something else and leave the programming to people who have the better premises for that job.


IDEs can be easily found from the first page that you get linked to from the UDN about UnrealScript: http://udn.epicgames.com/Three/Devel...ptProject.html


And programmers are very clever people (as you probably know ), so maybe they are expected to be the ones that can most likely find their own way and don't need any fancy GUIs within the UDK in order to create awesome content.



And what other engine are you referring to there? Acknex A7/A8 Engine with the super-simple Light C as programming language, which is not object orientated?

[illspirit]

Seems easy enough to use to me, and I'm mostly just a map/art guy. My last real experience in scripting a game was for GTA2 like 10 years ago, and my only foray into working with any UE was an Onslaught map for UT2k4 which was never finished or released..

As for the seemingly dedicated shooter-ish script like replication and such in UDK base; if you don't need it, just leave it alone. Even if you did manage to strip out every unnecessary bit of script, the native code in the .exe which relates to it would still be idling in the background, so you really wouldn't be reducing overhead that much. Or if your game idea is so radically different from a shooter that you need a truly blank slate, it might be easier to use a rendering engine like Ogre and write the gameplay stuff from scratch.

[agentfx]

I'll agree UKD programming is really challenging to learn even setup to start learning! I'm starting out on the journey, tho, luckily for me I'm not trying to make a game, just get an idea of how the system works.
But yeah the Docs are kinda all over on it, its hard. I'm not sure how far I'll take it but getting some foundation would be great.
The video tutorials here
http://forecourse.com/unreal-tutorials/
are really good altho I haven't watched them all yet, just getting trough them now.

[Blade[UG]]

Funny, the tutorial on UDN tells you to create a Game, a PlayerController, and a Pawn, and then guides you how to do exactly that.

The reference guide tells ALL of the syntax (except for a couple of bits that are slightly out of date). ALL of the source is here for you to read.

Oh, yes, and all of the UT specific code is in the UT classes now. Of course, there are some things that you may not find desireable in the lower tier classes, as well, but that's going to always be the case, no matter what you are working with, unless the base classes have absolutely no functionality whatsoever.

What you're asking for, though, is to start with a system that does nothing. How useful is that? The vast majority of people who see UDK, think "OH I'M GOING TO MAKE A FPS OR TPS" and frankly, the easiest way to do that is to start with a completely functioning game, ala UTGame, and override the parts you need to change.

Reading Actor and Object isn't to tell you how to program, it's to tell you what is available to you, in every place. Every function in Object is always available to you anywhere in Unrealscript. Every function in Actor is available to you in all Actors within the world. If you haven't at least looked at them, you have no idea what is already available, and what you need to write on your own.

All of the classes together, their comments names, and parameters, all equal API documentation - I'd say far better than any seperate piece of documentation would be (at least for the functions that are obvious and/or commented properly -- there are at least a few in the tree still that no one has any idea what or how they do what they do).

The structure of it is all really simple -- game control begins in GameInfo::InitGame. When a player connects (instantly in single player), PreLogin, Login, and PostLogin are called. All remaining UnrealScript is executed by the engine calling any "event" functions as they are needed.

[kiwibonga]

I gave up on UDK about 24 hours ago and was thinking of writing something similar, a kind of "post-mortem" on why I decided to assemble an engine out of open source components after all, instead of using UDK's impressive set of tools.

I have a background in programming, so UScript was a breeze to learn and implement... The language is very clever in many aspects, and very convenient.

To me, what rang true with what the OP said is the idea that UDK is an application that allows you to create a standalone mod of UT3... It's not exactly the truth, but I think that the way it's advertised, as something that can let you create "any kind of game," did not hold true with what I was trying to do... My experience was mostly frustration at the different things that turned out to be impossible... I had this checklist of key elements I wanted to implement in my project, and not a single one could be incorporated without major sacrifices and ugly hacks... So ultimately, UDK fell short.

I think I would have been more successful with full access to the UE3 source, but alas, I don't have the budget, and I doubt my track record of not ever having released anything of significance, ever, would help.

With that said, hopefully the conflict of interest that creates that gap in versatility (adding more features to UDK reduces the value of a commercial license) won't get in the way of UDK maturing into the new golden standard for game engines... It's really not that far off...

[Hyper_Shado]

I had this checklist of key elements I wanted to implement in my project

Such as?

[Blade[UG]]

Alan, if you're talking about Unity, Unity is just as much a nightmare for an Unrealscripter to understand as Unreal is for a Unity scripter to understand. Perhaps more so, considering that UnrealScript works a lot like other systems that already exist elsewhere, in fact it's virtually identical to the operation of some text based MUDs going back to the 80's. Some people find one system or the other to be easier to use - experienced programmers tend to find UnrealScript far easier to operate, from what I've seen, while the Unity system leaves most people utterly mindboggled.

I don't see how it's even possible, that the game engine only makes one call into a single script - how does the script in the engine you are referring to interface to things that happen within the game?

In a few other 3D engines that I've worked in briefly, objects that are part of the world have absolutely no relation directly to their script - you can connect pieces of script to an object, but it doesn't necessarily relate the object to the script. In Unreal, everything in the entire world, as well as many dozens of other things that are NOT part of the world, are all built in code.

In any case, Alan, those of us that already know how to do this, we have a hard time instructing those who don't. So, since you're going through the beginning of it, what do you need to know? You can help us help everyone.

[Blade[UG]]

I had this checklist of key elements I wanted to implement in my project

Such as?

right on, i have serious doubts that there is anything "impossible", although unreal isn't suited for every possible use, i think on a commercial level we've seen just about every genre of game that anyone has made come out with Unreal these days.

I'd like to see a long list of what is "impossible".

[grgcucu]

I didn't read too much because my eyes were smoky when I saw your protest thread. UDK is the easiest and most powerful engine I worked on(the easiest is FPS creator but it's too ** up ). If in ten years you have so much experience, then you should now what a game engine really is. If you managed to work with so much stuff, then I think that stuff was drag and drop, chose your player, chose the level of difficulty, chose your genre maybe with many flashy and cool buttons.

In my opinion you don't have more than 18 years and you're a script kiddie that google searches('how to do this' 'how to to that') for every little piece of what you do. UScript is high level to very high level(on the game industry), and if that isn't easy, then sorry, but you don't have anything to do with programming, take a real job, like kiosk keeper, or pizza boy .

PS: I didn't read the other people posts and copied them, I just said what I had in mind. Pheu.