todd

Planet Anaglyph or: Drawing and Quaternioning

Slight update from what people saw in class on Tuesday. Finally figured out why it wasn't doing proper perspective on each camera (turns out I was just resetting the views too soon).

For those watching solely via blog, I finally got the local/global coordinates working the way I wanted (thanks to a lot of copying and pasting of various NeHe tutorials...my life is a lie...). Next step will be a proper handling of some sort of antagonist. This will mean having a similar coordinate system to the planet, affected by but ultimately separate from the planet's rotation.

Everyone liked this "on the surface" view more than the "entire planet at a distance" view...I'm inclined to agree, although this will take the specifics of the game in a new direction.

Here's a good demonstration of the subtle powers of stereographic imagery as well...the ship (darker area center) is clearly facing the player, a fact that manifests when one is wearing the red-eye-left red/blue glasses.

The odd values on the screen are various data about the rotation of the world, viewport info, and such. I'll be using a lot of this for specifics on the world's surface, things like collision detection.

Protoyping Status

The maze game in still underway.

For those unfamiliar with the latest developments, this will involve a player walking around the top of a series of spheres (think "Little Prince"). However, traveling between them will involve playing with their silhouettes...if they share the same outline, the player may transfer between the two worlds. The objective is, simultaneously, to reach an exit and get the planetoid to form a certain silhouette.

I've been getting a little hung up on some of the technical stuff (still in the "R" phase of "R&D"). High on the list is getting the sums of rotations working the way I want. Linear algebra seems like a time so long ago...

On the other hand, I have figured out how to store simplified topographical data for the series of spheres. Basically, the player will only be able to move along three bands of the sphere, the "equator" and two meridians, all 90 degrees from each other. The data then, will be stored in three lines, each line sharing four spots (points where two bands intersect). Information like collision detection will be stored these lines. The program will monitor player progress on the lines, and this will be reflected in the 3D render.

Patholog Thoughts

Just a few ideas, depending on our scope and direction.

At its surface, this entity can be very large, general network...what we'd need is an army of people to fill it up (an issue we'll undoubtably address).

Not only is it large, but also very open in what we can do with it. That's where we need to focus our own specific energy.

The paths are the most developed, as I see it, and on their own very intriguing. One possibility is to just spend all our time polishing this part to a shiny, chrome finish in time for siggraph. Tripp's observations on privacy issues are certainly well warranted. Forums, blogs, and e-mail all some way of dealing with this, the patholog itself shouldn't be an exception. While I doubt it'll be this simple, permissions seem to be the way go (public, private, by group, etc).

"Real Estate" is also a concern...basically the privacy issue from the other direction. I can imagine businesses, public spaces, heck, anywhere where people would object to having some content or other existing...comparisons to grafitti are not wholly without merit. The 'net is essentially a separate space from the geographic world...you can largely avoid profanity filled forums and shady web sites...that might be more difficult when content is directly relation to where you travel. I dunno, this is probably too far in the future for this semester, but it has and will come up.

Enough of that for now...I'm also thinking about stuff to do with the data on its own, possibly independently from a given user or traveler. Y'all remember the "message in a bottle"...actually that could jive with the path database...it could create its own little virtual path, bumping into others. Anyway, that's just one of a few half-ideas I have.

Anyway, I'm still kinda for simply polishing the whole path-crossing part...we have most of the basics down, but could easily spend the semester fine-tuning. And the only questions we have left are some of the trickiest one (like permissions).

I agree that we (and probably as many others as is feasible) should simply add to the network we have. That, in and of itself, is pretty straighforward. Seeing how data grows may help us make further decisions on how we're going to use it.

People, Tools, and $

1. People:

Potential Advisers
-Mark Bolas
-A presence from the Game Development part of the Interactive Dept, (i.e. Tracy Fullerton or Chris Swain)
-A presence from Animation (I'm contacting Richard Weinberg)

Production Team (besides yours truly):
Near Term: 1 Programmer, 1 Artist/Animator
Long Term: 1-2 Programmers, 1-3 Artists/Animators

Programmers: Having a programmer who knows database structures and networks is key, having one with
a background in artificial life (intelligence, neural nets, etc.) would be ideal.

Artists/Animators: Graphical elements will be key. Aesthetics are a key part of my goal. While I love graphical work, the question here is one of simple endurance and time. Many times I’ve programmed a perfectly reasonable engine and tool set, only to burn out when it came time to add graphics (the reverse is also true).

The “near term” involves the research aspect of self-generating environments. The “long term” would be the team needed for developing a full-fledged game.

Tools:
2a. Software:
Processing- Java-based library, specifically designed for testing graphical algorithms. I’ll certainly be using this a lot in the planning stages, seeing what systems work and which are limited.

OpenGL or Equivalent- The environments will ultimately be in 3D. A game engine is tempting, but I doubt I can find one that will provide the flexibility I need without extensive learning of a proprietary scripting system.

3D Modeling/Animation program-Maya or 3DS Max are among my most familiar and hence top choices

C/C++ Development Platform-Probably Visual C++

Adobe Photoshop: Staple for any 2D graphical work necessary

2b: Hardware:
At least 3 Wintel workstations with high-end graphics capabilities: One for coding, one for generating graphics, and one for testing and debugging

Final product could involve an installation, although compatibility with typical desktop PC a priority.

Money:
(3) Workstations ~$5000
Software (Student Fare) ~$5000
*Presentation Hardware ~$5000 and up
Student Workers ~$2000

Totalling about $12,000-$17,000