The Infinity Blade Forums Have Moved

We've launched brand new Infinity Blade forums with improved features and revamped layout. We've also included a complete archive of the previous posts. Come check out the new Infinity Blade forums.
See more
See less

Learning and looking through source classes

  • Filter
  • Time
  • Show
Clear All
new posts

  • Learning and looking through source classes

    New to UDK here. Relatively new to programming, but still have vague ideas on some of the concepts.

    To get straight to the point, I started with GML. Many functions and their parameters were inside the editor and documented very well. I spent a lot of time looking through UDK documentation and reference, and have yet to really find a comprehensive list of UDK's built-in functions. So I used UnCodeX to take a look at the source code/classes and am just overwhelmed by it. I really just don't know where to start, or how much the engine has already taken care of.

    If I'm confused about this somehow, please feel free to elaborate. What I'm getting (The perception of someone relatively new to programming) is that for lots of basic functions (camera, damage, things that are already define in a game like UT) are defined in parent classes in the source code which I can call, modify, or derive from in my subclasses. Being unfamiliar with the engine, I don't really have a list of basic high-level interaction I'll want for gameplay elements. There are lots of tutorials out there that tell me how to do specific things, but being able to look at all the game-logic types of options I have is infinitely valuable for stringing together ideas or figuring out the most efficient way to go about things.

    So basically I'm asking if I'm going about this right, and if theres any advice on where in the source code to start. Or even documentation somewhere to give me an idea. Sorry if I'm missing something but I've been searching a lot, and I'd greatly appreciate any help.

  • #2
    I'm also relatively new and the things that I've found most helpful are the official documentation and the Gems. Apart from that as you say there are lots of tutorials to do specific things - I'd recommend starting with a basic project and seeing it through to completion - ask lots of questions in the forums and you'll pick up lots of tips.


    • #3
      Object would contain most of the core functions you'd expect to see and use, from there actor and knowing the difference between them and object. Core functions in subclasses of actor are covered in the parent classes like pawn, weapon, etc and are usually labelled as events.

      There's no real list because it would be a huge list that wouldn't really show the inheritance and flow of events as well as the source can


      • #4
        A couple of useful documentation hubs to get started are and Like most of the UDN they go pretty deep and are worth exploring. The search facility is also very good, able to find relevant pages from single keywords ("keybind", "collision", etc.)

        UnrealScript is an object oriented language. If your programming experience doesn't include that then it's worth finding some tutorials on the net about OOP in general. A lot of early mistakes can be avoided simply by understanding the proper relationship between class and object, instance and reference, etc.

        Give or take a few exceptions there are a handful of key classes that underpin the entire system: Object, Actor, Controller/PlayerController, Pawn, GameInfo, Camera, HUD, PlayerInput, WorldInfo, and PrimitiveComponent. That's not the whole picture, but it's a good start.

        Some thing's that are worth knowing...

        • All classes derive from Object, thus everything defined in Object is available. You'll find a lot of math support and utility functions here.
        • Many classes derive from Actor. Actors are the foundation for a gameworld object, and are equivalent to Entities or GameObjects found in other engines/devkits. Actors by themselves don't have any physical/visual form in the world, instead they host Components...
        • PrimitiveComponent is the base class for any component that has a physical presence in the world such as collision primitives, static meshes, skeletal meshes, physics, etc.


        • #5
          If you have the ability, I highly recommend you check this book out:
 (no affiliate link, obviously)

          It will get you in the right mindset for UnrealScript. It explains which things to extend for what, plus you actually get to make something. I wish it was around when I started with the UDK.


          • #6
            i think what you need is Uncodex:

            you can interface it with the source code for UDK and search for core functions you need.


            • #7
              Thank you all for your suggestions. I'm hoping to really buckle down with UDK, so I can justify it over Unity(The price tag makes it awfully easy).

              I purchased the book spire recommended and am going through it pretty easy. I still have questions though, mainly whether to start my own classes for specific functions or not. I have heard Uscript itself can be slow, so I want to know exactly how extensively I should mess with it without extending off the UT classes.

              For example if I wanted an inventory for an RPG, would it be better to code it myself so I can have a functionable array along with an extensive menu of organizable items? How about randomly/procedurally-generated levels? iOS touch gestures?(Plan to look through iOS forum soon) Animated textures/alphas or animtrees that can be timed and modified based on frames/collisions? These are possibilities that currently are anomalies to me in UDK.


              • #8
                Unreal script performance is all relative and you should ignore it while learning, it will only cloud your judgement at this stage. Code for flexibility and clarity, extend classes, override functions, don't inline or unwind code for speed gimmicks until you know the engine better.

                The other thing I would add is to take a lot of comments about performance with a pinch of salt, because much of it is Chinese whispers. The truth comes from experience, intuition, experimentation, and lots of testing and profiling. The general case is not to have dozens of actors running complex code in Tick.


                • #9
                  Another thing worth mentioning might be that the MVPs asked Epic to provide better documentation in the class headers for most classes so people new to the engine could at least get an idea what kind of functionality UTBot adds compared to UDKBot and so on. And they responded that they'd let their engineers have a look at it in the future, so hopefully we might see a more eased learning curve at some point.

                  Anyway, GametypeTechnicalGuide is a good start if you want to get into how classes work with and depend on each other.


                  • #10
                    The "UnrealScript is 20X slower than C" hogwash is something that Mark or Tim wrote into the original UnrealScript Reference, back in like 1998, and probably wasn't even something that he should've written back then, let alone something that some people want to push around as a point now. Back in those days, the UnrealScript source included with the engine was absolutely tiny compared to all that we have now, and we do stuff instantly in UnrealScript that you would've been insane to even do natively back then.


                    • #11
                      That is good to know, I appreciate all the insight from people on the matter. It definitely eases my mind more. I'll continue looking into uscript myself and come back and start a new thread when I have a case worth asking about.