Blog for James Lupiani at GarageGames.com

Community Weekend & Frozen Codebase

James Lupiani — 2006-10-16T22:46:49+00:00

Well, my first draft of this entry turned out to be far too long, so I'm just going to split it up into multiple smaller posts. Yes, I disappeared for a while. I've been really busy! Towards the end of last year, I was helping Rick Overman with the renovations for GG.com, then a little bit of backend coding in January for the last month of my internship. I returned to Florida for a while to save up for an invasion of Europe, but for various reasons it fell through. Then I suddenly found myself moving to Green Bay to work as a game programmer alongside fellow former intern Justin Kovac.

Community Weekend rocked. Despite some reservations after IGC 2006 was called off, it was great to see that things came together regardless, with the help of some good hospitality from GarageGames. It was a perfect example of how indies can do more with less. There weren't any elaborate catering setups or insanely large Apple cinema displays, but it was definitely at least as fun as last year. The games were more polished than last year, and it's good to see some of last year's favorites still pushing onward.

As for Frozen Codebase's game, [Censored for Corporate Hubris], I don't think I'd truly grasped what we had in our hands until I saw other people subconsciously leaning as they tried to land that next jump, and getting excited about the possibilities for future levels and gameplay.

Oh, for those of you who weren't at !IGC, you probably have no idea who Frozen Codebase is or what [Censored for Corporate Hubris] is all about. Frozen Codebase is a new company formed in July and based out of Green Bay, Wisconsin-yes, that little town with that football team. The climate is, of course, slightly warmer than Antarctica, and nearly everyone I talk to immediately assumes that's why I moved here and just won't let that go. But I digress.

Our team is crammed in a little business incubator (pun intended?) on a college campus, and consists of three programmers, three artist/designers, and a production assistant/whip cracker. Most of the team can be seen on the right playing with heavy machinery on "tie day Friday." We spent about eight weeks putting together the prototype/demo for our game using guerilla scrum tactics and a bunch of small focus tests we farmed out to students and whoever else we could drag in and NDA. Now that it's been shown to peers and public, I'm an odd mix of complacent and anxious. I'm not on nearly as precarious a limb as before, but there's still lots of work to be done and contracts to be signed.

So, ever since Ben Geisler and I returned from !IGC, we've all been working hard to improve the game based on feedback. Billy, Justin, and Norb have been working feverishly on powerups and new level concepts, Jesse's been refining the camera system, Ben's been revamping player animation cues, and I've been adding some fancy graphical elements and game logic to let the player intuitively see how the scoring system works. Chad's been bugging us hourly to get it done, of course. We've also been beefing up our internal tools and equipment, including a new state-of-the indie-art recording studio, which we painstakingly constructed from scratch. Here's lead designer and de facto sound guy Norb Rozek demonstrating its use.

As with many resources on GarageGames, we've decided to release this design to the community. Feel free to replicate it for your own projects. It works great for announcer vocals with subtle reverb effects. For best results, FCB recommends using double layer materials. It's the scroobiest!

Monday Nov 7 10:30

James Lupiani — 2005-11-07T10:30:07+00:00

Reflections on IGC/boot camp/my internship at GarageGames.

First, let me apologize in advance, as I won't be feeding you eye candy for this entry. I'll write a Torque development project update next. On to the critical updates...

As the year progressed, it became more and more clear there would never be a better time to make a big change. With my contract at Catalina Marketing scheduled to end or extend, savings in the bank, and an itch to do more development, my planned trip to IGC became a long-term stay as an intern at GarageGames. I also had the opportunity to attend Stephen Zepp's boot camp, which I highly recommend for anybody just getting started with Torque. An enormous amount of the Torque knowledge that took so long to absorb through IRC and the forums was covered in just three days.

Being immersed in this technology again has led me to put more time into my own personal project, which to this day remains mostly behind the scenes. I think I've lacked the confidence in my ability to complete it, especially after some of the setbacks I've had working with others. Besides, who needs excuses if you can bail out and not lose any face, right? Maybe that's another reason Torque has so many licensees but so few released games. I feel Jeff Tunnell's pain in that respect, but the same stubbornness that has me continuing to work on my game is what's gotten me this far in the first place. That being said, I'm trying to make the mental transition from hobbyist to professional, and part of that is realizing that if I don't get something out and learn from it, I won't be seen. I've heard that message a lot lately, and it's hit home pretty hard. I think it's time for me to take some more risks.

Now then, the internship! I'm working with Rick Overman on the next incarnation of the GarageGames web site. For this run, the changes are mostly to do with usability: the navigational layout of the site has changed considerably, making it way easier to get around. The most visible change I've worked on so far has been adding categorized/sorted browse pages so it's easier to find games and tools. There are lots of minor changes and fixes throughout the code, and some stylistic tweaks yet to be finalized. Joe Maruschak's been encouraging me to flex my elusive creative side by instructing me in graphic design (a topic often elusive to us coding types).

Games? No, not yet... I came here to learn about the industry from the experts and get some real development time in, regardless of the project. It would be a shame to make it all the way out here and not work on a game, though. We'll see. Given that few coders seem to be masochistic enough to do web development full-time, I think I'm needed on this project more than anywhere else.

And feeling useful is pretty damn important to me right now.

Wednesday Sep 21 1:49

James Lupiani — 2005-09-21T01:49:17+00:00

If you're writing an application that's primarily GUI-based, your app should not require or default to running from within a CLI window.

It's really starting to irk me. Maybe it's console elitism, maybe it's printf-codependence, or maybe it's just laziness.

Let me give you a few examples in recent memory that I find particularly distasteful:

1. Blender 3D - Blender has a bad enough reputation for the learning curve, so I won't pick on it too much. In its case, the only saving grace is that the console window might occasionally provide useful debugging information. That being said, I think there may be a number of more elegant solutions available in, for example, every other 3D package known to humankind. There's a relatively obscure NURBS modeler known as Rhino3D that relies heavily on a command system, but it deals with it by integrating the console into its UI.

2. Stani's Python Editor - I decided to give this another try earlier today, in light of the sheer amount of feature integration it offers. I couldn't hold back a groan when I first ran it and a console window popped up. I would have trashed it without a second thought, but it turned out that getting rid of the console window was a simple matter of changing the shortcut to use the GUI python interpreter instead.

3. Torque - This has been coming up as a topic in the forums for what, four years now? There is absolutely no reason release builds of Torque games (especially official GG demos!) should be set with /subsystem:console. The logging facilities and in-game console are more than adequate. You want console output on a second monitor? I suggest you research an ancient app known as tail.

You're probably thinking, "what the heck is this guy on about? All you have to do is change--" Let me stop you right there. Even if everybody knew how to change the behavior for all these apps (and could indeed recompile those that require it), they shouldn't be forced to. Another response I've heard is basically that it's not a bug, it's a feature. That's like a real estate agent trying to put a positive spin on a run-down house by calling it a "fixer-upper." Here's why...

GUI applications that launch from within a CLI window give off a strong initial impression of being unpolished or outdated. Non-technical people that are old enough to remember DOS usually say something akin to, "This thing runs on DOS? How 80's is that?!" Windows users in particular end up having to deal with two separate taskbar items to click and Alt-Tab between. Closing just one of the windows will typically kill both of them. This tightly-coupled behavior is a usability faux pas that should be dealt with sooner rather than later in software design.

So, please, take that extra ten seconds and do it right.

Thursday Aug 11 2:35

James Lupiani — 2005-08-11T02:35:52+00:00

Getting back in the swing of things.

In the nine months since my last entry, I've:

Received my bachelor's degree in MIS from USF (Dec 2004)
Whew. The end came into sight and sped by like a bullet from a gun. Before I knew it I was up and out. I continued dropping by to do the radio show with my friends for the spring semester, and then...

Got a job as a Software Developer at a local company
Most of the software I've written and worked with these past few months has been in Python, which was what originally attracted me to the position. Because Python is turning up all over the game industry, I figured I could get some more experience with it and save up some money at the same time. My little foray into the large corporate environment will come to an end in October, just in time for me to head out to Eugene for IGC 2005! Finally this year I can afford (time & money) to fly out and meet everyone. I've got to get to planning the specifics soon...

Purchased TSE
I must have decided I actually liked constantly merging in changes, and as a consequence of above income, I decided to get the TSE-EA license and play around with that. I've since updated my game's code base to use it, and I'm looking forward to exploring some of the eye candy features!

Along the way, I'm tying up some loose ends I'd never got around to. For instance, I've ported over my popular Star Rendering class to TSE, but I'm doing it right this time. I've separated it out into a Sky-derived class that you can drop into a mission instead of the regular Sky. I also wrote a new conversion utility in Python that draws from a different star catalog, with which I can apply colorization to stars based on their spectral class. I haven't decided if I'm going to post it all as-is, or start working on additional features I'd planned, like making the stars twinkle.

I'm also submitting some minor Torque/TSE patches along the way. Getting everyone to update zlib has been on my list forever. I could've sworn I sent in a patch before, but I guess I hadn't--I did today.

Ordered a new laptop
Also as a consequence of the above. My good ol' laptop is exhibiting its severe overheating problems again. I expect its power chip to fail soon, if not the remaining RAM slot. Rather than spend another hundred hours repairing it, I shrugged and ordered a Toshiba Tecra M4. I was looking for something a little more portable than my current (Sony VAIO PCG-GRZ630), with better battery life and a real video card so I can still do some 3D development on the go. The zing factor is it's a tablet PC, so now I'll be doodling on my screen like it's an infinitely large whiteboard.

Ah well, that's all for now. I'll try to post some fancy screenshots or something soon.

Sunday Nov 28 9:32

James Lupiani — 2004-11-28T09:32:09+00:00

That's right, I'm still alive.

I'm on a collision course with graduation, with a degree in MIS from the College of Business Administration at the University of South Florida. That's what I've been busy with the past year or two. As a result, I'm a little behind the times on news. I'm pleased to see GarageGames and its affiliates doing so well. Even GDMag is giving it some press coverage now!

As soon as I'm done with all the remaining work before I graduate, I've got to start going crazy and looking for a job. I've already found some interesting prospects, but I'm seriously thinking of applying at GarageGames. I read in the latest newsletter they're looking for some people. I've got a background in both PHP/MySQL and working with Torque--so I could help with the web site, and/or I could become an intern and work on the engine. Man, either one would be awesome!

I was hoping to find some enthusiastic people at USF interested in game development, but if they're out there I haven't run into them in my travels--though I have met some very skilled people that I'd love to work with in any sort of systems development projects. The reason I wanted to find local people is that I've had so many headaches trying to keep online teams going. The problem really does have more to do with managing people than game development, and I guess I'll have to revisit solving it once I get more free time. Otherwise I'm on my own.

My problem right now is cash. I've got six months' grace period before I have to start paying back my loans, and in the meantime I'll have no insurance to speak of unless I can get picked up by an employer.

Wednesday Feb 26 8:56

James Lupiani — 2003-02-26T08:56:38+00:00

I'm bummed.

Well, it's been a while, and my development activity is rather low, so I'll make some more personal notes and try not to take it to blogging heights.

So... here I am, and suddenly I'm a couple months into the semester. I haven't touched Torque much lately, except to keep my local codebase up to snuff with the CVS HEAD. My team's also rather bummed... I think the most we've said to each other the past few weeks revolves around resetting lost passwords. I've also only kept in sporadic contact with the gang on IRC. I kinda miss chatting with you guys; maybe I'll stop by later.

Oh, and I was gone for a four-day weekend (two of them driving days) and got home to face a blue screen of death from my good pal Windows, which decided that it would corrupt HKLM/Software and laugh at me. Meanwhile, Bill Gates is over in Redmond saying "You should've upgraded to eXtreme Privacy violation! Windows 2000 doesn't automatically back up the registry like other versions do. Hah!" But the joke's on them: I have a second drive in this machine with Red Hat 8 on it.

My interest in gaming--and perhaps games development itself--seems to be both waning and shifting. I did a little soul searching. I played a couple MMO games, which led to two inevitable conclusions: One, that they seem horribly boring and tedious after the excitement wears off. Two, I had just wasted $25. I kicked around in good ol' Unreal for a while, too. Maybe I'm just distancing myself; games seem much harder to get into now. I was toying around with the idea of making some simple little games or programs with Python and stumbled upon this neat turn-based space empire game called Outer Space.

I guess I don't know what I want anymore, with my life or with personal little projects. I just hope I find something soon, it kind of gives me something to look forward to when I get home.

Anyone have any offers?

Sunday Oct 27 0:49

James Lupiani — 2002-10-27T00:49:23+00:00

Messing around with multi-textured materials.

I've been playing on and off with a multipass/multitexture material system for Torque. I'm testing it using Melv May's fxRenderObject framework, and once I'm satisfied with it I intend to expand it for use in interiors and shapes.

I had a sudden inspiration while playing with the in-game tools one day that it'd be possible to use datablocks to define texture stages. So my class is actually a datablock, and optimized for network transmission. This could allow a server to specify special materials (team colors or logos perhaps?) and clients will receive them upon connection. Well, it was just a hunch. The nice thing is it fits right into the conventions that Torque uses already, and you can mess with them on the fly while the game's running. Plus, you can group a bunch of datablocks together in a script file and use them as a library or theme.

It's been a good exercise in learning the nitty gritty of multitexturing, which I've never had a chance to play with before. First I planned out what I wanted to do--which basically boiled down to something like Q3A shaders. After talking with some community members, I decided to leave out animation features, at least for my first attempt. The idea is to supplement the existing rendering without getting totally replaced whenever someone comes up with vertex and fragment shader stuff for Torque.

It actually has two implementations. First I got it working with multipass and limited blending modes, then earlier this week I got multitexturing working...at least, partially. Something's weird with it, and it won't blend more than two stages (I have a Radeon, 3 TUs). But enough tell, here's the show:

Here I've blended a little glow texture with a larger background texture using simple blend functions.

And here I've used that same larger texture as a detail map on the grass texture that comes with torque.

The way it's defined is a little messy, it's very much programmatic. I hope to come up with a more elegant solution for doing it at some point. Here's the datablock used for that second screenshot:

// Example Staged Material
datablock MaterialData( MyTestMaterial )
{
    // STAGE 0 ------------------------
    // Main texture
    texture[0]      = "~/data/terrains/grassland/grass";

    // STAGE 1 ------------------------
    // Detail map
    texture[1]      = "~/data/terrains/metal/metal2";
    texMode[1]      = combine;
    colorMode[1]    = modulate;
    colorArgA[1]    = previous;
    colorOpA[1]     = src_color;
    colorArgB[1]    = texture;
    colorOpB[1]     = src_color;
    colorScale[1]   = 2.0;
    alphaMode[1]    = replace;
    alphaArgA[1]    = previous;
    alphaOpA[1]     = src_alpha;
};

So yeah, a little messy. But it's a lot of fun to mess with so far. ;-)

Saturday May 25 14:55

James Lupiani — 2002-05-25T14:55:44+00:00

Flying is the art of throwing yourself at the ground and missing.

Or you can just reprogram the simulation. It worked well for Kirk, didn't it?

I finally took the plunge last weekend and completely redid the flying vehicle physics under a new SpaceVehicle class. Right now it's very simple, but it feels much nicer to fly. It seems realistic enough to not seem absurd, yet just about responsive enough to do some real dogfighting with. Along the way I found some weird things with the way the input system was handling Move updates. I think I'm just going to scrap the maxSteeringAngle stuff and make everything assume a scale of 0.0 to 1.0. It's much easier to handle forces acting on an object when you can just use it as a percentage.

So what I've done so far is separate control forces into five groups: lateral (strafing), linear (forward/reverse), pitch, roll, and yaw. Each of these forces has a corresponding drag value that controls how well it dampens itself out. Gravity's completely ignored for the time being, which makes some very weird stunts possible (flying up to another person inverted and waving).
Collisions don't seem to be putting up much of a fight right now. The only irksome part is when it gets stuck to the ground. I would like it to eventually be at rest with the landing skids on the ground, so before long I'll have to find the reason for this one. Still pending is a decision of whether or not to scrap the current CPU-intensive collision meshes and switch to a box model.

Saturday May 11 20:30

James Lupiani — 2002-05-11T20:30:58+00:00

Ah, a week of laziness...I think.

Exams are over, summer's here, and pants are optional. Life is good.

Except for working on games. That's just got me sighing a lot. My earlier attempts to get some sort of cross-platform Torque modeling solution out of Aztec got cut off by a load of other stuff, and I don't know if I'll get back into the swing of things. I hope the other team's faring well, but I haven't heard so much as a peep from them.

I've had a ton of little stuff that I needed to get done, and I figured I'd start with the vehicle physics. I think there's something fundamental I'm missing about the vehicle physics, because half the time I wonder if I'm testing that newfangled WashingMachineVehicle. It's not that it drops like a rock (well, sometimes it does). It's just that it feels floaty, completely decoupled from everything else...and I think the gyros are defective. Damn imports.

What I've got to come up with is some sort of fly-by-wire system that doesn't feel fake, but isn't like flying a winnebago with wings. So far this seems to necessitate a completely new vehicle class, with several separate values controlling maneuverability and drag. To complicate this a little, the engine forces aren't going to act directly on the center of mass. I'm not quite clear on the proper way to do this yet. I can use rigid-body functions on the state in updateForces, but it seems to cancel out the others in some way. I'm going to apply each engine impulse separately, and have yaw (and pitch?) control the thrust differential. Hopefully that will work.

Actually, that sums up about my entire life about now: hopefully that will work. +)

Thursday Apr 4 4:11

James Lupiani — 2002-04-04T04:11:02+00:00

Content Tools for Torque: Future or Farce?

Alright, we've all been debating over it for a while now: content creation tools for Torque are pretty good as far as typical in-house tools go, but really aren't "good enough" for the masses. The frustration didn't really spark until--as I'm sure everyone here knows already--Valve changed the license agreement (and name) for their map editor. It's now similar to that of Q3Radiant's: you can only use it for Half-Life/Valve products. Fortunately we have QuArK to fall back on...unfortunately, QuArK doesn't like me much. I guess I'll have to bite the bullet and fight it 'till I get it working.

What we have developing here seems to be something of a chicken-and-egg situation. A lot of people are now showing great interest in creating our own 3D app that supports all of Torque's features. I'm just going to do a core dump right here on what I see as the issues at hand, and hope something comes of it.

Current Situation:
We've got exporters for a few of the popular modeling apps. Great, right? Well, yeah, until you see the price tag on the modeling apps. MilkShape's a good solution to the price tag problem, but as the old adage "you get what you pay for" shows, it comes up a bit short in terms of feature set. One could argue that the relatively inexpensive cost of Torque makes it that much easier to pay for a 3DS Max or Lightwave license.

We have Worldcraft 3.3 (or not, depending on your legal interpretation) and QuArK. Provided we can all get QuArK project files up to snuff (the project people would almost certainly add official support as well), I think it'd make a pretty good level editing package. I personally am not fond of its overall interface and apparent dependence on WAD files, but I can live with it if it means not having to start from scratch.

The Future?:
We hock these third-party controlled tools and make our own editor(s) from scratch. Separately, I believe the editors would work with minimal design issues (just copying off existing ones, right?). Combined, I believe it would be possible to come up with a very powerful editing application. Having this sort of control also allows some more forward-thinking ventures, like integrating a shader system.

Theory: the real differences in creating a BSP-based interior and a typical polygon mesh are just the tools used to make them, the special nodes (mount points or pathing), and the post-processing and storage. I believe that these differences can be made trivial by creating a well-designed set of plugins for a single application. Different tools, and different exporters.

The matter of licenses is also very relevant. Two main cases:

Proprietary/Commercial License: freeware or not, the person(s) in charge could run off with the editor and we'd be back to square one.

Open Source (GPL) License: nobody can hijack the code, they can only fork the code and advance separately.

I am not in favor of any such new programs being Torque-specific. The main problem there is the learning curve. If the modeler were for Torque only, anybody new to using the engine would have to get used to it. And that's a big problem if you know any artists. Pascal "decoy" Bos over there swears by his modeling app, and seems reluctant to try any others I bug him to. =) Ultimately, I believe such a Torque-specific system would be self-defeating.

My Proposal - A Compromise:
Take our pick of the open editors out there, and contact the administrator of the project. Myself and several others are coming to respect Aztec, and I plan on contacting that project's administrator shortly regarding Torque. Hopefully, the possibility of a large community using the app will persuade the authors to support Torque and/or allow us aboard to help them. Plugins (or more?) could be created allowing free creation of artwork for Torque. Failing that, the convenience of the GPL/LGPL license would allow us to create our own fork of the code and modify it to support Torque.

So why do I say Aztec?
- It's LGPL. Nobody can say "gimme it, it's mine!" and run off with it.
- It's moving towards portability. They're in the process of converting from MFC to wxWindows, a prominent cross-platform library. Coincidentally, it runs on all three platforms that Torque does.

I believe these two satisfy the conditions Jeff Tunnell noted. Further, you get:

- The groundwork is already there. Starting from scratch and juggling the variables of a big picture isn't really necessary. The project is headed by the author of Q2Modeler, so it's not completely unexplored ground for him.
- The interface is pretty, and more or less familiar to those that have used the big apps. Yes, it's relevant. Look at all of the ugly free editors out there. They don't exactly make me look at the screenshots and say "Wow, I can see myself working with that for hours on end."

Brain dump complete. Comment when ready.