Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Save your forks, there's pie!

Entries in this blog


Why I turned down a great job offer.

I recently received a very generous job offer from a rather prestigious company. I didn't even apply, they contacted me through LinkedIn. To say that I was honored to even receive a cold-contact from such a company is an understatement. "Flabbergasted" is a much more appropriate term.

The salary was great. There was an additional cash bonus of approximately "holy crap" dollars. There was also a stock grant of even more "are you freaking serious" dollars. The projects sounded right up my alley. And the managers sounded like good people. All around, it sounded great.

But I had to say no, for two specific reasons completely unrelated to compensation packages.

I'm an east-coast guy and they wanted me to move to the left coast.

My family is here and my wife's family is here. We specifically live in a place that is convenient for seeing our families on a regular basis. We had considered the possibility of moving, if the job presented a clear opportunity for significant career advancement. But we'd also like to have kids soon, and that's going to peg us even harder to only a few hours' drive from where the grandmas and grandpas live.

Also, I've spent the last two--almost three years working as a freelancer. The term "free-lance" comes from the great Scottish author Sir Walter Scott, referring to a sort of medieval mercenary, one whose "lance" was free of any sworn allegiance to any feudal lords. I've been incredibly productive during that time. The corporate desire to have people "on site" grows more and more alien to me every day. I know what work I'm capable of, and I think being self-directed and independent has markedly improved my output. To be asked to go to a specific place to do work in our now rather aged era of telecommuting feels like being asked to intentionally hobble myself for nothing more than someone else's convenience. I think the work is more important than that.

I'm not done with my current path.

I started freelancing for a reason. I was dissatisfied with my work-life relationship and I hoped I could one day create the sort of company that I have always wanted to work for. Freelancing is not an end to itself, but it is hopefully a means. The flexibility it affords is much closer to that ideal work life that I envisioned for myself than I've ever encountered before. I'm able now to work on my own R&D projects in addition to the freelancing with a focus and effort for which I had never had the adequate time while I was working as a 9-to-5 stiff. To take the job would be to give up on those plans, just as they are starting to show promise.

I take the mercenary notion of freelancing very seriously. I operate by my own ethic, one that places doing the right thing and doing the most important things above doing what I'm told. When a client hires me, they don't just buy my time, tapping on a keyboard at whatever they want. They buy my opinions and my taste regarding how work should be organized. Sometimes that can come across as defiance, but I do it out of respect for their needs as I see them, not as they are expressed in the heat of the moment.

Freelancing is a system that explicitly maintains that--at the end of the day--I own my own labor. It is the nature of corporate non-compete and non-disclosure agreements to capture and monopolize my labor as much as possible, for as little compensation as possible--indeed, why would a contractual agreement be necessary if the compensation were enough? And to make "my" company, I need to own my labor. While the NDA and Non-Competes weren't a major deciding factor in themselves to turning down the job, the prospect of what they meant for my personal projects certainly helped the decision along. It would essentially mean cancelling most of my projects. Their offer, while generous, was not quite that compelling.

I just couldn't do it.

Through out the interviewing process, I had this voice in the back of my head, chiding me, "it's a great job, you don't turn down such a good job." I'm sure working for this company would have been very rewarding. But I don't want a "job". I think I can do more. And I think I owe it to everyone involved to do so.




Week of Awesome 2 - The Toys are Alive - #1

So Week of Awesome 2 starts on the day I have a half-day of job interviews and a demo of a product I'm working on. From 10:30am to about midnight tonight, I'm either driving somewhere or trying to present myself as awesome and totally not a slob at all. But tomorrow, I should be free for the rest of the week.

The theme is "The Toys are Alive". A title comes to mind, "Adult Toy Story". Nah, that's too obvious.

The key to a good game competition entry is to have a simple concept, executed well, completed early, to which "polish" is added with the remaining time. Yes, polish is a positive addition of things, like sprinkles on a cake. Also, to not neglect sound. Even the most basic sound instantly increases the quality of a submission 10-fold. One should stick to things one knows well. Venturing into new territory is a good way to get "stuck in the weeds" and fail to complete a submission.

With that in mind, I should probably be making a business intelligence suite, perhaps a series of reports demonstrating the effectiveness of a hospital full of toys. "Toy Hospital Administrator Simulator". I'm sure to win[1]!

Since I still don't have a real concept in mind after half an hour of typing, I'm going to continue to fill space with useless junk about strategy.

HTML5/JS game. I'm going to reuse my growing project template for doing HTML5 web apps. It's all just boilerplate stuff for loading bars, rounded corners on buttons, that sort of junk. Other people might use something like Angular or Bootstrap, but I am too old for that shit.
2D graphics. I'm still learning Three.js in my WebGL Virtual Reality[2] project, so I'm going to stick to what I know and do Canvas 2D instead of WebGL 3D.
3D audio. It's just so easy to do in modern browsers, why the hell not?
Mix of procedural and static content: Maybe a static level-select map and procedural levels.

Figure out a proper concept to meet the theme
I don't currently have a good system for easily specifying and running keyframed 2D animations. Will have to figure something out here. Might be where I spend most of my time on this project.
I have simple boilerplate code for doing multiplayer stuff, but I feel like only a really good concept should have it. To add it as a gimmick would be detrimental.

Okay, that is all for now. I'll update this post here if I think of any concepts.

[1] Only if there is a "biggest Poindexter" award.

[2] Check it out. Star it. Follow it. Fork it and make contributions. Ask nicely and get direct commit access!




WebRTC device syncing


Big update today. When you use your PC in conjunction with your Smartphone, the two devices will communicate over your local network, rather than having to take a round trip through the game server. This reduces latency, so when you move your mouse, it updates in the display almost immediately.




VR Lessons Learned So Far

This is a loosely organized list of things I've noticed while using and developing virtual reality applications for the smartphone-in-headset form factor. It is specific to my experience and may not reflect anyone else's personal preference, such that VR is apparently quite dependent on preference. But I think that steadfast rules of design are necessary for the impending VR bubble, to convey an aesthetic and unified design such that users may expect certain, common idioms and adapt to VR software quickly. Thus, this is list a roadmap of my current aesthetic for VR. It is a living document, in the sense that future experiences may invalidate assumptions I have made and force me to recognize more universal truths. Proceed with caution.[/font][/color]
Presence is the ability to feel like you are in the scene, not just viewing a special screen. You'll hear a lot of people talk about it, and It is important, but ultimately I believe it to be a descriptor of an end result, a combination of elements done well. There is no one thing that makes "presence", just as there is no one thing that makes an application "intuitive", "user friendly", "elegant", or "beautiful". They either are or they are not, and it's up to the individual experiences of the users to determine it.
Presence is a double-edged sword. [font=inherit]I've found that, once I feel "present" in the application, I also feel alone, almost a "ghost town" feeling. Even if the app has a single-user purpose, it seems like it would be better in an "arcade" sort of setting. To be able to see other people may help with presence.[/font]
The hardware is not yet ready for the mass market. That's good, actually, because the software and design side of things are a lot worse off. Now is the time to get into VR development. I'll say nothing more about the hardware issues from a performance side. They are well known, and being worked on [font=inherit]fervently [/font]by people with far more resources than I.
Mixing 2D and 3D elements is a no-go. Others have talked about not placing fixed-screen-space 2D heads-up-display elements in the view for video game applications, but it extends much further than that. The problem is two-fold: we currently have to take off the display to do simple things involving any sort of user input, and there is no way to manage separate application windows. We're a long way off from getting this one right. For now, we'll have to settle for being consistent in a single app on its own. A good start would be to build a form API that uses three-space objects to represent its controls.
Give the user an avatar. This may be a personal preference, but when I look down, I want to see a body. It doesn't have to be my body, it just needs something there. Floating in the air gives me no sense of how tall I stand, which in turn gives me no sense of how far away everything is.
Match the avatar to the UI, and vice versa. If your application involves a character running around, then encourage the user to stand and design around gamepads. If you must have a user sit at a keyboard, then create a didactic explanation for the restriction of their movement: put them in a vehicle.
Gesture control may finally be useful. I'm still researching this issue, but the experiments I've done so far have indicated that the ability to move the view freely and see depth make gestures significantly easier to execute than they have been with 2D displays. I am anxious to finish soldering together a device for performing arm gestures and test this more thoroughly. This demo makes it clear that this is at least an extremely lucrative path of study.
Use all of the depth cues. Binocular vision is not the only one. Place familiar objects with well-known sizes in the scene. Use fog/haze and a hue shift towards blue at further distances. But most importantly, do not give the user long view distances. Restrict it with blind corners instead. Binocular vision is only good for a few feet before the other depth cues become more important, and we are not yet capable of making a convincing experience without the binocular cue.
Object believability has more to do with textures and shading than polygon count. Save on polygon count in favor of more detailed textures and smooth shading.
Frame rate is important. I remember being perfectly happy with 30FPS on games 10 years ago. That's not going to cut it anymore. You have to hit 60FPS, at least. Oculus Rift is targeting 75FPS. I'm sure that is a good goal. Make sure you're designing your content and algorithms to maintain this benchmark.
Use lots of non-repetitive textures. Flat colors give nothing for your eyes to "catch" on to make the stereo image. The design of these viewer devices is such that the eyes must actually fight their natural focus angle to see things in the display correctly. It will be easier for the user if you make it as hard as possible to not focus on object surfaces. Repetitive textures are only slightly better than flat colors, as they provide a chance to focus at the wrong angle, yet still achieve what is known as the "wallpaper effect". And do not place smaller objects in any sort of pattern with regular spacing.
Support as many different application interactions as possible. If the user has a keyboard hooked up, let them use the keyboard. If they have a gamepad, let them use the gamepad. If the user wants to use the app on their desktop with a regular 2D display, let them. Do not presume to know how the user will interact with the application. This early in development, not everyone will have all of the same hardware. Even into the future, it will be unlikely that an app will be successfully monetizable with a user base solely centered on those who have all of the requisite hardware to have a full VR experience. [font=inherit]Be maximally accessible.[/font]
[font=inherit] Make the application useful. This seems like it shouldn't be said, but ask yourself what would happen if you were to rip out the "VR" aspect of the application and have people use it with traditional IO elements. Treat the VR aspect of it as tertiary. Presence by its very definition means forgetting about the artifice of the experience. If the experience is defined by its VR nature, then it is actively destroying presence by reveling in artifice.[/font]
[font=inherit] Much research needs to be done on user input especially for large amounts of text. Typing on a keyboard is still the gold standard of text entry, but tying the user to the keyboard does not make for the best experience, and reaquiring a spatial reference to the keyboard after putting the headset on and moving away from the keyboard is nearly impossible. Too often, I find myself reaching completely behind in the wrong direction.[/font]
[font=inherit] 3D Audio is essential. We could mostly get away without audio in 2D application development, but in VR it is a significant component to sensing orientation and achieving presence. I believe it works by giving us a reference to fixed points in space that can always be sensed, even if they are not in view. Because you always hear the audio, you never lose the frame of reference.[/font]
I may add to this later.[/font][/color]




the nature of cursing

Note: this post will contain offensive language. As a treatise on the nature of cursing, I believe A) it's necessary, and B) it's appropriate.

Swear words primarily must be offensive. It has to be a taboo word that one uses out of context from its actual denotation. Most of our current swear words are slowly becoming less taboo, meaning their status as swear words is diminishing. There are some notable exceptions, like "nigger" and "faggot" that are becoming more taboo. However, words like "fuck" and "bitch" are definitely decreasing in their taboo level. When my grandmother can say "I am so sick of that fucking asshole", then you know the impact of those words is not quite the same as what it used to be (of course, my grandmother also works at a bar...).

Because of the necessity of the taboo of a word, made up words are not usable as swear words. For new swear words, you must find a word that is not commonly used, is taboo, and is not currently used as some form of epiteth. Racial slurs are quite taboo, but they're already in use, so they do not qualify. For a new curse word to be any good, people must blush or even gasp when they hear it. This is not a nicey-nice game.

I mentioned that the word is used out of context. Words often have conflicting conotations and denotations. Take this (very) short list

word denotation conotation
fuck to copulate (when used alone) an expression of anger
bitch a female dog a complaining woman
shit fecal matter an expression of anger
faggot a bundle of a homosexual male
sticks and
twigs used to
transport embers

Notice that the words themselves have certain features in common, specifically they are short, often monosyllabic (the word "faggot" is most frequently used as just "fag"), and often composed of hard consonant sounds. Thusly, the word "languish" would not make a good curse word, as it is too long and composed of mainly soft sounds.

So, what short, harsh words fit this necessary taboo nature, and in what context would using them make them a reasonable curse word?




The Future of the 3H-GDC

Alright, so we just finished another wonderful contest, with the highest contestant participation yet. A total of 10 contestants and 8 submissions that came in on time. The submissions were actually all rather impressive for only 3 hours of work.

But where to take the 3H-GDC from here? It's starting to get really popular, and the prizes that were donated for this fourth one were really freaking expensive. I'm beginning to think it's time to get serious about the 3H-GDC.

How serious? Well, holding it regularly, having real corporate sponsors with really, really expensive prizes, having a real website with a real submission process. Basically, fixing everything that I do rather off the cuff right now.

Comments, suggestions? Please don't discuss the base-code issue here, I'm starting a new journal thread for it, as I do think it is a very important issue to get "right".




TDD of graphical applications

I use a lot of Test Driven Development with my projects, mostly because I'm a shitty programmer without it, it is my crutch. But one problem with TDD is that it isn't really suited to anything graphical. You can do some generalized, precursory tests, stuff like making sure the image is the right proportions (like that's hard to do ;)), or checking pixels in very small images (large ones would be far too tedious), but nothing that really ensures that things are actually "right".

Regression testing is a possibility, but it requires screenshots from an existing system (kind of defeating the purpose of TDD), and the tests will fail even if there is 1 pixel different over 1 million pixels. Not very robust.

However, what possibilities lie in the field of signal processing? We can use various concepts of signal processing to compare a compressed image to the original image to get an idea of the level of information loss due to lossy compretion algorithms. What if we also employed neural networks in an attempt to recognize objects actually in the picture?

Again, another project that I will probably start with no intention of finishing.




TDD for the masses

If you hang out in #gamedev, then you've heard Washu and I talk a lot about WHY you should use TDD, with plenty of horror stories of when people DIDN'T use TDD. But we don't really talk about HOW to use TDD. I wrote this 1-printed-page (had to cheat on the margins) document for use at work, in an attempt to convince everyone else that they should be using TDD, just like they said they would. (don't ask) Anyway, it covers the main points (though not all of them), and has a couple of resource links for more information. The point of this doc is to be short. People won't pay attention to 2+ page docs.

Test First, Ask No Questions Later

Test driven development (TDD) can help developers create higher quality code on first iteration, as it helps developers avoid common errors of logic and design. The tests serve as a form of documentation, making clear the proper usage of the code. A large test suite facilitates subsystem integration, as it provides immediate feedback when new changes break old code. Test results are explicit and discrete, giving a better overview of the development progress. In short, tested code is confident code.

The TDD cycle:
1.) Take small implementation steps; large changes introduce large bugs,
2.) Design your implementation with testing in mind; determine what defines successful completion of the requirement and how to test for that completion
3.) Write one test; resist the urge to code in large runs,
4.) Write enough code so that your tests compile; do not write an implementation--just stubs,
5.) Run your tests, your new test should fail; if this is a tertiary pass through the TDD cycle, your changes may cause other, previously passing tests to fail,
6.) Write just enough code to pass all the tests; do not continue until all the tests pass, in this way you know that your changes do not break existing code,
7.) Refactor as necessary; minimize duplicate code, eliminate inefficiencies,
8.) Continue from step 2; consider if you need to expand your testing, remember to test boundary cases of input (bad input, good input that is close to being bad, typical input, etc.),
9.) Return to step 1; continue implementing small pieces of the requirement.

Tips on writing good tests:
1.) How to move a mountain: blast it into pebbles. Small tests (as defined by the number of Assertions made by the test) have a very high "Testing Resolution". A failed assertion immediately terminates the test, even if the test contains more assertions. Large tests with multiple assertions may hide assertion failures that occur after the first failed assertion. By splitting multi-assertion tests into single-assertion tests, all Assertions that can fail will fail, giving a higher resolution picture of the defect at hand. The test itself may be long on code to prepare for the Assertion, but it should only have one or two assertions.
2.) Test early, test often, test everything. Developers may feel like TDD requires more time than coding without testing. Initially, this is true. The developer not only takes the time to write the code, they also take the time to write the tests. The total amount of time spent on the code is far less, as higher quality code requires fewer bug fixes.
3.) The only good GUI is a thin GUI. How will you programmatically duplicate user interaction with reliability, precision, accuracy, and flexibility? Design GUI's as only being a front end to well-tested, GUI-independent logic classes. Ensure the GUI elements are receiving the expected bindings and trust that the GUI elements of the Operating System work as advertised. This also aids in code reuse.
4.) In with the good data, out with the bad. How will you programmatically ensure that a map does not render 500 feet off kilter? In general, data validation must be completed via Regression Testing (comparison to known good results) or typically "by eye".
5.) For more information:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp02172004.asp (includes an example project)
http://www.nunit.org/getStarted.html (getting started with nUnit)




Story-Driven Game Framework: an Enterprise Approach

I've been talking with a couple of guys here at work about game development. We're all avid gamers across all different types of games (i.e. electronic, board, pen-and-paper), and we are all fairly successful enterprise software developers. So, I'm trying to take the results of our discussions and formulate them into a general software design for character driven games, as distinctive from sports games or puzzle games, etc.

The basic idea is that the resulting game framework should be suitable for developing open-ended worlds with story-centric interactions. The emphasis is really on story telling, then game play (which may include multiplayer). Only after these aspects have been fulfilled will graphical quality be considered.

As what we really care about is the gaming system itself, not the means in which the user interacts with it, the Game Client portion of the design will be relative thin compared to the Game Server portion. In this case, "client" and "server" are relative terms. If possible, sinking the server into the client and removing the network stack should be sufficient to make a single-player game. So, such considerations as graphics and sound will be of little interest. Arguments over "DirectX vs OpenGL" are unnecessary, because in all reality, the first client will probably be text-based. UI considerations will only be "that which is enough to demonstrate the capabilities of the framework."

I have a ton of notes on paper, and still a ton of research to do, but I have been able to build a basic outline thus-far. Much of the project will be filling in the blanks from here.

1) Introduction
a. Purpose
b. Document Conventions
c. Intended Audience
d. Suggested Reading
2) Scope
a. Define
i. Need
ii. Goal
iii. Objectives
iv. Business Case
v. Assumptions
vi. Constraints
b. Operational Concept
c. Known Risks
3) Requirements
a. Overview
b. Game Network
i. Topography
ii. Encryption
iii. Data
iv. Performance
c. Story Telling
d. Physical Representation
e. Game-Play
f. Server
g. Client
4) Game Server System Design
a. Overview
b. Server Environment
c. Game-Play
d. Story
e. Mapping
f. Physics
g. Scripting
h. Artificial Intelligence
i. Networking
j. Database
5) Game Client System Design
a. Overview
b. Expected User System Requirements
c. Networking
d. User Input
e. Graphics
f. Sound
6) References
7) Appendix A: Glossary
8) Appendix B: Areas for Further Research

I don't really need to complete these sections in a linear fashion. In fact, a linear progression would probably be stifling to the process. Continuous refinement and parallel implementation will be necessary to fully account for all features and pitfalls.

I realize that what I'm undertaking is pretty much the software development equivalent of putting a man on the moon... with tools from my garage. However, I think the goals of the project and the milestone goals (unpublished as of now) will set me up for having some sort of useful results even if they don't make it into one system.

Incidentally, my journal writeup here serves as a pretty good start for the intro bullet.




so busy

well, I've been quite busy lately.

Two weeks ago, I started a new job working on a GIS web portal. Right now, I'm running through QA testing, oh joy, oh rapture, take me now. I HAVE NEVER BEEN SO FREAKING BORED IN MY LIFE!!!

On occasion, I get to write some code. It's funny, I was hired because I knew how to program C# using the features of .Net, and I had some experience with the eXtreme Programming methodology, which they are transitioning to (from what, I don't know, maybe CBTSOYP).

Transitioning to XP, my ass. They are flat out RESISTING it. Absolutely NO pair programming. Tasks are assigned, not volunteered. Strangely, we ARE doing the morning standup meetings. Almost no unit testing, and certainly no test driven development. I wrote a single class the other day and quadrupled the number of unit tests in the entire project, and it wasn't a large class (it handled adding and retrieving URLs from a DB). And yet, they find themselves with the problems that XP is meant to prevent (breaking large portions of functionallity when refactoring, ensuring that components integrate properly, etc), and wonder why.

(I need to cut this short, at work *right now*)

Some of you have probably already read "wasting time, but getting paid for it, so it's okay". So you'll know that little bit of code that I got to write is basically 50% wasted. I can reuse the DB code, since it's essentially the same data, I can reuse the data retrieval module (thankfully, that's the class that quadrupled the number of tests). But I have to completely rewrite the UI and the business logic, and add on top of that an RSS aggregator. Oh, did I mention that our "client" stipulates that we cannot use any OSS of any kind? (not that *I* mind, but I think the VP won't like the fact that I'm going to have to spend a few days reimplementing something that could be just dropped in).

I went to Miami, Florida to visit a friend and just generally party for 5 days. It was great, I took pictures.

I've gotten no work on projects done since starting this new job. It's about an hour drive to and from work, so by the time I get home I just want to eat, relax, and get to bed by 10pm so that I can get up at 5am and start over again. I hope it doesn't stay like this.

My flipping computer died. I think it's the hard drive. Luckily I keep all my docs on the secondary drive. And I don't have any money... I still need to buy a car and pay off my student loans. Someone kill me now.




Refactoring with Pong, ep 2

okay, last time on Refactoring with Pong, we demonstrated a poorly designed program, a pong game written in under 30 minutes, with no attention paid to design, naming convention, or documentation.

Now, the engineering process wasn't completely lost. A lot of problems were completely skipped because I used Eclipse. There are a lot of times where Eclipse just won't let you be a stupid programmer, unless you are absolutely ademant about it. Specifically, Eclipse made sure I had all the right classes imported (as well as made sure there were no extra packages imported), as well as made sure each method stub for each interface was at least included in the source file.

However, Eclipse did NOT tell me when I multiplied the y coordinate of the ball by -1 instead of multiplying the y component of the ball's velocity by -1 for bouncing off the side walls. Damn you, you stupid piece of garbage, do what I mean!

Okay, let's discuss the code:

import java.awt.Color;
import java.awt.Cursor;
import java.awt.Font;
import java.awt.Graphics2D;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
import java.awt.event.MouseMotionListener;
import java.awt.image.BufferStrategy;
import java.util.Random;

import javax.swing.JFrame;
import javax.swing.Timer;

* Created on Jul 13, 2005

public class Pong extends JFrame implements MouseMotionListener, MouseListener, ActionListener
int p1x = 10, p1y = 0, p2x, p2y = 0, bx, by, bdx, bdy, s1 = 0, s2 = 0, state = DEAD, minspd = 2;
static int DEAD = 0, PLAY = 1;
Random r = new Random();
BufferStrategy bs;
Timer t;
super("Pong in 27 minutes");
this.setBounds(0, 0, 800, 600);
bs = this.getBufferStrategy();
t = new Timer(1, this);
p2x = this.getWidth() - 10;
* @param args
public static void main (String[] args)
new Pong();

public void mouseDragged (MouseEvent arg0)
// TODO Auto-generated method stub

public void mouseMoved (MouseEvent arg0)
p1y = arg0.getY();
public void actionPerformed (ActionEvent arg0)

public void paint()
Graphics2D g = (Graphics2D) bs.getDrawGraphics();
g.clearRect(0, 0, this.getWidth(), this.getHeight());
g.fillRect(bx-5, by-5, 10, 10);
g.fillRect(p1x-5, p1y-20, 10, 40);
g.fillRect(p2x-5, p2y-20, 10, 40);
g.setFont(new Font("fixedsys", 24, 24));
g.drawString(""+s1, this.getWidth()/3, 60);
g.drawString(""+s2, this.getWidth()*2/3, 60);
g.drawLine(this.getWidth()/2, 0, this.getWidth()/2, this.getHeight());
if(state == DEAD)
g.drawString("click a mouse button to start play", this.getWidth() - 500, this.getHeight()/2);

public void update()
if(state == PLAY)
bx += bdx;
by += bdy;
if(bx >= this.getWidth()){
state = DEAD;
else if(bx0){
state = DEAD;
if(40>= by || by>=this.getHeight())

public void checkPaddles()
if(p1x - 5 5 >= bx && p1y - 20 20 >= by)
int dy = by - p1y;
bdx *= -1;
bdy += dy/10;

else if(p2x - 5 5 >= bx && p2y - 20 20 >= by)
int dy = by - p2y;
bdx *= -1;
bdy += dy/10;
public void AIMove()
if(by > p2y) p2y += 7+minspd/2;
if(by 7+minspd/2;
public void mouseClicked (MouseEvent arg0)
if(state == DEAD)
bx = this.getWidth()/2;
by = this.getHeight()/2;
bdx = r.nextInt(5)+minspd;
bdy = r.nextInt(5)+minspd;
state = PLAY;

public void mouseEntered (MouseEvent arg0)

public void mouseExited (MouseEvent arg0)
// TODO Auto-generated method stub

public void mousePressed (MouseEvent arg0)
// TODO Auto-generated method stub

public void mouseReleased (MouseEvent arg0)
// TODO Auto-generated method stub


there are so many things wrong with this code, I don't even know where to begin. Probably the biggest thing is that only half the code is there.

"Wait... what?" you say. "I'm looking at the code right now. I see two paddles, a ball, a window to play in, and enough processing to actually get the game running, even have score keeping. What could be missing?"

Tests. This code is not tested. The fact that it even ran the first time was only because Eclipse let's you know when the code is free of syntax errors AS YOU CODE. I wrote code without ever writing a single test first, and that is just a cardinal sin.

Though tests are not actually a refactoring process, they are essential to refactoring. The tests are what tells you "you stupid programmer, you 'fixed' the code and now nothing works". They also tell you exactly what happened after you "fixed" the code.

What else is wrong... bad variable names, lack of any reasonable OOP features, completely monolithic design, duplicated code (maybe I could have got it done in less than 27 minutes if I hadn't duplicated so much code), and a GUI intertwined into the logic code causing a tanlge worse than the cables behind your desk (seriously, how do they get that way? I remember draping them neatly back there, why the tangle?). It's amazing I ever got this thing to run.

Ugh, I've sickened myself. I need to stop for today. Think about these problems and we'll meet again tomorrow.




presenting at SE conference

One of my old profs is running a software engineering conference at my old university. She has asked me to give a brief presentation. I will be speaking on "the roll of testing in self-guided research."

I will be relating my experiences from my senior research project "Optical Illusions in Computer Graphics." I've identified three different types of testing that I utilized over the course of the project:

Unit Testing: in support of the Test Driven Development design paradigm that I used for the project
User Acceptance Testing: in the form of a survey ran here on Gamedev. The survey was used to determine the effectiveness of the optical illusion techniques.
Performance Profiling: in support of the justification of the project -- that it would provide data complexity similar to more complex, traditional techniques, at a "cost" equivalent to simpler, less data-complex techniques.




Preparing for senior year

Well, one more year of college. I think...

This year I am Vice President of the programming team (it sort of fell on me, like a tree falls on a parked car during a hurricane). I am also the President of the new Upsilon Pi Epsilon chapter on campus (we're Alpha Beta Sigma). I will also have some sort of advisory capacity to the campus ACM chapter, since I was president last year and this year's president will probably need a lot of help.

I'm working on Sundays, stocking bread on shelves in the Harrisburg/Camp Hill area. I'm going to be trying to sell some websites, don't know how well that will go, need to bang out some templates. The problem is, web design is usually packaged along with some sort of hosting plan, and I don't have any hosting capability.

Work will continue on Showdown IRC. I also intend to start a new project, similar to Showdown but themed around snipers, with movement. I also intend to limit the use of the IRC server. With Showdown, it's a stand-alone IRC Client with an embeded game. With this sniper game, I intend to make it less obvious it is an actual IRC client and seem more like it's a regular game server.

The idea is to not allow the user to select the IRC server (or perhaps severly limit this option) and not allow the user to join any channel they choose. With Showdown, the game client user and regular IRC client users can interact freely, which spreads users of the game client too thin -- they can't find each other. By removing the selection of server and channel, I force all of the users into one location (and since there are very few users for such an indie game, this is a good way to ensure they all come tomether). This channel should be password protected, and the password automatically relayed by the game client (a manner of authenticating to the channel that the joining user is actually using the game client, leaving regular chatters outside).

From there, users will create "rooms" which are tertiary channels, password protected in the same way as the lobby channel. In this way I can ensure more rigid control over >2 users joing a game.

I'll write a lobby-bot that will not appear in the user list, and will respond to automatic queries about room status'.

Basically, the idea is again to use the preexisting IRC server as the game server. However, this time it is meant to be more transparent to the user, making it appear more like a traditional game server. I guess it's similar to MSN's gaming zone lobby system, just I don't actually own the servers.

This will be an excellent way for me to learn C# and Managed DirectX. I'm obviously fully capable of the design necessary for the game, as I was able to create Showdown on my own. Now it's just a matter of learning the syntactical and library differences between Java and C#.

Oh, did I mention I'm also taking 6 classes?




Power Outage Fried My Computer

Yup, my main desktop was dead for about two weeks thanks to a power outage. I originally thought that it was just the hard drive, because I could boot it up, but it would die whenever I got to a certain point in loading Windows. After closer inspection, I have determined that the outage actually fried my graphics card (Radeon 9800 something something). The fan on the card's heat sink is siezed and the chip under the heat sink is charred around the edges. I've got an old 9200 SE in it's place right now, but it's giving me weird scanline issues and I can't change my display settings. Eh, whatever. I got my documents backed up to an external USB hard drive now, and I got the important documents burnt off to CD, so everything is safe.

Right now the desktop is operational, but I'm concerned that the reason the GPU was fried was because the mobo is faulty. This computer has always had problems of some type, from frying parts to never being able to properly handle a warm OS restart. If I perform a restart instead of a full shutdown cycle, it loses its secondary IDE channel and halts processing for about half a second about every 5 seconds. This isn't an OS issue, it did it to Linux and BSD, too. That, coupled with the fact that it has become prohibitively expensive to upgrade the memory (Rambus RDRAM, wooo), and it's clear that this computer just has to go.

I had been considering rebuilding it to a usable configuration and gifting it to a family member, but given the restart issue I don't think that is a workable solution as none of them will understand what is going on or how to fix it (just shut it down). It took me a year to figure out exactly what was going on, I don't want to leave that kind of bug for my grandmother or someone.

Incidentally, my laptop has hit a brick wall, too. It's running fine, but it's just not powerful enough to do the things I want to do. It's an old P3 1.2Ghz machine, but it uses an integrated Intel graphics chip, so it doesn't support the minimum specs for doing XNA development. When I got the laptop, even though it was literally half the specs of my desktop in every way (512mb of ram instead of 1gb, and a 1.2ghz processor instead of 2.4ghz, a 20gb hard drive instead of a 40gb hard drive, etc, etc), it had almost completely replaced my desktop because I could use it in the livingroom instead of having to retreat to the basement where I keep the desktops. Since XNA has replaced Hardware Accelerated Java2D for me, in everything from ease of development to support to performance, if my lappy can't do XNA, then it's pretty much worthless to me.

So right now, the only computer I have at my disposal is my work laptop. At least it seems to be working ok. Knock on wood.





For my asteroids/elite-like project, I want to have featureful physics system. I've never really coded physics stuff before, but I have a pretty good handle on mathematics, so as long as I do enough relearning I should be fine. I've had a lot of success in the past with keeping this journal during my development process, so I'm going to do it again.

Before I get right into the physics talk, I should briefly describe the game. The idea is to create a multiplayer solar system sandbox. I want simple, vector-style graphics ala Asteroids, and I want a simple economy of trade/piracy, ala Privateer, Freelancer, etc. I have a bunch of ideas of things to add after that, but for now that's the basic idea.

For a first-cut system, I want to model all the ships and asteroids as if they were billiard balls. This is a pretty close approximation for the asteroids, but it's a little rough for the ships. However, at this point it doesn't really matter, as even simple billiards would be better than what I currently have (it's abysmal, I shant share it with you).

I'm using http://billiard-physics.net/ to brush up on my kinematics. I could rederive most of the equations, as I sort of remember most of them, and know how to find them, but I'd rather just save the time and look them up. I have my old college physics text down in the basement, as well as my calculus text. However, I remember these covering mainly static systems, dynamics wasn't really covered that much.

The game won't have a 100% perfect physics system, for example, I plan on setting the maximum velocity to something much slower than speed-of-light. Also, I will have to strike some kind of balance in conservation of momentum, as users arbitrarily accelerating into asteroids in a frictionless environment will increase the total kinetic energy in the system indefinitely (and I'm definitely NOT going to model chemical-to-kinetic energy transformations).

That's it for now. I'm going to Buffalo, NY for the Bills vs. Packers game on Sunday. Most of the code that I have written right now is mostly thumbnail sort of stuff and I will probably throw most of it away.




Optical Illusions: what's next

In the original optical illusion project, all hills are of equal slope. In order for a hill to achieve greater altitude, it's base area must increase as well. This leads to a "throne thought" (i.e. a thought you have while sitting on the "porcelain throne"), is it possible to indicate areas of greater slope in the optical illusion rendering technique?

The rendering technique is based off of a specific tile design. A little ASCII art is necessary:


This is an 8x8 pixel tile. There are two color values, and they may be alternated. There are 3 more patterns that are rotations of this pattern, there are 2 patterns with the two smaller squares in opposing corners, and 1 blank tile with no small squares. With all small-square orientations and color alternations, there are a total of 14 tiles.

Without the small squares, there is no illusion, the illusion springs from the small squares in a way that I only understand intuitively; I cannot quite articulate it. All I can really say is that it sort of tricks the mind into seeing an aliased line, the stair-stepping that happens when rendering a solid line on a raster display without an anti-aliasing algorithm.

With the 8x8 tile, the small squares MUST be this size, any larger and they are no longer visible as squares (they would appear as half of the tile); any smaller and they are single pixels and too small. However, with larger tiles, like 32x32, the size of the smaller squares can be modulated. This may enable us to indicate areas of differing slope. The direction of the slope selects the tile pattern and the magnitude of the slope selects the size of the small squares.

We'll see.

edit: oh, I got an A on my paper.




Optical Illusions in Computer Graphics #9

I've finished a 40"x48" poster as a summary of my research project. It is supposedly going to be hung in the hall of my CS department for a year. I guess I'll have to come by and see it some time.

Poster (4.0MB).

Also, my abstract was published in the St. Joseph's University Sigma Xi Research Symposium Abstract Booklet. See page 58.




Optical Illusions in Computer Graphics #8

On Friday I attended the Sigma Xi Student Research Symposium at St. Joseph's University. We actually had a total of 5 students from Ship presenting, all pretty good projects.

The keynote speaker for the event was Dr. Joy Crisp of the Jet Propulsion Laboratories. She spoke about the Mars Rover project, and had some very interesting things to say about the evidence of liquid water they have found on Mars. After the talk, I even had the chance to talk with her. In fact, one other student from my school and I nearly monopolized all of her time.

We had our posters setup before the speach, so all we had to do was walk over and present. Basically, we stood next to our poster for 45 minutes (there were two "shifts" in this manner), and whomever wasn't presenting at that time/at all would walk around and ask questions. Dr. Crisp came by and asked all kinds of questions about my project, she seemed genuinely impressed.

I'm very happy with the event. Well, that's mostly because I got to try a real philly cheese steak for the first time, but the symposium was good too. I think I (as well as my fellow Shippensburg students) had one of the most original projects there. I know someone's project was "modelling the solar system in OpenGL and C++" and their abstract did not indicate how this was any different than what everyone does in Intro to Graphics. Someone else was doing some stuff with Normal Mapping. Their abstract made it sound like they were doing really revolutionary stuff, but I couldn't figure out how this was any different from Doom3, Far Cry, or Rainbow Six 3. I really wanted to go over to their posters and see what the big deal was, but I had people asking questions for the entire hour and a half for the posters (yes, that means I was presenting outside of the timespan I was expected).




Optical Illusions in Computer Graphics #7

okay, here are some preliminary results.

For test #0, there were a total of 125 attempts, of which 7 were successes and 118 where failures. This is a 5.60% success rate. This test was (as guessed by Monder) a control against random selection of points.

Test #2: 155 total attempts, 151 successes and 4 failures. That is a 2.58% failure rate. Since the isometric map makes the height of the hills very apparent, the user should be able to determine the highest hill every time. This test is therefore a control against user error, as well as the unfortunate habit of the program to put the hill against the edge of the map (an easy fix, I only just noticed it today).

Test #1: Out of 150 attempts there were a total of 127 successes and 23 failures, an 86.67% success rate.

For anyone that explicitly said they had problems with the program, I removed their data point. This data is considered corrupted. If we consider people who got 0 or 1 successes as statistical outliers, then the success rate for test type 1 jumps to exactly 90%.




Optical Illusions in Computer Graphics #5

Getting closer to the final product (I better hope so, I'm presenting it in 2 days). Here you can see the three images of the eventual survey. These three images represent the same tilemap data rendered using three different methods. The first displays no height data whatsoever. It will be used as a control against users that guess at random. The third is an isometric map that makes the height of the hills very apparent, this will be used as a control of the effectiveness of the solution (will users be able to pick the hill as easily as normal). The second image is the experiment.




Optical Illusions in Computer Graphics #4

I have prepared a set of surveys that I hope to distribute soon. I can't talk about the survey very much, or what the survey will be testing, because obviously that may compromise the survey.

Obvious aspects of any survey experiment

The survey is an experiment:
You first create a hypothesis, what you expect to happen based on your observations while researching and preparing for the survey. You then create an experiment that will either prove or disprove the hypothesis. If you hypothesize that shoe size correllates with hand span, you will design an experiment to collect the associated data of a participant's shoe size and hand span, but you will NOT also measure that person's height, because that has nothing to do with the hypothesis in question.

There is more than one survey:
Your variables are the participants (and any knowledge that they may bring), the environment for the survey, the information you give the participant, and the questions you ask the participant. In order to appropriatly account for each variable, you must create a number of minutely different surveys.

There are certain variables you cannot control:
This is probably the number one consideration of any experiment. All other considerations stem as a necessity from this consideration.

I will not be able to control the participants environment past the framework I create for distributing data. Since this survey will be computer-based, this means that not only do the person's system specs become a consideration, but so does the entire area around the participant. Since I cannot see this area around the participant, I will have to collect data from many participants.

For this reason also, we must select participants for each specific survey at random. This will ideally distribute the variation in the uncontrolled variables across all experiments, giving them the same error.

The knowledge of the participant can effect the outcome of the survey (or, why we need control experiments):
If a survey participant knows what you are trying to test/prove, then the participant will either conciously or unconciously skew their replies to match your expectations. It is vital that you control the amount of information your participants have on the survey. Part of this means that you will also conduct two sets of experiments: one where the participants are provided with no knowledge of the test, and one where the participants are provided with some knowledge of the test.

For example, say I am testing the effects of minute amounts of alcohol on the ability to drive. I hypothesize that, in small quantities, alcohol will act as a mild stimulant and actually increase the participants driving ability. I will conduct three sets of experiments, one in which I tell the participants nothing about the experiment, one in which I tell the participants that small amounts of alcohol are grossly detrimental to driving ability, and one in which I tell the participants that small amounts of alcohol are effective in enhancing driver responce time. In this case, I may find that my hypothesis is correct, but I may also find that knowledge of the situation has a greater effect than the alcohol itself.

I will also double this number of experiments again. This time, one set of experiments will use real alcohol, and one set will use a substitute with no intoxicating effects. Again, I may find that knowledge of the situation is the most important aspect.

aside: as it turns out, minute amounts of alcohol actually DO enhance driving ability. However, knowledge contrary to observation (that is, that it does *not* enhance driving ability) enhances driving to a greater extent (participants are more cautious). Also, the social implications are too great, as common knowledge of this fact may be used as an excuse to drink and drive.

More participants are better:
A larger sample of the population is statistically a better representation of the population as a whole. More participants = more accurate testing.

A very good set of guidelines for preparing online questionaires.




Optical Illusions in Computer Graphics #3

I've moved hosting of my optical illusion project to here on GameDev. Link for great justice.

I planned the next entry to include my screenshots, so I will copy the screenshots page to here.

Die Schirmschusse fur alle
Demo 0
Basically just getting the isometric map rendering without any effects.

Demo 1
This is the isometric map of demo 0 with the primrose illusion rendered underneath, utilizing a different set of colors.

Demo 2
The illusion effect in demo 1 was not very strong, specifically because of the isometric projection. I attempted to return the pattern of the illusion itself to a normal orthographics projection, and then clip it down to fit the map, but the results were not impressive.

Demo 3
This is the demo that can be viewed in the isometric map demo under the demos page. Only a small portion of the illusion pattern is revealed at any one point in time, and that portion sweeps across the screen, giving the effect of a moving wave. This, however, is very subtle, leading me to rethink the perspective of the project.

Demo 4
This is the demo that can be viewed in the orthographic map demo under the demos page. It utilizes both the primrose field illusion for the water and the bulge illusion for the hills. This is the strongest demo so far. I will most likely make a game similar to Fire Emblem on the GameBoy Advance (yes, I will even develope it on the GBA).




Optical Illusions in Computer Graphics #2

My work began by first attempting to determine the current "state of the art" in optical illusions in CG. Much of this is covered in the literature summary linked to in Optical Illusions in Computer Graphics #1. This included searches on:

Citeseer, and
The ACM Digital Library.
The majority of the information I found was in the realm of neuropsychology, discussing the underlying mechanisms of the visual system that lead to the creation of illusion. While a cursory understanding of this area will be essential to a thorough project, the search results were much too detailed for my purposes.

From Google, I found two very interesting sites:

Michael Bach's Optical Illusions & Visual Phenomena, and
Akiyoshi Kitaoka's illusion pages.
Michael Bach provided some excellent explanations on how optical illusions work.

Akiyoshi Kitaoka has provided the main basis for my work. His illusions :

will be the main components of my final project.

Most of the other papers are specific descriptions of CG techniques such as Phong Shading, or ruminations on possible uses for illusion. One paper in particular is very interesting, however, Phenomenal Characteristics of Peripheral Drift Illusion"[A. Kitaoka, 2003], which is the best explaination on HOW to generate a specific illusion I have ever seen. I will have to request Dr. Kitaoka's other papers.

my current bibliography (if you missed it in the litsum)

[Gouraud 1971] H. Gouraud, "Computer Display of Curved Surfaces," Department of Computer Science, University of Utah, (June 1971).
[Phong 1975] B.T. Phong, "Illumination for Computer Generated Pictures," Communications of the ACM 18, 6, 311- 317, (June 1975).
[Blinn 1978] J. F. Blinn, "Simulation of wrinkled surfaces," in SIGGRAPH 78, pp. 286-292, (1978).
[Freeman, Adelson, Heeger 1991] W.T. Freeman, E.H. Adelson, D.J. Heeger, "Motion Without Movement," Computer Graphics, Volume 25, Number 4, (July 1991).
[Kitaoka, Ashida 2003] A. Kitaoka, H. Ashida, "Phenomenal Characteristics of the Peripheral Drift Illusion," VISION Vol. 15, No. 4, pp. 261-262 (2003).
[Fermeuller, Pless, Aloimonos 1996] C. Fermeuller, R. Pless, Y. Aloimonos, "Families of Stationary Patterns Producing Illusory Movement: Insights into the Visual System," Computer Vision Laboratory, University of Maryland, College Park, MD, (October 1996).
[Kitaoka 2002] A. Kitaoka, "Primrose's Field," Trick Eyes, (2002).
[Yu, Choe 2004] Y. Yu, Y. Choe, "Angular Disinhibition Effect in a Modified Poggendorff Illusion," Department of Computer Science, Texas A&M University, (2004).
[Christie 1975] P.S. Christie, "Asymmetry in the Mueller-Lyer illusion: Artifact or genuine effect?" Perception 4:453-457 (1975)
[Eidos 1995] Eidos Interactive, "Thief: the Dark Project," Eidos Interactive, (1995).

If anyone has any links to papers on visual illusion specifically in the context of CG, please let me know. Remember, a visual illusion could be practically anything. Any time CG aims to represent reallity through less-than-reallistic modelling, that is essentially an illusion. So, papers that deal in maximizing poly counts are probably about making modelling more reallistic, and therefore are not in my problem domain. Papers that deal with shading/texturing/whatever to make up for lack of detail in modelling ARE in my problem domain.




Optical Illusions in Computer Graphics #10

This is the last update!

The paper is finished. All done. Waiting on a grade.

In summary, the hypothesis that optical illusions could be used in a utilitarian fashion was correct. Using optical illusions I was able to convey information that users were able to effectively use to complete a task. Read the paper for more.

I had a lot of fun working on the project. Going out to Philladelphia for the research symposium was great. I will be submitting my paper to a research conference in the next week or so, my professor thinks it has a good chance of being accepted, so that's cool.

The project has already impressed quite a few important people. I recently talked with the President of a local software development company, who saw my project poster, and he was very interested in some of the things that I proposed from it.

I want to thank the staff of Gamedev for stickifying my Survey Thread (Oluseyi is the one who did it, I believe). Because of that, I collected 550 data points, which really made my data look nice and complete.

Things I learned from the project:

stretching out into other fields of expertise is recommended
test driven development ALWAYS saves time. You may feel like you are writing twice the code, but the truth is that you are spending half the time (total) writing it. ALWAYS test, THEN code. NEVER code before you test. Even if you think it's small. Just don't do it.
regression testing is kind of dirty, but it can get the job done in a pinch. For 2D applications, it may not be necessary in most cases, you should try to find a way around it.
never write java applets. applications are okay (but only just so), applets are garbage. I wonder how good flash is for web apps?
pace yourself and work is a breeze! keeping this journal over the course of the project really made the poster and the final paper a simple task.

So, if anyone out there has a job for a graduating computer science student that involves 2D graphics and making people dizzy, send me an email!



Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!