Shop Forum More Submit  Join Login
I got the circuitry system in--fortunately there were no major problems and so far it seems to function without bugs!

The really cool thing is that it allows for both instant computation AND feedback loops. So both of the circuits in this diagram (…) are possible.

As far as the user experience goes, it is very simple to get the hang of. You just plop the "chips" in the gameworld like any other object, select the wire tool, and draw wires to/from the inputs and outputs (drawing a wire to/from a connection that already has a wire will simply delete it and replace it with the new one). I'm planning on allowing for both physically simulated chips (i.e. they react to collisions and gravity) and "static" ones that just float and don't react. The user will probably be able to choose with just a simple checkbox which version he wants.

The only thing I have left to do is to detect when there is an illegal feedback loop (i.e. not properly buffered, leading to non-terminating recursion, which would freeze the game--very bad), and preventing the player from placing a wire connection in a configuration that would lead to this. Shouldn't be too difficult, and once that's done I will likely post a video demo of this new feature.
I've added the following items which I don't believe I have mentioned yet, at least not in my journal:

--Weld joint
--Gravity vortex
--Thermal goggles

Now I am actually working on that "circuit" system I have been writing about. So far, so good--no problems or insurmountable bugs. Overall I don't expect it to be too difficult to implement given all the functionality that is already built into the engine. Hopefully I will be able to post a video of the system in action soon.

If you have any suggestions/requests for weapons or other items, now would be a good time to let me know!
Well water has been implemented. I don't have any support for persistent fluids though--it's just as in the first game, where the water particles dissipate on impact. Also upon impact they undergo complete heat conduction just before being destroyed--i.e. in one single game step the water particle body and the body it impacted reach temperature equilibrium. Generally since the water particles have much lower mass than normal game objects, this means it still takes a stream of water particles a few seconds to, say, put out a fire on an object. (Or much longer if it is a very big object that is burning--it's all based on the object's mass and heat capacity.)

I still have the circuit/electricity system in mind, and I will definitely be implementing it at some point (probably soon). However, for the time being I am working on simpler things; first up is basic gravity vortexes. These can be placed by the user and simply cause nearby objects to be sucked in (or pushed away if the user chooses).

It definitely is great to have most of the underlying game engine done, so that I can move on to just implementing the objects. And fortunately the fact that I made it highly modular and scriptable means it is really really easy to code very dynamic and interesting items, and then reuse their functionality in later items if I so choose (due in part to the fact that inbuilt or user created scripts can expose functionality globally for other scripts to use). I really hope script creators will take advantage of this and we'll get to see some amazing items that I could never have thought of myself.
I'll just give the link, and you can read my detailed comments on the video page.…
Well, in the original Interactive Buddy, the temperature system was very basic. In short, a thing was either on fire or not. If it was, and it touched another flammable thing, than that thing caught on fire too. And that was it.

In IB2 it's a bit more complex. Every physical body has a variable for heat capacity, thermal units (and from those two you calculate temperature), and conduction. They can also be flammable or not, light on fire at a specified temperature, and, when on fire, increase to a specified temperature (burn temp). Thermal units is the only variable that changes over time, but all the variables have an effect on how they do so and what happens when two bodies touch and transfer heat. (Bodies also lose some heat through the air at a rate determined by their surface area--which is calculated at object creation.)

I also have plans for a "pseudo" electricity system. I'm not going to be using calculus to solve for any circuits or anything like that, but I intend to have batteries and other generators (e.g. generators that turn on when you press a certain key on your keyboard) that can connect to different parts (logic gates, motion sensors, etc) which can ultimately connect to things that use the power (lights, motors, etc). Should be interesting.

So, that's what I'm working on now regarding Interactive Buddy 2.
Wow, I never realized how slow the Flash debug player is.

This piece of ShockScript code (which runs a dump loop 300k times and outputs how long it took to run)...

(set x 0)
(ui.notify (exec_timer (loop 300000 (set x (+ x 1)))))

... takes about 4.7 seconds to run on my machine on the debug player. When I run the game straight from Firefox using the regular player, it takes about 1.3 seconds.

So, another fantastic speedup for ShockScript (at least compared to how fast I originally thought it ran)! Plus the game itself just runs way smoother in the browser--many more objects can be added without slowdown.

I'm currently building the object selection system, so that any object that is added to the gameworld can be easily selected just like how you can click and drag to select icons on your desktop. Previously, it only worked with rigid physical bodies, and things like joints and particles and anything else were not selectable. They soon will be.
Well, I have been working on Interactive Buddy 2 on and off the past month. Some results:

--Beginning to implement joints (still need to make it easy for players to use though)
--Shape drawing tool (very easy to use)
--Bug fixes in the UI
--Beginning to implement score/money system (big addition over the original: combos and multipliers; I want to make it VERY fun to get money in this game)

Check out these two new videos:…
http:// .com/watch?v= Pj0AUqxaSfo <-- need to copy and paste, and remove the spaces, otherwise it will get turned into an emoticon!
I finally got the basic buddy physics in the game! (video:…)

Basically a lot of trial and error and manual tweaking to get it to work. Next step is to start working on the actual behaviors (walk, jump, grab, throw, etc) and eventually the high level AI.…
First, a new video:…

Now some context: I have implemented some "control templates" as I am calling them, so that it is very easy for me and other script designers to get functionality like throwing objects or attaching object silhouettes to the mouse (both of which seen in this video). This allows for very precise yet still very easy and fun control over object creation and placement. It also means that all throwable objects, for example, will be thrown the same way (i.e. click and drag to set trajectory, let go to create object) so players will get the hang of things very easy and controls will be consistent from item to item (including user created items, if they choose to use these templates).

Basically, what these templates are are ShockScript functions (well, more specifically, constructors) that take your own defined functions as arguments and automatically implement the necessary player controls and associated graphics. For example, an example script that uses the template "Throw":


(set makeCircle (func x y xv yv (exec
  (set cir (new SimpleCircle x y 20))
  (cir.setXYVel xv yv)

/* (comment) so now we have defined a function "makeCircle" that takes four parameters: the x and y position of the object to be made, and the x and y velocity of it. This is perfect because the Throw template expects to be given a function with these four parameters. So, let's invoke the template */

(new templates.Throw makeCircle 4)

/* (comment) As you can see, we have instantiated the Throw template (must be instantiated and not just called because it needs to have some persistent variables, and also so we can have a reference to it if we want so that we can modify it using its methods). We fed it our makeCircle function, which will be called at the appropriate time (i.e. after the user has clicked and dragged and released). At that time our SimpleCircle will be created with the appropriate trajectory, with no extra effort on our part. And all of the trajectory graphics will be taken care of too. The '4' parameter is just a multiplier for the trajectory--basically how "sensitive" the function is to how far you move the mouse from the initial point. */

And that's it. With just one line all the code for throwing an object (just like the bowling balls in the video) is taken care of, and any function that accepts an x and y position, and an x and y velocity as parameters, can be fitted to this throw behavior.

Right now I have the templates 'Throw', 'Drop', 'Stream' (for flamethrowers and the like), and 'AttachToMouse'. There will surely be more later. This will make it easy for myself and script writers to invoke standardized, consistent behavior for their created items (if they choose to, of course--using these templates is by no means mandatory). And it will ensure that players have a consistent control experience across items.

P.S.: anyone know how to get code blocks in these journals? That code formatting above is very ugly and I'd like to be able to include whitespace and have a fixed width font. Any help much appreciated!
Warning, technical discussion ahead :)

Well after reimplementing all the code that allows for the more advanced features of ShockScript (prototype inheritance, etc) it turns out the speedup is closer to 7x. Also besides strictly typing more variables, another change that brought about this speedup was instantiating more of the necessary objects at ShockScript compile-time, rather than run time. Right now when you run a ShockScript script, the ONLY object that is created at run time (unless your SS code itself is creating objects for your use) is an array for each nested function which contains the evaluated arguments for that function. And even that I will be looking to instantiate at compile time for hopefully another small speedup.

Next on my list of things to do is change the item tree to allow for an icon view, kind of like say the tools selector in Photoshop, which will be an alternative to the current tree/list text-only view.
Well, I once again got into the guts of ShockScript and made some strictly under-the-hood changes. Mostly I greatly reduced the usage of untyped variables (which are slower than strictly typed ones).

The result is a 10x speedup, at least in some cases (could be higher or lower in others, I have not done extensive benchmarking yet). Specifically a dumb loop that iterated 20,000 times and set a variable on each iteration took about 1.1 seconds on the pre-optimization ShockScript; it now takes about 0.12 seconds.

I still have some glitches to work out (not all of my ShockScript code compiles without errors yet) but simple examples work fine with a great speedup.
I'll reply with the URL when I do it. Basically that just means I'm posting a topic on that lets users ask me questions if they want to. I'm using this journal entry to verify my identity on that site.…

Check it out!

Making lots of progress lately, not all of which can even be seen in that video. :)
Well, haven't worked on IB2 too much lately (school and job search have been taking up my time), but believe me, I have not abandoned it. Especially now that Adobe is showing they are serious about mobile devices. I really want to release the full version of IB2 then reuse as much of the code as possible for a mobile version (adding in multitouch aspects, but probably scaling back graphical flourishes and limiting on screen objects). It looks like this could be a reality. Plus I intend to use this engine on other projects as well (already it is extremely versatile, and will only become more so as I keep working on it). Platformers, action games, etc are all possibilities. So, again, not abandoned by a long shot.

In the past couple of days I have started to glue the physics code to the scripting engine, so that you can add and modify physics objects through ShockScript code. This is really the backbone of the engine, so I will be making sure that this aspect is perfected. Demo? Hopefully soon.
Well, I completely rewrote the ShockScript interpreter to be faster (~30% faster in most cases, due to the use of linked lists to store commands rather than vectors or arrays) and way more powerful.

Full object referencing is possible, so you can do stuff like this:

(set x (new Object))
(set x.prop 10)
(trace x.prop) //outputs 10

Also, as you can see, you use the 'new' keyword to create a new object of whatever type (just a generic 'Object' in this case).

You can even do this, which is functionally the same as above:

(set ["x"] (new [+ "Obj" "ect"]))
(set var "op")
(set x[+ "pr" var] 10)
(trace ["x"].prop) //outputs 10

Within a reference, anything in brackets gets evaluated. This is also used for array access and manipulation, e.g.

(set array (new Array 1 2 3))
(trace array[0]) //outputs 1
(trace array[1]) //outputs 2
(set array[2] 99)
(trace array[2]) //outputs 99

Also, EVERY SINGLE hardcoded function, object, etc that is in the game code, can be accessed by ShockScript. Basically there is a 'root' object that references the main, top level game class. So e.g. typing (root.ui.notify "Hello world") will popup a notification saying "Hello world", using the same notification function that I use when hard-coding. 'root' is the main game class (analogous to the root timeline from old Flash days), 'ui' is the object that represents the game UI, and 'notify' is a function of that object which displays text at the bottom of the screen.

This is great functionality for me when coding the game and also script creators, because it means that EVERY function I write for the game is automatically included in ShockScript, with NO extra effort on my part. The default ActionScript, AsWing and motor2 libraries (among other smaller ones) will also all be fully accessible, meaning thousands and thousands of hardcoded functions will be at your fingertips (so far AsWing is already in, so I know that adding the other ones will be a simple task).

But, you might be wondering, won't it be impossible for a script creator to keep track of all those functions? How will he/she know what is even available? The solution: enhanced syntax highlighting and a fully-featured autocomplete system. This means that if you, say, type 'root.', a list will popup below the cursor listing EVERY function, object etc. that is available from the 'root' object. Same thing with 'root.ui.', etc. (Or even hit escape on blank text and a list will come up with all top level items, of which 'root' will be one.) Then hit the up and down arrows to scroll through, and an info box will come up on the side listing what it is and any relevant information. Basic info such as function parameter and return types is automatically detected by the system with no additional effort on my part, but I can also add more detailed descriptions for selected items if I think it is important. Then just hit enter to add the item to the script. Partial autocomplete is also supported, meaning if you type 'root.s' only the items starting with 's' will be shown, making navigation easier.

And when you create an instance of a class (e.g. 'set x (new Box)'), you can "type" the variable so that autocomplete will know what it is and display the associated methods and properties when needed. So in this example you can type 'set x:Box (new Box)'. The ':Box' part doesn't actually get evaluated (it actually gets thrown away during compilation), but it tells the autocomplete system that 'x' is an instance of the class 'Box'. So, once that is done, typing 'x.' anywhere in the code will bring up all the methods and properties of the 'Box' type in the autocomplete box, just as in any standard IDE. Note that static typing is not actually supported at runtime--"typing" a variable in this way only allows for better autocomplete support.

All of this stuff is done and working in the current build of the game, so they aren't just ideas to implement. Unfortunately (but in the long term, fortunately) the physics library that I am using, motor2, is about to have a major update (although no release date set), so I am putting off working on anything physics related (which of course is all the really fun stuff :)) until that gets released. The good news is I've seen a demo of the new motor2 and it is FAST. It will easily be the fastest Actionscript physics library out there. But that need to wait is what sort of prompted me to reexamine the shockscript stuff. Now I am moving on to refactoring and expanding other parts of the UI (and making the code structure more streamlined, now that I know all script creators will have access to it), until the new version of motor2 is released.
Check it out...…
Well, no big updates (I took a little break from IB2 for a bit), but I did just get proper scoping and user functions in the new version of ShockScript.

Now you can do stuff like this (a simple Fahrenheit to Celsius converter function):

(def (FtoC input) (* (- input 32) (/ 5 9)))
(trace (FtoC 72))

Some explanation...

--"exec" is always the root command; it just tells the ShockScript engine to execute all of it's arguments (i.e. all the lines that follow it). (Basically all ShockScript code is written as a "tree", with parentheses delineating the "branches"--so you will always need a "root" command from which to start executing, which is "exec" in this case.

--"def" is the built-in function used to define user created functions (analogous to the "function" keyword in ActionScript). I chose the name "def" because Python uses it, and it seemed to fit here better than "function" or something similar. I think it reinforces the idea that you are _defining_ a new function which will be permanently available, not just running a one-off command.

So, after writing "def", you enter, enclosed in parentheses, the name of the new function followed by the names of its arguments. Then you write (also enclosed in parentheses) the actual ShockScript code that the function executes. Within that ShockScript code you can reference the arguments, just as in any other programing language.

Variable scope rules are in effect, so for example setting a variable within a function will do so in local scope (only accessible by that function) unless you use the set_global method (which obviously sets the variable in global scope). Referencing a variable will by default cause the engine to first check local scope, then the next scope up (if you have called one user function from within another), and so on, until the top-level "global" scope is reached. Arguments passed to a function will naturally be in local scope and only available within that function.

--The "trace" function is built in, and just displays its input on the Flash debugger console if you are running in the debug player. So, in this case, the FtoC function we just created takes 72 and converts it to Celsius, and passes on that number (which turns out to be approximately 22.2) to the trace function, thus outputting it to the screen.

So, nothing too major, but I think it's pretty nifty and it should hopefully make designing sweet weapons and mods for IB2 a little easier and more efficient.
Just signed up for a Facebook "fan" page for Interactive Buddy. Become a fan!…

There are some pics I posted of the physics in action that you can't see anywhere else at the moment (not that they are too groundbreaking or anything). I plan to post video demos to that page as well.
Well, now that the basic script uploading functionality is in, I am moving on. (I still need to build the whole "script marketplace"--both UI and server code, but I'll save it for later.)

I am finally getting to the fun stuff--getting the physics and entity system working! (By "entity" I mean anything at all in the gameworld--examples: a box, a buddy, a trigger that causes a door to open when a buddy is near, a particle generator, etc etc etc) And, I am trying to ensure that it will be easy to create custom entities using scripting, or to customize existing entities extensively just by using the UI without scripting.

I wish I could say a demo is forthcoming, but now that I'm really getting to the meat of the game, I think I will be releasing videos instead of playable demos to showcase the features. This is so that people won't be able to submit unfinished versions of the game to game hosting sites.

So, here's a tally of what to expect regarding the entity system:
--Entities are easy to add--just select say "box" from the game tree and click in the world window to toss one in. (Just like in IB1)
--Entity properties can be defined in the properties window before they are added. For example the size of the box can be tweaked from that window before you click in the world window. Or perhaps its density. Basically anything you can script can be included in the properties UI--so users will be able to create custom properties UIs for all of their custom entities as well.
--Entities already in the gameworld can be selected, and their properties can then be changed in real time. Again, script writers can (if they choose) code in this second properties UI to enable this functionality.
--Entities can by physical and concrete (like a box, a baseball, etc), visual but not physical (like a baseball generator that shoots baseballs into the air like a fountain), or completely abstract (like a script that runs silently in the background, computing the digits of pi, and then outputs that to the screen once it gets to the thousandth one). The more concrete ones might have been considered "weapons" in the first game, while the more abstract ones would have been considered "modes". IB2 considers all of these to be types of "entities" and is able to keep track of all of them automatically (including their interactions with other entities) in a unified manner.

I'm sure I could talk more about this, but for now I'll get back to work on it so that I can get a video out there soon.