Full Sail Game Development: Real Time Animation

So I’m in the month before my final months, where I will be working on my final project at Full Sail. This month is really interesting because I’m practically making the basic structure of my game engine.

The class is called Real Time Animation, and it’s a class where we use Directx11, a graphics API that lets us talk with the GPU, to build off of the fundamentals we learned in Graphics I and Graphics II to animate models. What’s interesting is that even though I had some sort of a basis of an engine in Graphics II when I took that two months ago, I restarted everything completely.

I did this because the teacher said the way we created our project, which was a universal app in Visual Studio, would make things harder for us down the road. This sucked because the universal app did a lot of work for us, so I had to do all the work that the universal app did. Things like creating a window and setting up all the devices needed to start rendering were all things I had skipped thanks to the app, which is a reason why I wasn’t too upset having to do it all by myself: because I would enjoy actually having the understanding how to set up those systems.

Now, I said that this program that I was making would be the basic structure of my game engine, so I knew I needed to make things right from the beginning even though it would take me more time. To do this, I made a scene class. In this scene class, I would have a container of models, which were their own class that would store model data, update the model, and render it, so this way I could just loop through every single model I had when I wanted to update or render. And I was doing really good at first with making things modular and trying to make the good basis of an engine.

But the hard part of building an engine from the ground up is you don’t know about all the pieces that make up an engine when you first start. Later, when you figure out those pieces and you realize how they affect the pieces you already laid out, you realize it’ll be a pain in the ass to work those new pieces into your current system. This has happened many times over the month.

One case that had me rolling was that I had a vertex structure for my vertices that would handle a basic object such as a plane. But then I made a new vertex structure that would be fed into a new vertex shader, so I could put skeleton data into that vertex (blending weights and vertices). The tough part about this was that everytime I created a new vertex structure, I would have to create a new container of those vertices and make their respective setter functions.

What a pain in the ass right? Well, I asked my teacher how to handle this, and he said, first off that the models shouldn’t even know about the models. Instead, the resource manager that loads in all the mesh data should hand a pointer off to the model that points to the vertex data (it should also know the size of the structure and how many vertices there are), and I can just use that pointer to set the vertex buffer given the vertex buffer has a void pointer called pSys that could take in a reference to any block of memory.

I know this was pretty technical and long winded, so I won’t bore you with too much other details like this because there are a lot of them. Ultimately, making a game engine is ridiculously complex.

One thing I can tell you is that I’m excited to work on the engine, but I’m also scared of how big of a feat it is. There is so much thought that needs to be put into an engine, and oftentimes, those thoughts don’t come until after you have already put that thing into the engine.

But anyways, like I said in my last post, I’m starting my final project next month with three others. My friend who is working with me on the engine right now is actually going to a different group to work on a VR paintball game, so it’ll be weird to have to teach the three others how my engine works and what not. But it’s crazy because this month we’re already getting started on the final project.

My group and I had to submit a proposal for our game, which I formed the idea for during a lunch break a few weeks ago. My video had to be short, so I couldn’t get into too many of the details. But ultimately, it’s a lacrosse inspired game where you face off against a team of four others (either human or AI) where try to score on the team’s goal by throwing a ball in with your lacrosse stick. What’s interesting is that the arena’s floor is made of these hexagonal pillars that can shoot up or shoot down, thus, causing fluctuations in the way you have to traverse the arena.

A lot of the design hasn’t been thought too in-depth about given I’ve been swamped with RTA, but I’m really excited. I think the idea of an arcadey sports game (heavily inspired by Rocket League), will give us a lot of time to focus on our engine, which will have its own AI, networking, collision detection, physics, and rendering, because the game design starts off basic but can start expanding with complexity if we can put time into it.

The person who accepts the proposal recommended we make our proposal on Powtoon, so my team and I did. It was a pain in the… Yes, my ass is very sore from this month. Anyways, here’s our effort (voiced by yours truly). https://www.powtoon.com/online-presentation/cSGgJTIcHz9/8sticks1ball/?mode=movie#/