On the wisdom and practicality of teaching UDK to kids

[Integral]

I am a technology teacher at a science museum. I teach enrichment classes: basically, I use stuff that kids are interested in as an excuse to teach them things. Currently I have a sequence of two video game programming classes (15 hours of instruction each). They both use Game Maker and target middle school students. The first mostly uses the drag and drop interface (but teaches inheritance, state machines, and of course logic), while the second is all text based coding (and covers everything you would expect, except pointers, which that language lacks). Their largest function comes in at 200 lines before I show them how to break it up into smaller function calls.

We used to have a third course on video game programming in Unity (which targeted high school students), but have had to do away with that. I am looking at UDK as the replacement, and have the majority of my time (up to 30 hours a week) until spring/summer to bring this to fruition.

However, I have serious doubts about the viability and wisdom of my plan. I started poking around in Kismet, and found everything very easy and satisfactory. However it is hopelessly proprietary and does not lend itself well to actual education. Yes, I could teach kids how to use Kismet, maybe make a Mario clone, but doing that outside of a cursory way is doing them a disservice. It is a major failing of technology teachers to teach the tool instead of the tech behind it.

So this leaves me with UnrealScript. I poked around some UnrealScript tutorials and not everything was crystal clear to me but I managed to read between the lines some. I browsed the src folder and got a rough grip on its organizational structure. I am mostly only left with one major question:

How the hell am *I* supposed to learn this? I am a self taught programmer, but not informal in my approach at all. There are gaps in my knowledge (of course). I understand everything I have read though I do not know how to approach the hundreds of thousands of lines of code I have in front of me. One tutorial on creating your own pawn (seemingly a very good UnrealScript "hello world") required that I go into some file and edit a specific setting on line 3596 (something like 78 pages in, single spaced, 12 point font). Talk about code smell!

I know that my students will not be able to fly on their own after so short an introduction to the tools, but I want to show them what the "big boys" use, and I want to edge them towards being more confident around "real" code. I would like to ask the communities help in my endeavor, since I feel a little lost today (or perhaps that is simply the second week of this flu speaking).

Violence is a no-go. Concepts I want an excuse to teach them are: application of the discrete derivative/integral (like say a mortar that is trying to hit a moving target), the merge sort and A* algorithms, pointers, and the machine code/assembler/linker/compiler relationship. I have thought of/heard requests for a class which teaches how to build a tower defense, racing, or a 2.5d platformer game. Assume a class of 6 to 9 highly motivated 16 year old students with 30 hours prior instruction, and where a 50% rate of conceptual comprehension is acceptable (that is to say, the class moves as fast as 50% of the class can handle). Class time can be either 15 or 30 hours in 3 hour chunks.

How would you do it? Is it even wise? If not, what do I do to fill the demand for more video game development classes?

[James Ordner]

I'm gonna get hit with the no engine comparisons rule here, but this isn't the typical "which engine should I use to make my game, UDK or Unity" topic, so here's my thoughts.

Give Unity another shot. You're not gonna get pretty eye candy from it, but it is easier to use than UDK. Programming in Unity is as simple as writing a few lines of code, dragging it to an object, and watching it work. With UDK, UnrealScript is a powerful language, but it is a pain to set up, and you're faced with restarting the editor and rebuilding the code every time you want to see a change. I have a feeling middle school and high school kids won't take to kindly to that.

If they understand Unity and enjoy it, then you can consider moving them up to a more professional engine like UDK. Start them off easy and build up. Honestly, the more engines they are exposed to the better, as they will get a more overall view of game development in general, not just how one engine works. Just don't make them jump straight into a complex engine like UDK without previous game experience. You could scare them off and not get them back, which is definitely not what you want.

[Bob_Gneu]

All and all if your class is stable enough with C++/Java to be able to pick up anything in Unity you can transport the same concepts over to UDK and its UnrealScript.

The best way to get into UnrealScript is probably mutators on UT3, but if you are bent on UDK you can probably pull together a mutator like system to be used on something you make. The concepts you noted above can be a mix of a maze, ballistics game where bots move around, trying to evade you. Probably turn based to allow for a bit of trial and error, but also showing how their code (AI, Ballistics and other) play together to solve the puzzle of making it interesting.

And as for a place for you to start out - Unreal Development Kit Game Programming with UnrealScript: Beginner's Guide
Rachel has written the de-facto starting point. And if that isnt technical enough, some of the 3DBuzz Mastering UnrealScript chapters are (one of which I wrote) are on the UDN, the entry point is linked in my signature.

One note though, you don't really get to play with pointers or machine code/asm or linking in unrealscript.

[Spoof]

How the hell am *I* supposed to learn this?

Unreal script isn't a bad language for learning, but it does have quirks and dependencies that require you to gain experience. The last thing you want is for students to watch you try and debug a default properties block that simply isn't playing ball with the rest of the language syntax.

That's really the mountain you have to climb - getting enough experience with the API/language/engine to be confident to use it in the classroom. That tutorial may be out of date. A simple "hello world" project shouldn't require any modification of the core API, with the exception of adding your project to the DefaultEngine.ini config file.

If it'll help here's an alternate 'hello world' sandbox.

class SandboxGameInfo extends GameInfo;


static event class<GameInfo> SetGameType( string MapName, string Options, string Portal )
{
    return default.Class;
}


event OnEngineHasLoaded()
{
    `log( "Hello, World!" );
}


DefaultProperties
{
    bDelayedStart = false; // spawn pawn immediately

    PlayerControllerClass = class'Sandbox.SandboxPlayerController'
    DefaultPawnClass = class'Sandbox.SandboxPawn'
}

The controller and pawn classes are just stubs ready for modification.

class SandboxPlayerController extends PlayerController;

class SandboxPawn extends Pawn;

This could be expanded into your own sandbox project environment that only expose your classes to the students, hiding the complexity behind them and focusing on what you want to teach.

Also if you want a 'pure, code-centric' platform in C/C++ you could try the open source engines released by a certain John Carmack and his 'subconscious ego' company.

Btw, there's a recent post on implementing A* here which may help.

[tegleg]

to help you learn the basics of interacting with the engine and unreal script this is a good place to start
http://www.moug-portfolio.info/categ.../unrealscript/

the language itself is fairly easy, if you know a bit of java, unreal script wont be a problem, they are very similar.
making some kind of very simple game i imagine would keep the students interested enough to want to carry on. Spoof has already given you a start.
get them started with something easy then let them see what they can do with it.

the very best of luck
and have fun with it

[Integral]

Thank you all so much for the feedback! So many helpful responses makes me hopeful.

The choice of moving away from Unity was not a choice. Apparently we were violating their license: Unity is not free to educational institutions (they must pay full price). Outfitting our small lab (12 seats + instructor) with it would have cost on the order of $20,000. We are a not for profit that has exceedingly low rates on our classes... Unity is simply not a viable (legal) option.

The kids who get to the third level class have historically been highly motivated (and quite a number of them quite bright). I don't have much to fear about disenfranchising them on due to difficulty. They want to learn this stuff (a few students have gone to Digipen et al!), and if I dumb it down then they will reject it on that premise. Plus, I am an enrichment teacher: it is not my job to make 100% of students fully master the concepts I teach. This is a penultimate class for the interested.

I will go and try to follow some of those resources you gave me. It may take a while, my flu is getting worse. Thanks so much!

PS: Clever reference!

[Crusha K. Rool]

UnrealScript can't easily be singled out to individual examples. You pretty much always have to use the full picture if you want to get anything done that has the potential for an independent game project.
You should have an understanding of:
-the meaning of Actor classes as opposed to other Object-derived classes.
-creatures in the world are represented as Pawn.
-Pawns can be controlled by AIControllers or PlayerControllers.
-PlayerControllers have a reference to HUD subclasses that handle the drawing of stuff on the Canvas.
-PlayerControllers have a reference to PlayerInput subclasses from where they can read what values are currently set for movement input.
-players can assign exec functions in the PlayerController class to keys to execute them (like shooting weapons).
-the importance and use of the GameInfo class.
-the concept of InventoryManager and Inventory items like Weapons (though this is almost something more advanced already and can be switched out for simpler custom systems). After all get Pawn classes notified about firing weapons first, so you don't even need the Inventory system for such stuff in a simple offline game, which can keep the code more readable.
-common engine events like Tick, Touch, Bump, Timer, PostBeginPlay, etc.
-states
-the concept of ActorComponents, i.e. subobjects of an Actor that define how he is rendered by the engine.
-depending on how complex you would be willing to make the class: network replication. But this is something that can be difficult for people to easily wrap their head around in the beginning.
-maybe to some extent how you can create your own SeqOperations for Kismet.
-how to expose variables to the editor properties windows.

That is pretty much all you need to make a simple game with UDK.

[milerk]

you will have to master Unrealscript understanding its hierarchy is very important
everything derives from Object class which has all the functions needed to connect the class with UDK,
the first classes you should be looking at are
Actor - used for everything visible on the level (players, weapons, projectiles)
http://udn.epicgames.com/Three/BasicGameQuickStart.html - short introduction to the most important classes in UDK game
http://udn.epicgames.com/Three/Unrea...tGameFlow.html - gameflow reference here

these classes derive from 'Actor' and you would be using them a lot, they can handle movement, camera, everything you need
so remembering some of the functions found there would be helpful, most of these are commented

http://udn.epicgames.com/Three/UnrealScriptHome.html
here you can find stuff related with UnrealScript, differences between US and Java/Cpp
also US features like States, Iterators( foreach groups )
function and class prefixes such as 'Event' functions which are fired by the engine when some sort of event occurs, stuff like that

so good luck