Chromecide.com

As Flux Singularity is approaching a point where I will be able to start beta testing, my mind has turned to the inevitable, “How do I make my money back?”

I would love to be able to simply release it as an open source project, providing it for free to anyone who wants to use it, but let’s be honest here.  I’ve put an uncountable number of hours into the design and development of this system over the last few years.  I’ve sacrificed time with my family.  Don’t get me wrong,  I enjoy working on the system and I really believe in the concept, but without trying being selfish, I want my dues.

Now I’m not a greedy person.  I’m not the sort of person that thinks “Alrighty, hard work done, now to sit back and watch the dollars roll in!”.

I want to find a new way of doing business.  A business model that is fairer. For Everyone.  Where the people involved get paid what they deserve and the end consumer DOES NOT pay for someone’s luxury car.  I’d like to be able to “share the wealth” (and the love) with those that deserve it.

One idea I’ve had was born from the concepts of Crowdfunding and an idea I had for Crowdfunding the production costs for an Independent film, so that by the time the movie is ready for release, everyone who should have been paid, has been, allowing the movie to be released for free. As in creative commons free.

Could the same concept be applied to software, albeit in a slightly modified format?

Let’s say I’m at a point where it’s time for me to start marketing my system:

The old way of doing things:

I would first look at my system, the time it has taken and build a business plan around a standard sales model.  This would allow me to calculate how many copies of the software I would need to sell to break even.  I would then use this information to draw up a business plan taking into account such things as overheads and all of the REALLY interesting stuff.  I would then need to present this plan to an investor (or a bank) to be able to get the money to allow me to market it.  Of course this investor would then want a cut of the profits (assuming I made some).  This way of doing things would force me into the Greedy way of doing business.  I’d be made to charge more for the software than I would feel comfortable with.  I’d quickly begin to lose control over the decision making for the project, as the investors put pressure on me so that THEY can benefit.

Alternatively, I could go down “Software as a Service” route.  Not release the system at all, instead setup a dedicated server, and rent the use of the system.

A new way?

All I want from this is to make back what I’ve put in.  After that point, I don’t see the need to keep charging for it.  Like I said.  I’m not greedy.

Is there such a thing as “reverse” Crowdfunding? Raising the finds for a project after it has been completed?  After the “crowd” can see a working version of what they are supporting?

Would people support a Crowdfunding campaign, whose goal is to free up a developer from the greed of Commercialism?

I REALLY don’t want to go down the standard business paths for Flux Singularity, but I DO want to be paid for what I have done.

If I didn’t need money for outrageous things like rent, utilities and food, I’d just release it for nothing straight up, but unfortunately, the world simply does not work that way…

Thoughts?? Please Comment…

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 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.

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.

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.