Gearhead Prime: tech demo

[magic.coding.fairy.peridot]

I've played with (in Python) the way class variable values are carried over to class instances: instances seem to just refer the class variable's value until individually reassigned. Then that instance has its very own value for what would otherwise have been a class variable. I've certainly found that useful, so it might be useful here too, I dunno.

Can you do the same with class methods? That is, make an instance of type Door that has its own unique code for the Use method.

Edit- And of course, if this isn't possible, it would still be possible to write the "scripting" bits of the game in Lua. Python has a library for everything.

You can; python supports all sorts of dynamic jiggery-pokery with classes and objects (and don't even get me started on metaclasses, which thank God I haven't actually needed yet). But I think I'm inclined to keep things simple: a class for GenericDoors (an instance might represent a generic steel door) and another for particular Doors (including open/closed state and damage). The instantiation mechanism can be handled by making GenericDoor inherit from a GenericObject class that knows what it means when an attribute contains "3d6" instead of a number. Or something along those lines.

As for incorporating Lua, I really don't think it makes sense. Lua is not enough simpler or more flexible than python to warrant the burden of mixing languages. Python scripts for object actions can be contained in string attributes in the yaml file (though some yaml files cannot be allowed to contain python code for security reasons; this might argue for another approach to scripting).

[Joseph Hewitt]

Great! In that case, I better start learning Python!

One more question about scripting: Is there a way to "sandbox" the scripts so that certain things are off limits? It might be useful for security + stability purposes.

[PlaintextMan]

You can; python supports all sorts of dynamic jiggery-pokery with classes and objects (and don't even get me started on metaclasses, which thank God I haven't actually needed yet).
...
As for incorporating Lua, I really don't think it makes sense. Lua is not enough simpler or more flexible than python to warrant the burden of mixing languages.

Yeah, that pretty much sums it up; Lua will be uneccesary if everything is already done in Python.

Great! In that case, I better start learning Python!

You won't regret it. To me, Python was love at first sight.

One more question about scripting: Is there a way to "sandbox" the scripts so that certain things are off limits? It might be useful for security + stability purposes.

Erm... that is a good question. I have never (needed to) done something like this yet, but I'm sure it is possible.

That said, though I can understand one not wanting a user-contributed script to mess with the player's files and such, when was the last time someone did something malicious like that with a real-world game? (there are many examples of games that are very naive in how they treat addons/mods, and very few examples of them getting actually maliciously exploited)

[magic.coding.fairy.peridot]

Great! In that case, I better start learning Python!

One of the nicest things about python is that there really isn't much to learn; it you're used to C/Pascal/perl/C++ there won't be much in the way of surprises. If the perl motto is "there's more than one way to do it", python's is "there should be one, and preferably only one, obvious way to do it". The ghp code is not the tidiest to learn from, but there's nothing really mindbending in there.

One more question about scripting: Is there a way to "sandbox" the scripts so that certain things are off limits? It might be useful for security + stability purposes.

Not really, not in the Java "you can safely run untrusted code" sense. But if you tell people which modules they can import, and they don't try to circumvent it using eval or introspection, you can fairly effectively limit people to using particular APIs. This is python's access control philosophy generally: don't actually *stop* programmers from doing bad things (e.g. accessing private members) just force them to use a method that they know is circumventing access control.

[PlaintextMan]

The ghp code is not the tidiest to learn from, but there's nothing really mindbending in there.

Heh, except perhaps generator functions (the yield statement). An elegant mechanism indeed, but I don't think I've seen it another language before. Kinda sad that I only got around to learning of it now...

This is python's access control philosophy generally: don't actually *stop* programmers from doing bad things (e.g. accessing private members) just force them to use a method that they know is circumventing access control.

Yeah, and this is actually a great feature of Python philosophy in general: don't enforce; recommend some good paradigms, but don't absolutely force or bar the programmer. It seems like a bad thing on the surface, but in the end it cuts out a lot of actually uneccesary complexity (C++ const-insanity comes to mind).

[magic.coding.fairy.peridot]

The ghp code is not the tidiest to learn from, but there's nothing really mindbending in there.

Heh, except perhaps generator functions (the yield statement). An elegant mechanism indeed, but I don't think I've seen it another language before. Kinda sad that I only got around to learning of it now...

Hey, it could be a lot worse. Go read up on scheme's call-with-current-continuation and the mind-bending things it can do. Generators are downright homey by comparison. Even when you use the new yield-can-return-a-value trick to pass values back into the generator.

An earlier attempt to provide serialization, instantiation, and automatic type checking for Sprocket objects used metaclass hacking, which is where python gets decidedly weird. In the end I scrapped it because it's more important for the code to be comprehensible.

I actually have mixed feelings about using numpy in this project; on the one hand it's the natural way to efficiently represent arrays of terrain, but on the other it adds a dependency and code that really uses it looks APL-like and is hard to follow (unless you use it daily at work like I do). We'll see; so far it's only used inside gamemap.py and it would be easy to pull out.