Shop Forum More Submit  Join Login
Well the title says it all. I've got a version of the IB2 UI running with Google App Engine, so that you can create a username and password in the game and save your scripts to Google's servers. Supposedly App Engine scales very well (in addition to being reasonably priced), which is the reason I am likely going to go with this platform. I'm still going to have to optimize the number of requests that are made to the best of my ability, but that will be a work in process and I'm already happy with how this is running.

Demo soon!

Also, expect more updates and more work on my part on IB2, since I'm back from school for the summer and have more time.
Well I have been working on IB2 a bit more lately.

Another new feature of this version? An online database of user created weapons/modes/other scripts that is accessible directly from the game, regardless of where the swf is hosted.

I already have some of this working--specifically I already wrote the actionscript functions to interface with this database and the corresponding php code and mysql tables on my host ( great, inexpensive web host that doesn't overcharge). You are also able to create a username/password directly from the game UI in the version I have on my computer right now. I still have to code the UI parts to handle saving and retrieving remote scripts, however.

I am thinking of letting users assign ratings to each other's scripts, so that it will be easy to find highly ranked and therefore quality scripts right through the game--no need to go to another website or anything.

I just need to implement hash checking so that redundant data is never downloaded, and then zlib compression to that what needs to be downloaded is in compressed form and then uncompressed by the flash player as needed. Since nearlyfreespeech charges 1 cent per 10mb transferred, I want to make sure I get the absolute most bang for my buck, and make sure that including this feature is economical. Since scripts are just text though, I don't think this should be a problem.

Perhaps I will include some kind of forum right in the game that people can post to using the username they also created in the game to trade script ideas or discuss other game topics.

I realize these ideas are pretty unconventional for a flash game, but I really am hoping to encourage the community aspect in ways that haven't been done before. Hopefully it will all pan out!

If you have any ideas regarding online stuff, let me know! Just be aware that I can't do anything "persistent", such as having one user control one buddy and another user control another buddy and have them fight in real time. It has to be stuff that I can do with periodic requests to an online database, not a continuous connection to a game server (which I do not have).

Also, I will likely be releasing a demo soon so that you can try out the online database features for yourself.
i have released a demo of the interactive buddy 2 user interface...…

some notes:

--in the final version all shockscript functions will be documented in that empty tab you see in the editor, but for now i am focusing on other things so i hope you understand. i realize this means that it will be very difficult for anyone to really get the hang of shockscript ui scripting at this time. again, in the final version everything will be laid out. still i invite you to mess around with the shockscript (easiest way: copy paste the "protected" items' shockscript into a new item and change it around).

--there are in fact many shockscript ui functions that i have implemented but not used in the samples, like scrollbars, color pickers, menubars, ability to spawn new windows, etc. plus i might actually implement some more as the game progresses.

--i couldn't decide whether the game should reside in a window or as the "background" so i decided to enable both options. just try maximizing the game window :)

--the tree doesn't yet save your created items, but of course in the final game it will.

--i'm not sure how buying items will work. i'm deciding whether all items should always be displayed in the tree but with the unbought (and therefore inaccessible) items grayed out, or if they should only show up in the tree after you've bought them.

--please let me know if there are any glitches! especially in the script highlighting, as there were some bugs earlier but i think i squashed most of them.

--if you make any cool ui scripts, post them! although i realize that the functions aren't documented yet and functionality is very limited at this early stage, so this will be hard
well, thanks to Adobe Alchemy, a project which allows C/C++ code to be converted over to a format the Flash player will recognize, together with the open source project to convert the Lua scripting language using Alchemy, Lua scripting is now supported in interactive buddy 2. my scripting engine (shockscript) is still completely supported, but now you can also evaluate Lua code from within it. e.g. you can write

(set env (lua_environment))
(lua_exec env "...lua code here blah blah blah...")

you can initialize and/or close as many lua environments (or "states" as they are also called) as you would like, and run whatever code you would want to run using the lua_exec function. i have not yet done any speed tests, but it should run pretty damn fast at least compared to shockscript. thus for "mission-critical" areas of a script, perhaps where there is a lot of looping, it might be a good idea to accomplish this using lua within shockscript rather than straight shockscript (in the same way that programmers often embed assembly code within C++ projects for important, speed critical areas). it should continue to get faster as Alchemy and the Lua porting project continue to evolve (i will certainly make sure the latest version is included).

importantly, within a Lua script you can make Actionscript function calls and instantiate new classes, etc. right now the code provided by the porting project is a little clunky, but still fully functional (and they said they aim to provide a better interface soon). for example, you can use the lua function,as3FunctionName,...args) to call as3 functions from within Lua.

so what does all this mean? it means that the weapons and modes that people (and I) make can leverage not just shockscript, but the full power and speed of the Lua scripting language (which could conceivably end up being faster than actionscript 3 itself, at least for some operations).

it also means that as other open source c/c++ projects are ported over to flash using alchemy, I will include them if they are relevant to the game. for example, although i am now using the AS3 version of Box2D, there is currently a project underway to convert the C++ version directly for flash player execution using Alchemy. this could enable (perhaps massive) speed increases for the physics. hundreds and hundreds of onscreen, interacting objects (rather than merely a hundred or so) could be simulated easily if this project lives up to its promise. likewise as ports of other scripting languages (like Python perhaps) are created, i will likely include them as well if they are not too large in filesize (the lua scripting adds about 400kb, which i consider acceptable--we'll see how other projects turn out).

I expect a demo of the new ui and scripting capabilities to be ready within the week.

After that I am returning to school, so the project will likely be put on hold for awhile.
well i have completely scrapped my work on the interface so far in order to implement the open source ASWing library in place of the (also open source) Flare library and the simplistic pane system i had come up with.

actually, that statement is a bit too drastic. the two frame (i'm calling the "panes" frames now) design is still the main idea. that is, one frame is a tree that you select items from, and the second frame shows the properties/controls for that item. however, they aren't merely panes now, since you can actually resize them, move them around, or completely hide them thanks to the versatility of the ASWing library. you'll understand more completely when i release the next demo.

it also looks much more professional than my dull gray colored panes, so i think you will appreciate the visual upgrade as well.

and because the ASWing library is so fully-featured (it seriously makes coding an arbitrarily complex user interface a breeze), development time should be greatly reduced, and more time can be spent on making sure the user experience is as effortless as possible.

and of course the paradigm is still that every item is built off of the scripting engine, so that users can script their own items easily.

so all in all it is very good news that i discovered ASWing this early on and will be able to make use of it fully.
well, the aforementioned tree selector for items, modes, options, etc (basically everything, you will understand when you finally play the game) is in place. it is fully integrated into the scripting engine, so users will be able to add their own scripted weapons (or whatever--modes, gadgets, anything that can be scripted) to it, and they will appear right alongside the default weapons (or in different folders, depending on where they choose to put them). each item will be entirely definable in a single script, including its own UI (with sliders, checkboxes, etc), which should make it incredibly easy to share fully-featured user created items with people online. it's simply a matter of copying and pasting a shockscript script.

the tree itself utilizes the "flare" open source visualization library for flash, so luckily i didn't have to code a tree component all by myself. as a result it is a breeze to add items to it, and it looks very clear and professional (in my opinion). plus when you expand/contract branches, there is a nice folding open/close animation that i would have never have been able to code myself (or that i would have been reluctant to take the time to do, anyway).

a demo should be coming soon, assuming i run into no major bugs.
well, it turns out i have decided to work more on the UI of the game, and leave the buddy design until later. sounds like most of you guys and girls would prefer that i stick close to the original buddy design with some minor improvements. i'm thinking the same thing. but we'll see, that's probably going to be a long way off (contrary to what i wrote in my last journal.. i guess that's just how independent game development goes).

anyway, regarding the user interface: i'm thinking it's going to be like this: two "panes" or "columns" (whatever you want to call them, i hope you know what i mean) on the left, and the main play area on the right.

the first pane will contain a folder tree just like you'd see in windows explorer or something where the items, modes, and all the game options are laid out in a tree. (naturally you can expand and contract each folder, as well as add your own folders/move stuff around--although for default items maybe i shouldn't allow modification... we'll see).

[side note: if anyone knows of any good free, opensource actionscript 3 tree components that i could use, i would much appreciate a link... something like yahoo's astra would be excellent, but that particular implementation won't work for me because it extends api's only available to flex builder, while i'm just using the free flex sdk with flashdevelop (also free) to develop the game. for the same reason i can't just use the built in tree components in either flash cs4 or flex builder (assuming there are ones), as i don't own the products. otherwise i'll have to build a tree display system myself, which will take extra time]

when you select an item in this tree, the second pane will show elements related to this item. for example, in the "game settings" folder, if you select "physics options" it will have a bunch of options for the physics. if you select a weapon, such as say "hose", the second pane will have options for that item, such as sliders for strength, volume of water, etc. (different for every item of course).

then of course the main game area will be to the right and should take up about 2/3 of the actual width of the whole game (whereas each pane is about 1/6 each).

this is different from the original game which was all menu driven obviously. but since i plan to have tons tons tons more items and modes (plus user creatable items and modes) i think such a system is a necessity. and since i'm making the game widescreen with bigger dimensions there won't actually be any less game area space than the original, which is important because i plan to have both panes visible at all times.

do you think that you (and people in general) would like such a setup? thanks for all of your comments!!
right now i'm trying to come up with what the actual buddies will look like and how they will function. specifically i'm trying to decide whether i should make them look and move like the original buddy in ib1 (composed of circles for body, head, hands, and feet that sort of float near each other) or do something new. some possible ideas...

--more realistic rag doll type with attached limbs (could be too complicated)
--stick figures (could be too simplistic)


actually that's all i could come up with. feedback encouraged!
i'm working now on the code that will glue the physics engine to the actual IB2 game logic. specifically at the moment i'm working on code that will allow the game to keep track of all the various entities that will populate the game, like boxes, balls, forces, pulleys, joints, etc. and allow these entities to be acted upon by user created scripts. this will allow the user to do things like:

(set box1 (createBox 1.0 1.0))
(set box2 (createBox -1.0 1.0))
(set joint (createDistanceJoint box1 box2 2.0))

which will create two boxes in the gameworld and constrain them to always be 2.0 units away from each other.

it's really important that everything works with shockscript because, as i mentioned earlier, everything in the game ui will be built using shockscript.

when you, for example, pick the item "Add Box" and click to place one, what will really be going on behind the scenes will be a shockscript function call such as "(createBox xmouse ymouse)" [the real createBox will take more parameters, but you get the idea]. so anything you can ever do in the default ui can be done and extended by your own shockscript. and indeed i plan to allow the user to actually code his own ui elements with scripting in order to facilitate custom weapons, modes, etc (more on that later).
the new flash 10 player has the ability to load what are essentially custom shaders (that unfortunately run on the cpu at least for this version) for image processing effects. these are known as pixel bender effects. i definitely plan to use this feature for many ib2 effects, although i'm not sure which ones yet. probably things like...

--warping effects (e.g. for use with gravity vortex)
--motion blurring

i'm really hoping flash 11 makes heavier use of the gpu, especially for pixel bender effects (which already work with the gpu for programs like after effects and photoshop, just not flash yet).
this journal concerns the details of the scripting engine for interactive buddy 2. it gets kind of technical so

well the new (and definitive) version of shockscript is really looking great. i'm really surprised that i was able to get it working so well in such a short time. the reason is probably that the syntax is so darn simple. essentially everything in the language boils down to this:

(function arg1 arg2 arg3...)

where the arguments can themselves be functions that are evaluated in a recursive manner. e.g.:

(* (+ 2 2) (+ 1 3))

evaluates to 16.

This might seem convoluted, but i find it very powerful in its simplicity. Because it's so simple, i am able to include any conceivable data type with ease.

for example, arrays work like this.

(set x (array 3 4 5))

The 'set' functions assigns the array [3,4,5] to the variable 'x'. Now let's return a value from the array.

(get_element x 1)

returns '4' since '4' is in the '1' position of the array stored in 'x'. the following code:

(set_element x 1 8)

turns that 4 into an 8.

here's one more (more complicated) example. i have used line breaks instead of spaces to separate each command, although technically each line is actually an argument of the exec_timer function (which just evaluates all of its arguments and returns the time in milliseconds taken to do so).

(set x (array 0 1))
(set i 2)
(loop 1000 (exec (set_element x i (+ (get_element x (- i 1)) (get_element x (- i 2))  )) (set i (+ i 1)) ))

this sets each element of the array 'x' to the corresponding fibonacci number. i.e. 0,1,1,2,3,5,8,13,21,... up to the thousandth number. it takes about 250 milliseconds to evaluate this on my computer. that's not bad considering that the final product shouldn't have too much shockscript running _every_ frame.

i should have a demo out soon, as soon as i program some more built in functions.

so the framework for shockscript is pretty much done, with one major exception: user definable functions. that's coming, though.
well i am in the process of creating shockscript for actionscript 3, which actually will probably be quite different from the scripting engine for interactive buddy 1. more Lisp like, i think. it should also be way way faster while retaining the same functionality as the old version (although the syntax is different), since the structure is simpler and AS3 is way way faster than AS2. i'll get a demo out for shockscript in probably a few days.
well i've been messing with the box2d physics engine for flash and so far so good! whereas the original interactive buddy only allowed ~20 circular objects before slowdown was likely, this new engine should reliably allow about ten times that at least, and with much greater accuracy. i still have to test it for polygons though.

the really good news is that having this physics engine already in place will let me focus on the more unconventional features i want to add to the game. with ib1 i remember spending lots and lots of time getting the physics to work just right (and even then i no doubt only succeeded to a very limited degree). now i don't have to worry about that at all!
However, the timeframe for development is years, not months. I really want to expand on the first one in drastic ways that will require a complete rewrite of all code. But I don't want to spend a large amount of my time on this project, just a little bit each day. So I hope you will understand that while it is coming, it will take awhile! The main things I want to implement are:

--better physics with way more objects on screen and more possible object types--I plan to use Box2D or similar physics library instead of coding it myself. i could never do as good of a job as what a dedicated physics engine could do.
--vastly improved ai such that using the word 'cognition' to describe it would not be such a stretch (e.g. complex conditioned responses, coordinated social behavior [would require multiple buddies :) ], and such). i'm interested in neural networks so maybe they would have a role--not sure how feasible that would be though. certainly somehow i have to create a system whereby behavior leading to certain predefined instincts (which perhaps could be user defined) being satisfied is reinforced, just like in real life.
--completely interactive environment--users define every object and force in the gameworld in a very customizable way. can add basic shapes, add constraints to them, and define their behavior through some sort of simple scripting engine. (e.g. add a ball, use a constraint to make it hang from the ceiling, and give it a behavior "attract to buddy; if contact buddy then shock buddy")

Those are the three big things. and since it will be coded in AS3 everything should be much faster too. Definitely let me know what you think! And i want to hear your ideas too!!

btw i plan to release plenty of "tech demos" along the way to show you the features i add. however, at no point will i ever release a beta version of the entire game with all the features in place, because i don't want any sites distributing an unfinished version of my game. so maybe for example i will release one demo showing the object physics, another one with a buddy but no objects available, another one showing how the scripting engine works, etc. but never one with everything in place.
Well so far I have added comments to about 2000 lines of code, which means I still have 6000 to go. No sweat--expect it to be done and released within the next two weeks.

Note: if you are interested in doing anything with the source code, including merely understanding it, you are definitely going to appreciate the comments, because otherwise the code is long, convoluted, and confusing. But with the comments it's not too bad, I promise. :) At least I hope it's not too bad, because I really want people to make mods out of this, or at least use ShockScript in their Flashes.
Well I am 100% committed to releasing the source of IB before I leave in a few weeks, I just need to comment it a bit to make it somewhat understandable. And more importantly, I need a host. Any ideas?
Expect it to be released sometime in July, maybe...
For the latest, greatest version of the Buddy, go to its second home on!…

And if you've already played it enough, at least vote please! And leave a review if you have time!

And thanks again for all of your comments on this submission here on DA, I appreciate them more than you can imagine.
For the past few months, I have been adding small things to DA Buddy, like more Items and Skins. Then I added a new level of user control by creating the scripting engine and making it accessible. The next step is to take user control even further by adding new (and more user friendly) abilities. Things I would like to add...

- A physical constraint system so that objects can be constrained to areas. IE: Ropes, platforms, etc. These will be able to be set by the user through some kind of interface, or through the scripting engine.
- Creation of objects with dynamic attributes. For example one might create a baseball that weighs 10 kg, lights on fire whenever it hits an object above a certain speed, and explodes on contact with the buddy. The actions the object performs (explode for example) when an event (such as touching the buddy) occurs will be able to be selected from a group of presets that have adjustable properties (for example a 'force' variable for the explosion) OR created entirely from scratch using the scripting engine.
- Ability to save the 'stage' with all item positions and properties intact. This one is a maybe though, since a well written script in the scripting engine can accomplish the same thing.

As always, suggestions and comments of any kind are welcome! The latest version can be found here:…

Note that I am updating it often, usually at least once per week, so it is worth bookmarking! Also, when I get a final version that I am happy with, I plan to release it to more websites. First on that list is, so if you frequent that website, be on the lookout!