Announcements
Week 73
Posted by Isquires on Thu Jun 28, 2007 10:00 am - 0 Comments

We've updated the Pocket Realms site with help from Jordan at theglowbox. There is a form to subscribe for updates on the beta schedule, and sometime in the next week we'll have a blog set up. Hopefully we can improve the forum situation as well.
Week 72
Posted by Isquires on Fri Jun 22, 2007 5:05 pm - 0 Comments

Well I've finally got a temporary site up for PocketRealms. Don't let my lack of web design skills fool you, we're doing some cool stuff behind the scenes here at Warb. Aside from Pocket Realms, there are some other interesting directions for us to take the technology. In fact, if you happen to have a unique application that would make use of networked simulation & 3d graphics, send me an email and we can explore possible forms of collaboration.
Week 68
Posted by Isquires on Wed May 23, 2007 12:12 am - 0 Comments

It's time for another transition - my contract with NICTA (organization behind Yoick) is wrapped up and I am now working full time on the warb engine as well as Warb's own virtual worlds platform. I think I'm going to call it Pocket Realms! I'll be working this week to get a site and screenshots put together. [Edit for clarity: I am no longer affiliated with Yoick, NICTA, or Project: Outback.]
Week 58
Posted by Isquires on Thu Mar 08, 2007 8:15 pm - 0 Comments

Wow... it's been about 3 months since I last posted progress. I think it'd be an understatement to say things have been crazy on our end, but we've finished prototyping our new platform Outback Online in combination with the guys at Yoick. I'm anxious to get back into a mode which is more transparent on our operations (and I can see that day quickly approaching), but for now I'll have to remain brief on detail. In general, Sidereal Fury has transitioned into custom content for Outback Online and will ideally release alongside the platform. In the near future I'd like to begin conversation with any other developers out there who are interested in getting a jump start on content creation for Outback, but it'd be premature to open that up until we've reduced churn in the API (I'm rewriting half of Sidereal Fury every month at our current rate.. ok, an exaggeration but we're still shifting things around).

As far as dev, most of the recent work has been split among UI and integrating new network tech. Our short term goal is to continue adding features needed to create the minimal experience necessary to start sharing the product, before we get back to the graphics & gameplay widgets.
Week 46
Posted by Isquires on Thu Dec 07, 2006 12:44 am - 0 Comments

It's been a few weeks gap between updates, as I've had an action packed November. The warb engine is now being used in an Australian project (fully .NET), so I flew out to Melbourne to discuss the integration points. Now back in Austin, I'll be working hard to help the company to develop an online social networking game (think Second Life). This is exciting for the warb group, as the Australians have embraced our design methodology and will also permit the continuation of development on Sidereal Fury. During the next few months, I need to reserve details specific to changes in the engine. However, the long term goal is still to create an open API and a level of accessibility to the end user.

Short term focus is on terrain generation tools, collision detection, and multi-threaded execution (trying to add a new feature, while polishing a few others that were in recent months starved for attention).
Week 41
Posted by Isquires on Fri Nov 03, 2006 7:08 pm - 0 Comments

I've replaced the update list (a flat list of top level objects) with a scene object, which derives from warb object. The scene object now contains all objects which previously would have been added to the update list. This simplifies the interface a bit, since now all objects are attached to other objects (there is no longer a distinction in the API between adding a top level object and connecting an object to another). This also improves insertion behavior - originally the types that an object could be inserted into were listed in an attribute, along with several flags to define whether the object is insertable at the top level and visible by default in the insertion palette. Moving to the scene root means that the insertion description is simpler, since being insertable into the scene would now just require listing the scene type among the types into which the object is insertable.

Last week's accomplishments:
- Custom editors for warb object components (renderer, controller, collider).
- Spec'd final insertion behavior for editor and in-game object creation.
- Replaced engine's update list with a warb object "Scene".
- Created camera manager and custom user camera perspectives.
- Moved all of the "Test Drive" code into the scene object's constructor. There is also an event for start and end simulation, that can be handled by any object to help construct the scene at run-time.
- Added texture file support for cube maps.
- Added effect files to resource manager.

Next week's focus:
- Flesh out spec for network interface and any object attributes that will define network update behavior.
- Continue to add support for asynchronous Render & Update.
- Evaluate options for contract artwork towards a new project.
- Begin implementation of underlying engine code to support new insertion behavior and in-game insertion.

Btw, for those who haven't heard, the XNA Game Studio Beta 2 was released this week.
Week 40
Posted by Isquires on Wed Oct 25, 2006 10:19 pm - 0 Comments

We've started generalizing the editor for use in creating a variety of scenes. Originally some initial setup would be performed for even the most basic scene, including the setup of lighting, background, and player position. I've moved most of this setup into scene config objects. Each config object, when inserted into the scene, will perform setup of background content & lighting; handle connection setup; load persistent data from the avatar profile; and potentially even monitor scene state to script new object creation. Although really any game object could perform these actions on insertion, the scene object will support customization through the property grid (so that the designer doesn't even need to write source to configure the general properties).

Last week's accomplishments:
- Created field object.
- Updated collision detection to support field interaction.
- Moved default scene setup into scene config object (setup specific to SF such as asteroid placement, was moved into the space scene).
- Redesigning game objects to maintain render state in a secondary data structure.
- More objects will now render in edit mode.

Next week's focus:
- Terrain Rendering.
- Custom editors for colliders, renderers, and controllers.
- Avatar interface (now avatar controller).
- Network messaging for object deletion.
Week 39
Posted by Isquires on Wed Oct 18, 2006 1:03 pm - 0 Comments

We recieved some new artwork last week! Among the submissions were a new player ship, weapon, monster, planet textures, and some terrain. I'll see if I can get some screenshots hosted.

Otherwise, most of the work this week was general cleanup and refactoring. I fixed up some issues with skinned animation, and we're looking at bumping up the client app into the seat of primary executable. Previously, most of our testing has been done in the editor, but now it is time to move the editor into a position which does not depend on game specific source. Likely forms for all types of applications will be built into the engine, and simply be displayed by the custom game application. Along with this change, we're looking at improving custom editors for renderers, colliders, and updaters on objects.

Last week's accomplishments:
- Cleanup for editor.
- Cleanup in connection manager and client app.
- Work towards a general avatar interface (cross-game support).
- Work on code execution security.
- New artwork.

Next week's focus:
- Terrain rendering.
- Custom editors for components.
- General editor refactoring.
- Complete spec for avatar interface.
- Debug several issues with collision response.
- Network messaging for object deletion.
Week 38
Posted by Isquires on Mon Oct 09, 2006 9:36 pm - 0 Comments

Everything is in a much better state now, after several volatile weeks (mostly due to changes necessary to support shadow mapping & animation). I've finished integration of the octree scene graph which made a big difference in CPU usage - list traversal and visibility checking ended up contributing quite a bit to general overhead of scene management. Another interesting find is the gain in swapping around a bit of the rendering order. We currently sort objects by renderstate & shader technique, and previously I would iterate through each of the render passes per object. With recent changes, I've moved the pass loop higher in the stack which means we iterate through all objects before advancing to the next shader pass. Apparently the cost of building transformation matrices was much less than the cost of modifying the effect. Long term, I could probably cache these matrices such that there is almost no additional CPU overhead per render pass.

On top of all of that, we tested some terrain rendering ^^

Last week's accomplishments:
- Visibility is precomputed using the scene graph.
- WarbLights & cameras now build and sort visibility lists per frame.
- Switched to octree from RDC for collision detection.
- Wrapped up shadow mapping & implemented shadow casting for directional lights.
- Worked a bit on terrain rendering.

Next week's focus:
- Terrain rendering.
- Debug several issues with collision response.
- Network messaging for object deletion.
Week 37
Posted by Isquires on Sun Oct 01, 2006 10:31 pm - 0 Comments

It looks like we've narrowed down on the final shadow map implementation. Before we can confirm that this will be a general purpose fix, we need to address some performance issues elsewhere in the engine. If everything runs smoothly after that, then we can finally put lighting to rest and start looking at the next set of features.

Last week's accomplishments:
- Further research and testing of shadow map variations.
- Implemented a new scene graph data structure (sort of a floating octree).
- Began work to reduce the number of visibility checks - currently we check visibility with the camera for each light rendered. Eventually there will be a single visibility pass per frame using the scene graph. We will also update high level collision detection to use the scene graph rather than RDC.
- Converted textures to new file format.

Next week's focus:
- Finish up scene graph implementation and integration.
- Optimize collision detection using scene graph.
- Validate final shadow map implementation.
- Implement shadowed lighting for directional lights.
- Network messaging for object deletion.
- Investigate implementing a terrain renderer... O.o
Week 36
Posted by Isquires on Sat Sep 23, 2006 4:38 pm - 0 Comments

We're still working on shadow maps this week and next. There are quite a few variations out there that address both performance and aliasing issues. So far, I've experimented with standard shadow maps, perspective shadow maps, trapezoidal shadow maps, and sub-divided shadow maps. Really almost every variation that attempts to address the aliasing issues applies a transformation on render that will warp the shadow map into a space which takes better advantage of the shadow map resolution. It is suprising how little consensus there is on a good algorithm, but it is likely because there are many tradeoffs between the various implementations - typically quality vs. performance. I'll probably spend a few more days tweaking our rendering (I wrote some quick & dirty debug utilities that help to analyze error), before I move on to the RDC replacement.

Last week's accomplishments:
- Improvements to shadow mapping quality & performance.
- Updates to allow merging of snapshots.
- Added UI support for importing resources.

Next week's focus:
- Finish up shadow mapping.
- Investigate replacements for RDC.
- Messaging for object deletion.
- Update textures loaded to use the resource manager & cache.
Week 35
Posted by Isquires on Sat Sep 16, 2006 2:27 pm - 0 Comments

Floating point is the bane of my existance. Now, having said that I'm not sure if I want to spend the time it would take to really explain all of the failings in floating point (at least for game programming), as it would take awhile, be pretty boring, and drive me further to insanity. To summarize, it adds too much unpredictability to the engine. A scene that works well when everything is small and contained, could fall apart as it expands or moves farther from the origin. Worse, when a problem is caused by lack of precision (or fluctuation in precision), it is really hard to debug and understand. There often isn't anything obviously wrong with the implementation - stuff simply looks bad and behaves strangely. I battled with precision issues a few months back when implementing background objects, and ended up placing distant objects (like planets) very close to the camera; clearing the zbuffer after they are rendered. Lately I've been working on shadow mapping, so floating point rears its ugly head once again...

As far as shadow mapping, we've actually made a ton of progress this week. Between discussion within the group and some online research, I have a much clearer perspective of the tradeoffs between each of the flavors of implementation. What is sad though, is that the simplest and cleanest implementations still don't perform quite well enough when combined with multiple lighting passes. Likely we'll at the very least need to scale the quality based on system capabilities (like area of the region to average when performing filtering). I originally wanted to render to shadows in camera space prior to lighting objects, so that I could blur that surface. However, rendering the scene 3 times per light really ate up our graphics bandwidth and I had to settle with mediocre quality for the time being. With the new lighting on the other hand, we were really able to boost quality back into the range that I had envisioned. I was worried about the loss of PRT really taking away some of our initial style, but by placing spot lights on every ship and giving projectiles & explosions point light sources, the engine is still capable of the same dramatic quality.

Last week's accomplishments:
- Shader implementation for spot lights and point lights (already handled directional lights).
- Added support for specular materials.
- UI for deleting, moving, and otherwise managing resources.
- Shadow mapping.
- Random bug fixing, cleanup, and refactoring.

Next week's focus:
- Cleanup shadow mapping and look for performance optimizations.
- Investigate moving from RDC to Octree for object collision & visibility tests.
- Messaging for object deletion.
- Update textures loaded to use the resource manager & cache.
Week 34
Posted by Isquires on Fri Sep 08, 2006 11:25 pm - 0 Comments

This week's update is delayed due to all sorts of chaos (in particular the Austin Game Conference). I'm still trying to unwind from the experience, but I definitely enjoyed many of the sessions and met some interesting people. (If any of them are reading this - hope to see you again next year!)

As far as Sidereal Fury, I wrapped up lighting for now and made some progress implementing shadow maps. Michael also got a bit more of the communication framework implemented and has multiple ships flying around in a shared state. Pretty much everyone else was either finishing work or out of town this week.

Last week's accomplishments:
- Updated scene lighting.
- Progress on shadow maps.
- Initial support for transfering object data and remote calls.

Next week's focus:
- Messaging for object deletion.
- Snapshot support for merging objects.
- Complete shadow map implementation.
- Something fun like a new behavior or UI component.
- Field object.
- Debug collision detection performance issues.
Week 33
Posted by Isquires on Thu Aug 31, 2006 1:42 pm - 0 Comments

I come bearing good news - daytime workload is finally lightening not only for the primary developers on Sidereal Fury, but also our artists. When they are not creating games, those that contribute to our project work on some pretty spectacular assignments. With many of those nearing a close, we hope to push forward towards an end-of-year alpha. With the rate at which the multiplayer component is progressing, we should be capable of putting several players into a free-for-all shoot out or even one of the preliminary race sequences.

Last week's accomplishments:
- Import UI for resource files.
- Finished up animation.
- Continued work on network state.

Next week's focus:
- Multiplayer (transferring event data).
- Shadow maps.
- Replacement lighting for PRT (either basic per-pixel, or perhaps LDPRT).
- Field object.
- Collision detection optimization.

Next week is the Austin Game Conference - hope to see many of you there. Also, the XNA Framework beta was just released - I'll spend some time evaluating what's there and comment on our migration plan sometime within the next month.
Week 32
Posted by Isquires on Thu Aug 24, 2006 9:06 pm - 0 Comments

Rendering update - we're going to have to drop PRT lighting in exchange for animation (and neither play nice with instancing, so it may be that only static models will get instanced). LDPRT is still an option, so we will probably evaluate its compatibility with shadow mapping once animation is all finished. The end is in sight for rendering framework - which is great. I'm all shader'd out and looking forward to implementing some game logic for awhile. The game UI also needs updating, so I might also focus on menus to help with keyboard mapping. Resource management is looking nearly complete as well, so we'll probably visit the download manager after that. James is working on a sort of harpoon / net gun which should be interesting.

Last week's accomplishments:
- Implemented behavior manager.
- Partially implemented animation support.
- Mesh file is finished up.
- Converted .x files to warb mesh file format.
- Updated game objects to use cached mesh files.
- Wrote compression code for resource files.
- Lots of fixes for asych update.
- Snapshot can now serialize a scene asynchronously during update.
- Fixed MRU list and editor settings (weren't getting persisted properly).

Next week's focus:
- Multiplayer (state managers).
- Finish up animation & lighting.
- Shadow maps.
- Field object.
- Import UI for resource files.
Week 31
Posted by Isquires on Wed Aug 16, 2006 12:31 am - 0 Comments

I don't think we implemented anything terribly exciting this week. Most of what we're involved in right now is grunt work to support the next step in collision detection and multiplayer sync. Paul has also been continuing with the resource management which looks like it is coming close to being finished. Once that is implemented, all game objects will be able to reference the same cached versions of models, sound effects, and textures (without knowing any more than resource name).

Last week's accomplishments:
- Implemented Controllers, Renderers and Colliders for most game objects.
- Continuation on multiplayer (I think Michael is working on sending object creation data to the client).
- Snapshots (our form of scene serialization) now support properties necessary for propagating network state.
- Additional work to support resource caching and discovery.
- James did nothing, way to go! :p

Next week's focus:
- AI behavior manager.
- Field object.
- Sound Manager.
- Multiplayer.
- Animation.

It seems like I've listed those 5 task items before.. wait I have - for the past several weeks! Yeah, we keep getting side tracked; but it is usually with newly-discovered (and important) framework stuff. The bright side is we are still making great progress; our feature creep is starting to feel more like quick sand (rather than the black hole we experienced for awhile).
Week 30
Posted by Isquires on Wed Aug 09, 2006 10:09 pm - 0 Comments

I forgot to mention last week that the screenshots added also include some of the newer UI components. In the upper right corner is the ship radar, which renders game objects as circles and sizes them based on position relative to the ship. The speed bar and energy bar are at the bottom. The speed bar fills up as velocity increases (duh), and will fill up again as a darker color when the afterburner is engaged. The energy bar is the blue bar below the speed bar and will decrement as weapons are fired and during afterburner usage. We also have a targeting indicator - I'll try and get that into the next set of screenshots posted.

Aside from all that, this will have to be a short update as I am in the middle of a pretty big overhaul. The project is big enough that any significant architecture change feels like a juggling act. What I am trying to do right now is seperate WarbObject (our game object) into smaller components - Collider, Renderer, and Controller. The controller is the module for either AI or user input. Controllers are already implemented and allow us to share AI between different game objects. The Collider is similar but handles collisions and can also be shared. The Renderer will be the biggest change and will allow us to sort objects into bins based on the rendering type. This means we can instance geometry for all rendering, rather than select clusters of objects. It also means that the inheritance hierarchy is no longer muddled by rendering classes. Currently, you can either inherit from the WarbObject that you want to behave like or the warb object you want to render like (not both). Since C# does not allow multiple inheritance (which I understand the reasoning for), there is code duplication. Pulling the rendering out into modules that can be shared solves the problem and allows us to use inheritance for game logic.

Last week's accomplishments:
- Started work on the first capital ship.
- Security drone AI.
- Defined and implemented Warb Resource File.
- Scene files now contain all custom resources.
- Resource loader & resource import / export.
- Various fixes for undo.
- Progress on multiplayer component (client no longer requires port forwarding).

Next week's focus:
- AI behavior manager.
- Finish game object modules Controller, Renderer, and Collider.
- Field object.
- Sound Manager.
- Multiplayer architecture.
- Animation.
Week 29
Posted by Isquires on Fri Aug 04, 2006 12:20 pm - 0 Comments

New screenshots! This is another update which is arriving a bit late, but I wanted to wait until some of our recent artwork was integrated. Each of the new pieces will somehow contribute to our first playable level. The comet shown in the first image is the focus of the level. Players will fly along a track which reaches to the end of the comet tail and also dive through a tunnel within the comet itself. Harvesters (second image) will be placed along the length of the tail and represent the bulk of a mining operation taking place. The harvester will orbit the comet tail, firing lasers which track large chunks of comet debris. After smashing comet chunks into smaller pieces, mining drones will fly through the area to collect the valuable components. We also have a new track piece - the start gate, visible in the third image. The fourth image shows a scaled-up version of a mining drone chasing the player ship.

Last week's accomplishments:
- Ongoing collision improvements.
- Updated geometry instancing to support mesh subsets.
- Comet game object.
- Harvester game object.
- Start gate game object.
- Mining drone game object.
- Mining drone AI.
- Security drone game object.
- Multiplayer client now renders an echo of your ship, after updates from the server.

Next week's focus:
- Mesh file format.
- AI behavior manager.
- Rendering framework improvements.
- Field object.
- Sound manager.
- Multiplayer synchronization.
- Animation.
Week 28
Posted by Isquires on Wed Jul 26, 2006 10:06 pm - 0 Comments

Wow, what a week. It is amazing how much fun new stuff flew through the project over the past few days. We've been working with Asorson Studios to get some good looking art for the first few levels, and they've been a blast to work with. Not only are they very professional, but the quality of their work definitely exceeded my expectations. The other great aspect of working with them is that they stuck to our concept work, but managed to add their own style and level of quality. I highly recommend checking them out if you are in need of digital content. I'm waiting on the last bit of work from them before I start posting screenshots, but there should be some media to share by some time next week.

The other wild pieces of this past week were the Texas Independent Game Conference this weekend, and the Austin 3D Users' group meeting earlier this evening. Each ended up being a great experience and particularly relevant to where we are in our production. The indie game conference had great sessions and I had a chance to meet a lot of fun people. If you are an independent developer and didn't make it to this year's conference, be sure to check it out next year. Saturday evening they had a game demo party and we had our first chance to expose Sidereal Fury to a large audience for play testing. The feedback was very useful and also gave me the energy to reinvigorate the team who has been working nearly a year on this project.

The 3D Users' group was also a lot of fun as the topic of art direction was covered by a panel of great speakers. Since we've been working a lot lately with external artists, this hit home and gave me some ideas for how to streamline the process.

Last week's accomplishments:
- Refactoring of our collision and update system.
- Finished up geometry instancing.
- Integrated a bunch of new content.
- Started looking at animation support.
- Produced a working test client for our multiplayer protocol.
- Paul rebuilt his dev machine which means we might get his old one to use as a test machine!

Next week's focus:
- Mesh file format.
- AI behavior manager.
- Rendering framework improvements.
- Field object.
- Sound manager.
- Multiplayer synchronization.
Week 27
Posted by Isquires on Wed Jul 19, 2006 3:31 pm - 0 Comments

This was a quiet week, most everyone is busy or taking vacation. I've been working on instancing through our shader but I've been having a hard time debugging several of the issues. As far as I can tell, the only real debugging support with VS 2005 is through PIX. I got some tips from the guys at MDX Info, and their tutorial gave me a great start on the feature; however I still feel like there is a ways to go until the feature will be able to support instanced geometry with the PRT lighting. I'll be happy when my ships no longer look like crushed-up pop cans...

Last week's accomplishments:
- General collision refactoring and cleanup.
- Added a mechanism to generate low detail collision meshes.
- Added a collision mesh render mode.
- Continued to implement client / server communication.
- Spec'd out new rendering framework (expands on current implementation)
- Continued work on geometry instancing.
- Several updates to scene management interface.

Next week's focus:
- Mesh file format.
- Texture & Sound file formats.
- Geometry instancing.
- Improve rendering framework.
- AI behavior manager.
- Field object.
- Sound manager.
- Client / server protocol.

Finally, this weekend I'll be attending the Texas Independent Game Conference here in Austin - hope to see some of you there!
Week 26
Posted by Isquires on Thu Jul 13, 2006 8:33 am - 0 Comments

Shoot. I dropped the ball - this being the first weekly update to arrive late!! Although, in my defense this has been a long week. Last night the source control server died and I ended up having to reinstall the OS to get things back up again. On the bright side, we finally have mesh to mesh collisions working! This has been the feature that won't die since day 1. We've bounced back and forth between implementation ideas and organization of the architecture, but now finally it is working in-game and I can fly the ship through a giant donut that is temporarily placed near the origin. There are quite a few optimizations to be made, but we're getting decent framerate while colliding and the game still feels solid.

Last week's accomplishments:
- Mesh to Mesh collisions.
- Prototype client / server interaction.
- Radar finished.
- Particle Emitter optimizations (went from taking up 25% of a typical scene's frame time to about 2%).
- AI Ship (named Carlos) now follows the player around and shoots at him.
- Scene & resource management dialog.
- Began work on level of detail based mesh selection.
- Began work on geometry instancing with shaders.
- Spec'd out multi-behavior processing for AI.

Next week's focus:
- Generate low detail collision meshes.
- Investigate collision detection optimizations.
- Continue to implement connection manager.
- Add support for geometry instancing.
- Abstract out rendering from game objects.
- Write a path-following AI behavior.
- Create a behavior manager class.
- Field object.
- Sound manager.
- Mesh file format.
- Update resource manager to support sounds and textures.

It's pretty funny having AI in the game now. I'll be focused intently on the performance monitor as I work through a series of tests, then out of nowhere - BAM!, Carlos is blasting my ship into pieces.
Week 25
Posted by Isquires on Wed Jul 05, 2006 10:39 am - 0 Comments

The 4 day weekend was kind to Sidereal Fury. We managed to knock out a bunch of the in-game UI, spec out our multiplayer protocol, and even refactor a great deal of our resource management code. I've been thinking about scene installation and I am somewhat on the fence as to whether we should define our own mesh file type. Currently, pretty much every mesh has lighting and normal information in external files. In addition, we have externally referenced textures. I am thinking about leaving textures external to the mesh so that they can be swapped easily and modified without needing to update the mesh file itself, however the normal and lighting information all depends on the model and would need to be regenerated if the model changed. Although it is possible that we may want to update the normal map external to the mesh, I can't see that being very common as it isn't as useful as updating the diffuse map. It would also be very unlikely to have more than one normal map per mesh and there is definitely only one set of lighting constants for a mesh. Combining all of this information into a single file not only simplifies our installation and updating process, but creates a strong dependency between required resources. If our conversion tools were to only support a one way conversion into our format, it would also be an easier way to maintain some control over our art assets while still keeping them separate from the binaries (although I am less concerned about that aspect at this point).

Last week's accomplishments:
- Added private messaging to chat.
- Added /ignore and /unignore commands to chat.
- Chat server now logs to file.
- Chat server now enforces unique names.
- Chat client now blinks on new message.
- Added colored text to chat client.
- Implemented energy management for ships.
- Created GUI component "Energy Bar".
- Created and animated GUI component "Target Indicator".
- Partial implementation of ship radar & display.
- Spec'd out multiplayer protocol.
- Refactored resource management.
- Began defining mesh file format.
- Updated texture API and added variations on transparency support.

Next week's focus:
- Field Object.
- Sound Manager.
- Mesh file format.
- Client / Server communication.
- Mesh to Mesh collision.
- Radar.
- Ship AI.
- Abstract rendering implementation out of the game object inheritance hierarchy.

At this point, development on the editor is finished for the year. All of the features from this point on are either targeted at the game client, server, Warb Engine, or resource management.
Week 24
Posted by Isquires on Wed Jun 28, 2006 3:07 pm - 0 Comments

Quite a few features have wrapped up this past week so we are starting a couple new large scale projects. Specifically the in-game user interface, multiplayer protocol, and AI are now under development. I sync'd to source late last night after working on one of the UI components for a few hours, and I found that now when I run the game there is another little ship flying around. How freaking cool!!! All it does right now is randomly turn engines on and off, but it is a lot of fun just to push it around and shoot at it as it wobbles about in space.

Last week's accomplishments:
- Speedbar UI component.
- Targeting.
- Began work on ship AI.
- Updates to texture to screen and other texture functionality.
- Finalized performance monitor tab.
- Finished up emitter class.
- Added small pieces of randomly generated asteroid debris.

Next week's focus:
- Field object.
- Chat client additions (colored text, private messages, and client GUIDs).
- Investigate .NET remoting for multiplayer.
- Mesh to mesh collisions.
- Continue ship AI.
- Energy bar GUI component.
- Sound manager.

We also had a short team meeting this week to discuss the logistics behind ship energy and armor balance. I'll try to summarize and post some of that information either in next week's update or on the forum.
Week 23
Posted by Isquires on Wed Jun 21, 2006 11:21 pm - 0 Comments

New Screenshots! What a contrast between June 2006 and November 2005. I'm glad that we decided to catalog our progress - not only does it add consistency to development, but it gives us a chance to actually witness our progress. Week to week if I run the game or review source changelists, the differences are so incremental that it is sometimes disheartening. It is fun to be able to take a step back and really see how far the project has come. The first screenshot is of a giant "thing" with tentacles. It looks pretty neat and is fun to fly around. The second shows one of our new weapon systems and projectiles. The third image is of the updated track sections, and the fourth shows the radial blur and bloom effect that kicks in while using the ship's afterburner.

If I had to pick a feature of the month I would say that the performance tab that got integrated this week fits the bill. I don't know why this wasn't on our list from the start, but what a difference hard numbers make when debugging issues.

Last week's accomplishments:
- Utility mesh collection.
- Animated textures.
- Skeleton loader for sandbox app domain.
- Performance monitor tab.
- Reduced the performance requirements of our editor controls.
- Began work on Emitter and Cluster game objects.

Next week's focus:
- Create field object.
- Mesh to mesh collisions.
- Chat client additions (colored text, private messages, and client GUIDs).
- AI for bots and monsters.
- Ship HUD controls.
- Targeting.
Week 22
Posted by Isquires on Wed Jun 14, 2006 9:15 pm - 0 Comments

The big project this week was supporting object state update in an asynchronous thread. This change makes a big difference in performance, and in particular for those with slow CPU's. The last big performance related feature that we plan to implement is support for object instancing. Likely I will implement this along with the generator class since generators will contain a list of many instances of the same mesh. Rather than pay the cost of sorting our render list after each modification, we'll let generators handle rendering for each of the objects they generate. This results in automatic grouping of objects of the same type in situations where there a lot of the same object (also the situation where instancing will most improve performance).

Last week's accomplishments:
- Improved edit time camera on selection change.
- Update for objects is now asynchronous from render.
- Began work on performance tab.
- Added auto scroll to output window.
- Explosions attach to the impact location.
- Update track rendering to use new mesh rings.
- Improved refresh performance of scene explorer.

Next week's focus:
- Collision improvements - mesh to mesh and rotation.
- Generator and Field warb objects.
- Finish chat client (colored text, private messages, and client GUIDs).
- Initial AI for bots and monsters.
- Controls for in-game HUD.
- Performance tab.
- Targeting.
Week 21
Posted by Isquires on Wed Jun 07, 2006 4:42 pm - 0 Comments

Up until now I've gotten by with a very primitive understanding of HLSL as well as the principles underlying vertex and pixel shaders. I have actually managed to implement some interesting effects, as well as support for PRT lighting just through tweaking examples. However, when integrating support for normal maps I finally had to get my hands dirty and spend some time learning a bit more about how to write shaders. I found the Nvidia and ATI sdk's helpful and they both have pretty good tools for visualizing shaders. At the end of the week, our rendering shader now supports normal maps. Integration wasn't as complicated as I expected since the PRT calculation is per vertex, and the normal map support is per pixel (each are pretty much isolated). Also, I don't think it would be very difficult to add support for height maps now and do the whole parallax thing.

Last week's accomplishments:
- New particle explosion for projectile collisions.
- New weapon system.
- Several new sound effects.
- General improvements to explorer tree and insertion palette.
- New waypoint, asteroid, and space eel models.
- Added support for rendering models with a normal map.

Next week's focus:
- Collision improvements - mesh to mesh and rotation.
- Generator and Field warb objects.
- Finish chat client (colored text, private messages, and client GUIDs).
- Initial AI for bots and monsters.
- Controls for in-game HUD.
- Edit time camera behavior on selection change.
Week 20
Posted by Isquires on Wed May 31, 2006 2:45 pm - 0 Comments

We've decided to support two extensibility scenarios. The basic modder will be able to load up our scene editor and create a level using objects we ship with the game. They can actually also use other user created objects without much extra effort.

For more advanced users, we will expose classes to derive from so that they can define new behavior and effects for their own game objects. To support this scenario we are concerned both with usability and security. In order to address usability we will spend some time refactoring our public API, release some source code examples from our own game objects, and write a few documents to help users define game objects that will persist to file and reload on device reset. Security is the other issue because we don't want users to write malicious game objects and distribute them to other players. The good news is that we have a good deal of control over security per app domain in .NET. We can create an app domain and grant security permissions only to trusted assemblies. This prevents untrusted assemblies from communicated over the network or writing to disk. Paul has been working on implementing a skeleton loader which will create an app domain for the game in which we have better control over permissions. Part of implementing this feature required a second restructure of our source tree. The good thing is that dependencies are now very well defined and we managed to fix up a lot of loose ends in the process. :D

Once this is complete, we are pretty much finished with the editor. We'll need to make a few more changes to the insertion palette, output window, and chat window; after which we can start writing the game app.

Last week's accomplishments:
- Work on app domain loader.
- Restructured source and project dependencies.
- Moved Warb Engine outside of SF source.
- Move SF specific game objects out of the engine.
- Further improvements to collision detection and response - we now implement prediction for sphere to sphere collisions.
- Fixed up weapons and explosions to use new collision code.
- Improvements to insertion palette and explorer to support ctrl+drag.
- Cleaned up the output window.
- Added a new "Super Soaker" weapon - lol.
- More improvements to frustum culling - between this and RDC for collisions, we've taken a scene which would run at about 20 FPS on my machine to about 95 FPS.

Next week's focus:
- Finish chat client (colored text, private messages, and client GUIDs).
- Generator and Field warb objects.
- Edit time camera behavior improvements when changing selection.
- Start work on in-game HUD.
- Support rotation in collision response.
- Update rendering shaders to support normal maps.
- Finish waypoint model and high-res asteroid models.
- Start work on AI for bots and monsters.
Week 19
Posted by Isquires on Wed May 24, 2006 9:19 pm - 0 Comments

I'm one of those people who nitpicks about coding style and naming conventions. Although I will agree that it is easy to spend too much time debating convention, I also think there is huge benefit to maintaining consistent style throughout a project. Lately I've been on a mission to refactor our source code. Over the course of the week I've visited pretty much each class and fixed up formatting, naming, accessibility, and comments. It is suprising how much code I am able to delete by sharing implementation and pruning unused methods. I think this is partially because our group is distributed, but also because there has just been a lot of churn in the code base. Long term, time spent refactoring should reduce the cost of making changes and fixing bugs. The other fun part about refactoring is I get to skim implementation details for the features I didn't write, which is something that I like to keep up with but don't always find time for.

Eventually I would like to release source for several of our game objects to serve as an example for those who want to derive their own game objects from our base classes. My other goal is to keep primary engine classes from depending on Sidereal Fury specific objects like ship or asteroid. Sometime within the next week I'll probably break these off into a separate project to keep them from referencing SF assemblies. This will allow us to reuse the Warb engine in future projects.

Our goal is to conform to the .NET Design Guidelines. There is a really good book by the folks at Microsoft called Framework Design Guidelines : Conventions, Idioms, and Patterns for Reusable .NET Libraries which I keep on my desk. This is definitely worth reading if you are developing anything in .NET.

Last week's accomplishments:
- General Refactoring.
- Removed Warb Engine dependencies on Sidereal Fury game objects.
- Added Copy & Paste.
- Created tools to test and debug collisions.
- Updated file saving code to persist static fields.
- Updated file saving code to support dictionaries.
- New icons for recently added warb objects.
- Menu items added to the editor for scene editing and undo / redo.

Next week's focus:
- Finish chat client (colored text, private messages, and client GUIDs).
- Generator and Field warb objects.
- Load the Warb engine in a secondary app domain.
- Edit time camera behavior improvements when changing selection.
- Start work on in-game HUD.
- Finish up insertion palette and tree view.
- Update rendering shaders to support normal maps.
Week 18
Posted by Isquires on Wed May 17, 2006 9:28 am - 0 Comments

This was a fun week. Despite having a busy month outside of the game we are still making good progress. For the first time we finally have sound coming from the ship engines! The afterburners also have a neat new effect where we give the player a blurred tunnel vision which increases in intensity as the ship's velocity exceeds the normal max velocity. I think I will spend some time working on the in game UI this week so that we can display the ship velocity and energy bar. Coincidentally, tonight's AIGD meeting is going to focus on UI design and implementation. Hopefully we'll pull something useful out of that and get a head start on the week.

Last week's accomplishments:
- Projectile sounds.
- Engine sounds.
- Afterburner sound.
- Finalized our the battleship's model, textures, and normal map.
- Added /help and /who to the chat client.
- Added post processing effects activated by the afterburner.
- Integrated RDC collision filtering.
- Integrated new collision detection and response for spheres.

Next week's focus:
- Test collision response.
- Work on mesh to mesh collision and adding rotation to response.
- Finish chat client (colored text, private messages, and client GUIDs).
- Copy & Paste.
- Generator and Field warb objects.
- Load the Warb engine in a secondary app domain.
- Edit time camera behavior improvements when changing selection.
Week 17
Posted by Isquires on Wed May 10, 2006 1:46 pm - 0 Comments

Last week I was comparing our alternatives for rendering distant objects. I ultimately ended up picking option #3 below - which was simply place the object in the scene and make it really big and really far away. The associated problems included the need to define a massive viewing frustum which means we are now looking at using progressive meshes. Another problem that I didn't predict was a loss of precision in our z buffer. Placing the planet as far away as I would have liked causes objects to "pop" when they get really close to each other. With the final placement, a ship with afterburners engaged can reach distant planets within 20-30 seconds. This should still be far enough though, considering the final implementation of afterburners will only allow activation for a length of 4-5 seconds.

Last week's accomplishments:
- Implemented sound manager in a test app.
- Added explosions.
- Added ship afterburner.
- Implemented basic frustum culling.
- Implemented RDC collision filtering in a test app. *
- Added planet object.
- Added /setname to chat.
- Chat server now disconnects clients after timeout.
- New Screenshots!

Next week's focus:
- Integrate sound into the warb engine.
- Integrate collision response and filtering into the warb engine.
- Continue work on chat client.
- Add game objects "Generator" and "Field".
- Implement copy and paste.
- Wrap our engine in a secondary app domain.
- Improve Edit time camera.

* RDC stands for Recursive Dimensional Clustering. I couldn't find a good link online, but if you are interested in learning more check out Game Programming Gems volume 2.
Week 16
Posted by Isquires on Wed May 03, 2006 1:09 pm - 3 Comments

Lately I have been thinking about how to render distant planets. From what I can tell, there are four options:

1. Render the planet as part of the sky map.
2. Render the planet from a texture as a screen aligned sprite.
3. Render the planet from a 3d model and make it very very big, and very very far away.
4. Render the planet from a 3d model reasonably close to the camera, but render it first in the scene with zbuffer write disabled so that it always renders below other objects.

Option 1 is probably the worst since the planet will get distorted as the camera rotates, not to mention it won't benefit from lighting.

Option 2 similarly won't recieve lighting (or at least it would be hard to give it realistic lighting).

Option 3 is only bad because it would require a very distant clipping plane. This basically means typical game objects will never be clipped by the far plane.

Option 4 sounded like the best option initially, until I realized how hard it would be to get orbiting objects to render correctly. I would like to eventually have the ability to add orbiting moons to distant planets, but for the rendering order to be correct, zbuffer write would need to be enabled for both.

I'll probably implement option 3 for now, but I am open to further suggestions. I'm also brainstorming mechanisms to allow editing of the position of distant objects such as planets and light casting stars. These objects should never be placed within the active scene (planets because they are massive, and stars because they act as directional light sources). I am thinking of using an arrow which points at the origin of the scene, which the user can rotate about the origin. This arrow would represent the unit vector off of the origin for the object, which I would scale based on the object's default distance from the game camera.

Last week's accomplishments:
- Updated internal documentation and project plan.
- Added an MRU list to the editor.
- The ship can now roll horizontally with the left and right arrow keys - this is pretty fun!
- Refactored input code to be more robust and only respond if the render window is the active control.
- Started texturing planets.
- Improvements to collision response (this is starting to get really interesting).
- Finished implementing undo and redo.

Next week's focus:
- Improve Edit time camera.
- Clean up output window
- Continue integration of sound.
- Clean up chat client.
- Add game objects "Generator" and "Field".
- Implement copy and paste.
- Implement "Planet" game object and add it to the palette.
Week 15
Posted by Isquires on Wed Apr 26, 2006 2:25 pm - 0 Comments

I've been trying to create cube maps to use for the background of our scenes and it is turning out to be much more challenging than I had hoped. The engine has already been updated to render cube maps with the .dds format, but there doesn't seem to be a good way to create the texture. My current workflow consists of:

1. Load the texture into Photoshop using NVIDIA's dds plug-in.
2. Use the cubemapshuffle script to rearrange the faces for editing.
3. Flatten the image.

4. Make my changes.
5. Flip the image 180 degrees and save as a regular bmp / png / whatever.
6. Load in cubemapgen to test my changes.

Repeat steps 4-6 until the image looks good.

7. Save from cubemapgen as a .dds file.

Now, I am hardly an experienced user when it comes to graphics utilities, so it is likey that I am not aware of an obvious way to make these edits (or to manipulate the cube faces). If you have any insight, please post on the forum.

Cube maps aside, this week has been relatively slow. Many of the developers are busy researching our next set of features, and a few are busy with their day jobs. I suspect progress will be slow for another two weeks, but I'll push to get a downloadable copy available soon.

Last week's accomplishments:
- Created a chat server and test client.
- Continued work on undo / redo.
- Minor updates to the camera behavior.
- Fixed cube map rendering on application resize.
- Created several environment maps.
- Added output window to the editor.
- Tracks can now be anchored to moving objects.
- Added type converters for Vectors, Matrices, and Quaternions to reduce our scene file size.

Next week's focus:
- Create a high level task list for the next iteration of development.
- Finish support for undo / redo.
- Improve Edit time camera.
- Investigate adding simple AI for ships.
- Continue integration of sound.
- Clean up chat client.
- Add game objects "Generator" and "Field".
Week 14
Posted by Isquires on Wed Apr 19, 2006 3:21 pm - 0 Comments

Week after week, we're still here chugging away.

I've finally finished up scene lighting and all objects now render using a PRT shader. Remarkably this is done with almost no noticeable performance penalty. We also added a new game object to our palette which can be customized to render any mesh and texture in the scene. This means it is no longer necessary to create a new class every time you want to represent a different mesh in game. Overall, we've dumped a bunch of new features into the editor and engine this week, and it sounds like we'll have a version available for download in the near future!

Last week's accomplishments:
- PRT lighting for all game objects.
- Added scene templates (used when creating new scenes).
- Added a new game object "Mesh Object" which renders a customizable textured mesh.
- Added a sky map.
- Added a star & lens flare effect to represent light sources.
- Started work on our installer.
- Further optimized scene loading (Paul's a machine).
- More work on collision and collision hierarchy.
- Minor cleanup and bug fixes throughout the editor.

Next week's focus:
- Add an MRU list for previously opened scenes.
- Investigate support for undo / redo.
- Continue work on collisions.
- Finish up the output window.
- Improve the Edit time camera (it should zoom to view the selected object).
- Implement new game object base classes "Generator" and "Field".
- Continue to investigate adding sound.

We're running out of items on our feature list for the editor, and we're still a few weeks ahead of schedule - so if you have any fun ideas for the game, now is the time to let us know on the forum! Otherwise we're going to shift modes and spend time creating game objects for our insertion palette.
Week 13
Posted by Isquires on Wed Apr 12, 2006 12:53 pm - 0 Comments

Our original collision algorithm would look for collisions at the end of the frame, and then solve for the position and time of the initial impact. This worked for the most part but would miss collisions that occured in the middle of a frame (for example if the simulation is running at a very low frame rate). We also had some trouble handling collision between multiple objects. This week we began rewriting the collision detection and response to use a prediction algorithm. Hopefully we'll be able to recognize pitfalls early by reviewing our initial implementation, but end up with a more robust mechanism.

Last week's accomplishments:
* Rewrote sphere based collision detection to use prediction over the length of the frame.
* Fixed up ship navigation to use the keyboard.
* Updated the camera behavior for edit and test drive.
* Updated icons and editor graphics.
* Many small changes to the behavior of the insertion palette and tree.
* The scene is now saved to a temporary file before starting a test drive (so that changes at runtime do not affect the initial state of the scene).
* Created a client to test communication with our server.
* Added debug validation on objects which will make it easier to find object leaks and incomplete initialization.
* Refactoring of the scene resource manager.

Next week's focus:
* Optimize particle emitters.
* Stub out virtual methods which will specify update work which will execute only on the client, or only on the server.
* Add a warb object generator game object.
* Create an output window for trace messages.
* Resume work on scene lighting.
* Start investigating game sound.
* Rewrite collision response based on the new collision detection.
* Continue work on palette, tree, and property grid behavior.

There are also some new screenshots posted - these primarily show off changes to the editor, but also notice the change in camera perspective. The fourth image is of our server app which, although basic, marks another milestone in our project!
Week 12
Posted by Isquires on Wed Apr 05, 2006 11:53 am - 0 Comments

Well, I've moved back to keyboard control for the the ship navigation. After almost a full week of messing with mouse controls I decided that the behavior I was striving for wasn't really that desirable. I do however have some new ideas on how to improve the keyboard controls, to address the original concerns (which lead to mouse based navigation). The good part is that while updating ship controls last week I wrapped a lot of the physics code with engine properties. Now all I have to do is turn on certain engines (like the "FrontTopEngine", or the "RearRightEngine") and the ship will respond appropriately. This means I really only have to tie a keyboard key to one of these engine properties. Ultimatley the derived classes (like scout class, or battle class) will define specific engine locations and potency. I could even adjust the rotational velocity generated by engines based on their distance from the center of the ship.

Ship control aside, our presentation for the AIGD went well - thanks to those who showed up. I really like the CyberJocks facility, they let us project our demo onto a huge wall and there were comfy couches to sit in.

Last week's accomplishments:
* Finished integrating scene file save and load!
* Scene objects can be dragged around the editor screen using the mouse.
* Scene objects can be deleted (through the world view or tree view).
* Added a time scale control to the editor toolbar.
* Added a time increment button to the editor toolbar.
* Added some icons for various WarbObjects.
* Added initial server application!
* Created a base class to handle all WarbObjects that contain meshes (will provide default rendering and mesh to mesh collision response).

Next week's focus:
* Debug collision response.
* Continue work on ship navigation.
* Implement a keyboard based targeting system.
* Add a warb object generator base class.
* Add some server connection information to the SceneManager class.
* Save to a temp file prior to test drive.
Week 11
Posted by Isquires on Wed Mar 29, 2006 3:30 pm - 0 Comments

Aside from continued improvements to the editor, we recently revisited interaction with the ship. Really early on, the ship was controlled by placing both hands on the keyboard - each controlling a side of the ship. For example - 'E' and 'I' pressed together would fly forward, while only 'E' pressed would turn the ship right. Although this was what I had originally planned to stick with, it wasn't quite as intuitive as I had hoped. It also didn't provide for any targeting mechanism. I suppose that the user could have tabbed through possible targets when firing missiles, or weapons could have just locked on to whatever enemy target was closest, but we ultimately decided to try supporting the mouse for targeting and navigation.

The next implementation placed the player's left hand (on the keyboard) in charge of strafing and engines, while the player's right hand (on the mouse) would steer and fire weapons. Movement of the cursor would aim any ship turrets and holding the right mouse button would turn the ship in the direction of the cursor. The biggest problem with this version is that the ship's turning seems sloshy and it was difficult to aim in a specific direction (let alone turn to avoid an obstacle).

The most recent changes place a reticle in front of the ship to indicate the current direction, and a second cross-hair is placed that moves along the surface of the ship's bounding sphere, in relation to movements of the cursor. When the player holds the right mouse button, the ship will turn in the direction of the cross-hair, with an acceleration relative to the cross-hair's distance from the reticle. The cross-hair will remain fixed at the location on the bounding sphere when the mouse was first pressed as the ship turns towards it, meaning the ship will never overshoot the direction you originally intended. The slightly unnerving part about this is your cursor will drift about the screen as you turn, since we are projecting the cross-hair position back on to the screen to update the cursor. Without this, the cross-hair would jump after a turn, when updating based on the cursors position (which would be otherwise unchanged). Anyway, even after those recent changes, it still seems like more work is necessary to improve the control scheme. What's funny is that I'm also starting to miss the original keyboard implementation - who knows, perhaps I'll try that out again (or provide it as an alternate configuration).

Last week's accomplishments:
* Updated ship steering and targeting.
* Added a tree control to the editor to show object hierarchy.
* Began integrating the file saving code into the editor.
* Objects can now be dragged out of the insertion palette and will insert at a location corresponding to the cursor position.
* Implemented pause in the editor.
* All meshes in the edit view are now rendered as wire frame.

Next week's focus:
* Continue work on ship navigation.
* Add a step button to the debug toolbar for advancing the scene with a fixed time interval.
* Add a slider control to the debug toolbar to adjust the time scale.
* Finish integration of file support.
* Add an interesting environmental effect.

Note: The Austin 3D Users' Group is meeting tonight for a demo of Right Hemisphere's Deep Creator, as well as a presentation on Forensic Animation. The event will take place at Lucy's Boatyard, from 7:30 to 9:00.
Week 10
Posted by Isquires on Wed Mar 22, 2006 12:51 pm - 0 Comments

Most of my time recently was spent wrapping things up for a demo we'll be giving in about two weeks, as well as preparing the presentation. We've done a pretty good job of keeping the bug count down, but I feel like it should be extra stable to avoid a traumatic experience. It is kinda fun to treat this as a chance to reflect on our progress, considering a portion of the presentation will be spent evaluating what we've accomplished so far. This is also a great opportunity to regroup and look forward, planning development on our next set of major features.

Over the next month we're looking to add another 2-3 developers to the project. This will help us ramp up our content production and start creating more game objects to interact with in the editor. We also need to start addressing the multiplayer element, as I'm sure many issues will arrise once we introduce network state and latency.

Last week's accomplishments:
* Created weapon system class which attaches to the ship.
* Created projectile class which is "fired" by the weapon system and handles collisions with other game objects.
* Added Mesh to Mesh collision detection and Mesh to Sphere collision detection.
* Added an object insertion control to the editor.
* Added start, stop, pause, and restart buttons to the editor.
* Optimized collision detection by representing collidable objects in a new data structure that evolves over the course of a frame.

Next week's focus
* Implement some special effects, such as an explosion or lens flare.
* Save scene to a temp file prior to test drive.
* Improve camera behavior (represent the interaction as an attachment by spring).
* Start development on a server app.
* Add an object tree to the editor, to represent the relationship between objects in the scene.
Week 9
Posted by Isquires on Wed Mar 15, 2006 7:27 pm - 0 Comments

I've made another overhaul of our game object class this weekend. In addition to updating the objects to support some changes in the file saving code, game objects are now hierarchical. This means that any given object can be composed of multiple child objects. Objects inherit velocity and position information from their parent, and transfer collision response back up the chain.

This improves the representation of many of the structures we've created so far, so I went ahead and updated some of those areas as well. For example: a startpoint's parent is now the track, and each waypoint has the previous waypoint assigned as its parent. Previous to this change, we had to restrict editing to the final waypoint in the list, to prevent corruption of connected waypoint position information. Now we store relative position and orientation information rather than absolute values. Changes in waypoints in the middle of the track will trickle down to connected waypoints.

Other improvements include attaching ship components to the ship as individual game objects. Now they can be blown off in response to collisions. Potentially we could create other destructable objects by "gluing" other game objects together, such as many small asteroids to make a single large asteroid.

Last week's accomplishments:
* Added an attribute to flag fields and classes which should not be persisted to file.
* Implemented support for object composition.
* Textured our new ship and separated moving parts into individual meshes.
* Created an independent application to test and profile the file saving code.
* Added support for changing property accessibility in the property grid at run-time based on the application state.
* Added a test drive control to our new editor.

Next week's focus:
* Improve camera behavior.
* Save scene to a temp file prior to test drive.
* Increase collision detection resolution.
* Integrate new ship components.
* Create a weapon and projectiles.
* Add object insertion control to the editor.

I should also add that we will be presenting at an Austin Independent Game Developers meeting on April 3rd. If you live in the area, come by and check out the game! The meeting will take place at CyberJocks from 7-9pm.
Week 8
Posted by Isquires on Wed Mar 08, 2006 7:16 pm - 0 Comments

New screenshots! I've posted several captures from this past month's progress. The first three listed for February show off new lighting and particle emitter code. The yellow rings are waypoints which represent a portion of the track. The final screenshot for that month is a sneak peek at our new editor. Shown are several track sections inserted into the scene, one of which is selected. On the right is a property grid and some custom controls defined by the selected object.

The image posted for March is a prototype ship created by our new artist, Evan. Hopefully this will replace the game's stock ship in the near future.

Last week's accomplishments:
* Property grid which shows public and browsable properties for the selected object.
* Ship rendering and scene lighting got an update.
* Performed some profiling and optimized portions of the engine.
* Improved the file format to handle duplicate object references.
* Created a new ship prototype.
* Implemented most of the test drive control for the new editor.
* Started on weapon systems and projectiles.

Next week's focus:
* Continue work on collision detection resolution.
* Finish implementing the first weapon system.
* Integrate the new ship into the game.
* Create the initial server application.
* Update warb object properties to support file saving.
* Define an interface for attaching warb objects (creation of composite objects).

The framework is looking pretty stable, which means we'll be able to switch gears entirely back to game play in the next week or two. I am probably going to restrict mouse movement to a hemisphere in front of the ship. Movement along this surface will define the orientation of the ship's mobile turrets. When the right-mouse button is held down, not only will the ship rotate towards the mouse (as it does currently), but we will then be able to save the projected location and update the cursor position as the ship rotates.
Week 7
Posted by Isquires on Wed Mar 01, 2006 11:20 am - 0 Comments

This was another one of those weeks where all of the work went into underlying framework and interfaces. Ironically, although this was probably our most productive week to date, there is almost no visual representation of our progress when playing the game. However, all of this work does mean that game engine and controls are much more flexible and extensible.

Last week's accomplishments:
* Created a new editor with toolbars, multiple (and simultaneous) edit time camera perspectives, file menu, status bar, and eventually docking panes.
* Separated application edit controls from warb object implementation (the application no longer has to know what kind of warb object is selected to allow editing).
* Warb object can now render itself differently depending on the application state.
* Warb object now integrates with scene editing by providing custom edit time controls and modifying the file directly (this is a good thing for modders who will create their own warb objects).
* Created framework controls which can render from a scene. These can be placed on any application with a scene manager (write your own warb engine tools!).

Next week's focus:
* Display custom object controls in a floating panel.
* Create a test drive window and controls for the new editor.
* Update warb object properties necessary for file saving & property grid display.
* Update ship rendering and lighting.
* Create the initial server application.
* Start work on projectiles.

After all of that, I am probably going to be able get back to game play and rendering. Hopefully this will be the last time that "ship rendering and lighting" appears on the todo list. ^^
Week 6
Posted by Isquires on Wed Feb 22, 2006 12:20 pm - 0 Comments

My goal this week was to update the ship rendering and lighting, but it seems like each time I sat down to work on it, I would get side-tracked with a different issue. The good news is that I did resolve a bunch of these issues, and made good progress on my other goals.

Overall, the group has been working a bunch on the scene editor structure and our general framework design. Given another week or two, our editor will support multiple camera views in panes that can be repositioned on the screen. We're also working on improving the rendering architecture so that users defining custom game objects won't have to know as much about our internal implementation to get things working.

Last week's accomplishments:
* Ship can now strafe.
* Collision with waypoints is implemented.
* WarbObjects support rendering to multiple devices.
* Renderlist and Updatelist are now sorted lists.
* Fixed some bugs with the star emitter positioning relative to the camera.
* SceneFile is finished and the editor will soon support save / load.

Next week's focus:
* Finish the app reorg and define interfaces to describe interaction with controls.
* Update ship rendering and lighting.
* Implement file load / save.
* Save to a temp file prior to test drive (to prevent the scene from corrupting the edit time version of the object list, and to save data in the event of a crash).

I am still finding it difficult to represent all ranges of motion in 3D space. The ship needs to be able to turn left, right, up, and down, and also strafe in those directions. At the same time the user needs to be able to target objects independent of the ship orientation. Our current implementation drives the ship using the right mouse button, and strafing / engines are implemented on the keyboard. The ship will steer towards the mouse when the right mouse button is held down, but this feels sluggish. I am not sure if there is a better solution if we want the ship to respond to collisions correctly, but it is definitley still an area in need of improvement (considering the entertainment factor of the game depends on ship control).

Btw, I still intend to update the screenshots on the site, but the ftp for the server is messed up - I'll contact our webadmin and get that resolved. Hopefully there will be some new eye candy available in the near future!
Week 5
Posted by Isquires on Wed Feb 15, 2006 1:03 pm - 0 Comments

Another week has passed, but this one was a bit quieter than the previous.

Much of this past week was spent discussing new editor formats - basically how we would like to arrange the editor to allow placement of user defined game objects. We've also spent some time discussing modifications to the ship controls, and rendering techniques.

Last week's accomplishments:
* Track scripting is complete - you can now complete a lap.
* Scene can register for events on the track such as lap advancement.
* Track now renders text to the HUD which displays the current lap, time elapsed, and number of checkpoints met (out of the total).
* Designed an algorithm for collision detection between the ship and waypoints.

Next week's focus:
* Update the editor to render to a control (as opposed to form) so that other controls can be integrated outside of the rendering surface.
* Add new methods of interaction with the ship.
* Update rendering in general to use some more interesting techniques.
* Fix scene lighting.
* Continue work on collision detection.
* Update the website with some new screenshots.

I've gotten a few inquiries lately from individuals interested in joining our development group. It is true that we are still looking to add at least 1 more programmer and 1 to 2 more artists to the project. If you interested, please email me your qualifications.
Week 4
Posted by Isquires on Wed Feb 08, 2006 1:35 pm - 0 Comments

Wow, this week went by quickly! The past few days have been busy for me, both managing the game development and having fun outside of work. Between Disturbed and In Flames concerts, I managed to fix the particle emitter's zbuffer problem - with help from the zman (ironically... I mean who better to ask about zbuffer issues!). We ended up just moving the particle emitter rendering to the end of the render list (after all scene geometry has been rendered). Although we have to turn off zbuffer writing for the particles to blend, they will still honor existing zbuffer values when deciding whether to occlusion cull. Since the game objects do not have any control over their render order, I created a particle manager class with which game objects can register particle emitters for rendering. The scene then iterates through the particle manager's emitters at the end of the render loop.

Last week's accomplishments:
* Particle emitter zbuffer fix.
* Added more creation options to our particle emitter.
* Lighting is now emitted by game objects (rather than statically placed light sources).
* More controls for track building in the editor.
* Several small updates to the camera behavior in the scene editor.
* Spec'd out a tentative collision detection algorithm with better resolution than our current algorithm.
* Several updates to collision response - I think we will end up writing a seperate tool / app to test object behavior and collisions.
* Spec'd out the resource layout for scenes and how download from a server will be coordinated.
* Helped Evan, our new artist, get set up with the project and discussed some initial tasks (likely creation of the waypoint & checkpoint geometry).

Next week's focus:
* Integrate property page editing into our scene builder app.
* Implement the collision detection algorithm.
* Scene scripting and custom update methods.
* Dynamic loading of user defined game objects.
* Scene file load / save integration with the scene manager.

I've also been playing around with the scripting for the track. I have a feeling that this could be complete by next week's update which is pretty exciting. The project is about 4 months into development (the weekly updates didn't start until more recently) and the game is finally becoming playable. It is very satisfying to take part in the evolution from concept to execution, starting to see ideas take shape.
Week 3
Posted by Isquires on Wed Feb 01, 2006 10:16 am - 0 Comments

Well, another week has passed and we're still here chugging away. The ZBrush event from last week was fun and I met with a few local artists. One of them sounds interested in the project and his work looks pretty high quality - hopefully he'll end up contributing to our final product!

Last week's accomplishments:
* Game camera is in a happy state for now.
* Track rendering got an update - we no longer draw the track section or waypoints as in the editor, but now draw some big fiery rings to fly through.
* Investigated security measures to apply to user defined game objects, so that they can not be malicious when distributed.
* Finalized the file format spec and started discussing implementation details.

Next week's focus:
* Implement some of the discussed changes to the file format.
* Improve collision detection resolution.
* Integrate property pages into the current editor (from a test app).

Moved to the back burner:
* Projectiles
* Custom object editing controls

I think I'd like to take the new waypoint rings and add a sort of metallic structure to line the inside (so that it looks like the fire / energy is being emitted from the metallic structure).

While implementing the particle emitter for the waypoints I also encountered an interesting problem. Up until now, all of our particles were pretty localized and exist in the same plane. Since the particles for the waypoints represent a ring that you should fly through, we will have to come up with a new implementation. To be more specific, I disable writing to the zbuffer while drawing particles so that they can be blended by hardware. This means that particles will always render behind any other game object. This is noticable as a problem when you have a ring that the ship is supposed to fly through, since the ship always appears to fly on top of the ring. It may be enough that adding some physical geometry to the waypoint will give the necessary occlusion, so I will try that out first.
Week 2
Posted by Isquires on Wed Jan 25, 2006 9:34 am - 0 Comments

This past week several more improvements were made to the site and it looks like it is coming along very nicely. You may have noticed the fancy wallpaper now available in the downloads section carefully crafted by yours truly... please - if you are an artist out there looking for a fun indy game to participate on, come save us from further programmer art!

Speaking of art, a few of us plan on attending the 3D users' group meeting in Austin tonight to evaluate the software ZBrush. This event will take place at ITT Tech at 6:30 pm. Here is a link to the full details.

As for Sidereal Fury, we've made decent progress this past week. One of our developers quit World of Warcraft - an event which although sad, I declare as a minor victory for Sidereal Fury! I personally have yet to break my addiction... although I do feel it waning...

Last week's accomplishments:
* Good discussion of the file format improvements and a rough draft of the spec for user created game objects was hashed out.
* Fixed some bugs with our collision response algorithm.
* State cache was completed and a few related bugs were ironed out.
* HUGE OPTIMIZATIONS!!! - I'll have to post some new screenshots which portray a framerate which puts our earlier images to shame. Thanks to the developer who discovered these issues.
* Camera was improved to act as if it is on a tether behind the ship.
* I havn't heard much from the guy working on our property pages (too busy hitting up the Canadian ladies eh?), however I'll remain optimistic and assume that he accomplished a great deal!

I also spent some time reading up on non-photorealistic rendering techniques, but I have yet to find something that would look good with what we've created so far. I'm still not sure how I want to render the track sections in the actual game world, so there is much research and experimentation to be done!

Next week's focus:
* Updating the file format to permit the inclusion of user defined game objects.
* Adding controls to the Scene Builder to support creation and editing of custom game objects.
* Improve the camera's behavior as the ship turns - I'd like the ship to roll a bit relative to the camera.
* Continue investigating alternate rendering methods for in game track sections.
* Continue work on property pages for game objects.

If we have extra time:
* Improve the resolution of collision detection.
* Begin work on projectile physics.
Week 1
Posted by Isquires on Wed Jan 18, 2006 5:43 pm - 0 Comments

This being the first weekly update, I should probably give a bit of background on the project so far. Warb Entertainment is composed mostly of hobbyist game programmers who have joined forces to write a full scale game. Most of us work 40 hour weeks or attend school full time in addition to our contribution on Sidereal Fury. I'm still looking for some artists to help out, so if you think this sounds like an exciting project to work on, please send me an email or PM me on the forum. I'll post more specific details about the positions in the near future.

As far as the game itself, most of the work on Sidereal Fury so far has been on the Scene Builder. This is the tool, featured in our early screenshots, which allows the user to place and orient track sections. The Scene Builder also includes a test drive mode which enables the user to fly a ship around in a game rendered version of the scene. Major milestones already accomplished include the implementation of programatically generated track sections, collision detection and response, ship physics, a custom file format, and a particle engine.

Next week's focus:
* Updating the file format to permit the inclusion of user defined game objects.
* Improving the resolution of our collision detection algorithm.
* Giving the ship's camera a bit of "play" relative to the ship (this will improve the perception of acceleration and deceleration).
* Finish up our state cache for handling render state changes.
* Investigate alternate rendering methods for in game track sections.
* Continue work on property pages (which represent the current state of game objects in the designer).
First post!
Posted by Isquires on Wed Jan 11, 2006 7:16 pm - 0 Comments

The Sidereal Fury site is finally up and running. Look forward to info on the project, screenshots of the game, and general discussion. During development of the game, this page will serve as a record of our progress. Feel free to drop by the forum and let us know what you think!