Blog Posteru!

So, yesterday was my first foray into actually programming with Project Darkstar (You know, really think more of this MQP should have been around this, but unfortunately, things don't always work the way you want to). So programming in Darkstar CAN be easy, but it had quite a learning curve, which is why I'm glad that we're making "get your feet wet" beginner tutorials. It's very difficult making a set of isolated tutorials about Project Darkstar, though, and looking back on it, they're in a slightly incorrect order.

-You absolutely cannot set up a Project Darkstar project that interacts with users without using the persistent storage, so perhaps that should have been first (although actually using the persistent storage without user input seems useless).

-You absolutely cannot use Channels without the persistent storage.

-You can, however, use Tasks without any of the above. So, a proper tutorial order could have been:

Tasks (although you can't make any useful tasks without users, channels, or storage in an isolated Darkstar example)
Persistent Storage (Although you can't store anything useful or convicing without users)
Users (You'd have to revise your task to do something useful, or create a new task)
Channels (You'd have to yet again revise the task to do something useful).

Our current project order is Users, Persistent Storage, Channels, and Tasks. We tell the user to just bear with us during the users portion.

Anyway, off I go to work on a detailed project description.

Blog Post update.

Check out the date for reference. Today I began the task of writing Tutorial 1's code, and tonight will do Tutorials 2 and 3. Unfortunately, the fact that I was late today resulted in Rob also being late, so, I hope to get myself in gear and crank out all the work I have to do this week. I hope to be caught up by tonight, however.

Tutorial 1 is very simple code, but it exposed a bunch of the little interesting chunks in Project Darkstar's client API. For example, it forces you to program in a multithreaded way. While you're trying to log in, you have to spin your wheels until you get a reply from the server. So, in my hack of a tutorial (A tutorial is meant to get your feet wet in a subject, of course, so it's a little hackish), there are 2 classes: The client listener and the TutorialWorld class. The tutorialWorld's purpose is basically the same as it would be in a game world: It has a while loop that keeps the main thread busy. Essentially, the loop is something like:

While(NotBail) { If(LoggedIn)P{ DO STUFF } }

Since the main loop is just reading the 2 booleans, writing to them is safe from the Darkstar Client Thread, which from the client code, looks something like:

public void LoggedIn() { world.LoggedIn(); }
public void LogInFail() { world.Bail(); }
public void Disconnected { world.Bail(); }
public void HitTheFan { world.Bail(); }

Technically, the main thread's while loop could feasibly be expanded to "if(LoggedIn) {Do Game Stuff} else {Do Waiting Stuff}" for a visual game. However, for the sake of this project... nah. Not needed.

Tutorial 2 here we go.

Tri-Weekly Blog Post - Friday (a day early)

Speaking Points
-Clean Installation Process
-Improved Demo
-A series of tutorials

So the clean installation process is well under way. The front-end is essentially done, and all snazzed up. The design document is still in the draft process, but I'm working with Jim to make it not-a-draft. The installer went through several phases:

+Prototype (Paul)
+GUI, most of the GUI control (Me)
+Linking GUI and backend (Paul)

Getting the GUI working as a nightmare. Originally, I tried using several ways to do it. First I tried Jigloo and VE. Neither of them worked, so then I tried to do it by hand. Once that also failed, I started trying to to find plug-ins for Eclipse to get it working. Eventually, I learned of an awkward way to get VE working, so I set off to work on my GUIs. Once the GUIs were built, I put together a basic framework for making installers. This was a pretty easy process. As it stands, the UIs are done, and now it's in Paul's hands. Godspeed, Paul. Godspeed.

The improved demo is at a bit of an awkward phase. The original module idea might take way too long, but it might not. It's still our backup plan. The other idea we had, hijacking the snowman game, we found out was a bit infeasible because the code was done quickly (as they have a deadline fast approaching), so refactoring it and fixing it would take a long time. It's still our best course of action, and we'll dig through the source code before the end of this week.

Progress
Since my last blog post, I have:

+Wrote a design document draft for the installer, working on the next draft with Jim
+Wrote a framework for the installer
+Made all the GUIs and associated artwork for the installer
+Had a meeting with Owen to discuss the snowman game demo
+Had lunch 4 times

All of the points were mentioned above, so there's really no point going in detail. Also, lunch here is way too expensive and not terribly good quality. I miss the Building 43 and 41 Cafes.