Category: Development

Byte-Sized Updates

• Full-Feature Demo Game: Implemented hitscan to be used in our feature game.
• The Knight Game: Developed another game that flexes some of our new components and our collision system that hasn’t been shown in a game just yet.
• Collision Solving: Wrapped up our collision solver by making it moderately more correct, and added a “mass” feature.
• Build System: Set up a build pipeline for our engine after one too many rebuilds aggravated our programmers to no end.
• Networked Game Management: Added functions like start/stop server and client, added callbacks related to client connection status, and added networked level loading.
• Network Discovery: Added LAN (local area network) broadcasting functionality so we no longer need to type in IP by hand!
• Monitoring Memory Leaks: We added memory allocation/free tracking and let the user know what’s leaking on our free list by object name and amount.
• Patch Notes: As we get to the end we seem to be patching more holes than making an actual boat.

For full write-up see here. The code can be found on the GitHub repo tagged with week-13.

Byte-Sized Updates¶

• Audio: Refactored the audio system to be more versatile and usable, as well as added in 3D audio.
• Primitives: Game entity primitives were created for the developer to be able to quickly instantiate a cube and other shapes, without having to make the models themselves.
• Config Editor Tool: A tool was developed to help developers modify the configuration file, without knowing apriori what property they want to modify.
• Build: We created a tool for exporting the header files of the engine, as well as other needed files and folders to be used in a standalone project.
• Patch Notes: We have a lot. Turns out as you begin to use your engine features you will find many more bugs than your original tests.

For full write-up see here. The code can be found on the GitHub repo tagged with week-12.

Byte-Sized Updates

• Collision Solving: Implemented rudimentary collision solving, but still have lots of distance to cover for a decent collision response system.
• Level Loading: Got loading from startup level to another prebuilt loader in the engine working. There were a few catching points, but overall went smoothly.
• Asset Processing Tool: Built an asset processing tool to process the Collada files (.dae) more efficiently, easier than in the past.
• GUI: Added more to the GUI system by fully integrating fonts, so font size and type can be changed per GUI function.
• Full-Feature Game: Started development of the target game that the engine is being built for, which forced some other smaller features.
• AI: Implemented an AI pathfinding system by combining vector flow fields and steering behaviors.

For full write-up see here. The code can be found on the GitHub repo tagged with week-11.

Progress may have slowed due to our trip to LA, but we can assure you it wasn’t for nothing. Our initial plan to go out there was decided months back; we had a full lineup of industry professionals who agreed to do interviews and look at our engine progress. Of course, in the fast-moving game industry, the best laid plans don’t always come together. A number of our planned interviewees had to drop out at the last minute, which left us in a bit of a panic.

We reached out to about a dozen other contacts in LA to try and find some other people we could talk with. One of those contacts was at Sony’s Santa Monica Studios, and he was able to get us in touch with Jeet Shroff and Florian Strauss, gameplay and technical directors on the latest God of War. What’s more, we still had an interview locked in with Insomniac Games’ senior engine programmer and ETC alumni Elan Ruskin. We also finally got to meet up and talk shop with Cort Stratton of Unity, who has been supporting us all semester long. Because these were all on-site talks, we were able to get a lot of clear answers to our questions and more direct feedback.

While the extra downtime wasn’t ideal, it did give us an opportunity to catch up with our classmates who were in LA on internships and new jobs. Ultimately, the trip was more productive for the team than expected.

In terms of development, be prepared to see talk about memory throughout the blog because we were leaking memory left, right, and center!

Byte-Sized Updates

• Graphics Added in functionality to the texture class, so it now does more than just loading and can actually be used!
• Tools Abstracted some previously developed tools into an editor component which is already proving valuable for development!
• Custom Dynamic Array We were originally not planning on creating our own data structures and just relying on STL but we gave into the temptation and it revealed some dark secrets.
• Second Game We made our second game (which is not a twin stick shooter) and it works!
• Patch Notes There’s typically not a header for patch notes, but this week we found some really interesting bugs, mainly involving memory, which we think were great learning experiences.

For full write-up see here. The code can be found on the GitHub repo tagged with week-10.

Before we get started, we apologize for the delay with publishing Week 9. The Isetta Team was in Los Angeles this past week trying to wrangle some engine developers for interviews and meetings, so we naturally fell a little behind on our usually strict schedule!

That being said, we got a couple of interviews while we were out galavanting in LA, and we hope you anticipate them in the coming weeks! Special thanks to Cort Stratton, Sunil Nayak, and Jibran Khan for helping us figure things out while we were out on the west coast!

Byte-Sized Updates

• Network Transform: Built up the entire NetworkTransform class, including client authority and transform interpolation.
• Event Messaging System: Implemented the event messaging system with both queued callbacks and immediate callbacks.
• Collisions – Dynamic AABB Tree: Finally got to work on optimizing the collision tree, and the speed up on the detection was better than expected!
• Console: Developed a console window for easier debugging and information display.
• Components: Added several more features to our Component class family, including much of what Unity has for theirs (which is beginning to make sense to us).

For full write-up see here. The code can be found on the GitHub repo tagged with week-9.

Byte-Sized Updates

• Component Registry: To add component inheritance support, we added a component registration mechanism for the components to store their type hierarchy.
• Collisions: Third week working with collisions and things seem to be wrapping up, main focus was on how to handle collision events when one occurs.

For full write-up see here. The code can be found on the GitHub repo tagged with week-.

Byte-Sized Updates

• Collisions: Collision system is taking form, and the most basic intersection tests have been implemented, but there is still a lot of work to be done.
• Networking: Tons of things happened, including user-defined network messages, a new static initialization system, and network IDs for synchronizing objects across the network.
• Serialization: We discuss the state of serialization within our engine, and some problems we’ve faced with it.
• First Game: We made a game with our engine and it’s not crashing and it’s not dropping frames and it’s fun to play!

For full write-up see here. The code can be found on the GitHub repo tagged with week-7.

Byte-Sized Updates

• Debug Drawing: Implemented our entire visual debug drawing system, which has already revealed a mistake!
• Level (Scene Graph): Designed the scene graph architecture as Level-Entity-Component, and created a reflection system for loading user-defined levels.
• Transform: Began development on our transform hierarchy, and implemented some gameplay features with it like a flyby camera.
• DLL: The engine was built into a DLL (well, sort of), and we were able to run the engine in another project.

For full write-up see here. The code can be found on the GitHub repo tagged with week-6.

Byte-Sized Updates

• Goodbye Module Manager: Removed the manager that handled the lifecycle of all of our modules because redundancy.
• Scene Graph Object Model: Determined to use a blend of data-oriented and object-oriented design for our scene graph object model for the rest of development (or until we change our minds).
• GUI: Created a module for the GUI system, and learned why having a sample game is important for engine development.
• More on Horde3D: Fixed the issues that Horde3D’s lightweight-ness brought back to us.
• Memory: As the team is integrating memory manager to their modules, we got a better sense of how to do it and made some updates. We added a free list allocator, abandoned our “all static” fantasy and is updating our alloc API design.
• Networking: Replaced the memory management with our own system and discussed some big design decisions for the networking backend coming down the line.

Although things look like they are not changing much, most of the current work is stemming from the need to rework systems after integration. The dependencies of a system are driving additional development on that system, almost like feature requests. We are pushing forward with an increased focus on the game’s needs, and we’re planning to start the game as soon as possible to find more cracks in our system.

For full write-up see here. The code can be found on the GitHub repo tagged with week-5.

Byte-Sized Updates

This past week, progress has slowed down significantly for a few reasons. We are at a point now where we are starting to integrate the engine systems together more heavily, which has stopped the development of new features. For example, we are beginning to integrate the memory manager with the other subsystems, but don’t have enough to talk in-depth about this week. Also, our GUI system is heavily reliant on the window system and has its own built-in input, which needed to be abstracted out so we could feed in our own. More to come on that next week.

The biggest road bump this past week was going back through the code and adding Doxygen comments for all of our public facing functions and member variables. This took each of us much longer than expected and we can definitely understand why many developers suggest waiting until a feature is settled to comment on it. We also did a large-scale code review with our faculty and spent a considerable amount of time fixing things. Finally, we have created a demo of the engine’s functionality at this point, which includes: Networking, Audio, Rendering (with animation), Configuration file loading, etc. The demo is located on the demo branch and, at the time of writing, is this commit.

For full write-up see here. The code can be found on the GitHub repo tagged with week-4.