Scripting in VB.net

One thing that all good game engines require is scripting support.  Scripting is even useful for non game engine programs.  Currently, there are limited options available in this department for most VB.net developers. 
I started off using an extremely limited script system based on select-case and integer lists. 
Basically, I have something like this:

'A single command line
Structure Command
   Dim OpCode As Integer   'OpCode is the instruction to be executed
   Dim Param() As Integer   'Param() is an optional list of arguments the command needs
End Structure

'A single user variable
Structure Variable
   Dim VarName As String    'VarName is the name of the variable
   Dim Data As Integer          'Data is the information stored in the user variable
End Structure

'A script, including local variables, code, and program counter
Structure ScriptObject
   Dim Code() As Command          'List of commands the script is composed of
   Dim Variables() As Variable      'List of variables used by the script
   Dim PC As Integer                      'Points to the next line of code to be executed
End Structure

Sub ExecuteScript(ByRef Script As ScriptObject)
   With Sript.Code(PC)
      Select .OpCode
         Case 1    'Move a sprite Param(0) to location (X, Y), X=Param(1), Y=Param(2)
            GPU.Sprites(.Param(0)).Location = New Point(.Param(1), .Param(2))
            PC += 1
         Case 2    'Sets Sprite Param(0), Visibility(Param(1) [0=False, 1=True])
            GPU.Sprites(.Param(0)).Visible = IIf(Param(1) = 1, True, False)
            PC += 1
         Case Else
            Throw New Exception("Command not implemented yet.")
      End Select
   End With
End Sub

As you can see, this method should work just fine, so long as the script engine doesn't need to be too terribly complex, and the number of OpCodes (possible different commands) is relatively limited.  Now the real problem starts showing up when you try to implement Sprites, Meshes, animation, sound effects, network communications, background music, keyboard mouse and control input, reading and writing files, conditional branching, looping, and any number things that need to be implemented.  Now consider writing scripts for this engine using columns of numbers, with no labels or other indications whatsoever for what they are for or do.  Brings me to mind of early machine code programming (bleh).  What happens when you make a typo on one of the switch statements, and the wrong command is selected, or not executed at all?  Terribly difficult debugging, is what!

What I needed was a human readable, more flexible, and easier to work with scripting language.  There are many different scripting languages available.  Many game engines use LUA for its brevity and flexibility.  However, LUA is extremely complex to implement.  I thought I would start off small with an older, simpler language.  For example, C. 

So, now I'm working on a brand-new script engine based on C.  C by itself is probably not sufficient to control a game engine, but I could easily add API extensions to give the script language control over elements of the game. 

I would like the game engine to provide access to primitives, such as loading and displaying images, playing sounds, making tcp/ip connections to send and receive data, loading meshes and world grids, that sort of thing.

In my previous script methods, I would need to program every kind of function and command, every kind of game engine object, and every data processing method, into the game engine itself.  This would greatly limit the things that can be done with the game engine to only the things I program it to be able to do...specifically, it would limit the game engine to only the things that I can imagine it should be able to do.

Offloading all of that processing to a C script would simplify developing the game engine, and more importantly it would allow the scripter to determine what the game engine can do instead of just me.  Implementing a powerful scripting language would enable the game engine to run any kind of game the game designer can imagine.

But, how does one implement something so complex as C?  I'd be lying if I wrote that I have all the answers to that, but I'm working on it.  I'll be analyzing this problem over the next several weeks, and as I start to make breakthroughs, I'll be posting them here!