The answer is: yes. Foxie will have both static and dynamic typing (and it's your call!).

That's a fair response. But wait! There's more!

First of all, apologies for the lack of updates in the past week. I've been back at work, after a little break, and haven't had much time to write about Foxie. Besides, in the little time I've had, I've been focusing on implementation.

But now, it's time to think aloud a bit. The more I experiment with Foxie's syntax, explore the depths of the compiler structure, the more I realize: people don't want a systems language for scripting (myself notwithstanding).

As nice as it may be to know which types belong to which function parameters, etc, it's not essential for scripting a game, especially in an environment as limited in scope as this. After all, we're trying to target RPG scripting, not a full-on game engine, with Foxie.

But what's this about "both static and dynamic typing"?

"Por qué no los dos?"

How do you have both? I'm still figuring out the details, mind you! But I'm thinking something like Javascript's "flow" library, but without the comment directives. Maybe instead, you would have some sort of annotation on the function or data in question, and the compiler would figure out what you want.

Obviously, I'm still hammering out the details, but the point is this: Foxie is going to be a much simpler, more dynamic language than what I had outlined in some of my earlier posts, especially with regards to typing.

That said, the language will be strongly typed, when the types are specified, so you can't pass a number into a function that's expecting a string. Other than that, I'll assume you know what you're doing.

I guess now might be a good time to lay out some of the base ideas behind Foxie...some of the fundamental principles that will guide the development of the language.

Relax, I'm not diving into compiler esoterica here. Not yet.

What I want to talk about are some of the "rules" of Foxie's design, the very few "should"s and "should not"s. Like these:

  • Foxie should let the creator modify a pre-made game engine
  • It should not get in the creator's way unless it keeps them from screwing up
  • It should allow imports of pre-made assets in common formats, like from the Tiled map editor, or PNG spritesheets, or MIDI/MP3 assets, or what have you
  • It should not allow direct access to Javascript APIs (!!)

Some of these, we've talked about. Some we haven't. For example, I think the last one will set off alarm bells for some developers. No interop with the host platform?!


You won't need it. I'll provide everything you need – besides, this is purely for scripting the game! You need data structures and functions for defining game behavior, not some JS interop to hack around the engine behavior. If anything, I'll add features and fixes as requested, if they make sense for the overall system. In short, to reiterate: you ain't gonna need it.

I think that's about as much philosophizing and navel-gazing as I can stand for now. In the meantime, enjoy the soundtrack, along with easily one of the weirdest music videos on earth: