Chromecide.com

So I’ve been mad at it the last few weeks.  Outside of work, I have been spending any free time I have working on Flux Singularity and it’s really starting to come together.  I should probably give some in depth analysis of everything I’ve completed so far, and what is left, but I’m just going to summarise the updates and get back to getting the system done.

DockUI

The Messaging and request subsystem is finished.  It can handle both single instance requests, as well as poll based requests.  Single instance requests are things like retrieving the details of an object to display on an edit form, while a poll based request is more designed for things like lists of objects, where the information can change over time and needs to be updated.

Flux Singularity

On par with the development of the DockUI widgets, I’ve created the core framework for the Flux Singularity Server API.  This includes methods for sessions and user registration, authentication and data security, as well as object schema and content manipulation functionality.

The Twitter information retrieval has been integrated into the core communications engine, and updated to reflect the new methods for creating and validating objects.  I’ll be beginning testing with this hopefully this week, so keep an eye out for a couple of Twitter accounts that, well…quite frankly…appear totally normal, but that’s the point isn’t it?

Next Steps

In my original coding for the Twitter interaction, I had the sending of Tweets being performed by the event loop.  I want to move this into the Twitter process loop to bring the methods into line with the modularity of the system.  This would then limit the tasks of event loop to those of data modification only.   For example, the event loop would calculate if a Tweet is ready to be sent, and if so update the “NeedsToBeSent” flag in the database.  This tweet would then be picked up and sent upon the next iteratoin of the communications loop.

Updating the way that works would complete the Twitter module of the Communications system.  With that out of the way, I will be moving onto updating the Web Site Renderer to include support for Hierarchical navigation, web forms and web site statistics gathering. (At the moment, it only supports basic, flat structured static web sites.)

Once that is complete, it’s onto the Event Processor, although the work to get that finished would primarily be updating code to bring it in line with the recent modifications to the methods for creating and validating objects, and to expand the capabilities of the script engine.

While this may seem like quite a fair amount of work, I’m still on track for having the system ready for some major testing by the start of August.

The only real outstanding question mark over the timing is the arrival of our New Bubba, because nature has it’s it’s own timeline, and The Better Half is gonna need a well deserved break after 10 months!!

With the imminent birth of my 3rd child, my mind has been turning to the future and how to ensure I give my children the best possible chance to succeed in the future.  I’m sure most parents do the same thing.

I was at the supermarket the other day with my 2 year old daughter.  We only had to get a couple of things, so I took her through the self-serve checkouts.  While I was holding her, letting her swipe the items through the machine, a few questions sprung to mind:

How many manned checkouts will there be in 20 years when my daughter is shopping for herself?  Will they all be self-serve?  Will there even BE supermarkets?

It’s a bit of a scary thought.  How can you ensure your child is prepared for a future that in reality, is unseeable?

Shopping for groceries online, at least in my experience in Australia, is still a bit touch and go.  You end up buying “packages” that contain items you never use.  The only payoff is the convenience, especially these days with how much time everyone has to spend working just to make ends meet.  But apart from that, and the few self serve sections that some supermarkets are installing, the face of shopping really hasn’t changed much for as long as I can remember.

The other major changes I have seen have been in the media landscape.  You’d have to completely disconnected to not be able to see it.  Not even 20 years ago, the sort of movie that an independent film maker could produce would not even be able to come close to the quality and distribution of the major film studios.  Yet here we are today with original, high quality high definition independent films being released all the time, and being viewed by millions of people worldwide.

Services have started springing up to help make the process easier, joining script writer with producers and directors, building communities of fans around a film before it has even been made and services to help gather finds from those fans to make the idea a reality.

I’m not even a film maker, but I have 2 production on WreckAMovie, which provides services for a collaborative approach to film making.  One is an idea for an open source feature length film, and one is for “One Man’s Life Work”.  It has just become so easy to start turning some of our dreams into reality.

Can you imagine what things are going to be like for my daughter in 20 years?

Dear Diary,

So another day another dollar.  Some of the tasks today were actually quite fun, amidst the normal drudgery.  I had two blocks of script writing, one was for an old school 2d horror movie style, quite retro, dad is always going on about the “good ol’ days of 2d”.  I just couldn’t imagine it. Why would you?

I also had a couple of blocks of order packing. I HATE those with a passion, they take so damn long and pay bugger all.  The others were just the normal drudgery, administrative tasks, and some programming.

Dad was telling me again today that only 20 years ago, people did the same thing, all day, every day.  Each person had a single job description.  And they and they had to go to offices, and factories. It still amazes me.

Next week should be good, because I’m rostered on for field duties.  Hopefully I’ll get some more horse work blocks, they were great, not to mention the pay is really damn good.

My “bike maintenance” block was fulfilled today, 2 days early, so pretty stoked about that. I also helped Connor study for his office admin certification, and he’s coming along well.  Will be good for him to get some extra cash while he’s putting together his block for that new tv show.

Anyways, bed time.

With the new baby due in a little over 6 weeks, I have had to take a long hard look at the projects I have in their various states of incompleteness.  Everything from horror movie scripts to iPhone apps.  Some are easier to drop from the list than others, but with my personal time about to be slashed, it is something that needs to be done.

The iPhone apps are easy, for the simple reason that Apple have made it too hard and too expensive for me to “get into the game”.  Add to that the fact that even if the app is approved, they could pull it any time, and the decision is made.

The horror movie scripts, well script, one is little more than an idea.  Tougher.  Especially the script for “The Shed”, a script I bought last year from a guy called Alex Whitmer.  While I’d love to be able see the script turned into a Feature length film and my full vision created, it is just not going to happen in the near future, so that is going to be dropped as well.  I’m actually thinking of releasing the script under an Open license, maybe one day I’ll be able to watch someone else’s vision of the script.

One I’m really not ready to let go of, even though nothing has progressed in FAR too long, is OpenEmergency.com.  I think the idea is good, but again, time is against me at the moment, so it will have to move to the back burner for a while.

The rest are minor ideas or projects that I feel can wait indefinitely so I’m not too worried about those.

This has left me with only one item on my list. Actually two, but they each rely on the other so I’m counting them as.  These are “One Man’s Life Work” a constant and persistent fictional universe and “Flux Singularity” the software to run it.

I’ll be working to consolidate the information on both projects in the next week or so, to help give myself a firmer direction for them.

With the base functionality of Flux Singularity forging along nicely, I have turned my attention to how to deal with the security of the content.  The idea of the system is to be able to have multiple story lines running in a single universe, in a coherent way.  If i didn’t have to worry about who is and isn’t “behind the curtain”, it would be a simple matter of securing the information in one go.  You either have access, or you don’t.

But now that I’m thinking about sharing the system, and possibly the data, it means I need a much more robust approach to content security.  I have been using my own projects as “test cases” against this concept.  I have a couple of stand-alone horror movie scripts I’ve been working on for a while, along with a couple of ARG concepts tied into a much longer running story line.

While the movies, the story and the ARGs exist in the same universe, they don’t exist together as part of a single story line. I don’t want to limit myself in future integration of the story lines, so structuring things in the form of “Projects” or “Folders” simply is not going to work, the solution needs to be far more flexible.

My proposed solution is to instead think of the universe as a “giant stream of information”.  Each project would be an “island” within this stream and users would then be granted access to an island.  Characters, objects and other concepts can then be shared between islands using “bridges”.  This would allow cross-story use of characters etc, while leaving the original content creator in control over who sees what, and what information can and can’t be bridged.  A bridge can link anything from a full object (Character, location etc), down to a single attribute of an object.

A simple example of this is a bridge between one of my movie “islands” with one of my ARG “islands”.  Both story lines, while separate, exist within the same geographical region.  Both story lines require a police officer, albeit in a minor role.  Instead of having to come up with 2 police officers for the universe, I can bridge the officer from one island to the other.  In terms of the overall universe, this would make sense, as both “incidents” in each story would be covered by the same police jurisdiction, so it would not be impossible for the same officer to attend both incidents.  If either story line required more involvement by a police officer, I could then choose to either create another officer, or expand the role of the original officer in one island, while he would remain a minor role in the other island.  At the completion of his role within my individual story lines, I could then release him into a “public island” which would form a repository of assets that can be used by other people in their own story lines.

I believe this concept of islands and bridging will encourage my primary goal of Flux Singularity.  To create a constantly changing and persistent universe and, as a side effect, would make fleshing out the history of the universe more collaborative.

One of the (many) pieces of advice offered by Christy Dena during our chat last week was to come up with a name for the ARG Management system I’m developing, even if only a “place holder” name.

I’ve been thinking about that for a while now, especially considering the current placeholder, “ARGMan”, is somewhat misleading. The system itself is more than a planning & deployment mechanism for running an ARG.

The system is designed more for the tracking and manipulation of a persistent universe. Characters, Websites, Social Interactions and Email can have scripted actions based on simple to edit conditions. Attribute values for data can be variable, the value based on provided conditions. The advanced search will enable finding objects of varying types, which can aide in the planning process and easing the pains of continuity tracking. The planning and delivery system is based around the core concepts behind Transmedia, not just ARGs.

The data is continuously changing, which resulted in the development of a new concept in storing and displaying the information¹. Trying to list all of the possible data types and structures to create a robust system would be impossible. Transmedia as a genre is too young to suffer from the structure of traditional media types, and I wanted my system to encourage that, and not try and force structure on the future of Transmedia.

So what’s in a name? What are the key concepts behind the system? Flux and Singularities.

From Wiktionary:

Flux

A state of ongoing change.

From Wikipedia:

Technological Singularity

Technological singularity refers to a prediction in Futurology that technological progress will become extremely fast, and consequently will make the future (after the technological singularity) unpredictable and qualitatively different from today.

Obviously, I’ve been a little liberal with my inspirations from the definitions, but them’s the brakes.

¹Keep an eye on www.dockui.net, my first Open Source project.  It’s pretty rough around the edges now, but due to it’s integral part in the Flux Singularity system, development is very active.

The link to flattr.com came to me through twitter via @christydena.  As someone interested in the emerging technologies of the internet, I thought it was a rather interesting concept.

From the site:

Flattr was founded to help people share money, not only content. Before Flattr, the only reasonable way to donate has been to use Paypal or other systems to send money to people. The threshold for this is quite high. People would just ignore sending donations if it wasn’t for a really important cause. Sending just a small sum has always been a pain in the ass. Who would ever even login to a payment system just to donate €0.01? And €10 was just too high for just one blog entry we liked…

I decided to go through the process of registering to see how the process worked and to see what the service could offer in terms of advertising and revenue generation. I’m not expecting to become rich overnight, but it will certainly be interesting to see if the concept works.

The Process

At the moment, Flatter.com is in beta, and as such, the first step in the process of signing up is to request an invitation.  This I did, and it took a very short amount of time before the invitation appeared in my inbox (albeit three times).

The invite is the standard “You’re recieving this because you signed up” type, with a link to the registration page.

The registration itself is straightforward.  Just invite code, user name, email and password and away you go.  Then they send the now obligatory “click this link to activate your account” email, which once clicked on, activates your account and takes you to the home page.  Would have been nice to have been auto-signed in, but oh well.

Once you have logged in with your newly activated account, you are taken to an information screen which lays out what comes next and how the concept works.

In short, you make a deposit against your flattr account.  This gives you a pool of funds that you can use to “flattr” other peoples “things”.  You MUST give to get.  Other flattr members have done the same, and it is this deposit that they are using to contribute to your “things”.  The idea is that over any given month you flattr the things you like.  At the end of the month, your allocated limit is the divided among the number of things you flattr’d.  For example, my monthly threshold is set at 2 euros.  If I was to flattr only one thing during the month, the owner of that thing would receive the full 2 euros.  If I was to flattr 10 things, each would recieve 0.2 euros.

So the rest of the registration process doubles as a tutorial of sorts on how to use the system.  Your are taken to your dashboard, where you are prompted to update your profile information, find something to flattr and create a “thing” that can be flattr’d by others.

One tip, is to be prepared for the “create your first thing” section.  You will need:

• A URL for your thing
• A title
• A description
• Keywords
• and you will need to choose from the supplied categories.

All in all, once I had received the invitation for registration, the process took me no longer than about 10 minutes, which included taking the time to have a look at what is on offer to be the recipient of my first flattr, and the setup required on this site, to be able to supply the information for creating a thing.

It’s most certainly an interesting concept and I think it would be fantastic for Amateur and freelance photographers and writers.

And of course, if you like this, please flattr me by using the button to the right

I have managed to get a little time to work on the ARGManager in the last few days.  My primary task was to reduce the amount of calls made by the websites running on the system when they are polling for updated content.

The research led me to look into the “_changes” API of CouchDB.  This has turned out to be very powerful and convenient API to use.  I now have the basics setup for a script that can be notified whenever web content is changed.  This has allowed me to move the processing of content and page updates for a website from the website itself, to my ARGMan server.  The process will now be called whenever an update is made to the content of a web site, triggering a re-rendering of any changed pages.  The system will then upload the modified files to the web server.

Thsi has 2 distinct advantages over the previous method I had in place.

1. There is no longer a call to the ARGMan server every time someone visits the web site.  This has reduced the time for page load of the website pages,
2. I no longer have to store credentials for my ARGMan server within configuration of the website.  I have been worried that, should a call to the server fail, these credentials could possibly be rendered to the web site page, allowing access to all the information stored in the ArgMan System.

The other primary function I have been working on is a process that can validate the basic schema of documents within the system.  Early on I decided that ALL documents within the database would need to include a “Type” attribute.  I have now written a CouchDB view that loads all schema definitions that are stored and ensures that documents with the same “Type” structure as the schema item have at least the same attributes as the schema items.  This provides a method to ensure that documents of certain types contain attributes that are required for the other aspects of the system to function correctly.

At the moment this view only supports ensuring that an attribute exists, and in the event that the schema specifies an array for an attribute value, ensures that the doc also has an array for that value.  The next steps for this is to add in the ability for certain keywords to be used to further validate the data; for example:

• must_exist – The attribute must exist, irrelevant of what it’s value is,
• value_equals – the value for an attribute must be exactly the same as the schema value(s)
• value_contains – the value for the attribute must contain an array item matching the supplied value(s)
• value_not_empty – the attribute must exist, and the value cannot be an empty string, null, or undefined

The added bonus to this schema setup is I am also planning on using the schema definitions when rendering forms for adding and editing documents.  For example, when creating a new character, the UI will load the schema definition and use that to render a base form with the minimum required attributes and pre-populated values.

Shattered.  Just as I was about ready to hit the go button on the web site I was going to use to test the site maintenance features of my ARG Management system, epic hardware failure.  20-20 hindsight says I should have checked the hard drives of the second hand machine I was using, that was shipped through standard post,  BEFORE I installed anything that was semi-production ready.  I’m good at that sort of thing.

So now I’ll have to hold off till pay day so I can get some replacement parts.  I think I have something I can use in the mean time, but it’ll take a couple of days for me to get the time to get everything re-installed and re-configured.

Luckily I have everything backed up in an SVN repos, so no stresses there.  At worst I have lost maybe half a dozen notes I had put in late last week, but I’ve mostly been working on system dev as opposed to content, so *phew*.

In terms of progress for the Management software itself, I have been concentrating solely on the web site maintenance side of things, and it is pretty much complete. I have upgraded the way that templates are created and rendered to provide some more flexibility in site design. I have almost finished the web site editor, with only saving content items being left to implement.

That’s why I’m so shattered about this server dieing. I have a site almost ready to go. The template needs a few tweaks, most of which are stock photos, but I have to wait for pay-day for those. A little more detail in the content and it’s all good. So it would have been a perfect test bed for the system. I have events set up to automatically release “new” content in the future. And now I’ve been stalled just as I round the last bend. Oh well, another lesson in patience i suppose.

Story writing. A lot harder than I remember it being ( in grade 6). Sometimes it can be hard just to progress a couple of sentences. Thinking about it now I should probably have started with a firmer idea of some of the details, but all in all I’m fairly happy with how it’s going. I never proclaimed to be the next Shakespeare, but I’m having fun with it.

PANG! a Tribute

I discovered Game Maker 8 the other day.

I have found it to be quite a simple system to use, and I think it would be fantastic for giving kids an entry into game development.

While it does support it’s own scripting language, GML, it also has a “Drag and Drop” style interface.  It is simple and intuitive to use, although some logic is required to solve some issues that would be really simple by just adding a script.

I decided to make a 1 level tribute to an arcade game that I spent WAY too much time and money(at 20 cents a pop) playing.

PANG! is a simple game where you are a little guy that has to shoot a giant ball.  When that ball is shot, it splits into 2 smaller balls, which in turn split into 2 smaller balls.  The level is complete once you clear the balls from the screen.  Your life count will decrease when you are hit by a ball or bomb, or when you shoot a bomb.

You can make shooting the balls easier by collecting power-ups, which make your “bullet” wider.

Once I started making my little version of PANG! I had already purchased the Pro version of Game Maker 8, but I decided to see if I could successfully make a single level of the game, using only the standard(free) version features, and no scripting.

The sprites were sourced from Game Sprite Archive.

Please see the link below if you want to check it out:

PANG! exe file for Windows [Download]

PANG! GM8 Source Files [Download]

I’ve been working fairly extensively on my ARG management package.  I’ve had the idea for a long time, but never really had the technology (or at least knowledge of it) to create it the way I wanted to.  but that has changed…

Enter CouchDB!

CouchDB is a document based database system. Instead of having “tables”, with “columns” and “rows”, you have “documents”.  Each document contains both the definition of the object being stored( attributes), along with the values for those attributes.  The other thing that has helped in the speed and ease of development with CouchDb is the fact that everything is done in JavaScript.

Everything from the documents themselves, to how you interact with the database, to the views, are all done in JavaScript.  Along side CouchDB, I have been using CouchApp which is a framework for developing applications with CouchDB.  This has certainly helped with, not only the speed and ease of develpment, but also the learning curve for CouchDB.  CouchApp also comes with a (very) convenient jQuery plugin that makes using the database with AJAX a very simple task.

My machine is setup to run the CouchDB server, along with the php-cli module.  I am using the php-on-couch Data Layer wrapper for accessing CouchDB from within php.

So, I have my Database server and my various methods of accessing it.

In terms of functionality, so far, I have:

Event Engine Framework

The events within the system are simple in structure, essentially being nothing more than a list of conditions, with a list of effects.  For example, I can have a simple event that is fired at a particular date and time, or an event that requires a much more expansive list of conditions based on attribute values from documents within the database.  If all conditions for a particular event are met, the system then processes the effects of that event, which can be as simple as updating the value of a document’s attribute, to sending Twitter and facebook updates or updating web sites.

The engine is constantly processing events, checking for updated conditional values etc, which at the moment is fine, but I’m looking to update it in the future with a little more smarts, to help reduce processing requirements.

Communications Engine framework

This section of the system is used for processing the communication requirements of an ARG.  At the moment, all it can really do is retrieve a list of tweets for any Twitter account that is listed in the database.  During this process, the system also retrieves the public details of the user that sent a tweet.

This module is also the one under the heaviest development at the moment, with the next steps being to make it so it can send tweets and update the public profile of any authorised account listed in the system.  Combine that functionality with the event system, and I will have a way, for example, of scripting “Twitter Conversations” between 2 in game characters.

Once the base Twitter functionality is done, I’ll be expanding the Communications Engine to include support for Facebook and Standard Email, and then eventually Instant Messaging.

Website Consumer

This consists of a .htaccess file and a single php file that can be placed into the root of an existing site, allowing  a website to be loaded, on the fly, from within the database.  This includes content as well as site templates.  The script first queries the database for any updated information, and then uses that to create a cached, static version of the site, within the local folder structure of the web host.  So to create a new website I have to:

1. Register the domain name
2. upload the .htacess and index.php file
3. Create a Website object within the database, including template and starting pages
4. visit the Domain URL

and the system takes over from there.

Widget Based UI

This module is the one that is leveraging the JSON side of CouchDB the most.  I have a group of JavaScript based widgets, that are stored as documents and loaded on the fly by the UI.  The display of them at the moment is a little “wireframy”, but i can live that for the time being.  The widgets I have created so far are:

• Widget List
• Widget Editor
• Web Site List
• Web Site Properties
• Character List
• Character properties
• Organisation list
• Object List
• All Tweets Timeline List
• Games List

I started to create the UI before i got into the Event Engine, but put a hold on it after some ideas had formed in relation to events.  Originally, each item within the database had a time stamp.  Not just documents, but also attributes, allowing me to specify what value an attribute would have at any given point in time.  This was quickly getting out of hand in terms of data entry, and I also realised that it would not allow for much flexibility in the timelines for Games that are being run.

That’s when I dropped the UI development for the rest of the system.  But with the frameworks for the Event and Communications Engine done(just need to complete the plugins), I’ll be again moving forward with the UI design.

All in all I’m pretty happy with the way it is all coming together, and I can’t wait to run my first game using this system.