Shop Forum More Submit  Join Login
Well, I have implemented the basic buddy physics into the iPhone/Android/etc version of Interactive Buddy. Basically by "basic" I mean the essential ragdoll behavior--i.e. how the buddy's body looks and reacts when he is unconscious.

And, it actually did translate perfectly from ActionScript! The body moves and reacts exactly as in Interactive Buddy 2! In theory this is unsurprising, since I basically coded the C++ line-by-line from the ActionScript. However, I have enough programming experience to know that unforeseen bugs and unexpected behavior often crops up when you least expect it, so the fact that this didn't happen is very encouraging.

Overall, I have to say I like C++ a lot. Once you get used to managing your own memory, it really is much like any other Object Oriented language. I really like the template system too--it made implementing a linked list very easy. And, naturally, it's super fast, so speed is automatically not a concern, especially since Interactive Buddy is a relatively non-intensive game (only six objects for each of his limbs/body, after all).

So, progress is great! Can't wait to get his behavior implemented too.
Interactive Buddy on mobile devices. (That's the answer to the question in the title.)

I have already started working on the basic engine behind the next generation (v3 if you will) of Interactive Buddy. I am writing it in C++ using the AirplaySDK framework, which allows release on iPhone, iPad, Android, WinMo7, and many other devices.

I am planning on copying the buddy physics pretty much exactly from the Flash version. (The reason is that the buddy physics are pretty damn good on IB2--you will see when I release. :) ) I am using the Box2D C++ version so everything is very familiar on that front, but it will take a while to rewrite the physics in C++ (even though as I said it will pretty much be line for line the same, just in a different programming language).

The game engine itself will be far more limited than the IB2 engine for Flash. No circuits, no user scripting, probably less complicated items without adjustable properties, etc. Instead, I want to focus all my efforts on getting a few very good, very fun multitouch abilities (Fist, Grab, Explode, etc). I also want the Buddy's behavior and reactions to be a central focus.

To that end, conversations will be a big part of the game. In IB2, conversations are going to play a small role--occasionally the buddy will ask a question and the player can click on his or her response, and the buddy will respond appropriately. But in IB Mobile, conversations will be complex, and the buddy will remember the player's responses and use that information to guide future conversations. To that end I plan to research and implement a good conversation "engine", similar to what lots of RPG games have. The engine itself will be in Lua scripting, which runs on top of my C++. (I already have Lua working in the project in fact.) That way I can make it quite complex without worrying about annoying C++ compilation errors and such.

The reason for this focus is that I really want the buddy to form an emotional "bond" with its owner. Since he will be with you wherever you go (assuming you carry your phone of course), this is all the more important. I feel that other games have not fully explored this idea, so I can really deliver a unique and compelling experience that users just haven't seen before.

Over the past few days I have devoted most of my efforts toward the initial coding of this C++ engine (despite the outline of my last journal entry :) ). This is also the first time I've coded anything significant in C++. I actually like it, and haven't had too many problems so far. (Good thing, since my upcoming job will involve lots of C++.)

So, wou may be wondering, is this going to delay IB2? Definitely not.

The truth is IB2 could actually be released today and it would be fine. The essential items are already in there, the buddy's basic behavior is already done, etc. Basically, it has already achieved feature parity with IB1 (with the exception of skins, which I may or may not implement in time for release). And indeed, there are many great _new_ features, such as a vastly improved physics engine, more interesting and varied items (IMO), a full circuit system, ability to save and share your current scene, ability to expand the stage beyond the "screen-box" of the original, etc.

Of course I do intend to spend a good portion of the next two months cramming in great new items to make it even better :) But I wanted my readers to know that I am already in the building stages of the next step, which is Interactive Buddy on mobile devices!
Well the AI system is basically done. I still have individual behaviors that I have to code in (especially interesting "idle" behaviors, including more dynamic, interactive conversations with the player), but the buddy already responds realistically to a whole bunch of situations (getting hit, on fire, trapped, etc).

I also just added a "Tear Gas Canister" item (which causes the buddy to get dizzy and pass out if he is near it). I have plans to add balloons, an air horn, a spring joint (for which the math part is already coded), and bullets/guns by the end of this week.

I am thinking the bullets will actually be pretty easy since Box2D already supports a continuous collision mode, so that superfast objects do not "pass over" thin objects. I also already have a collision callback system in place, so detecting when a bullet hits an object and notifying both the bullet and the object of that fact will be simple and easy.

Balloons, in theory, should be easy to add. But I have a feeling getting them to pop at the right times (in order to look realistic) will take some work. I also don't have a good rope system implemented, so attaching the balloons to objects (causing them to float away if they are light enough!) will probably have to be done with the basic joint types (distance, revolute, weld, or the soon-to-be-added spring joints). It seems there is no straightforward way to create a rope in Box2D without being hacky and unstable.

The air horn will be able to be blown near the buddy's ears to annoy him. :devil: I really need to add more "nice" items. (I am thinking of adding a "hug" item but I need to figure out how it will work.)
Well, the buddy physics are pretty much done, except for maybe some minor tweaking which I will apply as needed. They really do look great--all the motion is very fluid, and interacting with the buddy using items like the fist just feels so natural. It is also very stable (limbs never react crazily under unusual pressure or anything), and the buddy is very good at getting up under his own power if he gets flipped over.

So now, I need to create the AI for the buddy. Already I have the buddy's "sense" and "response" system set up. By that I mean, the buddy AI code gets fed a set of senses--so far, boolean values such as whether there is ground to his right or left, or whether he is upright, etc. The AI code will then interpret those senses, and come up with a set of responses--e.g. "run right", "jump", or say something to the player, etc.

In this way, the "inputs" and "outputs" are well defined and organized and I can control the amount of information the buddy has about his world.

To implement the actual decision making engine, I am thinking I will use a finite state machine, specifically a hierarchical finite state machine. That structure is well suited to AI decision making and has been used in lots of other games with success.

The fantastic thing is, implementing the AI is pretty much the last big "project" I have to do for the game. After that, I'll just be adding more items and getting everything polished for release.
Well it is about a month since I made the commitment to get Lucid Dreams done within 30 days. The progress has been excellent, with roughly half of the actual content (the levels and story) completely done. But that's still only half.

So, I am putting that project on the back-burner for now and focusing back on my "bread and butter", Interactive Buddy. I am absolutely committed to getting it out by Christmas (in large part because my job starts shortly thereafter).

Yesterday I completely rewrote the buddy physics, which are much less hacky. Specifically, instead of an amalgamation of custom physics behavior code that gets run each frame outside of the box2d physics engine, the body physics are now entirely just box2d joints. (The only thing I simulate myself is a set of spring joints that I implemented since box2d doesn't have them out of the box.)

As a result, the buddy now seems to be completely stable under any circumstances (e.g. the buddy doesn't bizarrely float away sometimes as it did before). Also, turning on slow motion does not change the behavior of the buddy physics anymore (aside from slowing them down) since they are no longer my ugly "hacks" that don't play nice with varied step sizes. And, perhaps most importantly, the new physics just look and react more fluidly than the old version.

I should have more regular journal updates now, since I know longer have to worry about giving away the story as I did when working on the levels to Lucid Dreams.
Well I have now been working on the actual content of Lucid Dreams (levels, graphics, etc). The engine is quite mature at this point, and while I will continue to work on that low level stuff as I need to, it is definitely at the point where I am comfortable really just focusing on the content of the game. That still includes some programming related stuff of course, especially since the ability to embed custom scripts within levels is a major part of the engine.

Check out the video below which highlights some of the engine's features, including how easy it is to build a level (even one that includes some scripting)!…
Well as predicted I have continued to make much promise on my platform game, Lucid Dreams.

One important thing is that the displaying of all game objects is optimized. Now, whenever any object is out of camera view, it is not drawn to screen (sprite.visible is set to false). You would think Flash would be able to do this itself, and indeed it does do it to some extent I think (when the object is FAR out of view), but manually coding this logic does indeed make the game significantly faster. This just involves comparing the bounding boxes of each object to that of the camera and determining whether they intersect.

Also, the ability to embed custom level logic (using ShockScript) rather than just "pre-made" items is allowing me to make the levels much more interactive and even, at times, cinematic. You'll see what I mean when you play the game I suppose. I have scrapped all the old level designs and am starting anew, with an eye toward using the custom embedded scripts to make things far more varied and interesting.

Also, I have begun conceptualizing the level designs on paper before starting work in the actual editor. I find that I am able to really flesh out cool designs more easily by doing this. It seems to let my mind come up with good ideas without worrying too much about how they will actually be implemented.

Here's a screenshot from an early level --
Well, just a little update on my life as it relates to my Flash projects--I did graduate college this past spring, and spent the summer mostly languishing in unemployment while looking for work. I spent some time on the Object World engine but not as much as I could if I were completely focused on it.

However, jump ahead to today--I finally managed to land a job (in NYC no less!), BUT it doesn't start until after the new year. So, bottom line is I have about five months with pretty much nothing to do. (I am living with family until I move to the city later on.) Nothing except for work on my Flash stuff, that is. So for anyone continuing to follow my development, expect much more rapid progress during the next few months.

Specifically, I'd like to have Lucid Dreams DONE and RELEASED by this time next month, hopefully spend another month and a half working on another game for the new engine, and all the while continue to add features that will benefit Interactive Buddy 2 (since it is on the same engine) and get that DONE and RELEASED by the time I make the move.

Compared to my usual pace of development this is quite ambitious but hopefully it will work out!

In terms of the engine, a really important new feature (to advanced level designers anyway, which includes myself as I am designing the single player story mode entirely within the in-game level editor) is the ability to embed custom ShockScript code in an easy, intuitive way within any created level.

Basically you drop in a little "action bubble" into the level, then you can select it and edit the code it contains at any time. It can contain code that executes just once when the level is loaded, or on every frame (or, by defining listeners within the "just once" code, it can be executed in response to a variety of events). The bubble is easy to see and select when you are editing the level, but turns invisible when actually playing the level.

And besides custom script bubbles, I also put in custom script chips for the circuit system! Basically it's just like the custom script bubbles, except the game expects you to define a ShockScript function for the chip, which on every "tick" of the circuit, is given the chip's inputs as arguments, and is expected to return either its output value directly (if the chip has been set to have one output--this is user selectable) or an array containing all its outputs in order (if the chip has been set to have more than one output). How the function determines its outputs from its inputs is, obviously, up to the script writer!

Also, another important and related new feature is the ability to assign custom identifiers to any object in the gameworld. (You just select them using the "Set ID" item and type in the ID you want them to have.) Then, you can access and manipulate these items right from the scripts you create using the custom script bubbles and circuits described above. They have all sorts of member functions available; for example, if you assigned the ID "mine" to a proximity mine object on the stage, you could embed the ShockScript code " (mine.explode) " to have it blow up instantly. Using event listeners, or just some "if" statements, you could have it blow up in response to all sorts of game situations.

And, as a side note, when you are writing the code, the autocomplete is smart enough to provide you with all the object ID's on the stage currently (and also their member functions once you are done typing the chosen ID) so that you can see exactly what you've got and how you can manipulate it quickly and easily.

Probably, only the most advanced users will fully take advantage of these features. Possibly, no one will besides me. But even if that is the case, this is going to make level design SO much easier, and will enable the levels I make to be extremely interactive and unique without my needing to spend tons of time on them. So, all in all, I am extremely happy I finally got this stuff implemented!

Good things are on the horizon!
Well, the title of that puzzle/platformer I've been working on is most likely finalized: "Lucid Dreams".

Check out the beta version below, which contains the first few levels but no storyline interludes, which I'm saving for the final version.…

Let me know what you think, especially if you have any problems!
Well just played with the HTC Evo with Flash 10.1 on it today, now that the Android update is out. It seems that Object World, despite its complexity, runs the same on the phone as the desktop (just at a lower framerate, unfortunately). So it seems Adobe has done a great job porting Flash to mobile devices, after all (I was a bit skeptical initially).

I have been very busy with employment-related things over the past few weeks, so I haven't worked on the engine much, but I intend to do so soon. That's all for now!
Well I have actually been working on the platformer/IB2 game engine quite intensely recently, despite not having any journal or demo updates. Since I plan to use the engine for the puzzle/platformer first, I have been working on level designs and artwork especially. Here are some screenshots:

I am trying to make the levels as varied as possible, both in terms of gameplay and artwork. To that end, I plan to include a unique background/color scheme for each level in the game. The images above showcase some of the ones I have made already.

The basic gameplay is very simple--the player spawns and must collect the red coins strewn about the level (the yellow ones are optional and go toward unlocking extra stuff). Once they are collected, the level exit opens up and upon reaching it the level is complete. Of course, I am using the great versatility of the engine to implement creative and unique obstacles to the player as he/she tries to collect the coins and reach the exit.

I'm not sure if there will be a demo of this progress or not, but I wanted to let everyone know that I am in fact still hard at work on the game(s).
The next update to the Object World Beta is going to change the format in which scripts are saved (both internally via flash "cookies" and when you export scripts to a file). So, if you have any custom scripts that you would like to be saved, please copy-paste them into a text file or something, as they will likely not survive the update! I won't push the update until at least late next week though, at the very earliest.…

I just added the aforementioned save feature to the beta. Check it out! Feel free to post any scripts for any scenes you create, I'm sure people (including myself) would love to see them, especially if they are creative or unusual! (You might want to use Pastebin or something similar since they can get pretty long as more objects are added.)

Also, please let me know if there are any bugs with saving or anything else.
I haven't updated this journal in a while but I am still here!

Lately I haven't worked on IB2 too much since I have had other things to keep me busy, but just today I started to code a major new feature: allowing users to convert the current game-world into a script which they can then run whenever they want to automatically recreate the scene.

I hesitate to call this a bona fide "save" feature since I know it will never perfectly save the game state. There will inevitably be rounding errors, and not every object state or even every type of object will be saved (e.g. particles, especially ones that don't affect the physics, will likely not be saved).

But, already it is working great with basic game shapes. Currently Wall, Peg, Box, Circle, and Shape Drawer are supported (although properties like temperature and even velocity still have to be added).

Basically for each item type (Baseball, Mine, etc), I have to code the logic which spits out ShockScript code which, when run, recreates each individual object on the screen of that type. It's not too hard since the objects themselves were all created originally using ShockScript function calls when the user added them to the game-world, but it's still gonna take some time to get everything supported. So then when the user wants to use this conversion tool, essentially what happens is that each object in the world is queried and returns the ShockScript code that can recreate it.

This will make it possible for users to create very complicated worlds (using circuits, etc.) without needing to worry about everything being lost when they close the game. Obviously this is major new functionality which I think will allow the game to compete with titles such as Fantastic Contraption, IncrediBots, etc.

Also, I think I am also going to release some kind of puzzle game using this engine prior to the full release of IB2. Right now this just makes sense, since all the functionality is pretty much already there for this type of game. The buddy behavior, money system, etc. is what I still have to add, so I think I will hold off until I get this puzzler made and released. So the bad news is Interactive Buddy 2 is a bit further off. The good news is that a complete game using the Interactive Buddy 2 engine could be available very soon (just no buddies :( )

I think the script conversion tool will help me greatly when designing the individual puzzles (as will as players, since of course new puzzles will be able to be created by them as well!).
So, I'm OK with showing the user an advertisement when they navigate to DA. It's what I'll likely do with Interactive Buddy 2, after all.

The ad:

But what happens when I click "Continue to deviantART"?

I get sent here:

Not cool, deviantART, not cool at all.
These are the items I have recently added to the beta. Next up, attachments that output the x, y, rotation, velocity, temperature, etc. of the object they are attached to. After that is done I will probably start working on other more novice-friendly aspects--more weapons especially.…
Just implemented motors in IB2, take a look! This will be available in the beta version soon, along with other new stuff.…
The temporary title is pretty lame--"Object World", heh. But that was kind of the point, I don't want to draw too much attention to this beyond the group of people who have been following my progress on DeviantArt, Facebook, etc. Although I did post this as a regular deviation rather than scrap so a fair amount of people will probably still see. Link here:…

So enjoy and most definitely post comments/suggestions/whatever. Bonus points for funny screenshots, videos, or most especially new weapon scripts!
I'm starting to consider actually releasing a beta version of IB2 (despite saying before that there would never be one!). I tend to get a lot of motivation from feedback I receive from people (which I think makes sense especially given the nature of this project--very wide open and having lots of creative possibilities). And I feel like just releasing videos is limiting community involvement.

One thing that would be pretty certain though is that no beta version will ever include the actual buddies. This would be a test of the game engine and environment only. But probably every other item and feature would be OK (circuitry system, fire, water, shapes, just literally everything else including everything you've seen so far). I will likely brand it something other than "Interactive Buddy 2 Beta" also. Something more generic and less recognizable.

I'm thinking I would still go ahead and stick a MochiAds preloader on it, not so much to make money (as at this stage I doubt I would get any) but to use the security and versioning features they provide. As I have made clear before I am trying to be careful to ensure that this game (including beta versions) does not end up on websites it doesn't belong.

Any thoughts? I don't know exactly when this beta would be available but best guess would be by the end of next week (so pretty soon :) ). Also anyone have any ideas for titles I could use aside from "Interactive Buddy" (since like I said I am reserving that exclusively for the finished product)?
Right here:…

Let me know if you have any requests for specific "chips"! Or any other comments!