So to start this off, I am currently taking GSP 420 which is a course built on creating your own game engine. I have to say, before this class I've been eager in wanting to take this course because I've always wanted to make my own game engine. Into two weeks of the course me and my group have decided to create a game engine based around a platformer where we will be building it off of
C# and XNA. The group I have is divided up into three cores;
Main Framework Core,
Graphics Core, as well as
AI and Collision Core. Currently I am a part of the Graphics Core and I'm pretty comfortable with that only because I enjoy working with graphics! So to begin with our Game Engine we made sure to do some analysis planning through creating a
class diagram and
requirements list specific to our core. Being able to create a class diagram as well as a requirements list is a great way to get an idea of how the core's going to be structured as far as the system goes.
 |
| Graphics Core |
As you can see with the above picture we have quite a few things going on with the graphics core and that's just only the graphics core. Since we want things to be almost pretty universal my thought behind this was to create a class which holds all sprites and this class was called
spriteContainer. With this class other classes can just load a texture on screen just by invoking a specific variable such as player or enemy1 such as the
levelEditor class. The levelEditor's purpose is actually what the name says, it edit's the levels properties as well as reads .txt files. In this class we can grab textures and set them to be a tile that blocks the players path, or a tile which determines the sprites exit point of a level. After setting up everything as pleased we can just draw all "tiles" based on the level index read and the file streamed. The cool thing with this class is the ability to read .txt files. So let's say we set a certain sprite to have a character of "P". Placing P in a .txt file will actually tell the compiler oh hay this is a platform. As you can see with the picture above there is an association going on with levelEditor and Tile. The purpose of tile is to take in an image from spriteContainer class where you can determine if the image is a platform, has a trigger, is visible or invisible. Now since our game engine is a platformer and we do want to be able to universally have the engine create an animation based off a sprite sheet we created an animation class called
Animate, which associates with the spriteContainer class. So in Animate, it will take into account any sprite sheet, create a cell which shifts left or right, as well as determining if the animation loops or not. Now just so I don't get to into detail, it all comes down to the
Rendering class. The whole purpose of this class is to
Draw, which will draw all tiles based on the level in level editor, as well as render and update the screen coming from
ScreenManager. Thus finishes the class diagram for our Graphics Core.
 |
| Requirements List |
Now it all comes down to the requirements List! I actually enjoy doing the requirements list a lot because it's great to use as a check off sheet such in a way when you begin testing you view your requirements list and see if the system follows all of the requirements. Usually when it comes to creating a requirements list, you want to get as thorough as possible because if there's a bug in your system and it has nothing to do with your requirements then that can go on the programmers fault. So when you look at the requirements list above, it doesn't look as thorough only because this is part of only the graphics core. The way me and my partner did it was pretty organize; labeling things by a
requirement I.D as well as giving each description a
status so we can use it as a check off sheet. When doing the requirements list, we did try to get as detail oriented as possible so in the instance when we test the engine we can make sure everything is running the way it should.
Overall I'd have to say when it comes to creating some sort of system, whether its a software, program and or game engine...It's probably wise to do some planning before hand rather than diving into the production phase because then you might run into more errors versus if you had plan things out. A great way to actually plan things out can come from creating Class Diagrams, Use Cases, Requirement lists, as well as a Risk Assessment Table.
No comments:
Post a Comment