Signs of life

Its been a long time since I've made a post here, but it is not for lack of movement. Sadly, most of the movement has been towards completing class, but now that the end is almost here, I've decided to take stock of what has been done on the RDA and the direction I would like to take things in from here on out.

First: after a lot of learning and thinking, I have decided to stop developing the RDA in its current state. The current state of the Python application left a lot to be desired (a semi-finished chat program with some dice rolling functionality). I enjoyed working on it and learned a lot from what I did, but I have realized in the downtime how far away from my original vision the idea has now come in my head.

A major component of what I wanted to do was to have some form of three dimensional view of the playing "table" as it were. I wasn't quite sure how I was going to do that at the time, but I had planned on using QT's OpenGL functionality at some point. I struggled with getting the proof of concept working for so long though that I began to get bored with the networking code and that lead to apathy.

Therefore, earlier in the year I decided to refocus. I became determined to learn what it would take to make a true OpenGL app and began spinning up a test bed in C++. I called this effort "AUG", a shorthand for "Atlas of the Unconquered General", after an artifact that could display an interactive vision of a battlefield for commanders. I was excited about using the new features of C++11, but soon I found how difficult it really is to get OpenGL under control. There are a lot of really good tools out there, but I got busy with class and soon fell back into a groove of never "having enough time".

More than that, though, I was beginning to have doubts about the design of the platform. I had learned a lot about what needed to be done, but I hadn't really changed anything about the design. I also hadn't spent a lot of time thinking about how I'd want it to be used. For instance: what kind of technical experience was I expecting the users to have in order to set up a server to host the game? What kind of experience was I hoping to convey to a user using the app that couldn't, for instance, connect to their friend's server for some reason? While thinking about these questions, I began to think about ways to make things easier for both me and potential future users of what I may finish.

Around this time, I happened to read about WebGL. I can't remember what demo I saw - i think it was of live programming WebGL with an Oculus Rift (seriously cool, btw), but things started to click into place in my mind. A web app could provide the ease of use I was worried about, and the flexibility to provide a host for people technically inclined, or potentially find a host for it online for the public to use with minimal fuss. I read articles about web sockets and began tinkering. Eventually, I picked up three.js, and used some of my web.py experience from class to whip up a simple server. Soon, I had a rudimentary web socket echo server in Python operation. Before long, I had all these components together in a proof of concept that worked surprisingly well.

So far, I've been pleasantly surprised at the ease of learning about and working with the technology I need to make the RDA a web application. From here on, I plan to concentrate my efforts on this, and as such, have broken the tasks down into more easily identifiable chunks:

• RDA (Resplendent Digital Assistant)
• Rules, turn tracking, dice rolling, model of mechanics
• AUG (Atlas of the Unconquered General)
• Scene display, character location and movement, model of world (per-scene)
• IM (Infallible Messenger)
• In game, out of game, and private chat, communications

Maybe this is still all too ambitious. I don't know. We will see as we go along. Right now, I'm working towards learning about the various tools at my disposal (besides three.js) and getting something solid set up so I can begin testing in earnest. Also, I figure if I have a server up and running a few people can at least keep tabs on me and keep me honest and motivated. Until then, don't be surprised if I start posting Javascript snippets.

A lesson in philosophy

It has been a while since there has been any forward progress made, mostly due to class eating up all of my time.  In order to not feel like the time has been completely wasted, I thought I'd make a post about a recent assignment I completed.

The assignment was to implement a solution to the famous dining philosopher's problem.  The problem generally requires students to use various tools such as semaphores and threads that, historically, have not been available in a simple cross platform way unless certain specialized libraries have been added.  Enter the C++11 standard, and you have the opportunity to finally write a cross platform solution with nothing but the STL.

The dining philosophers problem turns out to be one of the problems where it is beneficial to think of each thread as a class - after all, each thread represents a philosopher.  This solution called for a classic runnable class model which I implemented entirely in a header file out of a combination of laziness and ease of use (the latter reason is debatable).

The runnable class
A few points about the runnable class: first - visual studio hasn't yet implemented the delete operator so we still have to work to make runnable noncopyable the old way.  I expect this will change in the near future, so the preprocessor guards will come out eventually.  Everything else about this class is fairly straightforward - implementors are encouraged to use the m_stop variable or the stopped method inside their loops in order to respect the stop command, and I'm not sure if more can (or even should) be done on this front, though I am wary of relying on the people using the class to ensure most of the methods the base class itself defines are useful.

The magic of the solution occurs in the philosopher class.  C++11 provides a lock function that guarantees it is deadlock free.  A simple solution (modified Dijkstra's solution) is then presented using this mechanism for philosophers to request their chopsticks.

A simplified view of the philosopher class

C++11 provides a couple of interesting locking mechanics for a mutex, but the appropriate mechanism for a philosopher is a unique lock, since only one philosopher may hold a chopstick at any given time and the lock must hold even after the method that locks the resource (get_resource) has completed. The second argument to the unique_lock constructor tells it not to immediately grab the lock, since that will be done in the thread's run loop.

And that is really all there is to it.  Unfortunately, the current solution does nothing to address possible thread starvation.  In order to truly do that, a conductor would be needed (or in this case, a waiter).  The solution to that problem, however, will have to wait for another day.  Until then, you can click here to view the git repo for this project.

Adventures in reinvention

If at first it seems right, that is no reason we can't try again, right?

It has been a while since I've made any forward momentum on the RDA, but I'd like this post to be the first step in picking things back up.  And since this is a new location for the development blog, I'll give some history - after all, that is the purpose of this blog.

From the beginning of this project I felt like I needed an outlet to speak about the development of the RDA  - design decisions and technical choices about the project are so numerous that I'd really like a way to keep track of them for myself even if no one else really reads this.  The plan was to post reasoning, updates, and even code snippets so that this would be a truly open project.  I do enjoy a bit of web design every now and then so I went ahead and made a GitHub page with the intention of keeping track of everything there.  It wasn't a bad system, but I always felt like it could be made better and never had any time to do so myself.

After some though, I realized that I should really stop trying to reinvent the wheel here and just start a blog on Blogger (which made sense since I've already set up the RDA dev email address).  So here we are - this should help me focus on finishing something resembling a product and encourage me to make more posts since updating the site will no longer be such a hassle.  I'll leave the old site up for historical reasons, but I'll be working on back porting the posts from it to here, so I won't have to jump back and forth.  Eventually, I will probably convert the GitHub site into something more static with a link to this blog.  I'll mark posts from the past and try to provide more information in the new spirit of this blog.

Now on to features: the RDA has a solid networking setup with Twisted and AMP currently, but what it is lacking is the ability to separate users into chat channels.  After some waffling, I'll be using a publish subscribe paradigm for the channels.

The bulk of the code will reside in the chat handler on the server.  For now, I'll focus on simply providing the ability to split users into channels - I'll provide the functionality to manage the channels later when I work on the concept of a campaign.

Code conformity

Post from the past

Got to... style all over... python

Not much to this update - sorted out a few mistakes in git and finally purged all legacy urls. Submodule should be working correctly now. Overall this was mostly prep work for getting back into the swing of things.

Notes from the future

I had seriously broken everything and was quite happy when I made the corrections here.  As the post notes, the submodule structure was very wrong.  This was due to the fact that I had copied over a lot of the data (poorly) from the original BitBucket repo that house it.  As I will explain in an older post, I had chosen BitBucket mostly out of cowardice.  I wanted the ability to keep the repo private, but I eventually relented and moved to GitHub to run the original blog.  Half baked ideas from yours truly?  Say it ain't so!

Website updates!

Post from the past

Now with 100% less placeholders

I got a couple of complaints about the old style of the site so I consulted with a marketing coordiator I happen to live with and came up with both a new site and a logo for the RDA. The website still a work in progress, but it's slowly edging closer to being done and it is very exciting.

The original icon had the plug for the ethernet facing upwards, as you could probably see from the previous post. After thinking about it (and more consulting), the logo changed to what it is now. I really wanted the image to symbolize what this project is and I think the unmistakable symbol overlaid with an ethernet is a fairly good distillation of what this RDA does and is. I also wanted to subtly incorporate themes from the Twilight caste, and hopefully that comes through with the image as well. With that bit of work done, and the stabilization of not only the website but also the source control and Qt, I feel much better about moving on.

Icon has cheezburger

Post from the past

RDA logo and icon in the works

In addition to a site overhaul, I've started work on the RDA logo. Inkscape is surprisingly easy to use and the learning experience has been fun so far. I hope to have it done soon so I can resume work on the actual RDA.

Also of note: Qt has been picked up by Digia, which is good news indeed. I look forward to the eventual release of Qt5!

First blog entry

Post from the past

Not much to look at yet

Welcome to the RDA dev blog. In the following days, I'll be adding some old news to keep a complete history of development up to this point. They will have their own titles and I will try to set the date properly, but this is the real first post of the new site. I've taken a small break from coding (before I work on getting the Qt reactor working with Twisted) and I have been refreshing my memory on web dev. This project has really been teaching me things, it has been fun picking up some new tricks in CSS and HTML. My plan is to have the site in HTML 5.

This week turned up some troubling news as well. Apparently, Nokia has shut down their Australian offices which makes me worried about the future of QML. I was really looking forward to the beta release of Qt 5 and the new QML additions it would bring, but this seems to explain the delay. Not much to do except wait and see how things play out, I'm afraid.

Notes from the future

This was technically the first post of the old GitHub based dev blog.  Now that I'm using Blogger, hopefully I'll never have to backfill again!