Where did you learn UnrealScript?

[Surly]

I've spent practically every waking moment of the last week pouring through the source code for Dungeon Defense, and reading the corresponding blogs. It's come to my attention that Mr. Stieglitz is very comfortable with UnrealScript, so much so that it appears almost effortless to call upon parent-class functions proprietary to UnrealScript off the top of his head. To preface, I have a fairly substantial background in C, and have worked with a few scripting languages in the past, but the particulars of UnrealScript seem to have a rather large learning curve attached to them. Particularly so because the documentation is a little less than ideal, and a lot of it seems to be geared towards making mods with Kismet.

I could get a lot of answers to this question from a lot of people, but this one's specifically for Jeremy: Where'd you learn to do it?

Practice? Classes? (if so, where, and who's the instructor?) Books? Long background in Unreal mods?

If it's just a matter of chugging along as I have been, great, just want to hear it from a guy who clearly knows the language very well.

[javahawk]

Surly,

While I can't completely answer for Jeremy, I can tell you that him and I have been working in unreal tech for the latter part of the last 6 years. 6 years in anything and you could be considered a professional to some degree =). Don't expect to get everything right away, but then again, I dont suspect with your drive that it'll take you 6 years either.

Happy coding and thanks for your support!

Joshua

[Surly]

Then perhaps there's a lot more carrying over into UDK from previous UnrealScript implementations from 6 years back than I suspected. Even from the first day of development, I was very surprised to see how Archetypes were used to store variables for designers to use to manipulate code. Based on the blog entries, it seemed intuitive, almost as though he just couldn't wait to implement it from the onset. The UDK hasn't been available for a terribly long time, and UT3 never had much buzz surrounding it. Yet, here I see a fellow coding with the acumen of some one familiar enough with the code that I'd believe them if they lied to me and said they wrote the native code. Even Epic didn't exploit their own engine in many of these ways. The tools are right there in front of our faces, but it still amazes me how they simply don't occur to me to use them in these ways. Granted, the last time I toyed with UnrealScript was with UE2, so maybe the methods used in Dungeon Defense have been standard practice for a while.

Now correct me if I'm wrong here, but this is an assumption I've made which could be entirely false: Trendy Entertainment was commissioned to build this game, complete with development blog, and well commented source code, for the sake of providing us scrubs with learning material to digest. If that's the case, and I hope that it is since you fellows certainly have the talent to get a good paying gig like that, how many teeth would I have to pull out of your heads to go back over that Blog of yours and expand upon the overlying theory detailed in Blog 8? I read it, I liked it, but it seemed like a glancing overview of the real knowledge behind the guy writing it.

If any of you have the time, and feel so inclined, I think you could give a lot to this surprisingly stagnant (well, perhaps not stagnant, but not exploding as much as I would have suspected a free million-dollar engine scene would be by now) UDK scene by explaining the specifics of what made the writer so enthusiastic about utilizing the software. It would be quite a shame to limit the impact of the shared knowledge available with Dungeon Defense by failing to really get into the details of methodology and theory employed while making it, as the underlying expertise showcased is quite remarkable and clearly exceeds even what we would gain from the hotly anticipated Mastering Unreal Vol. III. Frankly, going through this source code has taught me more about UnrealScript than practically all other sources combined, including the UTGame classes and UDN documentation... there just isn't any other place out there to get this stuff, it's fantastic. It would be even more so with more in-depth discussion of the practices employed.

Hell, maybe you should just write a book; I'd buy it.

[JeremyStieglitz]

Hey Surly,

First off, thanks for the compliments, don't really know what more to say about that

Now to answer some of your Q's..

I've been doing game programming since I was 13, so essentially for the last 13 years (hobbyist and mods but never Unreal -- DFII: Jedi Knight was my thing, COGs if anyone remembers -- and around 2003 I went pro with, heh, Reality Engine).

I've only worked with Unreal more recently, since 2005, but I did pick it up pretty quickly. How's that?

I suppose my learning process has benefited from having a knack for learning other people's systems and reading through code, but in particular I learn best by example, and by getting my own hands dirty. So my process has been to examine Epic's classes & gameplay code, think about what their intentions were (sometimes clearly stated, sometimes not) and what the "best practices" could be, and then just mess around with my own code until I get the results I want. Through enough trial, error, and practice, I figure out (more or less) the "ideal" way to do things, all the while making mental notes to improve my output in the future.

I believe that the best way to learn is to do: apply your knowledge and see where it holds up, and where it doesn't. Reading a tutorial is all well and good to begin with, but you'll never know how well you've retained the information, and if you've learned to apply it, until you put rubber to road. So in a nut shell that's my philosophy about learning, and it's worked well for me at least

In particular my general approach programming is this (hardly earth shattering): take a complex problem and break it down into a discrete series of simple abstract steps. For example, recently I implemented a Chain Lightning Tower. I wanted it to chain from enemy to enemy, zapping them with a cool beam and stunning them while doing so. Therefore I chopped this task up into such discrete steps as:

1. Finding the closest enemy (and the nearest enemy to that enemy, recursively).
2. Repeatedly damaging that list of enemies on a timer.
3. Drawing the chain lightning beam from enemy-to-enemy, by dynamically instancing beam components and also keeping those on a list (actually an array of structs to contain all of the information.
4. Putting the enemies into an "electrocuted state" so they couldn't move while being shocked.
5. Handling threshold cases such range-limiting the amount of chaining which can occur, ignoring enemies who are obstructed from line-of-sight (don't want to target them), handling the case of certain enemies that could conceivably be destroyed while being electrocuted, etc.

By breaking up a complex task into a series of bite-sized chunks and writing those down first in a high-level overview, I made it more digestable and could better plan the overall system design. In general, that's how I approach all problems.

As for making some good use out of UE systems with certain practices (for example, a heavy reliance on Archetype Templates and Interfaces)... I guess that comes from a continual drive on my part to improve efficiency and flexibility of code. And simply wanting to get the most I possibly can out of the awesome Unreal tech... not wanting to leave any stone unturned, in terms of what Epic's systems can support.

I believe that good system design should be, as much as possible, data-driven and re-usable, and the fewer number of non-abstract classes, the better. Keep the code as abstract as possible, and try to get the specific implementations through the data itself. I fall short of this ideal in plenty of cases, but trying to always keep it in mind certainly helps overall!


Finally, regarding the future, while I can't be on UDK tutorializing 24/7 (I gotta spend most of my time making the games after all ), myself and Trendy are planning something that we think's going to be of great interest to the community:

The commercial version of Dungeon Defense, called Dungeon Defenders, will be entirely open-source from an UnrealScript standpoint. And not just the full commercial game, but the demo too! Meaning, you're going to get an entire retail-worthy game, with all of its features and functionality, as a total reference without having to spend a dime.

It will all be documented to the level of this UDK demo, and we'll be putting out corresponding blogs on certain key subjects as well. This won't be overnight -- the full game should be done around June -- but when it's ready, it should be a wonderful, free reference. If you found this little initial demo useful, then you'll find the absolutely massive jump in functionality and polish of the completed commercial game 10x as enlightening.

Should you decide to pick up the full game, while having essentially the same source code as the final demo, you'll also be getting ALL of our source assets (including the original art files!) and levels, which will be a very handy reference in is own right (lately we're slinging some mad Kismet at Trendy ).

So I hope that's something exciting to look forward to, along the lines of what you mentioned. Until then, you can master the source code of this initial demo and work it into your own projects as you see fit... and we'll keep you posted as we roll out some of the amazing new media for the greater, super-fun Dungeon Defenders game

All the best,
Jeremy

[twoflyingpigs]

Full Dungeon Defense with all source/assets, Jeremy, u just got a new customer.

I'm really enjoying jeremy's blogs and joshua's video tutorials recently, you guys should start writing a book together! If you are too busy for a book, then start a blog first, blog.trendyent.com sounds delicious.

[Blade[UG]]

You haven't asked me, but I would like to offer my basic tips. If you are the type that is an experienced programmer, and can pick up the basics of a new language in a short period of time, I really think that WOTgreal (and I presume that nFringe has similar abilities) is a fantastic tool for learning the code. If you start with GameInfo, which is where the calls from the engine into UnrealScript begin, read through that source. When you get to something that you don't follow, hold down control and click on it, and WOTgreal will automatically take you to where that variable or class or function or whatever is defined.

[Surly]

Hey Surly,

First off, thanks for the compliments, don't really know what more to say about that

Now to answer some of your Q's..

All the best,
Jeremy

Wow, now that's a response! Thanks for taking the time, I do appreciate it. I'm a little past the strict "tutorial" stage, and never really cared at all for doing them for reasons similar to your own. They're usually more focused on creating something specific than explaining the "Why we did it this way" or "How this could be used" to facilitate any real learning. It sounds like Trendy Entertainment's near-future plans are something I'll want to follow very closely.

As a veteran of UnrealScript for 4 years now, I look forward to whatever knowledge you can impart to people from other programming disciplines in your future blogs.

You haven't asked me, but I would like to offer my basic tips. If you are the type that is an experienced programmer, and can pick up the basics of a new language in a short period of time, I really think that WOTgreal (and I presume that nFringe has similar abilities) is a fantastic tool for learning the code. If you start with GameInfo, which is where the calls from the engine into UnrealScript begin, read through that source. When you get to something that you don't follow, hold down control and click on it, and WOTgreal will automatically take you to where that variable or class or function or whatever is defined.

Yes, I'm currently using nFringe with my copy of Visual Studio.

I'm pretty confident with syntax and writing/reading the code to do what I want, as well as non-game-specific programming practices, but good practices and theory unique to UnrealScript are always so new and interesting. Take state programming, for instance... fairly simple in concept but it's just something I've never needed to utilize in the past. And unlike what I knew about state programming before UnrealScript, it's built right into the language, so you can just push/pop states at your leisure. So cool!

Anyway, things like using archetypes in the actual scripting, for instance, just blew me away. Something I had the purely technical knowledge to do, but never would have because I'm so used to rigid, boring application development like, pfft, database utilities or word processors. Actually, when I first looked at archetypes I figured they were just organization tools for map designers and shouldn't be referenced from code.

Who knew software engineering could actually be entertaining?

[Sir. Polaris]

Very enlightening post from Jeremy, thanks for posting.

[UT2007]

very interesting.....i am on unrealscript since the age of 14 years old.

I agree that i was programming more windows programs than Games when i was playing DFII: Jedi Knight just like you.....but i do think that programming is all the same in logic....is a matter of syntax changing only. In front of you, i am now asking myself which road to choose.

U can build a sample game in one day, i can build a sample windows program in one day.

But i have somehow a very attracting preference for unreal engine games......i think time to choose definetly now, cant be good in two road at the same time.....u made me realise many things.

One thing SURE ! I love more UnrealScript than Unreal Engine tools !

Thanks very much to the Dungeon Defense programmer !!!!!!!

Best regards,

[iniside]

It's no matter of learning syntax if know other programming language it's matter of understrand it. I.E not everybody got WTF is pointer in C++, any many other syntax tricks.
Actually syntax in Unreal Script is very simply, yes there is few odds that i don't really get why someone would put them in language but oh well, I can live with it.
It's really matter of understrading framework that come along, in that case engine, and understrading how to game actually works (it's very diffrent from windows, and other "normal" applications).

And Worst case here is, when you first look at code you think " WTF is this, how should I start ?". When you figure out how to bring basic functionality to game, everything else come more or less easier.

I tell it from my own experienve. I sped few days just to figure out, how to rid off all UTGame code, and start my own code from scratch. Ok this was not actually from scratch, I just look trough UTGame classes and seek what is need to bring character in game, giv him an weapon, and shoot something.

[Whitenorthstar]

I just saw an ad for Dungeon Defenders in the Steam store, it's lookin' good!