This is the introduction video for Arbor, my capstone project at the Guildhall. I am lead programmer on a team of 13 developers and have done most of the gameplay coding for the game, especially code specific to the player, such as the swinging vine ability. Additionally, I created a very complex and useful checkpoint and camera systems. These allowed the level designers a high degree of control over the flow of gameplay and I believe the result makes Arbor a much more “player friendly” game. The video itself was created (and voiced) by our game designer, Grace Blessy.
Arbor is a sidescrolling puzzle-platformer with a dark theme. It is being created using the June 2011 build of UDK. In the game you play as Votive, an animated clay figurine capable of inserting three different types of magical leaves in the empty socket where its arm once was. Using the powers gained from these leaves, Votive must navigate the now tainted Temple of the Arbor Goddess, planting a number of Sacred Bulbs in specific locations along the way.]]>
This my latest update on my Minecraft level renderer. I’m drawing A LOT more than I was before and I believe a lot more than Minecraft itself does. I am also using the lighting data stored in the save files to light the world, which is why everything underground is dark. I also fixed the issue where I was drawing all blocks around chunk borders. You can check out what I had going on before here.
One thing I’m a little unsure about is the way I’m storing the vertex data. I think I’m storing all of the data for a vertex in 16 bytes right now, which is pretty small, but I’m paying a price in “re-inflating” that data in the vertex shader. I think I’m just going to need to find the right balance.
Sometime in the future I would really like to add LOD and some kind of culling to prevent drawing underground tunnels that aren’t possibly visible. Keep tuned!]]>
This project was my first foray into the realm of UDK. I was Game Designer on a team of 7 for Blastmaster (two artists, four level designers, one other programmer) although I still mostly did programming. The inspiration for this game came from the Mystery Science Theater 3000 movie “Space Mutiny” where the fearless meathead hero gets dozens of “railing kills” (see this for reference) on anonymous henchmen.
We didn’t really know what we were doing, but we really stuck to the core concept and made what I consider to be a pretty entertaining game. Perhaps more importantly, we really learned a lot about UDK and Unrealscript as well as how to work on a team.]]>
This is a work in progress, but it mainly deals with the pro’s and con’s of developing on multiple platforms. The picture a little sample I made using the Tyrian tileset artist Daniel Cook released for public use. The game is a scrolling shooter that is going to use this tileset extensively.
This thesis will study the challenges that arise from simultaneous development on the PC, Mac, and PlayStation 3 for a simple, two-dimensional action game. Throughout the experiment, rigorous bookkeeping will be kept to measure effort expended in a variety of categories with a focus on platform specific components. By analyzing this data, this thesis will be able to provide insight into development cost for each of the selected platforms. Additionally, journal entries will be kept to provide qualitative information on specific challenges encountered. This information will be useful to game developers when attempting to determine if the risks of adding a particular platform to their project will outweigh the rewards.]]>
This was a project I worked on during my second module at the Guildhall. It uses OpenGL to render Quake 3 levels with shadow mapping. It seems like a very simple project now, but I had never done 3D graphics previously and I was ecstatic to get it working. If you notice some flickering in wireframe mode, it is because the program is using Quake 3’s PVS data to cull unseen areas.]]>
This project is a textured heightmap of Hawaii that uses a “chunk based” level of detail system. The heightmap is broken up into a grid of 64×64 chunks. Depending on distance to the player and the intrinsic detail of the area, each chunk is drawn somewhere between a 64×64 quad mesh, or just a single quad. Additionally, chunks that are not within the viewing frustum are not drawn and this culling is done in a “quad-tree” like manner. Another optimisation is that all single quad chunks are rendered with a single draw call that is newly generated each frame.
The simulation runs using both Direct3D 11 and OpenGL. The terrain is lit using simple N dot L lighting.]]>
This was a project for my Directed Focus Study at the Guildhall. In a previous class we had created an exporter for 3DSMax for skinned skeletal meshes. After learning how to animate these meshes, I decided to go a step further and create a tool for viewing and organizing animations in a similar manner as UDK.
The two has two main parts, the “Animset Editor” and “Animtree Editor”.
The 3DSMax files I used had all animations for a character in sequence. In order to be useable, I devised the Animset Editor to “cut up” the animations into smaller chunks. This data is then saved in an XML file for later use by the Animtree Editor or game engine.
With the Animtree Editor, a user can organize animations in a hierarchy that is useful to a game engine. My version doesn’t have all of the graphical bells and whistles that UDK’s has, but it does many of the same things. The first step is to use XML to create node definitions. For instance, your game might want the ability to blend between idle and moving animations, so you could define a node that took two other node inputs, one for moving and one for idle, as well as a blend time.
The project was created using Direct3d 11 and all of the GUI stuff was done using “Crazy Eddie’s GUI”]]>
This was a game project my fellow programmers and I worked on during the first module at the Guildhall. It is a Sinistar clone named “Mr Sinister”. It’s not much from a technical standpoint, but we really threw ourselves into this project for about two weeks and I think the end result was really, really fun. I programmed nearly all the logic for the player’s ship, the starfield, and the “warp sequence” after you beat Mr Sinister. I also added some neat little mechanics like allowing your laser to charge into a “super laser” that can break through asteroids if you don’t hold down the fire button for a second, or turning your laser into a “hyper laser” if you can mash the button fast enough. Kills with the hyper laser give you more points.]]>
I’m putting this at the top because this post became VERY long.
TL;DR: Use WASD to move, the mouse to aim and shoot.
Press and hold the spacebar to build stuff. The amount of time you hold it down determines what you build in this order: power plant, tractor beam, turret, forcefield.
Press spacebar to pickup/drop stuff. Drop crystals onto buildings to upgrade them. Drop them into the central reactor to upgrade your gun. Build tractor beams to get crystals.
Hold spacebar while over the reactor to heal yourself. Each different building you hold provides a different power.
This is still VERY much a work in progress, in desperate need of real art. It’s a flash game I’ve been toying around with for a very long time, tentatively titled ‘Astro Mine’. The idea is that you’re a sort of deep space trucker, hauling a valuable asteroid back into friendly territory where it can be processed. On the way you get attacked by all manner of creatures, from space pirates to alien spores.
This is a really rough prototype of the game, made in Flash using Flixel with programmer art. Everything discussed in the game below is actually in the prototype, although there may be a few bugs. The player controls a gun/crane thing on the surface of the asteroid. It can move around the the asteroid, shoot lasers, build four different types of buildings, and move stuff around. The “reactor” sits in the center of the base and visually represents how much energy you have. Anything that is on the surface of the asteroid can be picked up and dropped into the reactor to provide more energy.
The game has four different types of buildings you can build. In addition, the player gains a special power while holding each of the buildings. The buildings don’t “cost” anything to build, but each takes longer then the next to build.
1.) Power Plant – provides more energy for the base. Special – the player moves faster
2.) Tractor Beam – pulls space debris into the reactor to give you more energy. Also pulls crystals onto empty base tiles. These can be used to upgrade buildings as well as the main ship’s gun. Special – lets the player shoot a “heal beam” to repair buildings.
3.) Turret – automatically shoots at stuff. Special – links all turrets under player control.
4.) Force-field- protects a 3×3 area from enemy bullets. Special – allows the player to control a “beam” that deflects enemy bullets.
So, as you can see, the game has a lot of stuff going on. Honestly, it’s probably a little bit too complicated at the moment, the energy system in particular. One thing I’m really not going to go into in too much detail is upgrading the player’s ship. You drop crystals into the reactor to do it, but if the reactor runs out of energy (from forcefields getting shot too much or you shooting too much) it will eject the force-fields. Also, the player’s build speed depends on the ratio of power plants to other buildings. This is reflected by the color the the reactor is, but I’m thinking about taking it out, because it just ends up being too frustrating/confusing.
One last thing, if you get too much energy the reactor will “vent” into space, attracting alien spores which will try to latch on to your buildings. After doing so, the building becomes disabled and is damaged slowly over time. If it is destroyed the infection is spread to the buildings around it. I think this is a fun mechanic, but punishing the player for having too much energy probably isn’t a great idea, in retrospect.
Anybody with suggestions for the game let me know. It only has two enemies right now, so any of those would be especially good. Also, anybody who wants to do art for the game, let me know. If I ever end up selling to to Armor or something, I would be willing to split the profits.]]>
This is my DX11 Minecraft renderer after about 6 hours of work. It’s implemented in C++ using an engine I created previously at the Guildhall at SMU.
Right now it’s rendering a 10×10 area in one draw call. It only renders the block faces that are facing air, although all of the chunk borders are being rendered, because I’m looking at each chunk individually when deciding which faces to draw. This is my major bottleneck right now.
I’m planning on doing a lot of optimizations in the near future. For instance, all of the vertex info is being stored as floats on the GPU, but if i were to render each region individually, i could store the x and z components as shorts and the y component as only half a byte! Also, there is currently now frustum or BSP based culling.
The video shows simple N dot L lighting using face normals, with the light position at the camera. I’m currently storing the normals for each vertex as three floats, so obviously that can be compressed as well, since for any given block there are only six possibilities.
Anyway, keep tuned! More updates to come soon!]]>