Blog for Brett Fattori at GarageGames.com

A small hello

Brett Fattori — 2008-01-10T20:34:47+00:00

Hello to everyone. It's been a long, long time since I last wrote a .plan up. Wow, almost a year... Not much has changed with me. I've been busy with work, not doing much game dev. I play a lot of XBox360, under the name "dk_911" if anyone wants to play some COD4, Halo3, or other games online.

Anyways, just wanted to say hiya!

- Brett

Recent Stuph

Brett Fattori — 2007-02-18T03:04:21+00:00

Hey all, I know, long time no talk. Well, I'm getting back into things and it's going slowly. I've been spending time, lately, doing little odds and ends to keep myself busy. I've found that the best way to get back into game dev, is to just do it. Last week, I spent about 5 days writing Asteroids in Javascript using the canvas element and some code that was developed at my work. We don't do games dev at work (unfortunately) but we do do a lot of work with Javascript. We're an e-commerce development house that has done work for clients like Godiva Chocolatiers, Kmart, The Home Depot, Eddie Bauer, and more. My work with Javascript has given me a whole new appreciation (and at times, hatred) of the language.

Ok, back to games dev... I wrote Asteroids in JS in about 5 days. It uses the canvas element as it's rendering context and looks pretty accurate. I had to write some code to do vector letters and numbers, and it took some time to understand what exactly could be done. In the end, I received a lot of feedback (positive and encouraging, mainly because people at work see me as some sort of Javascript oddity) and it'll be something I post somewhere in the future. It will also probably show up as an easter-egg in one of our "products". I'm in product development, so I don't worry as much about client issues and such -- throwing in an easter-egg is just my way of saying "Hi!"

I dropped by IRC a few days ago and have started chatting again with Tom Bampton. He's a great chap, and I've forgotten how much I enjoy talking to him. Paul Dana is there too, and some people whom I don't recognize, but then again -- it's a chat room where devs can just shoot the breeze. It's been fun catching up and seeing what's developed in my two year hiatus.

I also, recently, built a simple poker game with TGB Pro. Man how it's changed since I used it to build CashCow for a GID. It's easy to use and hard in other ways. Getting to know it has been a love/hate relationship. I still have a long way to go with the game, but it might end up being another TGB title at some point.

It was interesting because the overall game setup was like 5 hours to make cards, 1 hour to set up an interface, and 4 days (and still going) to determine what hand I have. The game is simply about chosing the best cards to keep in your hand, and discarding the rest. I got the idea from a touch-screen bar game a friend and I like to play. You're dealt 5 cards and it tells you what you have. You then decide which cards to keep and which to pass on, and then deal up some new cards. If you chose wisely, you'll get a nicer hand and get a good score for that hand. The kicker is that there are 4 jokers in the deck, which can be any card. So, your chances of getting a better hand are always there -- in addition to 5 of a kind which isn't usually possible.

I thought the logic for it would be simple. I refactored many times because I was so very wrong. Little things that make so much sense to you and I regarding what is a flush and a straight are so much more complicated when in code. I tried calculating based on card values, using bitfields to represent cards in my hand, and more odd ways of doing things. Eventually, it just ended up being a quick sort of the cards and then a gaggle of conditional logic. It works nicely, but it still has an issue with flushes versus other hands. The flush, which seems so simple to calculate, becomes a problem because of how it ranks amongst other hands. Since a full house beats a flush, it ends up making some of the logic a little more difficult.

Anyways, the goal of all of this is to make a solid card game "engine" that I can re-use. The final product will be a game which plays all types of poker, and hopefully some new ideas too. My ultimate goal would be to put this on a touchscreen system (of my own building) and put in at my bar in my basement for parties and such.

Well, I just wanted to drop by and say hi to some old friends. Hopefully I can get reaquainted with some of you, and make some new friends. Until next time...

- Brett

So long and so out of touch...

Brett Fattori — 2006-03-03T13:58:44+00:00

I feel so disconnected from this community as of late. I had so many good plans for little one off games to try with T2D when I purchased it back in October after IGC. Seems like I used to post new goodies about dRacer on a regular basis -- but as of late I just don't have the time to do much of anything.

I'm in the final stretch of getting my BS in IT. I'm currently taking two classes and finishing have one left to go. I took my final CLEP exam yesterday which covered biology, geology, astronomy, and physics. It'll give me credits for classes that I have taken but didn't complete back in the day. I'm pretty excited, but it's been painful.

Lately, all I've been doing (when not schooling) is working. The place I work at has ambitious goals to develop a very comprehensive set of components that enable application development for the web. Yeah, I know -- seen it before. Well, I've not seen anything like this... Believe you me when I say I've looked at Prototype, WebComponentArt, Laszlo, and recently ZX. We evaluate these component libs everytime they come out to see if they have something we don't. Apparently we're still ahead of the curve. I should mention that Prototype really isn't a component lib, it's more of a structure or framework. People usually build on Prototype, but it's the only cohesive part of the project, usually. So, back to our stuff... We're at a point where we have a complete set of UI components that are browser agnostic and are totally OO, running in a linked client/server environment utilizing remoting over AJAX to provide an application-like experience.

Wow, that was a mouthfull, but it's true. We're so integrated that it hurts that I cannot release this stuff and show people what a true Web 2.0 framework can be like. Like I said, I've seen them all that are out there. And yeah, they usually have some sort of component demo, but no real applications are totally built upon them. The competition is used to make bits and pieces of a web-app functional. What we're developing encompasses the whole application.

So, there... now you know what I've been busy with. I hope to get back to gaming soon... Keep a place here for me!

- Brett

Thursday Dec 15 2:17

Brett Fattori — 2005-12-15T02:17:33+00:00

I'm a blogger... Woo!

Okay, nothing too big, but I'm a blogger now. I figured I could stay away from this, but my colleague at work insisted that I start a blog to record my coding adventures. This is mostly work oriented, and will contain stuff that probably doesn't interest the majority of this crowd, but I figured I'd post here since this is my other home. I've been spending a lot of time developing in Java, JSP, and JavaScript. Yeah, you read that last one right... JavaScript. What a powerful language. I'm so impressed by how easy it is and how much I can do with it. It sure as hell isn't C++, but it's amazing what you can do in that scripting language.

Anyways, just thought I'd let y'all know...

Visit it if you feel so compelled:
kodewriter.blogspot.com/

- Brett

Tuesday Nov 1 2:40

Brett Fattori — 2005-11-01T02:40:23+00:00

Slow month, lazy coding, reading a lot...

It's been a slow month... Really slow since IGC, in fact. I feel like there isn't as much time in a day anymore. It might have something to do with it getting dark earlier and earlier. It might have something to do with enjoying my regular job and sticking it out there for an hour or two more... Who knows.

Anyways, it's a slow month. I haven't spent as much time as I could coding on dRacer. I've been playing a lot of Halo 2 again. A friend I used to work with at my old job likes to get on an play after 11pm. This leads to many a late night gaming. I suck at Halo 2... I'm only a 9 right now. Here's an aggravated story:

I start one evening with a score of 13. I'm all pumped up and ready to rumble, and what not. It starts us out on Turf, Team Slayer, with just rocket launchers. Way cool, and the guys I'm playing against aren't maniacs or sucky. We're all having a blast, and then I notice it. One of the guys on my team is blowing himself up. Seems his 10 is making his matchmaking to challenging, and he's decided that my game is the one where he's gonna blow his own brains out over and over. This was a poor design decision in Halo 2... No one should be able to lower my score because he decides that he likes to ride rockets! Well, I had the best game of my entire Halo 2 experience... 14 kills, with a 98% hit ratio. However, this fucktard killed himself 34 times in a row so we ended up losing and my score went from 13 to 10. Needless to say, that ruined my gaming night and put me in a sour mood.

So, this month has also been a research month. I've been looking into combinatorial coding and adaptive applications. There are some interesting papers and research on this topic. People are finding new ways to make programs "evolve" everyday. Joe pointed me to some information regarding using random bit ordering and removal to see about making code more efficient. It's an interesting fact that removing and reordering bits in an application, until it can be run again, is also an optimizational technique. Not exactly an efficient one, as it's more like the 1000's of monkeys, 1000's of keyboards thing. It'll be interesting to see what comes of this field of research.

Okay, enough blathering... until next time.

- Brett

Friday Oct 14 0:53

Brett Fattori — 2005-10-14T00:53:13+00:00

This kinda keys in with what Jeff Tunnell has blogged about recently... Plus some short IGC ramblings.

I work hard on the game I'm working on, and I started to take exception to what Jeff was saying when he was speaking at Associates Day. But when I listened closer, I realized that he wasn't saying "you're not trying hard enough" -- he was saying "try harder." These two concepts might sound the same, but they are different in their presentation. Telling someone they aren't trying hard enough is without encouragement. But saying to someone "try harder" implies encouragement...

At least, that's what I got from his talk. GarageGames is encouraging us to do better, try harder, and to achieve our goals. And from what I heard, they want to help us to do just that. I spoke with Jeff afterwards and presented him with two ideas.. He's a smart guy. He usually can pick out a good idea from among the bad ones. His words were encouraging, and I'm looking forward to moving on this game idea.

It doesn't mean I won't be working on dRacer.. That is still a huge part of my being, but it's not a fully engulfing project that absorbs all of my time. Close, but not all of it! I have a few extra hours here and there that I want to work on this new game. I'm not going to spill any beans just yet, but it's definitely something that I've put some thought into and hope it'll make it's little mark.

Thanks again to everyone at IGC! I had a great time.. To each and every one of my friends, those I knew from before, and those I made while at IGC'05, I look forward to seeing you all again.

- Brett

Thursday Sep 29 3:12

Brett Fattori — 2005-09-29T03:12:17+00:00

On my way to IGC...

Well, I didn't think I was going to be able to make it this year. But after some pulling, prodding, and general goodliness of the people I deal with, I'm on my way. We don't have a lot to show with dRacer, but we might try to put something together to show it off. Visually it isn't all that different from last year's IGC. Under the hood, it's a whole different story. With all the pieces that have been reworked or rewritten, people who've played it will notice a difference.

The majority of the rewrite was for multiplayer racing. Clark's done a fantastic job with it. He's just one amazing fella when it comes to things of a mathematical nature. He's great at analyzing the options and isn't afraid to try some things. The MP code is super solid now. Collisions feel rock solid (they used to feel slushy and kinda not all that real). It's really been written to work for fast moving objects. You might think that the code that is in the engine for vehicles is good enough, but you should really do some research. It's okay for buggies and slower moving vehicles, but get a sportscar on a flat-out section of pavement, and the old code becomes very apparently inadequate.

Everything from the net code, up to the rendering code has been tweaked and changed. The underlying systems are almost 100% different than last year. In fact, the only thing that remains the same is that it's written on the TGE, and even a lot of that has been modified. The component system, the camera system, MP code, AI code, track rendering code, and many other systems have been touched -- and in some cases they were evicted in favor of better systems.

Anyways, I'll be at IGC. I look forward to seeing the friends I made last year. Stop by and we'll have a beer together and catch up. Until then...

- Brett

Wednesday Aug 24 13:19

Brett Fattori — 2005-08-24T13:19:15+00:00

The development of dRacer progresses. We have a milestones list that continues to get shorter every week. Some new tasks have been added to it, but overall we're getting closer to moving out of pre-production and into an early production phase. Each task on our list is a little chunk of what we think is necessary to grow the foundation into a more solid, core codebase.

What people saw at IGC'04 and what we have today are two very different beasts, internally. Many of the important systems have been rewritten or so heavily modified that they don't resemble their original self. dRacer contains a rewritten physics system which Clark detailed here, it also has major improvements for multiplayer, a dynamic decaling system, and a heavily reworked system for racing management. Most recently, however, I've been working on improving the rendering pipeline for the racetrack.

A little history to start this off... Back in early 2004, I wrote a simple demo to prove to myself that creating a track, similar to one in Wipeout for the Playstation, wouldn't be that difficult. After getting a simple ribbon of polygons, represented by a triangle strip, to render, I was quite pleased. A little while later I added walls, an underside, and the ability to cap sections to make tunnels. Alltogether this wasn't a bad thing, except it had slowed and was becoming troublesome.

The first iteration of speedups on the track was done by segmenting the track into tri-strips of no more than 30 polys. The number 30 wasn't very magical, it was just a number I grabbed out of the air. One should know that the track was (at that time) being rendered as 12 tri-strips, and as one continuous segment. The new method of breaking the track down into segments fixed a number of problems I was having with visibility. The entire track was visible at one time, which meant a lot of faces were being pushed onto the graphics card only to be rejected anyways. So, now I was able to limit what parts of the track were being generated by utilizing the pre-existing visibility tests by breaking the track into smaller chunks. So instead of passing, say, 24,000 polys to the graphics card each frame, I was only passing visible segments consisting of up to 360 polys each.

I had even implemented a simple method of reducing the number of polys that were being passed based on the distance of a segment from the camera. It was a kind of dynamic level of detail for the track. I'm not even sure if that gained me any extra time because I didn't do any profiling at that point. I just guessed that less polys equals less render time. And by passing half as many polys when the segment was half the distance to the world visible limit, and then half as many more polys at 3/4 of the way to the visible distance, I figured it would be huge speedups.

Well, with the current round of speedups, Clark insisted that I come up with some hard numbers to justify the work I was going to do. He guessed (from experience) that changing the glArrayElement calls to a glDrawElements call would speed things up. We were already using arrays of verts, texels, norms, colors, and so on. Changing it from filling an array of these, to passing the arrays themselves, would most certainly be a speed gain. Additionally, I had noted that the current render routines were doing a lot of client state initialization and resetting of that state, only to do it all over again. Maybe there were gains to be made by performing less state switching?

I should let everyone in on a little secret of mine... I'm not a math guy. I get the usage of matrices and vector math, but I couldn't prove it to save my life unfortunately. Clark, on the other hand, is quite adept at mathematics and for that reason he offered to derive the formulas necessary to show what kind of speed gains we would see through our changes and through profiling. I set out to modify the code so I could isolate the two optimizations I was going to perform and built four versions of the engine. One was built with no optimizations, the second was just client state opts, third was just glDrawElements opts, and last was both optimizations. I then recorded a journal so I could use the same setup for each version of the engine. Here is my setup:

Journal: One lap around Black Forest (54.652 sec)
Processor: Pentium 4 3.0Ghz
System Memory: 1GB
Video Card: PCI GEforce 6800 GT 256MB (no overclocking)
Video Drivers: 77.77 WHL
Video Features: No Antialiasing, no anisotropic filtering, no vert sync

The results from the profiler follow. These percentages are their part of the total time recorded in the profiler for all processes being profiled. I was only concerned with the time taken to generate the track.

No optimizations: 6.776%
Client state opts: 6.349%
glDrawElements opts: 4.331%
All optimizations: 4.047%

Now it might not seem to be very much when you consider that the change went from almost 7% of total time to 4% of total time in the profile. However, from this we can determine the overall speedup of rendering from before any changes to after each type of change. Overall, it was a positive gain for each of the steps:

Client state opts: 7% speedup
glDrawElements opts: 37% speedup
All optimizations: 42% speedup

As a side-effect of making it easy to switch state on and off, I split out the calls for this into separate functions. I figured there were maybe even a few more cycles I could squeeze out of the renderer by making those calls inline. Interestingly, I noticed a slowdown rather than a speedup -- and I checked repeatedly. Overall, the speedup dropped to 39% with inline functions.

Overall, I'm happy that we were able to make these kind of gains. Each time that we reduce the amount of time taken by one process, we dump a little time back into a pool to spend on other things. Keeping track of the gains by profiling is also a good thing. A lot of times people rely solely on an FPS gain, which one might not even really see. Being able to qualify the work you've done by showing actual gains is invaluable. And as Clark pointed out, on a machine where rendering is more of a bottleneck, these changes will matter more.

Until the next time...
- Brett

(reposted due to deletion...)

Wednesday Jul 27 1:42

Brett Fattori — 2005-07-27T01:42:38+00:00

Decals, skidmarks, and UV Coordinates... oh my!

Hey folks, it's been a while since I last posted a .plan for y'all to read. I've been watching others post theirs and got the itch to submit my latest developments. dRacer progresses -- slowly. We're addressing the issues that would cause us to go from being a good title, to a great title. Lately I've been working on getting the static decal system merged with our dynamic decaler.

The dynamic decaler is a system that lets us put decals anywhere on the level, on any surface, and network them to the clients. Decals can be spot decals (essentially a square of texture) or a linked decal (like a smear or a skid). The system handles all the under-the-hood stuff like memory pooling and resource management, and exposes a couple of simple methods to add, update, and remove decals.

Here is what the skidmarks looked like, and what I was aiming for:

vs.

These skids were essentially a solid texture that was alpha blended onto the track as a linked decal. The UV coordinates weren't really calculated since the texture was solid. This was the simplest way of doing things, but I was never happy with how they looked. The edges were too sharp, making them look too "computerized".

I sat down and started working out the way to get texture coordinates in a format that I needed to support nice soft skidmarks. I needed to be able to draw a texture across the decal, regardless of how it lined up in world or object coordinates. This led to some challenges and late nights, but eventually I came up with (what I think is) a good solution. I knew it worked when I first saw my test texture line up properly.

Now I could be assured that the skids would bend and twist properly as the car bounced off of walls and careened across the road. I had to try it, so let me share my first test image after getting them to work properly:

...and, just a little showing off -- letting the AI generate lots and lots of skids:

- Brett

Saturday Jul 2 15:32

Brett Fattori — 2005-07-02T15:32:26+00:00

A response to Pat Wilson's blog...

Pat asked the question of "what gives?" in the arena of TGE development. Comparatively, T2D is overflowing with projects. Now, having participated in a GID with T2D, I can say that turning out a simple game in T2D is much simpler that in TGE. What's the difference? Well, I think that the difference of an extra dimension is huge, as is the environment within which you develop your games.

As many of you know (or may be new, and didn't see my early flurry of .plans about it) dRacer is my current project. I've spent over a year now working with Joe, Clark, and Mark (formerly of Bravetree) on a racing game. To date, it is still graphically at the level of what was shown during IGC'04. Sure we have a couple of new car shapes, but they are mainly tests. We're still working on the foundation of the game.

I think that if we were just churning out a simple FPS, we could have done so much sooner since the engine is, at its core, an FPS engine. But since we're making a game that is so fundamentally different from what TGE is written for, it has taken much more time.

Some people may say "but TGE comes with vehicles and a racing demo in it!!" To which I will respond: "If you like racing games where the top speed feels like 25 mph and the controls feel like an elephant on ice skates, then yes we could be done with it." But we didn't like that feeling. We wanted something tight and something that will provide a racing enthusiast (Joe is one of those) with a good experience.

To that end, we decided to use Clark's component system as our foundation. Thank god that we did, because without it we'd be up a certain creek without a paddle. But this still didn't just immediately solve our problems... There were, and still are, many different issues that must be tackled to make the engine into a racing engine.

Clark has rewritten the entire way that the engine works and it has made a huge difference. A racecar is a collection of components that each perform a small task, representative of the whole. Together they are a racecar, but separately they could be anything. This meant a whole new way of thinking, and stuff to learn.

Speaking of learning, I've been going to school to finish up my degree and get that piece of paper for my future employers. That has taken up a huge chunk of my time -- as does my real job, and this new job that I'll be starting on the 5th. Indies have real lives with real issues and real obligations. These usually distract us from our game development, and make timelines longer.

Up until just a short time ago Clark, Joe, Mark, Matt, and John were all doing a mix of contract and company work. Company work being game dev, and contract being everything else. Again, more distractions from what indies really want to do -- make games. So, to answer Pat's question as to why game dev on TGE takes so long, let me sum it up:

3D games require a lot of time to make the foundation to create a fully functional and entertaining game. The artwork and the look and feel don't take nearly as much time (according to Joe) as the coding does. In other words, code always lags behind art. I can agree with this...

2D games, while some can be very involved -- most aren't, take a lot less time in coding. Especially when working with an existing toolset such as T2D. You see, T2D wasn't designed to be a TPS (third person shooter) engine, it was designed to make 2D games. TGE was designed (and is still maintained) as an FPS engine, so many changes must take place before TGE is ready to make your game.

I know I'm gonna take some guff over this. People will say it takes just as much time to come up with and program a 2D game as it does a 3D game, but I'll argue that it takes far less time. As I said T2D is a 2D engine... that's it. It's designed to make 2D games easier to create. Nothing is set in stone... It doesn't come as a Pac-man clone that you can use as a base to make 2D games. TGE is an FPS that you then must modify to make games.

I'm gonna end here, I have a paper to write for class. I'll get back to dRacer after that -- oh wait, I have to mow the lawn too. Ok, after that... shoot, nope, I have my dad's birthday to go to. Well, that should only go to about 11pm... etc.

- Brett