Dabu!

This, I think, will be my last post in this blog.

We have "finished" - at least for this term. There is obviously plenty of work that still needs to be done, but for the most part, our job concluded on Wednesday when we gave our final presentation to the people at Sun Microsystems. Everyone who spoke with us following the presentation said that they were impressed and thought we did a great job, which is awesome. Now we just need to tell Heineman to give us an A. :)

So, for those of you who actually read this blog but missed the presentation, I'll fill you in a little bit. Our out-of-the-box experience is delivered in "stages." First, we wrap up the entire install process into a single double-click jar file. After everything is installed, we wanted to "wow" new users so we show them the Project Snowman game (which uses Project Darkstar) that has been developed in-house by Keith, Owen, Yi, and Jeff. The run process required that you have Ant installed, so we wrote a platform-independant launcher to run it in a single-click process. Once the user has gotten a chance to play around with an actual game, we teach them the API and let them start writing Project Darkstar code through the use of a set of basic tutorials. These tutorials cover every aspect of the API and when completed produce a very basic but functional server and client application that users can run and play around with. Finally, after they get a chance to learn the API, we have an optional "challenge" tutorial. This tutorial starts with a stipped-down version of the Project Snowman game and has users implement the different aspects of its server and client code. The idea behind this tutorial being to teach users what it takes to make a fully functional game using Project Darkstar.

I mentioned that there was more work to be done. Some of this will be accomplished in the beginning of B term. We want to give the tutorials to several of the Sun employees who work on Project Darkstar to get their feedback. Also, we would like to test our tutorials on several other students at WPI to see how the out-of-the-box experience pans out with them. We also need to write the paper for our MQP. The rest is out of our hands. Once we have these final pieces completed, everything will be released to the public and open-sourced to the community. There are also plans to use our tutorials at schools and universities across the country for Sun-sponsored game jams and events, which is exciting. So, yeah. The future is bright.

So, what did I learn from all this? One of the suprising things about my MQP is that even though I'm a CS major I wrote a very small amount of the actual code that was produced. This was NOT because I was incapable or didn't want to, I can assure you. Rather, I just got unlucky. Whenever code was necessary I was already working on some other task. So I didn't write that much code. I reprise: what did I learn, then?

Even though I didn't write that much code, I definately did a lot of reading. Early on, I looked at jMonkeyEngine. Even then, I didn't like it; however, comparing something like jME to Project Darkstar you can really see the difference between a massive pile of classes and an actual API. Seeing all the Darkstar code and hearing everyone at Sun comment on it has really given me a better understanding of what it takes to create a good API, and not just an API, but the underlying framework as well. I've gotten a chance to hear from some of the smartest people in the industry and see how they work in a lab setting, which I probably would not have done without this MQP. I've also learned a lot more about Java and JVM in general. Oh, and a few things about different operating systems just because everything we did had to be platform independant.

In the end, I think I've had a really good time working at Sun, and the experience has only improved the more time I spent working there. I hope that the work that my group and I have done will be beneficial to the future of Project Darkstar.

To top off my final post, I give you one last movie. It is .... how should I say it .... thrilling.

Adieu.

Me busy! Leave me alone!

So after a discussion with our advisor on Friday, a conclusion has been reached regarding the issue I spoke about in my last blog post. We're going to take the best of both worlds: Have a pre-defined project file (in NetBeans) included and then also specify a tutorial that will teach people how to create thier own project files. This tutorial will teach people about what is required to develop Darkstar applications from within multiple IDE's, namely NetBeans and Eclipse. Also, I added a section detailing what is required outside of IDE development as well. I was going to create pre-made projects for Eclipse as well, but the way Eclipse's project files are set up, you cannot have projects that are sharable without redefining required libraries. I was honestly suprised and slightly dissapointed at this, as it is a major downfall of what is normally a very solid IDE. However, we still always have the tutorial for creating Eclipse projects, so for now it will do.

Anyways. What have I been up to lately? Well, as the title suggests, I HAVE been pretty busy over the past several days (this is also one of the few times when the title actually made some sense). Basically I've been writing, writing, writing, and writing. Oh, and writing; can't forget about that one. And by writing I don't mean coding; I mean writing out project documents in text files. About a week ago when me and my project partners divied out tasks for the week, my friend and I were split between two tasks: writing the code for the tutorials and writing the actual text for them. He offered me the choice, and at the time I didn't care so we flipped a coin to determine who would do what.

Sometimes I really wish I had just chosen to write the code.

Writing each individual tutorial took much longer than expected. Even though there wasn't a lot of code I had to explain in detail every possible thing that was going on in order not to confuse the user. One of the things I keep in mind when I write them is that if I leave anything, anything at all, unexplained or amiguous then there is at least one user out there who is not going to get it, run in to problems, get confused /frustrated, and give up. And that means we've failed to provide an adequate out-of-the-box experience. Also, too much text can overwhelm the reader even if what is being explained is fairly trivial. So it's a tricky balance to get everything perfect.

Fortunately, I'm not the only person working on it. While I did all the text, my group members looked at it and made edits, suggestions, etc. I want to go over it one more time but so far I think it's really coming along. The tutorials are now in the process of being formatted into HTML documents, and I have to say, they look VERY nice. I'm truly impressed and pleased to see the results which so far have exceeded my expectations which usually doesn't happen that often, at least for me.

So thing have been coming along and I think we've made a lot of progress over a short time frame; however, there is still a lot that needs to get done. Mainly, I am slightly worried about the actual Snowman tutorials but as of right now I don't think I have enough information to comment on the status of those. We'll how it turns out, I guess.

"Eclipse's Classpath File is Retarded"

Indeed.

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

Something need doing?

I've been putting off posting anything for a about a week now and I really should start getting into the habit of posting more often, which I will try to do in the coming weeks. I'm not usually a blog type of person, so we'll see how it turns out.

Anyways. Let me try to explain the entire situation.

I am a college student currently attending Worcester Polytechnic Institute majoring in Computer Science. One of the requirements of graduation is that everyone must complete a capstone project in their major field, also known at the school as the Major Qualifying Project, or MQP. Most of these projects occur on-site at the school; however, there are also oppotunties for students to attend off-campus projects at a variety of global project centers. This includes locations such as Limerick Ireland or Silicon Valley. This is what I'm doing. My project, unlike the others, takes place at Sun Microsystems which is really close to the WPI campus, which is awesome. I don't have to pay for travel and I get to stay on campus and hang out with friends and such. Oh, and I also get to work at Sun Microsystems, which is pretty awesome in itself. The project takes place during A term (first quarter, basically) which lasts 7 weeks.

So I guess the next question is, what am I going to be doing, exactly?

There are several teams of students who will work at Sun, but my team and I will be doing work on an ongoing open-source project there called Project Darkstar. It's basically a framework for setting up a server system for running MMO's. You can find a better description from their website. As of right now Sun has this system but they have nothing to really show it off. It justs exists as a repository of source code that only hard-core programmers who are interested in the subject will go and bother to look at. This is where we come in. Our job will be to take this framework and construct some kind of 15-minute out-of-the-box experience that will "wow" developers and show off what the system can do.

This past week was my first week back at school since summer and has been dubbed the "Sun Boot Camp" by my project advisors. We spent the week going over things about Sun as a company, expectations, some code tutorials, project descriptions (which were presented by Sun employees), installing various pieces or required software, and probably several other things that I can't remember.

So that leads me back to the reason for the blog. As the project goes on we as a team will need to brainstorm several ideas and do some research after which will need to be compiled in some kind of report. The blog serves somewhat as a historical record of all our ideas and thoughts so that when we start finalizing the project and start writing the paper, we will have a record of everything that we tried and worked on, what went well and what didn't, etc.

So. This past week was mostly us throwing ideas around and getting mentally prepared for the trip to Sun. I'll spare the project details for the time being. I'm pretty excited and I think that this project has the potential to turn into something really cool. It also looks good on the ol' resume. ;)

Well I think that's it for now - next post will discuss some actual ideas and will start recording the progress of the project. Until then ... I'm out.