Nerdcore 4 Life

Well the project is finished. Has been for over a month. And it’s a total failure.

Which is probably why I haven’t been posting. It’s something I’ve been a bit embarrased to address. But it’s done(that phase of it anyway) and I think it’s time for a little post-mortem. Examining why it was a failure is the first step to figuring out how to succeed.

• Too Much: The scope was just way, way too broad. I wanted to create a solid, reliable, simple, cross-platform OpenGL based game engine coded in it’s entirety by me. What the hell? Even if I just picked one of those goals, “game engine” is just way too much for one person.
• Too Little: I had no idea how much time anything would take, so I assumed it would take very little. I think this topic has been addressed before.



• Rejected Libraries: I spent the majority of my time trying to kludge together my crappy GUI because I didn’t wan to use GLUI or GLUT. That was retarded. Code reuse is the cornerstone of good software development and I ignored it just so I could say “mine.”
• Wrong Goals: Did I expect to make a game engine the open source community embraced and used to make 3D games? No.  I wanted a good code sample to take to game companies to show them what I can do. Then why did I try to make a whole game engine? Are they going to look at all 10k lines? Of course not.  I should have focused on a succession of smaller projects that could contribute to a larger one like a game engine.
• Working != Progress: It’s difficult to measure progress in software engineering, so I fell into the trap of confusing working on a program with a program that works. That(combined with the next point) led to too much code and all of it clunky.
• Not Enough Design: I was so eager to get going with each part of my game engine that I didn’t stop to think about it. How will this whole system work? How will it fit in with the rest of the game engine? What technical challenges will it have to overcome? Consequently I ended up with code that was clunky, inelegant and big. More time spent with the pencil and less with the text editor would have made my life much easier.

So, what now?

Well I’m restarting my project with some leaner, more focused goals. I want:

1. Something cross-platform
2. Usable by the software community at large
3. A good code sample

One thing that I did like about my project is it’s inclusion of .OBJ files. They are a standard that every 3D editor can output to but there’s very little open-source support currently.  Now as it’s currently implimented my .OBJ support is horrible. It’s large(5k lines) and directly pluged into my other code so as to make it very difficult for an outsider to use.

So my first project is write a flexable, elegant .OBJ toolkit. It should read in .OBJ files and store them in a simple data structure that a calling program could easily convert to their own and it should have multiple “hook points” that another system could use to make it output exactly what they want.  I’m currently still desgning it. My goal is actually a 5 to 1 design to code ratio. I’m hoping that will produce better results than I’ve had before.

When complete I’d like to get this project on sourceforge or some other  open-source project site. I think these more modest goals are more in line with what I should be focusing on right now and will get me closer to my goal of a programming job in the game industry.

So last friday I was once again trying to psych myself up for a day of pouring over obscure file processing code when I realized something. This game engine could be broken down into the following parts:

• Core services(message routing, drawing, error handling)
• Utilities(3D math, actors)
• Networking
• Physics(collision detection, friction)
• Tools(for making an actual game)
• File IO
• User Interface(keyboard input, minimaps and the like)

Why am I killing myself doing the least fun all in one chunk? File IO is important but it doesn’t have to be finished before everthing else.

So I am taking a break from .OBJ files and I’m cracking the UI. And it’s the best decision ever, I’m actually having fun again. Imagine that.

The only problem with the UI is designing it showed me how weak my message routing scheme was. Basically I had a class that processed the windows messages with a giant switch statement(another obscenely over complex code leviathan I’m forced to deal with) and it called a series of pure virtual functions(OnCreate, OnDraw, OnMouseClick and the like).

The user was expected to extend this class and over ride those functions to do what he wanted. Which is great, if all of your game will fit in one class. If you want to have different classes handle different events though you were out of luck.

So I changed it to be more of a “message router” that various “message handlers” register with. Everyone who can handle a mouse event and tells the router that he wants to get them will recieve the proper notices.  Yes, I copied Java. But if it ain’t broke…

So I’ve been working on my project for about a month now. Maybe 5 weeks. That’s 5 weeks at 40 hours a week, a pretty hard core time investment. And I’ve spent the last week, 20% of it, trying to parse a god damned .OBJ file. Fuck me.

And you might think that after investing this much time in understanding one file format I’d stick with it. I could get my engine to use the same files and just add a few new lines to represent my stuff(physical properties and the like). But writing something to parse this crap once tells me how poorly designed a file format it is.

A good system, game engine, file format, database or whatever, keeps you thinking as high up as possible for as long as possible. That’s why XML is so popular, you define everything by the rules of the shcema. I don’t have to think about the rules, they’re allready defined. That lets me concentrate on my data, the ‘high minded’ part.

With these old file formats I’m constantly thinking about the rules. When can you use a negative index? Is there a default material? Do I have to look at the material before I look at the .OBJ file, and how do I do that if the material file is listed inside the .OBJ. There’s too many valid ways to do the same thing and they involve too many unrelated sections of the file.

And why would they make a file format like that you ask? C programmers. Those mesozoic mother fuckers. See, to guys who wrote programs that parsed FAT12 any ASCII file seems simple.  And if the format updated or added new features they just spent days wading through code to find out where/what needed to be changed. As long as they had a human readable file they were happy to do it.

So now I have to deal with their poor design choices. Fuck me.

No posting for a while because the project is going well. I’m at the point where it’s time to start dealing with(ugg) files.

There’s a relatively simple solution for 3D file formats, the .OBJ. It’s text based so it’s almost human readable and other 3D tools readily export in it’s format. It’s just a series of verts, normals, texture coordinates then faces. Basically like this:

---

# this is a comment
# Here is the first vertex, with (x,y,z) coordinates.
v 0.123 0.234 0.345
v ...
...

#Texture coordinates
vt ...
...

#Normals in (x,y,z) form; normals might not be unit.
vn …
..

#Each face is given by a set of indices to the vertex/texture/normal
#coordinate array that precedes this.
#Hence f 1/1/1 2/2/2 3/3/3 is a triangle having texture coordinates and
#normals for those 3 vertices,
#and having the vertex 1 from the “v” list, texture coordinate 2 from
#the “vt” list, and the normal 3 from the “vn” list

f v0/vt0/vn0 v1/vt1/vn1 …

---

Easy to understand and process. But obviously my game library will need to have more information than just the polygons for most objects. Does it move? Does it have mass? Do other objects bounce off it or clip right through it? If they can’t move throught it what are it’s dimensions? So the questions becomes, how do I represent that?

The way I see it I have 3 options:

1. Simply tack my information onto the end of the .OBJ with a new pattern.
2. Place my information into .OBJ comments so it’s still a valid .OBJ file.
3. Make my own file format from scratch.

I think I’ve talked about design principles before, that your pillars are simple, efficient, and elegant.  Effieicent isn’t that big a concern with file formats(getting it off the disk is never going to be the run) so lets concentrate on the others. Option 1 is simpler than 2, but 2 is more elegant. It’s nice that my files are compatible with a general standard. Or are they?

By burrying my propietary information in the comments they fake compatability, but is there a requirement that comments be treated a certain way by programs that use .OBJ? Not really, other than to ignore them if they find them. That means I could open up my faux-OBJ file with 3DS Max and change it’s color, then save it only to find it erased or moved my comments.

It’s actually very complicated and inelegant to try and hide new data in a standard not designed to hold it. Bad idea.

So that leaves making my own file format from scratch. I’ll be doing something XML based(simple and elegant). Sure this means I’ll have to make some tools for editing/combineing my files with .OBJ files but it’s not a huge amount of extra work and it’s worth it to have files that actually fit a standard instead of almost fit a standard. That never ends well.

My mom moved to Utah a couple of years ago to start a business teaching people to teach their dogs to shit in the appropriate places(not shoes).  And now every between every quarter that I don’t go back home to Michigan I am expected to make the 10 hour trek to Utah to see her like a dutiful son. Which sucks because I’m not a dutiful son, if I was I never would have left home to begin with.

And while Utah itself is a less than exciting place their home in particular has the feel of “death’s waiting room,” not the least of which because they have old National Geographics stashed all over the place.

Plus I can’t work there. I don’t know if it’s their computer setup or if I just have minor OCD but I could not get a bit of work done on my project. Speaking of which:

People have written to ask how the job search is going, and to be honest I’m not searching yet. I’m not going to get a job with a resume that has little programming experience(and that from 2 years ago) and a well chosen font, I need to be able to show a game company that I can do something. Which is where my project comes in.

I’m working on a codeset to build a modest game. Basically import a standard file type(.OBJ), editing it to work with my tools(adjust normals, add physics, set bounding boxes, etc.) and then allow a player to run around in it. Eventually I hope to have a basic, networked FPS. I think that the path to a great job in the game industry is showing them what I can do with an actual game, instead of telling them what I can do with a resume.

Or, as Seth Godin says, “if you’re remarkable, amazing or just plain spectacular, you probably shouldn’t have a resume at all”

I’m not remarkable yet, but I’m working on it.