Engine
Jan 05, 2015
After I posted this question on Grumpy Gamer, I started to take a close look at engines that were suitable for a 2D point & click game. Lots of great choices, but deep down (if I'm honest with myself), I'm a game engine snob. Whenever I use an engine, I keep wanting to modify it and hack into it to do what I need. I guess I've found over the years that it's a lot easier (and less stressful) for me if I just create my own.
I have a fairly robust 2D graphics engine written in C/C++ that I used for The Big Big Castle, Scurvy Scallywags and 30+ game-a-week prototypes over the years. It's stable and I'm used to it. It runs on iOS and (mostly) on Android, and I ported it to Windows and the Mac about six months ago.
I use SDL for window creation and handling input, but not for rendering. I just get the surface back and then use my own rendering code. It has an abstraction layer for OpenGL, DirectX, etc, but the DirectX layer is pretty simple and kludgy. I'm not sure I have the desire to fully learn DirectX, so I might get someone to help with that.
I think my engine has everything I need...
Except a scripting language.
I looked at Lua which it's pretty easy to integrate and is highly optimized, but I really hate the syntax. There is just too much that is goofy about Lua. I like my { braces }.
I looked at writing my own scripting language. It's not as complex as it seems, and I figured it would take me about a month, but I'm not sure I want to eat up that much time. 18 months seems like a long time, but it's going to go away fast, it always does.
The other option was Squirrel. I've followed it for several years, but never really had the need to integrate it. I like the syntax and it's pretty simple implement. I'll probably go in and modify the syntax a little to mimic how SCUMM laid out code for rooms and objects.
So, mixed with design and budgeting, I think this week will be spent getting Squirrel implemented and building a quick test game to see how well it works.
I'll let you know how it goes.
- Ron
I don't know if you will explain it, perhaps someone else will, but what is 'the engine' doing and what is a 'scripting language'?
Sorry for knowing nothing but would love to start learning now ;)
- Jesper
im not a game dev.
M-Theory is physicists code abstraction layer for data driven universe construction. I like it so I hope it will prove right :)
Or simply: scripting languages kick ass once you have them. :D
I'm loving this project and your level of transparency with the blog. Have you entertained the idea of bringing any developers on board (pro bono / like an open source project)?
I'm pretty sure I owe my career in Computer Science in part to being inspired by the awesome games you built that I grew up on; it would be an honor to contribute to this project in some way. I'm sure I'm not alone.
Joe
http://stackoverflow.com/questions/1513920/scripting-language-for-c-c
http://en.wikipedia.org/wiki/SCUMM
An "engine" is usually the core of the game's program.
It handles drawing things on the screen, playing sounds, handling input from the mouse and keyboard. Since this is an adventure game engine, it also models things you are familiar with in adventure games: It allows characters to walk inside and between rooms/"screens", pick up items, and use them on other items, converse with each other using dialogue trees.
An engine can usually be used for a variety of games. If it's an adventure game engine, it will usually be used for several adventure games, such as the SCUMM engine that was used in (almost) all of LucasArts's adventure games.
The actual parts that are specific to a game, such as WHICH characters are in the game, WHICH items interact with WHICH other items, how rooms are connected - all that is usually handled outside the "engine", usually written in a custom programming language (usually called a "scripting language") that understands the adventure game concepts of "characters", "items", and "rooms".
This separation is useful for several reasons, mostly because it allows you to have different people from different disciplines working on different parts of the game. The designers who decide how to connect all the different parts of the game, and write the game's text script, don't have to know how to program the engine, which usually requires a lot of technical programming knowledge - they just have to learn the scripting language for the game. Similarly, it also allows the artists to insert art assets easily.
As mentioned in another comment, the two parts don't necessarily have to be separate - especially since the Thimbleweed Park team is so small - but that's how it will probably be in this case :)
Fantastic explanation :D
( and we both like to reinvent the wheel the way we like ;) )
Recently I'm considering using SFML instead of SDL for the graphics (on mobile platforms I'm still using a gfx system of mine). Just experimenting in these weeks and I'm liking very much.
Looking forward for your updates and seeing how Squirrel will be adapted!
Eagerly waiting for details, Ron!
P.S. thanks for the Puzzle Dependency Graphs/Charts post @ grumpygamer!
For anyone interested in SCUMM and in understanding what a scripting language looks like (and is used for), I found this post of Ron explaining a bit about how SCUMM worked/works :
http://www.pagetable.com/?p=614
The only scripting solution that I have used that I felt comfortable with was the one that I wrote myself.
and squirrel does not look too bad imho (no practical experience with it though)
I develop multiplatform c++ game (Windows, OS X, iOS, Android). And, I usually write and debug lua-scripts on Windows. Then, if I need to debug scripts on another OS (but this is rare situation), print-debug - is all I have)
ah. That's a good choice :)
Even if it is a stick figure and the puzzle is to walk across a drain without falling through by placing a plank over it, I would be pleased
(Go ahead, I'll let you use my idea for free :) )
it would appear that the RSS-Feed is not updating correctly - yesterday's article (Jan 05) is not available on http://blog.thimbleweedpark.com/rss (the two previous entries are).
Could you please have that fixed?
Cheerio!
Seb
It can really help to maintain/debug one part despite the other part.
Once I programmed a point-n-click adventure, but I used two different engines: AGS and Visionaire. they both integrated script & engine. The result was a good game, but quite difficult to debug and to change something after the game was already done.
So, even if I don't know Squirrel, it seems it appears the most suitable tool, or at least a starting-point. Maybe you could adapt to your needs, changing something in a easier way than using other tools, and in less time than writing your own.
I think you could really spend one week to stress-test Squirrel, and then if it doesn't satisfy you, perhaps writing your own scripting language would be the best way.
You did it once, you can do it twice!
(if it´s playable..)
I mean, we should strive and reduce the complexity of the scripted code, not realize a one-to-one binding with low level APIs resulting in overcomplex scripts. The balance between "how much" the game engine and the scripted part do is critical. The game engine should do enough to have elegant and compact scripts... not being only a game-loop stub that demands everything to the scripts.
(not to mention DLLs are compiled binaries, which means that designers need to have a suitable compiler/IDE and the skill to use it)
(also, DLLs are available only on Windows platform, altough other OSes have the same tech with different names)
> (not to mention DLLs are compiled binaries, which means that designers need to have a suitable compiler/IDE and the skill to use it)
Compiler, maybe. IDE, no. Using command-line "cl" in Windows and gcc/clang in Linux/OSX it's possible to automate this so it seems interpreted. Setup a remote build system and you don't even need the compiler installed.
> (also, DLLs are available only on Windows platform, altough other OSes have the same tech with different names)
True. It's just easier to type than shared library and the name is more well known so didn't think that was worth clarifying.
If this is what you meant by "expressive power" I don't see why a scripting language is necessary for this. Just use the C/C++ interface you would export for your scripting language and you have the same thing?
I didn't want to sound pedant, sorry. :) I just wanted to point out that a DLL-based approach would require to use different binary resources (built differently, most notably to handle entry-points, initialization and general resource usage if needed) on different platform. That is, the porting is (a little bit) more complex. On the contrary, in a script based approach obviously the very same script is used every platform without changes.
In my opinion, if the project is aimed to be multi-platform, adding a layer of complexity (porting-wise speaking) is masochistic.
> [...] there is also something to be said about using already established tool chains for debugging, profiling, static analysis, etc. Look at Unreal Engine 4 for example. They ditched UnrealScript in favor of run-time compiled C++.
I guess real-time requirements are quite different in the Unreal Engine nowadays. ;)
> Compiler, maybe. IDE, no. Using command-line "cl" in Windows and gcc/clang in Linux/OSX it's possible to automate this so it seems interpreted. Setup a remote build system and you don't even need the compiler installed.
Automation is certainly possible outside an IDE, but I guess the designer will need a IDE to write down the C++ code and possibly debug it (an editor could not be enough). Moreover, knowing C++ could be a major problem to some.
> If this is what you meant by "expressive power" I don't see why a scripting language is necessary for this. Just use the C/C++ interface you would export for your scripting language and you have the same thing?
Sorry, I didn't explain myself well. "More expressive power" of course means "less line of codes". That is, the game-engine binding layer should enable the scripts to do *more* with *few* lines of code (and C++ do not shine on this).
I was referring to some script-base general purpose game engines where you end up having tons of scripts that makes the application from the ground up. The engine is just a sandbox VM with primitives.
This do make sense in some occasions (I built engines like this on purpose), but not everytime.
Lua is nice and light, if a little peculiar (the meta-table stuff is a little cumbersome and left me scratching my head from time to time) and it has some sexy syntactic sugar so you can write stuff like:
'Actor.create {
--attributes
}'
So you're missing out the parentheses. I do miss certain operators like '+=' and in Lua though.
Why don't you use your former colleague Douglas Crockford's pet serialisation format, JSON?
If you're writing your own tool will it ever see public release or will you be keeping it under lock and key?
The Lua source is very clean and easy to modify.
http://www.lua.org/source/5.1/llex.h.html
http://www.lua.org/source/5.1/llex.c.html
http://www.lua.org/source/5.1/lparser.h.html
http://www.lua.org/source/5.1/lparser.c.html
Advantage over Squirrel: more tooling and libraries (e.g. http://lua-users.org/wiki/DebuggingLuaCode). ZeroBrane supports live coding (hot code swapping) for several game engines, for example.
You could still run third party vanilla Lua code by compiling it to bytecode first. C-based libraries will also work out of the box (http://www.kyne.com.au/~mark/software/lua-cjson.php).
IDE/debuggers like Decoda or ZeroBraneStudio would require some tweaks to handle the modified syntax, but they're open source, and all in all it should take half a day to implement.
I don't want to tell you anything but this "DON'T VASTE A MONTH!".
LUA is great but if you don't like it choose whatever else but don't write your own scripting language.
Ciao.
That being said, I also hope that Ron will find Squirrel to be language of choice.
https://code.google.com/p/angleproject/
I've been using it for a while, writing only OpenGL ES 2.0 for Windows, with the advantage that the same code can then be used for tablets directly, or with usually a few minor tweaks OS X and Linux (and more recently with both Native Client and Emscripten to run the same in the browser).
Thanks Ron.
And if you are already using JSON ... I would guess you've already considered Javascript and discarded it?
for scripting you might want to look at:
http://munificent.github.io/wren/index.html
Hope that helps.
Cheers
* though this global scope isn't really that attractive now with VS 2015 CTP 5 as you get a new feature that allows this:
global.cs: put global stuff here in classes (eg. class Global { })
others.cd: import classes - now instead of writing Global.StaticMethod() , you can write StaticMethod() - except since this is C# you get intellisense and auto completion and such - I wouldn't touch a scripting language without these and great debugger)
others.CS: import classes - now instead of writing Global.StaticMethod() , you can write StaticMethod() - except since this is C# you get intellisense and auto completion and such AND NOW YOU DON'T NEED TO WRITE ANYTHING (just type st[space]) - I wouldn't touch a scripting language without these and great debugger). In c++ either you type more or you got very polluted intellisense. Yeah there's F# and such you could also use but while the language may be succint, the rest of the experience is nowhere near C#. And besides, succint languages are not needed when C# auto-completion takes care of the writing for about 90% of the code.