Oki-dokey.

Today I'm going to keep the topic specific to a certain issue that came up.

As we get more Darkstar information together for the tutorials and start actually implementing them, a question arose that I think is quite prudent. Part of the entire 15-minute out-of-the-box experience is taking a large and complex system and simplifying it for new users so that they can get in, get their feet wet, and end up with a flashy result; the goals being to get them interested in Darkstar and show off what it can do and how easy it is to do it. This has a couple implications. First, we want the user to actually see, write, and become familiar with the code. This is important because users eager to learn an exciting new technology will want to do just that: start coding. Let's say you go to some rock concert, see the guitarist hammering out a crazy solo, and suddenly decide, "Hey, that looks really cool; I want to try that." Initially, you aren't going to spend lots of time reading about how to play guitar; you're going to grab a guitar and start tooling around with it. Same idea. Second, we want everything, everything, to be easy and go as smooth as possible. To have a successful out-of-the-box experience, you simply cannot lose the user's interest or create an experience that is uncomfortable and/or ungratifying. If we give them a task that is perhaps a bit too confusing or complicated, they will get frustrated, walk away, and find something else to do (It doesn't take long!). Also, if they spend too much time doing required tasks that deviate from actually working with Darkstar, we have a similar issue. We wrote the installer program for this very reason: simplify set-up and get people coding faster.

So we want to get people coding quickly and with as little hassle as possible. How do we accomplish this? In order to start coding with Darkstar, you're going to have to download and install Darkstar, create projects with build scripts, and create properties files. Also, in order to run your application you have to run the java virtual machine with a long list of specific but required arguements. Some of these tasks aren't trivial. Ideally, we don't bother the user with any of this. Instead, we provide everything and all the user has to worry about is code. We already dealt with the installation, but what about the rest? Even if we provide things such as build scripts for a project or shell scripts for running the application, at some point the user is going to have to do these things themselves. After all, these scripts would be specific for the situation and would probably not suit a generic programmer's custom needs. This little conundrum leads me to the question that I mentioned at the beginning of this post, and the question is this:

Striving towards simplification, how much are we willing to encapsulate from the user?

An idea that we are going with at the moment is the use of an IDE, namely NetBeans. We chose NetBeans for a variety of reasons. First, the Snowman project is written within NetBeans, and if we opted out of using it, we would have to re-write build scripts in order to remove the project dependency on it. Also, (and this is true for just about any IDE) it encapsulates building and running into one application, which is very nice. But what about the drawbacks? Well, we are adding a dependency to the tutorials. A rather big one, in fact. Users MUST have NetBeans or else they will have to spend a lot of time trying to convert over to another IDE (or not use one at all), which is ... undesired to say the very least. In addition, setting up a Darkstar project in NetBeans can be quite tedious, and this detracts from the user experience. There is a way around this, but I'll get to that in a second.

Remember that the user will eventually have to learn how to create their own projects from scratch. An option is to have the first tutorial explain this process. Have the user create their project (which, by the way, allows for a more open-ended choice on how to go about doing it, whether with NetBeans, Eclipse, Ant, etc.) and then start programming with darkstar. Okay, sounds reasonable.

The big reason we have been thinking about NetBeans over the previously mentioned option is because we don't want to have the user deal with any set-up. These tutorials are not just learning tutorials; they are a full out-of-the-box experience. And along with that comes the fact that getting darkstar out of it's metaphorical "box" - and doing it quickly - is a really big deal. While teaching the user about set-up from the get-go is useful, for our intents and purposes it ultimately comes second to grabbing users by the ears and tossing them directly into the briar patch.

Thus, we arrive back at NetBeans. I mentioned that projects still require some set-up. While this is true, it can also be done completely beforehand. Part of what I worked on today (or yesterday now, it's getting late) is setting up a project file that can simply be opened, built, and run immediately from within NetBeans. This, I believe, is really the optimal choice for what we are trying to accomplish.

So that's basically my thoughts and opinions on this whole project at the moment. If the final decision is to go with this format, I have a proposal regarding the tutorial arrangement that I would like to discuss.

All tutorials can exist within a main tutorial folder, in which they can be separated into folders for each individual tutorial, say tutorial 1, tutorial 2, etc. These are mainly just for organization and is something we've sort of been doing already. Within these will be the folders for the NetBeans projects. This is where things get different however. For each tutorial project, I propose we create two separate projects. The first one will be a blank project (or a partial project, depending on the tutorial) ready for the user. The second will be a completed tutorial. This is how 3DStudio Max organizes their tutorials, and I think it's very effective. The first blank project allows the user to start coding right away without having to worry about set-up. The other completed tutorial will give the user a reference to a completed project, and this has several purposes such as allowing the user to compare/contrast between thier own work to see if they made a stupid mistake or did something wrong.

On a side note, having the tutorials set up in this manner can also allow them to be packaged separately from Project Darkstar itself, like a demo. This isn't a proposal though; just a thought.

Alright. So basically there's one basic point to my entire post today, and it isn't necessarily to treat users like they have the attention span of a goldfish, although that's basically the idea. To sum everything up: using NetBeans, including pre-made project files, and neat organization is key to a successful out-of-the-box experience. And that, my friends, is my two cents worth.

Wow, that was a long post. Well, for me at least. I like ending posts with an interesting video, usually something especially thought-provoking and intelligent that others may very well enjoy.

Check it out.

Zug zug.

It's been a little while. =/

First, last week. Last week most of the Sun people we work with went down to AGDC, a game developers conference in Austin, Texas to showcase Project Darkstar. Since everyone was gone and wouldn't be on the Sun campus, there was no point in us driving to Sun every day. So, we stayed back at home at the WPI campus.

During that time I worked with Project Snowman; in particular, the server portion of it. We've decided that Project Snowman would be a great starting place for our tutorials because it would allow us to focus almost entirely on the server end (the way it should be) and not have to deal with creating a client from scratch. Which also means .... *drumroll* .... no jME! Yay!

Let's call last week Week 4 (being the fourth week of our 7-week term). At the end of Week 3 I had been testing out the Project Snowman server/client on various machines to see how it ran. What I found is that the server portion of the project did NOT work on the Windows platform. So that became my main task for Week 4: Figure out why it wasn't working, and fix it.

I'm happy to say that after a little bit of deliberation, I found out what the problem was. The Ant build script was setting a value in a .properties file used by the darkstar kernel. It sets a value of some variable in this file equal to an absolute file path. Now this is where is gets weird. On Linux (and Mac, I assume) this path name gets read in fine. But on Windows this doesn't happen quite the same way. What I suspect is happening is that there is a small bug in Darkstar itself - when it reads in the file path (which, if you recall, is absolute) it appends that path to the current directory (which it shouldn't do) and then uses that path to look for required libraries. For example, if the current directory was C:\Program Files\ and the path in the .properties file is C:\Windows\, then the final path it tries to locate is C:\Program Files\C:\Windows\. It gets better. If the path that gets read in has any backslashes ( \ ), which is the standard file separator in Windows, it will try and find escape characters such \n (newline) or \t (tab). So now say my .properties file contains a path called C:\thefolder, then the final path looks like this: C:\Program Files\C: hefolder. Really messed up. The current fix is somewhat of a hack, but you can manually edit the Ant build file (which sets the properties file) to input the correct RELATIVE path, using FORWARD slashes, which are still usually interpreted correctly, even on Windows.

Other than that, I've also been looking at getting rid of the Netbeans dependancy for the Snowman Project. From what I've been able to see so far, when Netbeans opens a project file, it creates a couple small files that contain some file paths pointing to directories within the Netbeans install folders. These paths are absolute, and specific to the OS. That being said, there might not be a true "fix" to this problem other than simply writing a new Ant build script that doesn't rely on files that Netbeans creates (which is what it does currently). That is one of my current tasks, but that will come a bit later. And by a bit I mean like, a few days.

Finally, now that my partners and I have spent the last week doing a lot of prep work for this week (mainly doing some research on Project Snowman internals and writing a crapload of documents for our report) we can actually start working on the tutorials. FINALLY. To start, this week we are really focused on creating the first set of so-called "intro" tutorials that don't use the Snowman project quite yet; instead they cover the basics and essentially lead into the Snowman tutorials to come.

So things are looking pretty decent, I would say. These last few weeks are most likely going to be a lot of hard work, but I can't say I didn't really expect that to happen anyways. Until next time...

"OKAY! Guess I'll use these cigarettes I hid in my STOMACH! AWESOME!"

I can do that.

So lately I've been playing around with jMonkeyEngine while the others continue work on the installer, which, at this very point in time, the are supposedly very close to being done completely. Finally. But back to jME.

I haven't really enjoyed the first experience. The entire engine is basically a massive tree of extended classes with almost no interfaces and little sense of a unified structure. Also, there are several pre-defined classes which handle a lot of basic functions for you but if you want to do anything custom you basically have to extend the framework which annoys me because then it's no longer an API; you have to learn the underlying system which completely destroys the concept of encapsulation. But I digress.

The purpose of getting to know the engine was because of a couple reasons. For our final product we need some kind of flashy client-side program, and a 3D game world is not only a good way to do this, but is also what many current MMO players are accustomed to (Text-based MUDs are a thing of the past). We heard from co-workers that jME was relatively easy to use and set up (despite my recent rant it IS a hell of a lot faster than just straight JOGL). The Project Darkstar team is also preparing a demo (Project Snowman, written using jME) and we were (possibly still are) throwing around the idea that using this as a code base for our own project could be a possibility. Thus, jME. But most importantly we also came to the realization that even if we did use jME it was doubtful that we could start from scratch and deliver a highly polished product. We need to focus on the Darkstar portion of the product and since we only have 5 more weeks we, unfortunately, don't have the time to play around with pretty graphics.

So yeah, that's what I've been doing. Today our advisor actually came into Sun and gave us a suprise visit (Well, it wasn't a suprise for anyone else. Apparently we were the only ones who didn't know. Go figure). Anyways we had a good discussion about what we had to next and such. I'll post a better description of all this later. MY job for the time being (while my friends scramble to finish the installer... :p) is to start combining Darkstar and jME to see if I can get some sort of rudimentary working demo done within the week (Sooner if possible, but that goes without saying). But first, I must go through the Darkstar tutorials and get a better understanding of how everything works.

And that's it. It's about 9:35 PM right now and I'm still kicking around Sun while my project partners finish up this installer. By the time I leave I'll have been here for about 12 hours. Long day. =/


And on a completely unrelated note:
"It's a stone, Luigi. You didn't make it!"

Work, work...

So it's been a while since I last posted anything in here so I'll recap what I've been working on these last couple weeks.

First I spent a lot of time setting up the working area we were given (the game lab at Sun) with several different machines with varying operating systems. As of right now we have a couple Windows machines running XP, a PowerPC Mac with OSX, and a couple Linux machines with Ubuntu. I also attempted to get Solaris on one of the Linux machines but the install requires a root password which apparently niether myself nor the Sun people here know. Oh well. Basically the idea behind the various machines is so we can quickly test our code in multiple environments, which we have done already, but I'll get to that in a second. Once these were set up I also set out to get required software and stuff running such as Java and the Project Darkstar tutorials. I also spent some time looking at the darkstar forums and blog posts. That was pretty much the first week. This past week my focus changed over to the jMonkeyEngine. Several Sun reps have spoken about the ease of use of jME and so at this point we have basically decided to use it for our project. This week I've been looking into this and doing a bunch of tutorials and things.

So here's what we plan on accomplishing while we're here. There are three basic parts. First, after much frustration our first day trying to get Darkstar up and running we decided to implement an installer program that will eliminate some of the hassle of setting up the Darkstar (and third-party depedencies) binaries. Most of this work was done the first week and the past two days by my cohorts, although I got eclipse installed on several machines and downloaded and tested the GUI portion of the installer. Second, we hope to complete some out-of-the-box game to showcase the potential of the Darkstar engine, of which we are just about to begin working on (other than me playing around with jME or lots of brainstorming and talking with Jim). The final portion will most likely be developed alongside part two, and that's a tutorial system to allow new users to get familiar with the Darkstar API. Right now our idea is to take a very simple game and have the user "develop" it iteratvely, using some of our code as a base and our tutorial as a guide. This will get the user into the code immediately but also produce some flahsy and fun in a relatively quick and painless process.

And I think that's about it for now. All of us are thinking that we'll start posting in the blogs more often, like Mon. Wed. Fri. or something like that. Hopefully it'll work out :p
More to come later...