This is where making sure everything is configured correctly before the four hour wait comes in handy. Unfortunately, I must have been an impatient person, because I managed to pretty much run into every single problem on this page plus other random ones (like cannot lstat conftest.exe, or bad file number). One at a time. Every four hours. I’m sure many of these errors are because of windows being finicky, but I guess I can’t do all that much about that. I even forgot to put in the .mozconfig file last time, meaning I had to restart since it wasn’t building for debug mode. What a harsh lesson this has been about patience. Hopefully by the end of the night I’ll have this actually built, fingers crossed.
And this time I was finally successful!
We needed a way to test our server APIs for the GameSaver server, but I ran into the problem I talked about in an earlier post. So an idea popped into my head yesterday that node.js probably has access to command line arguments, and we could just set up the server to start in a test mode while running our tests. Then while in the test mode, simply turn off BrowserID verification, and auto-login with “testEmail”. Since only the command line argument changes that variable to enter the test suite mode, I’m pretty sure this is safe for now. So, this did indeed work out the way I thought it would, we now have access to our server APIs in the test suite without needing to verify with BrowserID. Then, I made a simple shell script that will run the database, run the server in the testing mode, and then run all the tests. This makes just running the tests pretty painless.
Now other students should be able to take any other server test tickets that go up in the GameSaver Pivotal, once this gets in.
We started on talking about developing for Firefox today. Humph wants to get going with the entire class on implementing Mouse Lock in Firefox. There’s a lot of stuff in the Firefox codebase, way too much to take in at once. First, we have to actually get an environment going in which we can test any changes in any layer of the code. So first we have to get the latest source of Firefox itself, then set up a debug build of it. Then we have to go ahead and try getting any changes working and built, even if they’re completely insignificant changes just to test the build process. We also have to read through the specification for Mouse Lock several times to try to get an understanding of it before even thinking about implementing everything. I think the best advice we have to take here is to start small, and try to tackle small problems.
This will be an interesting week.
Today’s talks were full on insight on projects just like ours, involving JavaScript, WebGL and other open web technologies.
The first talk I attended focused on building a startup with Open Source at the center. I was able to keep up with what he was talking about, but it was hard for me to relate at this point. The main point I got from it is that you should do one thing, and do it well. And don’t let anyone get in the way of that. As well, be good at using others’ code instead of starting from scratch for an Open Source project. I thought it was all pretty good advice.
The next talk I saw was on the Dragon Breeding game using Processing.js. Funny enough I saw a whiteboard for this game at CDOT about a week ago. Anyways, they showed off how they went from a prototype phase to a version close to what the final game might look like. It looked like an educational version of Pokemon, only focusing on dragons. Throughout the presentation, they talked about how it might be used in a high school curriculum. Since I’ve gone through the process of creating some 2D games/prototypes, I found the presentation pretty interesting.
Next up after the nice lunch and snacks they had set up for us, I showed up near the end of the Open Source Strategy talk. A lot of it went over my head since I didn’t catch most of it. There were good examples of the ups and downs of “adaptive” and “recursive” practices within open-source teams, but I couldn’t get the full picture.
After that I stayed for the presentation on XBPointStream. It was quite interesting seeing extremely detailed point-clouds being done in WebGL. The fact that it wasn’t for real-time usage like games, but instead for scanning in real objects was also great to see. They ended up showing a lot of experiments they did, like combining it with processing.js, and different work involving shaders. They also showed off a demo with a human body that you could see inside based on the level of detail set. Very cool stuff.
Lastly I saw Chris Tyler’s presentation on the “Consumer, Creator, and the Cloud”. He started off by describing how each of these drives computing, and how mobile/tablet computing has come into the mix. It went into good detail how Open Source had taken advantage of two of the three, and how there needs to be better open source creation tools to make content. As well, it showcased how the industry is changing and how open source technologies are helping to shape it.
I’ll definitely show up to more of next year’s FSOSS. I have to admit my sleeping patterns are pretty bad during reading week, but I had a lot of fun in the day I did show up.
I was trying to get server-side unit testing started on the GameSaver Server using APIEasy, but things weren’t so easy. The problem is that everything on GameSaver verifies through BrowserID first. Then if BrowserID says everything is legitimate, we allow usage of the server-side APIs. I can’t figure out a way past that right now. I should probably ask around what would be the best way to handle this. Maybe there’s a different way we should go about doing our unit testing for this.
I made another pull request today on my GameSaver prototype and example game. From what I’ve figured out, nobody was expected to get this far by now, but I got everything working pretty well. Just a few small things here and there to change up.
So I talked with dmose for a good half hour on where to go next since I went through most of the stories already on Pivotal. We came up with more things that need to be done. Now we can press on to other parts of the project, like getting a test suite running on the GameSaver server, creating each individual test, and automating installing the server’s dependencies. And of course refinement of the server itself and its corressponding code on the client side. I’m sure more stories will be up on Pivotal within the week.
GameSaver Server Dependencies/Installation Tips – Should help people get started: https://etherpad.mozilla.org/WH1bpNmzqBOn another note, FSOSS is tomorrow, can’t wait.
As I mentioned last post, I’ve been fooling around with the myfavoritebeer.org example, and I think I’ve made good progress so far. To be honest, I started making more progress when I figured out that windows and node.js just do not like each other, and it would be safer to test everything on a VM with a distro of Linux on it. Anyways, I had to change a bit of code in the node.js server, the mongo database wrapper, and the client to make sure everything was playing with the same types of data. Since it’s going off the myfavoritebeer.org code, it already checks for the user’s verified email before doing any db operations. I ended up storing the game data with a format that looks something like this:
var saveData = {
email: "name@something.com", // verified by browserID first
title: "TicTacToe",
data: {
// an object containing specific game data
}
};
It’s really up to the developer themselves what they want to save/load for their game, so we don’t want to restrict things too much. It’s not my job to design it though, of course. I’ll keep hacking away at this Game Saver stuff, and hopefully have something cool to show off by Thursday.
The first task of making a simple Tic-Tac-Toe game to use for testing purposes was… simple. No work really needed to be put into that of course. The real work right now is understanding how the technologies will work for the Game Saver. The example used is the BrowserID example website, http://myfavoritebeer.org . This example uses MongoDB (a NoSQL JSON-like database), along with BrowserID to keep state. I was able to make a sign in button of my own on the game to get it to verify, but I haven’t gone much beyond that yet. Now to get to the real work of saving/loading its state/results to the server using that example as a base.
I was talking more with members of the Gladius team today to get more of an idea what to do, and I decided to go with parts of the Game Loader/Saver portion of the engine. The plan is to test it with extremely simple mini-games in JavaScript, for example tic-tac-toe. The loader/saver should be able to save JSON blobs to a server using node.js, and pick them up later from the server and use them in-game. It also might be using BrowserID in some way for authentication. The sample tic-tac-toe mini-game will be done by myself and Jackie shortly, and from that simple test case we can start working on the meat of the project.
Unfortunately, I haven’t posted in a long time because I was even confused on what to talk about. Gladius stuff is just so new that all the people on it don’t have much of a starting point to build off of. And even if we try to get something done, it might not be the right design to go with the rest of the project. I ran into this problem last week when I tried to get the Tasker done based on their old code, but the lead developer had not designed it yet. I do have something done, but I have no clue if it’s what they want. It seems that I should start being more proactive about this, or I’m not going to get anything done, which would be a shame. I really like this type of work, but I don’t have any direction right now on where to go next.
Jesse Silver's Blog 