Jump to content
  • Advertisement

Devnull

Member
  • Content count

    147
  • Joined

  • Last visited

Community Reputation

223 Neutral

About Devnull

  • Rank
    Member

Personal Information

  1. Devnull

    Path Finding Research

    [size="2"][font="Courier New"][font="Microsoft Sans Serif"][size="3"]I'm currently working on the architecture for how the game will do path finding. Up until a couple of days ago, I had a plan that would work reasonably well, but then I stumbled upon a link to a thesis paper that really made me re-think what I was planning. I'll start this entry with a brief description of what the requirements are, then the "current" plan, and then I'll go into why this paper has made me re-think my plans. [/font] [/font][size="5"][font="Microsoft Sans Serif"] Part 1: World Description[/font] [font="Microsoft Sans Serif"][size="3"]The game world is logically divided into lots (i.e. user-changeable areas) and the rest of the world (users can only interact with this area and cannot actually build on it or do much to change it). The lots are inserted into the world at essentially random places and they are pretty much completely dynamic, from changing terrain to walls to objects placed on them), but are at least guaranteed to be convex polygons.[/font] [font="Microsoft Sans Serif"][size="3"]The world also has roads and paths that are essentially cheaper for agents to travel on, so they tend to move to them and then along them for longer trips. Some roads are for cars and bicycles only, some are useable by cars, bikes, and pedestrians and some are for bikes and pedestrians only. There might end up being other permutations or even more types of agents as well.[/font] [font="Microsoft Sans Serif"][size="3"]The world also has water areas (both sea and lakes/ponds) that will be routed upon as well, by various agent types (swimmers, boats, etc). Steep-sloped areas might also be routable via climbing animations, but more expensive to move on for path-finding, so they'll only be used in specific circumstances and/or by specific types of agents.[/font] [font="Microsoft Sans Serif"][size="3"]Finally, a number of objects may be routable as well - bridges, for example. And since objects can be placed or deleted by users, the objects must have routing information built into them that can be "attached" to whatever data structure(s) we end up using to represent the world, lots, etc.[/font] [size="2"][font="Microsoft Sans Serif"][size="3"]Lots are connected to the world via portals. Routable objects will also be connected via portals. Portals are simply links between 2 different pieces of the world and may or may not be on the same navmesh/grid/graph (or whatever we end up using that has its own local-space coordinates) and can be traversed via normal movement, teleportation, or a custom animation. Other examples of portals would be stairs between levels of a lot (custom animation to move the agent), doors between rooms (custom animation to move the agent and open/close the door), teleportals (instantly jump to another part of the world), or a boundary between land and water (move normally, then animate slower, then finally, change to a swim move-type or the reverse for exiting the water). Portals are by default open, but can be locked to specific agents. Like all edges between search nodes, portals can be one-way or two-way. [size="5"] Part 2: Requirements [/font][font="Microsoft Sans Serif"][size="3"]1) Quickly and efficiently path-find (10-20 asynchronous path plan queries per frame, most of which will be short-distances) between different areas of the world, taking into account all of the following: [/font][font="Microsoft Sans Serif"][size="3"]the different types of areas that can be pathed-upon[/font][font="Microsoft Sans Serif"][size="3"][/font][font="Microsoft Sans Serif"][size="3"]the movement capabilities of the agents[/font][font="Microsoft Sans Serif"][size="3"]the widths of the agents[/font][font="Microsoft Sans Serif"][size="3"]the allowed movement types within various parts of the world[/font][font="Microsoft Sans Serif"][size="3"]portals[/font][font="Microsoft Sans Serif"][size="3"]boundaries between different navigation data structures (lots vs. world vs. routable objects, etc)[/font][font="Microsoft Sans Serif"][size="3"] 2) Can very quickly handle synchronous queries that just ask whether or not a path exists between 2 points 3) Can handle relatively infrequent large updates to the world abstraction layer, but frequent small, local updates (i.e. objects moving within the world happens frequently and their footprints in the data must be updated, but large changes to lots will also happen (much less frequently) and will be allowed more time to update if necessary. In other words, the pathfinding world data structures must scale from small, frequent changes to large, infrequent changes. Note that such changes will also be asynchronous and may affect current path plans in progress. Limiting the re-plans from this would be ideal. 4) Path plan queries must be able to account for changes in status of portals, lots, and/or routable objects for specific agents (i.e. portal 3 is locked for this path-find for this agent). These status changes will be sent by the caller as part of the path plan query. In addition, the caller will also specify the minimum width for the agent for this particular path-plan. 5) The results of the path plan must return a list of points for the path along with a set of points describing a corridor boundary to either side of the path that describes the routable area around the center points of the path. The agent and the avoidance system will thus have enough information to freely move around the center of the path without doing a lot of expensive line-of-sights tests or replans. 6) The path planner will always return a path if one exists, but if one does NOT exist, then it will return a path that gets it as close as possible to the goal point. 7) Path planner must be able to account for local-space path-planning. For example, it must be able to return a valid path on a routable object that is moving within the world. [/font][font="Microsoft Sans Serif"][size="3"] [font="Microsoft Sans Serif"] [/font] [font="Microsoft Sans Serif"] [/font]In my humble opinion, this is actually a very daunting list of requirements for a path planner! I've always been happy when given a difficult problem, however, so I started doing some research and lots of thinking.[/font] [font="Microsoft Sans Serif"][size="5"]Part 3: Solution 1[/font] [font="Microsoft Sans Serif"][size="3"] The first solution to this problem borrows heavily from the work my colleague and I did on a previous game's path planner. To start off, I realized that the world is too large for efficient planning using one big navmesh/grid/graph. A typical world in that game, for example, had well over 50,000 search nodes (which made A* go very, very slow) and the plans I've seen for this game's maps are at least that big. Thus, like the previous game, we'll start with an HPA*-based architecture (described in "Hierarchical Path Planning for Multi-size Agents in Heterogeneous Environments" at [/font][font="Microsoft Sans Serif"][size="3"][color="#0000ff"]http://harablog.files.wordpress.com/2009/01/haa.pdf[/color][/font][font="Microsoft Sans Serif"][size="3"]).[/font] [font="Microsoft Sans Serif"][size="3"] To solve some known problems we ran into, we'll use navmeshes for all the layers and connect them where appropriate via portal nodes. The navmeshes will be composed of convex polygons and we'll strive to avoid long, thin polygons whenever possible when creating the Navmesh. The good news is, we already have code to create such a navmesh given our terrain and a quadtree with footprint boundaries for objects and other obstacles. It uses the GLU Tesselator and it's very fast - fast enough to use in real-time for relatively small meshes. The only problem with the existing code is that it can only generate the navmesh from scratch. Effort will be needed to allow it to update an existing navmesh to accommodate a small localized change. I'm assuming (for now) that this will be possible, even if it's a non-trivial task.[/font] [font="Microsoft Sans Serif"][size="3"] To allow for quick queries on whether a path is possible or not, when we create the navmesh, we'll perform flood fills on the polygons and mark all connected areas with connection group indices. That way, to tell if a path exists is just a quick query to find the start and goal polygons, check their connection group indices and if they're not the same, then no path is possible.[/font] [font="Microsoft Sans Serif"][size="3"] At the top layer of the hierarchy will be the world navmesh. Below that will be navmeshes that are embedded in it (such as lots or routable objects). The borders were a large problem in our previous game and I suspect still will be with this solution, but I have a few tricks to use some heuristics that I think will minimize this problem now. To the world mesh, a lot or routable object will simply be a polygon with edge costs based somewhat loosely on the structure of the interior of the routable area. For example, a "cluttered" lot might have a higher cost to enter than a completely clear lot. This is a non-trivial problem, however, and I expect that a fair amount of work will be needed to deal with the problems the borders between hierarchy layers inevitably introduces. Nonetheless, it IS a solvable problem.[/font] [font="Microsoft Sans Serif"][size="3"] One optimization that is a big help for this problem is to add "preferred" entry points to the lots and routable object meshes. We didn't have those in our previous game and thus had to decide (by some complex heuristics based on the front door and mailbox positions on a lot) where the best entry points for a lot were. Mostly, this worked, but sometimes it failed and caused some wonky paths. Having some pre-defined entry points would greatly help the path planner deal with the hierarchy-boundary problem, so we'll specify in the design that these will be needed for lots and routable objects as part of their navigation info. Users can then decide where to best enter their lot and designers can decide ahead of time where to enter/exit routable objects and we'll speed up the path planner by getting rid of the step to decide best entry points.[/font] [font="Microsoft Sans Serif"][size="3"] Finally, the planner will keep an octree of all the navmeshes in the world so that we can quickly determine which navmesh any 3D point in the world belongs to. Note that this does introduce a restriction that no two navmeshes can occupy the same space in world coordinates. After talking with the designers though, this is fine.[/font] [font="Microsoft Sans Serif"][size="3"] To query the path planner, the start and goal are provided along with any context info. The following algorithm is then followed: [/font] [font="Microsoft Sans Serif"][size="3"]1) Find polygons for start and goal point (along with which navmesh contains them). 2) Do "trivial" checks:[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"]If start and goal are in same polygon, return a straight-line path[/font][font="Microsoft Sans Serif"][size="3"]If goal is invalid, return an error[/font][font="Microsoft Sans Serif"][size="3"]Check to see if a path exists by checking connection groups. If not, then find new goal point in start point's connection group that is closest to the goal point (this is[/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"] [/font][/font][/font][/font][font="Microsoft Sans Serif"][size="3"]an interesting problem in itself and one I might go into in a future devlog entry).[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"]Alternately, we could save some state information during the A* search (in a later[/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"] [/font][/font][/font][/font][font="Microsoft Sans Serif"][size="3"]step) and find the closest goal point based on the nodes that A* explored near the[/font][font="Microsoft Sans Serif"][size="3"] [font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"]actual goal.[/font][/font][/font][/font][/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 3) Update navmesh data structures with temporary restrictions from path context (make costs infinite for edges of locked portals, lots, and objects)[/font][/font][/font][/font]If both start and goal are in the same navmesh, then do an A* search on that navmesh[font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 4) If start and goal are on different navmeshes, do an A* search on the navmesh that is in the highest layer. If they are both in the same layer (i.e. lot-to-lot path planning), then do a path find in the layer above them[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 5) Go through each node in this initial path and find the nodes that correspond to entry points, lower-layer navmesh points, and exit points (always in that order, with the exit point being optional if the lower-layer navmesh point is at the end of the path (and the same logic for the start point and initial entry point). Note that because we have preferred entry/exit points for our lower-layer navmeshes, we can skip the step that was required in our previous game to find the "best" entry/exit points before running the lower-layer search as well as the code that changed the higher-layer path to use the modified start/exit points instead.[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 6) For all other points, find the widths around them that are clear so that we can return the corridor around the path. Interestingly, this turned out to be a non-trivial problem when I looked into how to do this, but that research is also how I ended up finding the link that led me to Solution 2[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 7) For each set of special points, perform an A* search on the navmesh that corresponds to that higher-layer point using the entry and exit points as the start and goal points[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 8) Repeat steps 5 - 7 recursively for lower-layer navmeshes until all special nodes are filled in with paths at the top layer[/font][/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"] 9) S[/font][font="Microsoft Sans Serif"]mooth the path, fill in elevations as needed, etc.[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 10) Restore default edge costs of nodes affected by step 3[/font][/font][font="Microsoft Sans Serif"][font="Microsoft Sans Serif"][size="3"] 11) Return the results[/font][/font] [size="3"][font="Microsoft Sans Serif"][size="2"] There's likely some steps that I'm missing as I'm doing this from memory, but I think that's the gist of how solution 1 would work. It's basically a generalization of how we did path planning for our previous game using navmeshes instead of grids and waypoint graphs with some improvements and optimizations.[/font] [font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"]How do we handle navigation on navmeshes that are moving around? Well, the answer is deceptively simple - as part of the return values for each path point, we return a pointer to the navmesh it belongs to. The navmesh itself can be queried by the animation/movement system at each step to see what the current offset is (and this can be done recursively so that you can navigate on a navmesh that is moving within another navmesh that is moving within....well, ad nauseum. Just add all the offsets, like animation does with bone offsets). There are a couple of problems with this I can think of, and I suspect there's a few I haven't thought of as well, but I believe they're solvable, so I'm not going to worry too much about it right now.[/font] [font="Microsoft Sans Serif"][size="3"] Note that handling such things as allowed movement types and agent width restrictions would be handled at the A* level. Handling movement types is relatively easy (I think) by just checking against valid movement types allowed by each edge (set during navmesh creation), but width restrictions may not be. I know it's possible without being forced to use different navmeshes for each agent size as I know other games have done it, but I'll need to do more research to figure out details. Again, though, I believe this to be a solvable problem, so for now, I'm ignoring it in the interests of getting a high-level design done in a timely manner.[/font] [font="Microsoft Sans Serif"][size="3"] So, that's solution 1. It's sketchy in parts and there's too much hand-waving in other parts for me to feel comfortable with it as a recommended architecture, so I would definitely need to do more research and some prototyping to flesh things out more...which was exactly what I was doing when I ran across solution 2... [/font] [font="Microsoft Sans Serif"][size="5"] Part 4: Solution 2[/font] [font="Microsoft Sans Serif"][size="3"] While doing some research for solution 1 (namely, figuring out how to determine the path corridor points), I stumbed across a thesis by Douglas Jon Demyen called "Efficient Triangulation-based Pathfinding" ([/font][font="Microsoft Sans Serif"][size="3"]http://skatgame.net/mburo/ps/thesis_demyen_2006.pdf[/font][font="Microsoft Sans Serif"][size="3"]). It's a hefty paper (141 pages) and it took me a couple days to read and fully grok it, but it's worth it. The way he does path finding is pretty brilliant, in my opinion, and drastically cuts down the number of nodes that need to be searched. I'm honestly surprised that I haven't heard more about this considering that it was published in 2007.[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"] For solution 2, the world would be structured somewhat like solution 1 except I'm seriously debating whether a hierarchy is needed. At this point, I'm leaning towards no and that of course would solve the problems that are introduced by a hierarchy. However, before I definitely answer that question, I really need to prototype this system and see how well it performs on a large navmesh.[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"] The three benefits to this system compared to solution 1 are: [/font][font="Microsoft Sans Serif"][size="3"] 1) Because it uses a Constrained Delauney Triangulation method, there are known methods to quickly do small localized updates to the navmesh[/font][font="Microsoft Sans Serif"][size="3"] 2) Despite using triangles instead of full-fledged n-sided convex polygons, there are, in general, far fewer nodes to search in a typical path-find query. The reason for this is because the method reduces the search down to just the major decision points on a path and progressively fills out the path with almost pre-set path-finds on a smaller and smaller scale. In a way, this is a built-in hierarchy of path-finding. In addition, it tends to quickly know where dead-ends are and completely ignore them without searching them at all. This by itself is a HUGE optimization over A*[/font][font="Microsoft Sans Serif"][size="3"] 3) Because of the smaller number of nodes searched (in general), it may very well eliminate the need for a hierarchical path-planner architecture. The hierarchy is already built into the navmesh! While I need more data to confirm that this will be faster and that it will handle meshes of the size we use without problem, I'm reasonably sure that it will handle larger meshes in general and could at least get rid of one or more layers of the hierarchy from solution 1.[/font][size="2"][font="Courier New"][font="Microsoft Sans Serif"][size="3"] [/font] [/font][size="3"][font="Microsoft Sans Serif"]The secret is how it constructs the navmesh in the first place by denoting each triangle/node as a level 0, 1, 2, or 3. Level 0 nodes are islands not connected to any other nodes. Level 1s are leaves of a tree that is essentially a dead-end. Level 2 nodes are roots of level 1 trees that connect the entire tree to other level 2 nodes or level 3 nodes (though there is a stricter definition to handle some special cases like loops). Level 3 nodes are the top layer and they are where all navigable edges of the triangle are unconstrained and joined to level 2 or level 3 nodes only. There's some special case handling for rings and such, but essentially assigning levels to each node does most of the work of path planning right off the bat by pre-finding the dead-ends, corridors, and major decision points in a map. It's pretty brilliant, I think, and much easier to understand intuitively (to me, anyway) than other path-finding data representations. It emulates the way our brains do path-finding much better than any other method I've ever seen.[/font] [font="Microsoft Sans Serif"][size="3"]Another optimization that is built into the navmesh generation algorithm is finding choke points - since we know where the "corridors" are, we can pre-compute the narrowest point along that corridor and then use that as a quick search at the higher layers of the path-find to cut off whole corridors at a time if they are too narrow. [/font][font="Microsoft Sans Serif"][size="3"]Of course, it's not all good as there are still a few problems and some requirements I'm not sure the architecture will currently handle (portals, for example) and I suspect that there will be some interesting problems when trying to stitch together the navmeshes. I'm also sure there are some problems I haven't thought of yet. And this is assuming I even understood what I read correctly (which, given that it was a 141 page thesis, is not guaranteed!). Nonetheless, I believe it warrants further investigation and prototyping before even trying to complete the research for solution 1. [/font][font="Microsoft Sans Serif"][size="3"]Based on all this, these would be the general steps for a path-finding query, many of which are still the same as solution 1. [/font][font="Microsoft Sans Serif"][size="3"] 1) [/font][font="Microsoft Sans Serif"][size="3"]Find triangles for start and goal point 2) Do "trivial" checks[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"]If start and goal are in same polygon, return a straight-line path[/font][font="Microsoft Sans Serif"][size="3"]If goal is invalid, return an error[/font][font="Microsoft Sans Serif"][size="3"]Check to see if a path exists by checking connection groups. If not, then find new goal point in start point's connection group that is closest to the goal point[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"](this will require some re-working of the original solution and could thus be a bit of a time sink). There may be some simple ways, based on the node levels that would provide this cheaper than the methods used for solution 1, though.[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"]More research needed[/font][font="Microsoft Sans Serif"][size="3"] [/font][font="Microsoft Sans Serif"][size="3"] 3) Check for other special cases that need to be handled separately (see section 7.1 of Demyen's paper) 4) [/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"]Update navmesh data structures with temporary restrictions from path context (make costs infinite for edges of locked portals, lots, and objects) 5) [/font][/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"]Find the most abstract layer for the start and goal nodes, which will determine what layer the initial search is run in 6) [/font][/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"]Run TRA* (Triangulation Reduction A*, described in section 7.2 of Demyen's paper) on the layer determined in step 4. I don't fully understand this part yet, so I'm sure there's more to it than this, but that's what I'm working on researching now [/font][/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"] 7) For all returned points, find the widths around them that are clear so that we can return the corridor around the path. The good news is that there's some built-in functionality for this already in the navmesh abstraction and an algorithm is presented in the paper to find this information. Hopefully, it will just be a matter of using the algorithm at the appropriate time [/font][/font][font="Microsoft Sans Serif"][size="3"][font="Microsoft Sans Serif"] 8) Smooth the path, fill in elevations as needed, etc.[/font][/font][font="Microsoft Sans Serif"][size="3"] 9) Restore default edge costs of nodes affected by step 3[/font][font="Microsoft Sans Serif"][size="3"] 10) Return the results [/font][font="Microsoft Sans Serif"][size="3"]So that's where I'm at right now in my search for a good path finding architecture for our requirements. It's all very rough and hand-wavy still, which tells me I have more research to do.[/font]
  2. Devnull

    It's Been a While...

    I last wrote in this journal in 2006 and my life as a programmer has definitely taken some interesting turns. Since I started at EA, I've now worked on a lot of Sims games: - Sims 2 Console (Engineer, worked on Create-a-Sim) - Sims 2 Pets for Consoles (Engine Lead, mainly worked on optimization) - Sims 2 Castaway for PS2 and Wii (Technical Director - worked on LOTS of stuff, but primarily Create-a-Sim, Back-end Database tools, and the in-game weather system) - Moved to Stormfront Studios for a while (just before they shut down, unfortunately) and worked on Spiderwick Chronicles (Senior Engineer, worked on Load/Save mostly since I came onto the project so late) - Decided I didn't like Stormfront, so moved back to EA (SF announced they were shutting down a week after I gave notice...ironic) - Worked on Sims 3 (Senior Engineer, worked on overall game optimization and then spent the rest of the time on path finding) - Sims 3 World Adventures (Senior Engineer, did a brief stint and worked on routing in basements and on bridges) - Sims 3 Wii (Technical Director, weird project - mainly I talked to a lot of people in the the development company that actually did the work and ported a bunch of code from another internal project to their code-base to help them. Definitely not a role I think I was very good at or want to do again) - Sims 3 3DS (Senior Engineer, came in right at the end of the project and helped do some bug fixing for a month or so. It's now been announced as a launch title (at least in Europe) for that platform, so I can publicly say that I think the game kicks ass. That dev team rocks) - Current Project (Senior Engineer, unannounced project so I can't say anything about it, but what I'm working on is path finding and unlike on Sims 3 where we were forced to make some sub-optimal choices based on time (though, despite the severe roadblocks we faced, I think the final product was pretty good...and if you disagree, you should have seen what we had to start with and how long we had to fix it!), I have some freedom to do path finding from the ground up and do it right this time...or at least better ) So that's my gamedev career highlights up to the current point in time. I re-read some of the old entries in this journal and I have to laugh about how nervous I was about interviewing at EA originally. I'm much more relaxed and confident now - having a couple games under my belt helps At any rate, I think I'm going to start writing in this journal again as I'm starting work on a very interesting problem and it will be fun to blog about it a bit and get some advice from the many smart people here on GameDev.
  3. Devnull

    What Did I Do?

    Well, given the choices in my previous entry, I finally made a decision to go with option 2. I told my boss. Then the lead for the project in choice #1 convinced me to change my mind and so I decided to go for the smaller, current-gen project. I told my boss again. He now has whiplash. I'm now a Technical Director (well, as soon as our current project finishes anyway - "very soon now") Yippee! :)
  4. Devnull

    On the unfortunately deficient duration of Life

    Not only smart, but very very wise. I hope you stuck to your guns when you went in.
  5. Devnull

    What would YOU do?

    Given the following choices, what would YOU do? 1) Become a Technical Director on a small project for current-gen console technology. This would be an interesting game in itself with a very small team of people that you know and enjoy working with. The only real downside is that there's not a lot of technical challenge in it and it's working with essentially out-of-date technology so any skills gained are pretty useless going forward. Oh, and because its a smaller team with a shorter shipping schedule, it would likely mean some long hours next summer. 2) Become a Senior Engineer for the Next Big Game shipping on next-gen technology working on Terrain and/or AI (to me, these are really interesting fields and I would really enjoy either). 3) Quit and go find a job working on a game that you'd really love to work on. Neither of the above games are ones that I would really be passionate about (beyond the fact that I love programming games in general) and I KNOW that I could find a job doing a game I'd love...but this could very well mean moving out of state and it would also mean starting over at a new company, earning trust and proving myself all over again, etc. Ug. *sigh* A couple of years ago, I would never have dreamed I'd have these choices. Life does seem to change at miraculous speed sometimes.
  6. Devnull

    GDC 2006

    Well, looks like I'm going to GDC this year after all. I didn't think I'd have money, but that seems to have changed. I won't have a Gigapass this year, but a Classic Pass is still just fine for me. So much has changed since my last GDC - I feel like that was a different life. I'm definitely looking forward to GDC this year. Unlike last year, I have no agenda, nothing I'm looking to achieve. I just want to go to interesting panels and lectures, meet people and shoot the sh*t. Oh and talk about purple splines again, of course.
  7. Devnull

    Why 9-to-5 Jobs Suck

    Thank you. I needed to read that to remember why I got into the games industry. Today was a good day to read that and be reminded of my own similar experiences in the "Day Job" industry.
  8. Devnull

    Layoffs Suck

    I hate layoffs. Just in general. Even when you "survive", it's suddenly not such a fun place to work any more. I've been through far too many of them it seems - comes from working in the computer industry for so long I suppose. I understand why they happen. I even (sort of) understand the rationale for "springing" it on people en masse with no warning and no time to prepare, but it's still just unpleasant all around. The good news, I suppose, is that the game industry seems to be in a hiring mood in general. Or at least it seems to be based on how many recruiter calls I (and others) seem to get these days. At least the people leaving should pretty easily find more jobs. But still.
  9. I was re-reading old journal entries tonight and I noticed a couple things: 1) I don't update much any more. 2) My life has changed a LOT in the last couple of years. I don't update much any more not because I don't have anything to talk about. I have more geekery in my head than ever before it seems. But all my geekery these days is for work and I work for a large company. Large companies like secrecy and they have lawyers. I think that's really my only real regret about coming here. I miss being able to talk about programming freely. It's my passion and I feel so isolated when I do elegant code (or stupid code for that matter) and can't talk about it. I can't post code samples. I can't post screenshots. Well, not of the stuff from work anyway (my own stuff, sure, but I don't seem to be making a lot of time these days to work on my own projects). I wrote up a post-mortem about the last project. In it I talked about some of the history of my part of the project, some funny stories from the project, and some general ramblings about work. I also had screenshots from the dev cycle (basically a series of snapshots that showed the metamorphosis from comically/tragically funny to production-quality. Being the cautious person I am, I decided to get it cleared through my boss first since many companies have a nasty tendency to fire people over seemingly innocuous journal entries that lawyers think reveal some secret or other. Well, of course, it got sent on to legal and all of a sudden I was being asked to fill out about 10 pages of forms. So not worth it. And thus ended that journal entry, stillborn. But I guess that's the price I pay for working in a game company. If that's the worst thing I have to deal with, I'll be content. But alas, it does make it hard to think of worthwhile journal entries. Talking about the rest of my life (what little there is of it) bores everyone to tears, I suspect (including me). As for the second thing I noticed - the changes in my life over the last couple of years - I was amazed at the transformation. For years, most of my adult life in fact, I wanted to program games. I'd say that, and I'd whine about how no one would hire me. But I wouldn't actually do what I needed to in order to get hired. I wouldn't take the time to learn the code, nor do enough projects to get practice at it. I'd just feel terribly frustrated and wonder why no one handed me my heart's desire just because I asked for it. And then, out of the blue, I get an interview with Turbine in October 2003. I felt real hope for the first time in years that I might actually be able to follow my dreams. The interviews went well for a long while and they eventually flew me to Boston for a full set of in-person interviews. Even better, it was for working on Middle Earth Online. I can't imagine many other games I'd rather work on, honestly, given my passion for Tolkien and fantasy gaming, MMOs, RPGs, etc. It felt too good to be true. Well, of course, it was. They ended up not hiring me. The funny thing was, I don't think it was because I lacked in technical ability. I did well on the tech parts of the interview - which still amazes me because I look back on how little I really knew about game coding back then and I... well, I laugh. Not getting hired was the catalyst for a midlife crisis, I think. I had had a real taste of hope. For a brief time, I'd felt more alive than I ever had when I thought I might actually be able to work on a game like that. Somehow, unlike previous disappointments, I was able to channel the massive depression from that rejection into something useful. I spent the next year or so tinkering around with game code. I absorbed massive amounts of knowledge from books, code libraries, forums, anything I could lay my hands on. I dove into driving problems - terrain generation, permutations, 3D math, etc. I tore apart and wrote rendering engines. I gave up games and much of my social life. I had never felt such determination or had such discipline before. At any rate, in the summer of 2004, my wife saw a blurb in the University of Washington about a game certificate program - a year long course in game programming. By that point, I was starting to feel like I was spinning my wheels a bit. I knew enough to know I didn't know much and that I needed mentoring and people to bounce questions off of. So, I figured out how to pay for the course (thanks Dad!) and enrolled. October 2004 was the beginning of a year of real transformation - because of that class. I became obsessed with the class, learning everything I could. I not only did the assignments, but wrote a complex game engine from the ground up. I literally ate, drank, and slept game code for the next six months. I would spend every waking moment either working on my day job or working on my game code. And I was in heaven doing it. Of course, there was a price to pay, though. I realized how much I was disliking my day job and I just found it harder and harder to muster the discipline to work at it. They noticed, wanted to help me and tried their damndest to compromise. But I just couldn't put my heart and soul into it anymore. Or much of my brain. All I wanted to do was program games. What remained of my social life went by the wayside. I started seeing my family less and less. Six months into the class, I realized I couldn't continue like that. I was wearing myself out, and not seeing my family was not good for any of us. So I decided to back off somewhat - concentrate more on work, see my family more, and only do the minimum for the assignments for a while. Literally days after I'd made that decision, EA emails me and within a month, I had a job offer to work on the Sims as a programmer and enough money so that I didn't have to automatically turn it down because I couldn't afford to take the job. But the job was in California and for various reasons, would require me to move there by myself for up to a year. I wanted to finish the game programming course, I wanted to fulfill agreements with my current job and stay to help finish a project I was relatively critical for, and I definitely didn't want to move out on my own. But this was the opportunity I'd been waiting for and had worked so hard for years to get. There was no guarantee I'd get other offers in the Seattle area, though it was seeming likely. The game, while not my favorite genre, had interesting technology and would be a great project to work on. Most importantly, it would get my foot in the door, be that big break that I needed to get in the industry and prove (to myself more than anything!) that I could indeed do this. So I accepted the offer, moved to California, got a little studio apartment and dove into the project with a will and a passion that surprised even me. Living on my own, I had no reason to go home at night and no real desire to, so I spent pretty much all my waking hours here. Not exactly healthy, especially since I'd been already doing a similar schedule for the six months previous. Interestingly, I felt closer to my family in some ways. I flew home every other weekend and the time I spent at home was real quality time. I wasn't constantly thinking about what I should be doing to fill my spare time with code so I could get a gaming job. I was able to really relax during my weekends off - the first time really in years I'd been able to do that I think. And when I wasn't in Seattle, I was at work, pouring my heart and soul into a game, absorbing code, learning the engine architecture, learning to program on consoles instead of PCs, and generally having the time of my life. And then, one day, the project ended. We had a release candidate and no more code changes were being accepted. And then it passed internal testing, then external testing, and finally went gold. It was hard to come down off that mental mind-set - buried in crunch mode. I felt lost for a while again. But then I was basically told "take some time off". So I did and I flew home for a couple weeks. I immediately got sick for a week, of course, hacking up a lung, etc. A year of stress (even good stress) will do that to you. My body rebelled and I let it, finally. But I also completely relaxed. I played games again. I worked on a project of my own, just because it was fun. I spent time with my family and had real conversations with my son. I visited friends. And now, I'm back at work, starting pre-production for our next project. After an initial day or so of confusion where I got to know and grok my new bosses (and vice versa) and figure out what I'd like to be doing on the project, I'm now figuring out tasks and diving into them with gusto. Despite initial confusion, it's clear that I do indeed have some say in my destiny here, which is extremely important to me. It makes a huge difference being asked to do something instead of being told. So, life is back to a new "normal" for me, I think. After two years of pretty intense change, I think I can finally relax a bit, settle into my own skin, start enjoying my life with less stress again, and really enjoy my new career, because it's what I've wanted for most of my life. Oh, and go home in the evenings. =) And impatiently wait for next May, when my family can move down with me.
  10. Devnull

    From Under My Rock

    Yes, I'm still alive. Really. The last few months have been some of the most intense (and enjoyable!) of my life. I've dived into a new (to me) codebase. I've finished my first shipping game product. I've made a good impression. I've made some new friends. I've lived completely on my own for the first time since I was 18. I've done my own laundry at least once! All that and more, in fact. I've learned that most of my preconceived notions about working in the game industry were..dead on accurate. Some were not, but for the most part, there was very little that I didn't expect. It was a lot of work, but I enjoyed (almost) all of it. The code was nothing magical, it was just code. There was nothing I couldn't understand, given a little study. The people I worked with were very intelligent, but I didn't feel intellectually dwarfed (most of the time =) ). I was thrown into a fire, but my firefighting skills were up to the task. In short, I've found my niche in life and I'm happy to be here. I'm also glad that I have some time off to recover and relax. =) I'm coming to Seattle this weekend, then going to some classes the week after that, then coming to Seattle again for another week (possibly 2) after that. The rest of October and November will be relatively peaceful, no crunch time at all. I'll take some more classes, do some prototyping, write some post-mortems, and figure out how to accomplish some new tasks on our next game. Oh, and maybe write a few more journal entries, since they've been so nonexistent for a while. And FINALLY, I'll have time to really read SimmerD's amazing journal entries. Some excellent stuff there that I really want to take time to digest. In a few hours I'll get to see my family again after a very-long month of working, and I'm really looking forward to that. So, for now, I'm off. Hope everyone is doing well.
  11. Devnull

    Sleep?

    *blink blink* I think I'll sleep...now... *thump*
  12. Devnull

    Almost there...

    Shhhh =)
  13. Devnull

    Almost there...

    Almost there... So close!
  14. Devnull

    Hot Coffee and GTA

    I think this pretty much sums up my opinion on the GTA thing *shakes head and wanders away*
  15. Devnull

    Some previews and screenshots!

    Quote:Any war stories? Heh, well...tons from my last job, but nothing from the current project yet. Ask me after we ship, though =)
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!