Name change

So, I am officially updating the name of this project to Nutty Bolts (unless anyone has any last-minute brilliant ideas). I'll update the blog and my portfolio shortly with the new name.

I'm also working on updating the look and feel of the interface. At first, I was just going to apply a new color scheme (blue and orange) to the existing interface, make some minor updates based on the handy Web 2.0 style guide, and pretty much leave it at that. It was shiny and glossy and everything that a Web 2.0 site should be. But I also thought it was pretty boring and indistinct, so I decided to change it. After all, this isn't a new technology startup to help you be more productive - it's a game, and a game based on absurdity and unpredictability on top of that! Looking boring indistinct is pretty much a death sentence for the atmosphere that I think the game should set.

So, I decided to take a looser approach to the style guidelines, rather than treating its recommendations as holy writ. I think there's a lot of things that make sense for my project - the design is going to be relatively clean so it's easy for newcomers to get an idea of what it's all about, and it's going to have strong, bold colors to make its branding clear. But, there will be no precious rounded corners or gradients. The icons and headers will not have a smooth, glassy sheen that you can practically see yourself in. I started with a logotype font with lots of irregular angles and flat surfaces, like a bunch of wood planks nailed (or bolted!) together, and I went from there. Overall, my goal is to make the type of interface that Apple will run screaming from.

Yes, I know that this will certainly take a while, and I'm kind of afraid of proving the adage "The perfect is the enemy of the good." This is already my third full iteration of the site design, and it hasn't even gone live yet! Additionally, the irregularity of the design may make it difficult to code in HTML. But I think it'll be worth it in the end.

Legality update

So the other day I met with an intellectual property lawyer through my entrepreneurship class, and I discussed the legality of Dangerous Apples with her. Although it was pretty brief, I think I was satisfied by the answers. The good news is that the basic idea of Apples to Apples is not copyrightable, meaning that no gameplay changes are required for my version. The bad news is that the branding must be different enough to make it clear that it's not Apples to Apples. So I'd really prefer to get away from both a name involving "Apples" and the red-and-green color scheme. Guess it's time to go digging back into those suggestions I had gotten before.

Another user test!

I just got back from a test with real, actual, live users, and overall, things went pretty well. I introduced a completely new set of people to the game, including my first remote user. Overall, people liked it a lot, but as usual, there were some issues that cropped up, which isn't surprising considering that I totally gutted the application's code since the last time I tested:

-First, it appears that I have lost the game of Web Browser Bingo that any web app must play. The "join game" screen was completely non-functional in IE 7, and one user was forced to download Firefox. As much as people should be using Firefox anyway, it's not really Dangerous Apples' place to force that decision on them.
-Some players did not receive a hand of cards when the game page first loaded, but received them upon a page refresh. I'm setting the "game has started" flag before the cards are dealt, so it's probably related to that.
-Occasionally, the function to reward the winner with an extra point and move onto the next judge was called multiple times, resulting in inaccurate scores and worse, an inconsistent judge status. This was also fixed by a refresh, but I'm not sure why it's happening.
-Some red cards came up multiple times in a game. This might be a race condition issue.
-It was a bit confusing to tell who had won the previous round. To fix this, I will restore the "Last round's winner" display, as well as highlight the winning card, both of which were missing.
-The game should be less formalized - people should be allowed to join and leave during the middle of a game (which might be an issue to decide where in the judge order they should go). Additionally, given that we got to round 34 out of 20, you should be allowed to play as many rounds as you want.
-Other than that, the main issues were just in terms of layout and making sure people know where everything is. And grammar fixes.

So I'd like to say thanks to all my testers (both in this session and in past sessions), and if I missed anything else, feel free to post it!

Anyone home?

Wow, I have a blog here! *brushes Internet dust off* Apparently I haven't updated this blog in quite a while - largely because I haven't updated Dangerous Apples in quite a while. The end of grad school was quite a turbulent one, and the project time that I did have was largely devoted to Blue Shift Hockey Charts instead. But I'm back, and even though I have a full-time summer internship, I'm going to try to find some time for getting DA finished.

So, just a little status update from where we last left off. I had a successful and favorable user test of DA back in March. I was even able to test it out on an entirely new user, who was able to pick up the interface without any questions whatsoever. That's a good sign! However, one user accidentally joined the room twice, which would have ruined the game irreparably had it not been for my intervention. This represents the type of issues that I feel I need to resolve before DA is ready for prime-time - the overall workflow is in place, but I need to make sure it handles errors such as this gracefully. It's not fun work, but it's certainly more fun than having your game explode on you.

In the meantime, I've started re-doing some of the client-side code, which was getting kind of ugly. I've installed jQuery and am in the process of re-writing my JavaScript code to use it. I wish I had known about it before I started writing A2A, it would've saved me a lot of time. But it'll allow me to add more nifty features (dragging cards to the table, anyone?) in the future. I think I will also have to replace the numerous layout tables with div tags, because it's just a huge problem.

Also, I did have another feature idea for the future. I'm largely designing DA around the idea that it'll be played by people who already know each other. This is why I haven't implemented a formal user account system like a lot of other game sites. With this in mind, I think it does make sense to set up something like a Facebook application where you can create a DA game and invite your friends. Besides Facebook, any suggestions for other social systems that I can exploit?

Finally, just as a general rant about the lengths that web development takes you to. IE 6 (and apparently 5.5) has a rendering bug in which dropdown menus (implemented by the select tag) will always appear "above" everything else on your page, even if you don't want them to. This was a problem for the index page, which features a dropdown menu showing all of the current games and a dialog box that lets you create a new game. Sure enough, the dropdown obscures the dialog box. Apparently, there is a fix for this involving an iframe, but I wasn't sure how to implement it on a draggable dialog box. I also didn't like the fact that dropdowns can't be styled, and that it wasn't fading out with the rest of the page when the dialog was summoned. So I actually wound up implementing my own dropdown menu that doesn't have these problems. Surprisingly, it wasn't that much more of a pain, but the whole principle of what I had to do just makes me shake my head in amazement.

Hopefully, that'll hold you guys until my next update, which I promise won't be as long in the making!

Hosting!

Sorry for the lack of updates recently, grad school intervenes. Anyway, this is a momentous day in the history of Dangerous Apples - it is now hosted! This means that beta testing can continue. Please let me know if you're interested in helping out and I'll give you the URL (preference given to local people, just out of convenience to me).

Big progress update

I just played Dangerous Apples with myself (well, two copies of me) for four rounds. Even though it died when I tried to play a card in the fifth round (the reasons for which I have not ascertained yet), I think this is a great step forward. After I figure out why it died and polish it a bit, I think it might be just about ready for initial testing!

...but I'm still not going to give an answer when it'll be done.

Red cards on table

One of the interesting decisions involved with porting any system to a computer for the first time is figuring out whether to completely replicate the old system, down to the finest detail, or to redesign it using the added benefits of a computer. For instance, if you were writing a computer program to call people, you could duplicate the way it's done on a telephone, by entering in the phone number, or you could redesign it specifically for the computer, using an address book or something similar. Do you stick with what people already know and are familiar with, or do you try to correct the flaws in the old design and make something new and better?

I've recently run into this kind of decision for A2A; specifically, I'm looking at what happens when people play red cards. I have a "table" area of the screen where you can see the red cards that have been played, and this is also where the judge picks the winning red card. Now, when anyone plays a red card, it will show up on the table, but what I realized is that, unlike the real Apples to Apples, I can show which red card it is as soon as it gets played. In the real game, you see people as they are playing cards, so revealing a card immediately would also reveal who played it. However, since this is an online game, you do not see people as they play cards, so everyone's identity is protected. This means that I can reveal the exact red cards as soon as they are played. I'm interested in how this change might affect the game play. Will it be amusing to see the cards immediately? Will people rethink their plays if they see what other people have played? Is it worth knowing who has played already? The good news is, it's not that hard to whip up two different versions of the game, one that mimics the original game and doesn't reveal red cards until everyone has played, and one that shows the red cards immediately, so I can test both.

Also, I've renamed the blog to "Dangerous Apples" instead of "Apples to AJAX" since I'm using that name on the current design. I'm heavily leaning towards "Dangerous Apples" for the final project. The blog will stay at the same URL, though.

Chat area

Thought I'd give a brief status update since I haven't had one of those in a while. I have just gotten the chat application up and running, at least on the status page. It's not perfect yet, since I've noticed that I'm dropping a few messages. They're getting into the database fine, but they're not getting displayed. I think it's just miscalculating which messages it needs to ask for.

Also, to conserve bandwidth, I'm only hitting the server every 2 seconds, so you're going to notice the delay between when you write a message and when it appears on the screen. In the future, I may have it post your messages immediately and just poll for everyone else's responses, but then I would run into messages being out of order. Unfortunately, this is a case where there's only so much I can do.

But this is a very good thing now, as this is how the final application is going to work! I also implemented playing a red card the other night, so I'm making progress on several fronts. It's coming together really well. Hopefully, that should do for an update for tonight.

Redesign

So I've done what could be considered a very bad thing, and redesigned A2A's game page entirely. Don't worry, it didn't come entirely out of thin air - I met with a friend of mine (thanks Jackie!) to discuss how it looked, and I felt that based on what she advised, I was better off doing something completely different. And you can see it here!

Here are some of the advantages I see of the new design:

1. Much better use of browser space. One of the most important suggestions that my friend gave me was maximizing my use of screen area. There was quite a bit of wasted space in the old design, between fonts that were probably larger than necessary, design elements that could not be used to convey information, and a few things that weren't sized relative to how important they were - for instance, the chat window was ginormous, and the judge interface was tiny. The game will fit into a 1024x768 monitor, even when there are twelve players, and hence twelve cards being played at once. It should also be playable in 800x600 as well. The old design wasn't even close to fitting into 1024x768 - in fact, only the chat window fit on my screen.
2. Less bandwidth. Given that there is going to be a LOT of AJAX-based communication going on, I need to conserve the amount of data I transfer as much as I can. And the primary way that I'm doing that is by removing most of the images from the design, since images are usually much bigger than text. The old design had a whole bunch of images, most notably the rounded corners and shiny buttons. Those are gone now, and the only images in the new design are the logo, the card background, the background image for the headers, and possibly whatever I do with the gavel icon.
   
3. Better organization of information. As stated before, I've resized some of the parts of the page so that they better reflect their importance. The judge interface has been replaced by a table showing every card that's been played so far, and the chat area has been reduced in size. I also added a little box at the top of the screen to indicate whose turn it is and what everyone needs to do, which should be a great help. I didn't really have anything like that in the old design.
   
4. Finally, it just looks better. It's kind of a relative and subjective measure, but I just like it better this way. The old version was just kind of pink and wimpy, but this is a little more dynamic.
   

On the other hand, I feel that I am going to web design Hell for this. Yes, I used tables for the design instead of divs and CSS. I totally understand and agree with the notion that divs are much more readable, and easier to maintain and update (although I'm skeptical of just how much of a redesign you can do just by updating your CSS file). However, I think tables have an advantage in that they just seem to do what I expect, whereas divs tend not to. Maybe that's just a function of having learned to design with tables, but I just think divs have a ways to go in terms of usability. I also could not find a way to implement my initial concept (the interface resizes to take up your entire screen) just using divs, whereas this was possible with tables. I think it's more important to be able to do something in the first place than being able to update or maintain it. As things are now, I think I could still redo it in divs instead, but I think I'm going to have to take the laziness approach for now.

Regardless, I promise to stick with this design for the "final" product and not stick you guys with any other redesign changes, although I still need to redo the homepage in this format, and I am reserving the right to make minor changes here and there.

Status update

So before I get too far into my insights on this, I thought I'd drop a quick status note on what I've accomplished with the game so far. I've had the overall design doc finished for quite a while, and I created the overall HTML templates a few months ago. So that just leaves the functionality pretty much. I was working on the Javascript and AJAX for the pages, but I realized that in order to work on that, I needed some kind of back-end, so I've been working on that recently. Here's the list of things you can do right now:

* Create a game room - it will add you to the player list and shuffle the cards automatically
* Play a card (partially) - the display logic is in place, but it does not record which card you actually played anywhere.
* Set "away" status (partially) - again, the display logic is there, but no one's listening on the backend.

Since I'm running all this off my laptop for the time being, I don't have a heck of a lot to show you, but in case you haven't seen them previously, you can look at my original image-based renderings of the game screens here and here. They're still largely accurate for what I've done already!

So what does this mean for the inevitable question of "when it's done"? Well, I've always been hesitant to make a definitive statement of where I am, how much is left, and when you might be able to get your hands on it. In this business, your position can really change at a moment's notice based on something you hadn't considered; and this is even before you get into user tests and debugging, when anything goes!

I'm (sadly) reminded of my time in the online gaming community, and development teams' general dislike of progress meters indicating that the project is, say, 65% done. I remember one project had a progress meter that would simply display a random number every time the page was loaded, and I myself made an image of a progress meter divided into categories (graphics, maps, AI, etc.), in which each category's percentage was listed as "When It's Done". Needless to day, I used this image at every conceivable opportunity. So unfortunately, I am going to have to stick you with "When It's Done" for the time being, but I hope to use status updates like this one to give you at least some verification that I actually am working on it here.