Scripting Language: Rolling Your Own

Greetings all. First, an introduction. I'm new here again (my old account expired possibly due to inactivity, never posted, just lurked). I started programming for the Mac in 1996 after acquiring a first generation PPC. I went from 68K to PPC code, dabbled in Carbon and Cocoa, and now I'm back in familiar territory: PPC code for Classic.

My first major project was ambititious: a simplified RPG/adventure game based on an old tabletop game called "Dungeon Dwellers". It's been my one project I refuse to let die and after many rewrites from scratch, I think I'm finally in a position to finish it (or at least get past the proof-of-concept stage!).

Creating a modular system where in-game objects may be capable of very different abilities was always the difficult part. I tried creating a data structure that could be versatile enough for the most complex behavior yet compact enough so that a simple object that only displays a line of text when activated doesn't feel like a waste of HD space.

I also dabbled in 'CODE' resources and got results. Unfortunately, I was limited to 68K code so that path was short-lived. It wasn't until I decided to store game object data and behavior in a text file when things started to take off. It started as a scripting language solely for interactive dialogue between the player and NPCs. Dialogue would be displayed and the player could choose their response via clikable links (or by typing into an editable text dialog, whichever was appropriate).

I scoured the net and found most scripting languages are written in a C-like syntax. I wanted something that was simpler to compile so I opted for an HTML-like syntax for on-screen display and soon after added an assembly-like syntax for logic.

The result is a scripting language that can be tested and compiled in a script reader application and an engine that can be plugged into an application that can make use of its features.

I was wondering if anyone here has rolled their own scripting language and what their experience has been like. And yes, I am still programming for a pre-OSX environment. I'd like to overcome one hurdle before I approach the next

You need to switch to Mac OS X, now. That's not a hurdle, that's the gift that'll make your life easy. Programming on Mac OS X is *much* easier than on Mac OS 9. Didn't you hear the guy? Mac OS 9 is *dead*.

Once you've done that, you can check out ANTLR and LLVM, those'll let you get scripting languages up and running in no time, with a minimum of code and great execution speed.

That said, I'd still recommend you look at existing embeddable languages, rather than rolling your own weird ones nobody understands. You can actually use HTML or Flash via WebKit, and languages like Lua, Ruby, Python and Io cater to various requirements for your control language.

Once I get comfortable with objective-C programming (opening/reading/closing files, wrapping my head around the memory allocation, and such) and can find a way to do the things I'm so used to doing in Classic (like finding an equivalent to CopyBits(), having pixel-level control of a PixMap, parsing a text file, etc.) then I'll make the jump. I realize OS8.6 (never upgraded to 9) is dead. I plan on porting the game to OSX, but I'd like to finish it first and not try to port a half-finished project.

I'm sure there are plenty of other scripting languages out there that can meet my needs, but frankly I've invested way too much time into this one to drop it. It's robust enough to write a text adventure that could be "played" with the stand-alone script reader application. So putting it on ice isn't really an option. Besides, I'm a do-it-yourself kind of guy.

If you've got QuickDraw code, you can still use it on Mac OS X (though you've waited so long that it's deprecated). There's no need to make the jump to ObjC at the same time if you're uncomfortable with it.

On rolling your own scripting language: generally speaking this is just a bad idea. One, if you're doing it just for yourself then you should really do yourself a service and at least give one of the existing ones that OSC mentioned a try. Two, if you plan on letting others use your scripting language, they would much rather prefer an existing mainstream language that they can get plentiful documentation for over the internet, or maybe are even familiar with already. On the flip side of the coin, there are two reasons I can think of for rolling your own. One, it can be fun. Two, it may actually be necessary in rare cases where you need a domain-specific language for optimization or extra security. Or possibly in the even rarer case where a particular platform does not support your language of choice... yet -- which is the scenario I'm facing right now with XNA [grumble]

Next, on the OS, dude you really need to consider dropping all your hard earned work and just re-write your game from scratch using the new technologies in OS X. I had to drop my old stuff too, so I understand that decision doesn't come easy, but I can say that it turned out to be well worth it in the end. Just forget about copybits and blitting your own stuff. That just isn't the way we do things now with hardware acceleration. There *is* a relatively simple way to use OpenGL instead of copybits, but it just isn't very efficient compared to modern standard techniques using quads for sprites in OpenGL.

Memory management in OS X is much easier than Classic. Just use malloc and free if you're doing C. No worries about stack/heap collisions or setting the size of the app's memory footprint because that's all automatic now. No worries about restarting the machine because you forgot to initialize a pointer either, since OS X uses protected memory. Memory management alone is worth switching to OS X.

Finally, hindsight being 20/20, if I were to migrate over to OS X from Classic myself right now I would head straight over to OpenGL, starting with GLUT. There you get to learn modern file opening/closing, memory management, and OpenGL all at the same time in a relatively easy environment. And as one last note off the top of my head, completely abandon any ideas of continuing to use resources (as in resource fork resources) -- they're dead for all intents and purposes and you'd just be inflicting uneccessary pain upon yourself.

I did port an earlier version of the scripting engine and the script reader application to Carbon a while back. It worked great and I loved the (basically free) ability to resize the text and change background colors on the fly with no sweat. Porting to Cocoa from there should be no problem. Once I get a grasp on the graphics portion of Cocoa I will probably take the dive.

And yeah, I stopped relying on resource forks a long time ago. The only thing in the resource fork right now is app-specific stuff (BNDL, WIND, etc.) and a PICT or two.

These questions probably don't belong here but I'll throw them out anyway. If I use straight C can I still use nib files? I have at least 2 or 3 Cocoa books but they all assume Objective-C. Also, would I have to stick to Carbon? On that note, is Carbon still viable with the new Intel Macs?

As for rolling my own, yeah, part of it was the challenge. The other part was the fun.

Making some assumptions here based on what you've said so far (about your move to OS X)...

You don't want to plan on focusing your attention on using Cocoa for game graphics (* see note below), rather focus your attention on using Cocoa for handling system UI stuff like windows and menus. Instead of Quartz, Cocoa additionally provides an interface for using OpenGL for accelerated graphics. That's where you want to go with games in OS X.

Yes Carbon is still equally viable with Intel Macs. Cocoa is still better for all practical purposes (Carbon lovers be damned!!! (I kid, I kid)) and is Apple's recommended API for new Mac apps. Going Cocoa is worth it. Obj-C is pretty darn easy if you already know C.

(* The note below: by Cocoa for graphics I mean Quartz, and perhaps I am mis-characterizing that since Cocoa on its own is not a graphics API to begin with and can theoretically be used with any graphics API)

To be clear, there is no need to change any of your C data structures in order to use Cocoa/Obj-C. The purpose of data structures remains the same. Essentially, Obj-C simply takes C a little further and allows you to assign data members within an object, instead of a struct, to allow methods (functions) to be associated with them. It's a very simple, but powerful enhancement to C. When it comes down to it, Obj-C is really just C with stuff added to make it object-oriented. There's a little more to it, but not much.

That's a relief. I think I'll take another plunge into Cocoa, beginning with porting the scripting language over and going from there. While perusing the iDevApps forums I found the SpiderWorks website. They have a Cocoa Game Programming Workshop book that looks like it might be a good starting point (since my game is 2D and tile-based).

Just another take on the jumping from C/resources/copybits/classic toolbox approach, you might like to take a look SDL (http://www.libsdl.org). It's a pure C API, and it's also cross-platform. You can use it with standard draw-to-offscreen-memory-and-blit approach, or you can use OpenGL too. I initially ported some old OS 9 code across to it pretty easily. But I do recommend you go the OpenGL route, even for 2D as it gives you lots of neat scaling, blending features, hardware acceleration for free, no more managing double-buffered contexts, and is an easy step into 3D if you wanted to in the future.