Getting Started with UDK [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I've been trying for a couple of days now to learn UDK, but I seem to be stuck at making that leap to understanding how everything works together. I understand the syntax, that's all well and good, and I pretty much get how classes and .ini files interact. As for the API, I have the开发者_StackOverflow entire reference as pretty decent Doxygen-style HTML output.

What I'm looking for is a sort of intermediate tutorial on game creation from scratch (as opposed to modding UT3 itself), more advanced than just learning language syntax, but not yet to the level of going through the API step by step. I'm looking for some guide to the structure of the internals - how GameInfo and PlayerController interact, where Pawn comes in, etc. - a way to visualize the big picture.

Does anyone have a particular favorite intermediate-level tutorials (or set of tutorials) that they used when first learning UDK?

---

Check out these these were (maybe still are?) the best when I first started. I have then since stopped using UDK due to lack of time but these are really good.

http://forecourse.com/unreal-tutorials/

---

Strangely, I never found tutorials on that topic.

In the way things come together, there is no big difference between modding UT3 and creating a new game -- it's just easier to play around on top of UT3 code because there's content to work with.

Development/Src contains uncompiled source code. Each of the folders in there gets compiled into a .u script package for use by the editor and the game. They end up in UDKGame\Script

UDKGame has all the packages, including assets, maps, and compiled scripts.

GameInfo (or your class derived from it) is used for things central in your game. A standalone game would derive from this. The derived class does not have to be big, it's probably not a good idea to put a lot of logic here. You can and should use this class to store central properties for your game -- like, what HUD class your game uses, what player controller class, etc. For example, a racing game could track the time of the race here, and notify players when race started or ended, and would also have a property like HUDType=class'Racer.RacerHUD'.

Controllers, such as PlayerController and AIController (which UTBot is derived from), are used to send instructions to Pawns. Pawns don't do anything on their own, they're more like empty shells that the controller can manipulate. Things handled in the controllers are AI and input. Things handled in pawns are all kinds of animations for movement, taking damage, etc, anything visual.

Sorry, I don't have time for a longer answer, but I hope this helps a little bit.

PS -- What helped me A LOT was getting the game Whizzle and reading each class in that code. It does not derive from UT3 code, and it's very very small.