Day-To-Day Work Logs and Woot! Engine Stuff!

ERROR
AUTHOR NOT FOUND
LOAD DEFAULTAUTHOR==NICHOLAS

 

Hey now, the one before that was me too! What's going on here?

 

What do you mean, ##NICHOLAS ?

 

Today: fog, water, and more Lua news.

http://www.gaslampgames.com/2013/01/16/whats-new-in-programmertown/

 

It's ground fog, so it has a defined "top" height and density. Distance-based fog doesn't make much sense in a game without distance (i.e. an isometric perspective)

 

Since Triolo isn't here, I will mention that today's new blog post is about DIRT and FILING:

http://www.gaslampgames.com/2013/01/23/dispatch-from-the-ministry-of-art-direction/

For those wondering about the Lua stuff, we ended up gluing it to our internal object message-passing system and it turned out to be A Good Thing after all. Essentially, each type of game object gets a .go file (to confuse everybody's text editor into thinking we're using Google Go), which consists of a small pile of Lua scripts and a handful of Exciting Information about State And Stuff. Events will likely be rolled into some other file that combines a Lua script and game-specific mockups. It seems to be pretty good so far! We'll keep you posted, maybe in a future blog post.

 

I'm pretty sure you're just being difficult at this point.

Everything basically fits into a .go file, which stands for "game object." There's a list of received messages, a collection of state variables for the object, and then the actual received message types. (Create, Update, etc.)

For instance, here is a couple of messages that you might expect from a mineshaft (still being worked on):

Code:

receive Create()
<<
    gridPosition.x = 100
    gridPosition.y = 100
    name, renderHandle, error = query("rendStaticPropClassHandler", "odinRendererCreateStaticPropRequest", SELF, "models//environment//placeHolders//grinderPh.upm", 100,100);
    send("rendInteractiveObjectClassHandler", "odinRendererAddInteractions", renderHandle, "Mine", "Mine");
>>
 
receive InteractiveMessage( string messagereceived )
<<
    print ("Message Received: " .. messagereceived );
    if messagereceived == "Mine" then
        send( "gameCitizenRequestBlackboard", "gameObjectNewJobByNameMessage", SELF, "Mine" )
    end
>>

Basically, everything still communicates by message passing - a character sends a message to another character saying that he's been shot, that sort of thing. This will look very familiar to you if you have ever played with, say, Megazeux. (Or Erlang.) FSMs are now also being done in Lua, and they just consist of a table with a list of states which are functions, and each one can then throw the next state that it goes to and so on and so forth.

There will be a third Lua event primitive for events ("Lord Palmerstoke has commanded that you store his collection of Research Bees. What could be possibly go wrong?") and probably other files for things like Megaprojects, that sort of stuff. But this is the general direction things are going in. I'll ask Micah if he wants to drop by and talk about it.

EDIT: It is worth noting that this is how this works *today*. This is probably not how it will look by the time we are done, and it is not clear what Lua (if any) fits into the mod system, and what will actually be moddable. Details have not been finalized, and requests for features will be ignored.

 

No, we give them to Sean for his guinea pig's cage.

 

Messages are purely internal constructs and are never affected by jobs or whatever. For instance, you would never want a citizen to stop responding to grid request messages because, then, something waiting for a grid request from a citizen would never get it and would just keep hanging out doing nothing.

What you're talking about is the job selection stuff, and I imagine there will be ways to whitelist or blacklist that based on various things. right now it's just occupation but I can easily imagine people getting traits which either whitelist, or blacklist, jobs - or at least slant the utility functions.