D vs Java as a first programming language

[Chad J]

Hmmmm, now this may be of zero interest to the OP, but I the appearance 
of yet another programming pedagogy thread has caused me to spawn a 
crazy idea.

Disclaimer:  This is probably a bad idea.

So what if one of the ways to institutionally teach beginning 
programming was to just institutionalize the way I learned how to 
program?  You set up an Ultima Online server.  Customize it to cater to 
macroing/botting.  So it's kind of like robocode, but more RPGish and 
with some obligatory grindy numerical crap that has to be done before 
you are actually good at the game.

First of all, make sure the students coming in actually want to play 
games, namely an RPG style game, and if they don't send them to the 
bland boring typical programming classes.

The first few days of class are spent familiarizing the students with 
the game.  At this stage the instructor is mostly an admin as well as a 
player that helps other players out.  The students/players are allowed 
to play the game with relatively weak characters that should nonetheless 
be able to handle some fun canned activities.  They should also have 
some harrowing encounters.  You know; teach them their limits.  During 
this time the students will ideally gain some kind of personal 
attachment to their avatars and become assimilated into whatever kind of 
token economy might be deemed appropriate.

I suppose I should mention that you can safely assume that the students 
haven't played this particular incarnation of the game and that you can 
safely used canned quests and such.  It will all be novel to them.

After the first few days of the students being the squishy mortals they 
are, show them the power of programming.  Have them use a simple easyuo 
script like this overnight:

top:
; Hide every 10 seconds.
event macro 13 21
wait 10s
goto top

By repeatedly hiding every 10 seconds the player's character will 
develop hiding skill.  Run this overnight and you will likely have 100.0 
(maxed) hiding skill.  Now, hiding isn't an uber powerful skill that 
allows them to kill everything with the flick of a wrist, but it is 
useful.  This is good: you don't want to give everything away all at 
once.  Teach the students how to, in a pinch, run and hide, thus 
granting them invisibility to the AI mobs.  Given a low latency 
connection (school network?) and maxed hiding skill, they will be 
extremely hard for the AI to kill.  Now they are untouchable, but still 
poor at killing or very much else in the game.  That's good, they still 
have a reason to improve their programming skills.

Also, for reference, the less useful "hello world" script:

msg Hello world!$

Which makes the player's character say "Hello world!"
Yep. One liner.  The $ tells the computer to hit the enter key.

You're probably also glaring at that goto.  Heresy, isn't it.  But hey, 
goto is much easier to understand than functions.  It fits nicely with 
the idea of execution flow.  You can say that goto is horrible 
programming practice and hard to debug, and you'll be right, but the 
alternative is harder to teach at first.

At this point hopefully they've been using bandages to heal.  Hopefully 
they are also frustrated.  They have to move their mouse into their 
backpack, double click the bandages, then double click their 
character/healthbar every time they want to recover some precious hp. 
This just won't do.  So you have them write a macro to, on the press of 
a key, automatically find bandages in the backpack, use them, and begin 
applying them to self.  The solution looks somewhat like this:

hotkeyloop:
; poll for the key press.  It need not be only ctrl-shift-e.
onhotkey e ctrl shift
     goto heal
goto hotkeyloop

heal:
; Find a bandage.
finditem ZLF

; Use it.
set #lobjectid #findid
event macro 17

; Wait for targetting cursor to appear.
; If it takes longer than 2 seconds, give up.
target 2s

; Target self.
event macro 23

; done.
goto hotkeyloop

Hey, we have some branching and now the notion of variables.  The 
variables are #lobjectid and #findid.  They are builtins, and "set" is 
the assignment operator.  Teach it.
More gotos.  Deal with it.  It will get uglier in a bit, and that will 
probably be a good thing, ironically enough.

(Note: Last time I tried, onhotkey doesn't work with UO under Wine on 
Linux.)

Now for some magery.  They'll go from killing lowly rats and orcs to 
slaying dragons with this one.

top:
if #MANA = #INT
     goto cast
if #MANA < #INT
     goto med

med:
event macro 13 46
wait 4s
if #MANA < #INT
     goto med
if #HITS < #STR
     goto heal
if #MANA = #INT
     goto cast

cast:
event macro 15 41
target 4
event macro 23
wait 1s
if #MANA = #INT
     goto cast
goto heal

heal:
wait 1s
Finditem WKORQQD
set #LOBJECTID #FindID
event macro 17
target 2s
event macro 23
wait 1s
goto top

We start to see some if statements here, comparison operations, and a 
slightly more complicated program.
To be honest, I just grabbed this one from my old dusty collection of 
macros I've used at some point.  I have forgotten what WKORQQD is. 
event macro 15 41 casts energy bolt.  Other spells may be needed to 
level if the shard is set up differently.  Setting it up to keep it this 
simple is probably a good idea.  event macro 13 46 does meditation. 
This will train the auxiliary skills for magery too.
Maybe give them a skeleton program of this and possibly some bugs too. 
Fun with goto debugging.

For those that care, I haven't mentioned melee skills.  Those are harder 
to macro.  Just do magery.

You're still reading this?  Are you mad?

At about this point it's time to introduce EasyUO's subroutine feature, 
which is pretty much just functions.  Now they can ditch gotos.  Perhaps 
  switch goto loops out for while loops as the way to do a main loop. 
EUO seems to have most of the good structured programming constructs.
Before jumping directly into functions, it may be possible to goad the 
students into writing functions using goto primitives and thus teach 
low-level concepts like a call stack and a return address.  I'm not sure 
how much of a good idea this is.  I know I was writing functions this 
way before I know what functions were.  Then I learned, and sploited.

At this point they have some ?optional? assignments:
- There are nice builtin variables for things like #HEALTH.  EasyUO can 
also read messages displayed on the player's screen.  With these two 
things in hand, and a solid grasp of conditionals, control flow, 
variables, etc, it is possible to write a macro that does healing 
automatically.  No need to press a button.  It just continuously strives 
to keep the player at full health.
- Make another character.  A "mule" character.  Now make a macro to max 
out alchemy skill, so that the player can make potions.
- Make a macro that automatically chugs cure potions when the character 
is afflicted with the poison status.
- Make a macro that can max out 
tailoring/blacksmithy/carpentry/tinkering/mining on the mule character.
- Encourage classmates to share.
Welcome to teamwork.  Perhaps mandate that the students do all of these 
collectively as a class.  They will get first hand experience with the 
multiplicity of human programmers and how awesome it is.  Oh hey Linux 
Kernel, the might of mankind's giant programmer swarm is pretty cool huh?

Now perhaps we can get tricky.  Melee skills were ignored.  Perhaps this 
can be rectified.  Even though everyone is a mage just having maxed 
wrestling skill will be a valuable asset defensively.  Currently when a 
monster attacks them they get hit %100 of the time.  Maxed wrestling 
skill drops that to %50.  Alternatively, the student may opt to build a 
melee character (they should probably keep their mage, it's useful).
So how to max melee skills?
The macro-able way requires two characters to spar with each other until 
both are maxed out.  This is nontrivial.  The combatants will have to 
disengage when their partner is too low on health, or they will kill the 
partner and it's game over.  This may require the characters to move 
away from each other, and as such the macro must be vaguely aware of 
position.  Weapons degrade over time, so the macro will have to 
periodically equip a new weapon as old ones break.  The characters can 
heal themselves using the self-heal, but healing each other is 
considerably faster.  Heal self takes 10 seconds.  Heal other takes 4. 
Just how bad this is can be tweaked on server side (e.g. don't make 
weapons degrade over time).
At this point we can introduce the concept of finite state machines.  At 
some level most of these macros were just FSMs to begin with, but this 
is probably a good time to formalize the idea and begin exploiting it in 
earnest.  Writing this sparring macro as an FSM is probably a good idea.
This may also involve arrays.
It might also be good to mention the applicability of FSMs outside of 
this, such as in regular expressions.

Now if we really want to cement these concepts, we can have the students 
attempt to write AIs for their characters.  They'd probably be Player vs 
Player (PvP) or Player vs Mobile/Monster (PvM) AIs.  And by that I mean 
combat AIs.  The really nice thing about this is that the students will 
be able to replace a lot of their tasks in the game as a human being 
with things that their program can do.  They may even be able to run 
multiple AIs at once, thus multiplying their capabilities.  This 
realization and ability is quite an awesome experience.  It's probably 
doable in this setup too.  Of course, they'll probably need some 
guidance, and if fully autonomous AIs are too tough then there's plenty 
of room to expand on automatic healing/curing and construct a more 
robust part-man-part-machine kind of combat system.  Either way this is 
just damned cool.

That's about as far ahead as I've thought on this.

At one point my nephew wanted to learn how to do some EasyUO macroing to 
help him play UO.  My time was short, so in about 3 hours I taught him 
about 2-4 weeks of introductory computer science material.  He quickly 
realized this was more work than he thought it would be, and he seemed 
pretty wide-eyed by the end of the experience, but he did seem to learn 
and in a remarkably short period of time become something of a 
programmer.  So maybe there is something to this.

Notably, the topics covered by this will probably be different from a 
normal introductory course.  Finite state machines are covered, while 
user-defined types are not.  OOP is not covered here.

Pros:
- Fun factor.  The students are more likely to have unnaturally high 
levels of motivation during this course.
- Shock value.  It only takes a few lines of code at a time for the 
student to profit something fierce.

Cons:
- EasyUO is not a useful language outside of playing UO.
- Time spent on non-programming things.  Also, addiction.
- Differences with usual curriculum.  Non transferability of course 
credits.
- EA Games' rights to artwork in the UO Client.
- Has anyone even done this kind of thing before?

A couple of the problems can be solved with investment in a new UO 
client and macro language.  Of course, using existing RunUO server 
technology for the game server is probably a good idea.

Links:
High quality, free/open source UO server: 
http://www.runuo.com/products.php#1
The EasyUO main site: http://www.easyuo.com/
EasyUO documentation: http://wiki.easyuo.com/index.php/Documentation
Ultima Online site: http://www.uoherald.com/news/

OK, I've had my fun for the night.  Later.
- Chad