Grand Theft Flying Object
A top-down 4-player couch co-op game that has players competing and cooperating to steal enemy ships, man guns, and steer new ships against enemy forces.
If you see a ship you like, steal it. ;)
Developer Notes: This was a fun project! I wrote the core engine for the game (everything from input to how systems like graphics update every frame). The core engine was written entirely from scratch in C++, but one of the goals of this engine was "edit-bilaty." I wanted designers and artists to be able to make and see changes in the engine without any recompilations. To that end I embedded Python into the engine. For the Python embedding, I emulated an interface our designers were used to working with (an in-house DigiPen editor). Python was fully able to see and use any data or functions that were declared in our engine. In order to accomplish this I had to write a C++ runtime introspection system. This system allowed for C++ types to register their functions, properties, data, hierarchy information and more with the meta system, which would expose these fields to Python, the serializer, and to our editors. I also wrote the object factory, memory manager, action list, timers, messaging, and much more. Please ask me for more details if you're curious about what went into this game (students or employers!).
On the tech side, there are a lot of things that I wish I could change in this engine. The next engine I write will be easier to debug from the beginning. An in-game REPL loop will help a lot with that, as well as profilers from the beginning of the project. Another helpful feature would have been to have better debug drawing in from the beginning of the project. The second thing I would change, would be the memory system. In this game I chose to go overload global new instead of static member function new, which I think was a mistake. If I could go back, I'd make objects and containers more aware of memory so that users of the memory system wouldn't have to be. This would also make it easier to make hierarchical allocators which would make debugging easier as well.
My last major responsibility was as Technical Director, which basically means being the producer for the dev team. This was a tough task as I was already coding so much for this project. Some of the things that are important to me include writing clean maintainable code and writing extensible code (especially for a game where the needs of the project are constantly evolving). To that end I used premake (a lua based build system) to make it trivial to add tests to any project (built into a separate executable). I also held meetings with members on my team and tried to teach/share knowledge about the engine and general programming to the rest of my teammates. I ran into a lot of problems on this front, as a few of my teammates don't believe in testing code and I couldn't prove that testing the code would lead to a better product in the end. So, I continued to test my code without requiring anyone else to test theirs. If I could go back though, I'd make it so that the tests were run automatically when ever code was checked in, so at least we'd know if any tests were broken when new code was checked in.
Ok, there's obviously a lot more information I could go into about this system, so feel free to shoot me questions if you have any. Cheers!
Developer Notes: This was a fun project! I wrote the core engine for the game (everything from input to how systems like graphics update every frame). The core engine was written entirely from scratch in C++, but one of the goals of this engine was "edit-bilaty." I wanted designers and artists to be able to make and see changes in the engine without any recompilations. To that end I embedded Python into the engine. For the Python embedding, I emulated an interface our designers were used to working with (an in-house DigiPen editor). Python was fully able to see and use any data or functions that were declared in our engine. In order to accomplish this I had to write a C++ runtime introspection system. This system allowed for C++ types to register their functions, properties, data, hierarchy information and more with the meta system, which would expose these fields to Python, the serializer, and to our editors. I also wrote the object factory, memory manager, action list, timers, messaging, and much more. Please ask me for more details if you're curious about what went into this game (students or employers!).
On the tech side, there are a lot of things that I wish I could change in this engine. The next engine I write will be easier to debug from the beginning. An in-game REPL loop will help a lot with that, as well as profilers from the beginning of the project. Another helpful feature would have been to have better debug drawing in from the beginning of the project. The second thing I would change, would be the memory system. In this game I chose to go overload global new instead of static member function new, which I think was a mistake. If I could go back, I'd make objects and containers more aware of memory so that users of the memory system wouldn't have to be. This would also make it easier to make hierarchical allocators which would make debugging easier as well.
My last major responsibility was as Technical Director, which basically means being the producer for the dev team. This was a tough task as I was already coding so much for this project. Some of the things that are important to me include writing clean maintainable code and writing extensible code (especially for a game where the needs of the project are constantly evolving). To that end I used premake (a lua based build system) to make it trivial to add tests to any project (built into a separate executable). I also held meetings with members on my team and tried to teach/share knowledge about the engine and general programming to the rest of my teammates. I ran into a lot of problems on this front, as a few of my teammates don't believe in testing code and I couldn't prove that testing the code would lead to a better product in the end. So, I continued to test my code without requiring anyone else to test theirs. If I could go back though, I'd make it so that the tests were run automatically when ever code was checked in, so at least we'd know if any tests were broken when new code was checked in.
Ok, there's obviously a lot more information I could go into about this system, so feel free to shoot me questions if you have any. Cheers!
- Date: June 2012 - present
- Team Size: 12
- C++, Python, DirectX, Wwise, premake, tortoiseHg, gmock
- Responsibilities: Technical Director, Core Engine Architect
Rhinopocalypse
Guide a rhino through a voxel landscape as you destroy everything in sight
...in this 3rd-person action platformer. It is a truism that all civilizations eventually crumble. The cause? RHINOPOCALYPSE. In each epoch, players control The Rhino and reduce the setting to flat landscape. Levels begin with The Rhino at low power, able to destroy only small objects. As they inflict destruction, they are able to destroy larger and larger obstacles, moving up from bushes to trees to boulders to metal. The levels are constructed like Katamari levels, so that players find themselves returning to areas previously visited to destroy what they couldn't before. At the end? Nothing remains.
Developer Notes: I left my sophomore team to join this junior game (a year early). Being the junior member on the team I did not get to work on core engine, physics, or graphics as much as I would have liked; however, I got to implement a lot of cool AI behaviors, a memory debugger, an action list, and many other minor-but-necessary systems. All in all, working with a team of developers a year ahead of me really helped me to grow as a programmer.
Developer Notes: I left my sophomore team to join this junior game (a year early). Being the junior member on the team I did not get to work on core engine, physics, or graphics as much as I would have liked; however, I got to implement a lot of cool AI behaviors, a memory debugger, an action list, and many other minor-but-necessary systems. All in all, working with a team of developers a year ahead of me really helped me to grow as a programmer.
- Date: Sept 2011 - Mar 2012
- Team Size: 7
- C++, Python, DirectX, Wwise
- Responsibilities: Gameplay, AI, misc.
Shade
Shade from Jennifer Tran on Vimeo.
In Shade, the player controls a swarm of shadows attacking a city.
Shade is an isometric-top down action game where the player takes control of the darkness in the form of a swarming horde of shadows. Using group movement and flocking behaviors the player controls an ever-increasing swarm of characters as they wreak havoc throughout the city, converting as they kill. Amassing a force that will soon be large enough to overtake all opposition the player leaves a dark, fallen city in his wake.
With the player in control of a large, teeming army, the gameplay in Shade is huge in scale, similar to a Real-Time Strategy game. The controls, however, are simple and intuitive, dropping the player immediately into the action without tutorials or any learning curve – giving Shade an intense and visceral feel that only a true action game can deliver. Inline with the story, the player will also be sapping the bright neon color from the world as he battles throughout. Absorbing the light and color leaves the city dark and desolate and grants the player more power.
Developer Notes: I developed the core engine that was used to make Shade, but was not around for any of the gameplay or art asset development. I implemented a delayed messaging system, a prototype factory, game objects that were built through serialization and dynamic composition, input, a simple graphics layer, an error/asserts system, game clocks, and other core utilities.
With the player in control of a large, teeming army, the gameplay in Shade is huge in scale, similar to a Real-Time Strategy game. The controls, however, are simple and intuitive, dropping the player immediately into the action without tutorials or any learning curve – giving Shade an intense and visceral feel that only a true action game can deliver. Inline with the story, the player will also be sapping the bright neon color from the world as he battles throughout. Absorbing the light and color leaves the city dark and desolate and grants the player more power.
Developer Notes: I developed the core engine that was used to make Shade, but was not around for any of the gameplay or art asset development. I implemented a delayed messaging system, a prototype factory, game objects that were built through serialization and dynamic composition, input, a simple graphics layer, an error/asserts system, game clocks, and other core utilities.
- Date: June 2011 - August 2011
- Team Size: 8
- C++, Lua, DirectX, FMOD
- Responsibilities: Technical Director, Core Engine Architecture
A3: ALIEN ARTILLERY ANNIHILATION
Aliens immersed in turn-based artillery combat staged inside of 2D floating platform arenas with fully destructible environments.
The player is the leader of a small planet that rounds up his best fighters and resources to steal technology for the benefit of his people. Create a fully customizable army by choosing an individual load out for each unit. Load outs consist of weapons, combat items and genetic upgrades. The units are then dispersed upon a 2D floating platform arena. The environment is fully destructible and you can eliminate your enemies by direct damage or destroying the ground beneath them, causing them to fall to their death.
Developer Notes: This game was created in one semester. It was written entirely in C and we had no access to a graphics API. Visuals were done by rendering ASCII characters to the console window. Primarily, I worked on the core engine architecture and the physics in the game. This was the funnest project for me to work on because of how much physics I got to implement: Each level consisted of over 45k physics objects; I implemented advanced optimizations like sleeping and sweep and prune; the game boasted fully destructible terrain (including rope bridges); and I used a micro-collision system to implement stacking. Fun times!
Developer Notes: This game was created in one semester. It was written entirely in C and we had no access to a graphics API. Visuals were done by rendering ASCII characters to the console window. Primarily, I worked on the core engine architecture and the physics in the game. This was the funnest project for me to work on because of how much physics I got to implement: Each level consisted of over 45k physics objects; I implemented advanced optimizations like sleeping and sweep and prune; the game boasted fully destructible terrain (including rope bridges); and I used a micro-collision system to implement stacking. Fun times!
- Date: December 2010 - April 2011
- Team Size: 7
- C, Win32, FMOD
- Responsibilities: Technical Director, Core Engine Architecture, Physics