Back in 2008 while I was working on the MySQL database-driven PHP application demoed here, it became clear that this was not the direction to go if I ever wanted this system I’m building to be actually used in my department. There were many restrictions that forced me to move to something simpler, yet more robust and looks better. I started working on a new desktop application tool that I called “Site HW Generator” and made sure that this tool won’t remain just a prototype. I put a lot of effort into this tool including not just writing the code but also the creation of its logo, splash screens and so on.
In the following video I demonstrate the tool including a quick demo of the splash screen creation using Cinema 4D.
This is a self-study project. A prototype rather than a complete product. Back in 2008, I had just finished self-studying the basics of PHP and MySQL, and I wanted to put what I had just learned into test. I was looking around for a practice project idea that I understand well, so that I can implement it and be motivated about it. Back then I was working as a cellular-phone-network planning engineer, and in my department at that time, we didn’t have a database management system. We were responsible for a huge amount of data, yet we were using Excel sheets to keep track of them. You can imagine how it used to be very frustrating to update those file, how error-prone that process was, and how hard it was to have multiple employees working on the same file.
I wasn’t hired at that company to work as a software engineer at all, however, replacing that backward database system was a top priority for me, since I was suffering from it every day at work. At that time, no one in my department seemed to care about replacing that system with a commercial one tailored for our needs, and hence I decided to step in. I thought that creating a database management system for my department is the perfect practice project to test my PHP and MySQL knowledge that I had just acquired.
The reason why I’m reviewing this, is because it’s something I made that taught me few lessons:
- The only way to learn something is to get one’s hands dirty by trying to put the acquired knowledge into practice. If I had continued self-studying by just reading books and online tutorials, I would have never learned one fourth of what I learned by actually doing something.
- Being proactive is very important. If I had just waited for the company to replace that old and defected database system, I would have either waited too long, or someone else would have stepped in and created another system. If I hadn’t been proactive, I would have never created this, or the “Site HW Generator©“ tool, which is still used by my department till now, although I left the company more than a year ago.
A life changing class that I recently took at DePaul University was the Architecture of Computer Games. The goal of this class was to learn and apply some very important software engineering practices. The use of game development as a tool to learn applied software engineering is very rewarding since game development projects tend to be big, challenging and have many performance and resource restrictions.
The target of this class was not to build the Space Invaders game using XNA, but rather, to build a complete and efficient game system that wraps and abstracts XNA completely, and is fully general purpose that it can be used to build any other game. Building Space Invaders was just to test this big game system.
Each student was required to work individually on his own project and submit a working recreation of the Space Invaders game and its source code that implements all of the software engineering, game architecture, and data structures principles discussed in class. Each student was also required to submit a full design document of his project that contains UML diagrams, justifications for design decisions, and code samples. Along with that a recorded video demo in which he demos his game was also required to be submitted. Here’s the video that I submitted:
Building my final project, I achieved the following:
- Learning and understanding XNA.
- All version control was done with Perforce.
- Building an Input Manager that wraps all needed XNA calls, and can handle user input from keyboard and game pad.
- It can record user input history up to a certain length.
- It can handle combos (multiple key presses in succession that correspond to a certain reaction).
- Building a Texture Manager that loads textures in a flyweight manner, and uses reference counting of textures.
- Building s Sprite Manager that can manage sprites of different types. Each sprite can be either static or animated from multiple textures or a sprite sheet.
- Building a Timer to handle all timed events in the game including animations.
- Building a generic 2D Game Object that move, animate, and collide with other objects.
- Building a Collision Manager that can efficiently detect collision of objects without having to walk all the objects on the scene graph. The collision detection doesn’t use any of the provided XNA calls, but instead it was implemented using bounding collision boxes that can be drawn in debug mode as a visual clue. Each object can have as many collision boxes as required to make the collision as accurate and efficient as possible.
- Building a Sound System that encapsulates and abstract all XNA and XACT and that can do everything programmatically.
Each student was required to use as many design patterns as he can. I used the following design patterns:
- The Singleton.
- The Flyweight.
- The Factory Method.
- The Observer.
- The Composite.
- The Visitor.
- The Iterator.
- The State.
Each student was required to create any data structures he needs. No C# Collections were allowed to be used. I implemented the following templated and iterable data structures:
- A Circular Queue.
- A Sequential Symbol Table.
- A Hashed Symbol Table.
- A Doubly Linked List.
- A Fast-Delete Doubly Linked List.
It was definitely a very rewarding class that helped me understand a lot about software design and architecture.
One of the best and most challenging classes I’ve ever taken during my pursuit of my master’s degree at DePaul University was Game Engine Programming I. I just finished it successfully and I’m about to start its sequel class. The goal was to build a basic game engine in C++, which will then be developed much further in the sequel class and any independent studies the student would like to do. Each student was required to work individually on his own to finish and submit his final project. It was a lot of work and I definitely learned a lot from it. Each student was required to submit his working source code along with a recorded video of him demoing his game engine. The following is the video that I submitted:
Building my game engine, I accomplished the following:
- Building all the data structures that the engine uses:
- Parent-Child-Sibling (PCS) Tree: for maintaining the engine’s scene graph.
- Passed 73 out of 73 unit tests provided by the professor.
- Sequential and Hashed Symbol Tables.
- Iterable singly and doubly linked lists.
- Building a memory system that manages dynamic memory allocations and encapsulates and abstracts Win32 memory management functions. The memory system can handle multiple heaps and each heap can either be of fixed-sized blocks or variable-sized blocks. It can also handle any alignment requirement of blocks.
- Passed 40 out 40 unit tests provided by the professor.
- Building a file system on top of Win32 functions to handle the needed file IO operations of the engine.
- passed 20 out of 20 unit tests provided by the professor.
- Building a math system for the engine that does all the matrix and vector operations associated with the game and graphics engines.
- passed 102 out of 102 unit tests provided by the professor.
- Building an efficient graphics engine using OpenGL. The graphics engine was the biggest part of the project and it included many areas:
- Cameras and Camera Management:
- Building a camera object that can move, rotate, and zoom in/out.
- The camera draws its frustum as a visual clue.
- The camera calculates its view and projection matrices, and can determine whether an object should be drawn or not (object culling against the camera frustum).
- Building a camera manager that manages multiple cameras, and can perform operations on the active one.
- Textures and texture management:
- Building a texture manager that loads and unloads textures in a flyweight manner. The same texture never gets loaded twice.
- Hashing of textures is done by MD5 hashing of the texture image data rather than its file name.
- Textures use reference counting, they’re only unloaded if they’re not referenced by any graphics object.
- Texture manager tracks the number of textures loaded into GPU and their total byte size.
- Each texture object has its own min and mag filters, and wrapping modes.
- Graphics objects and graphics objects manager:
- Each graphics object is loaded from a single file that includes all its data:
- Vertex data (positions, normals, and UVs).
- Texture data (the texture images themselves, their min and man filters and wrapping modes). An object can have multiple textures.
- Information about its culling sphere.
- Objects are stored on the GPU memory using Vertex Array Objects (VAOs) and Vertext Buffer Objects (VBOs).
- Objects can have different locations and lights.
- Can be unloaded, which will unload its vertex data stored in its VAO, and unloads its textures (if they’re not referenced by another object).
- Each object has its own transformation. It can deal with transformation hierarchies when placed as a child of another object.
- Each object using a bounding sphere to be used in the culling against the active camera frustum. The culling sphere can be drawn in debug mode for testing.
- Graphics object manager:
- Tracks the number of objects on the scene graph.
- Performs the culling against frustum upon drawing using the active camera.
- Has factory methods to create objects.
- Tracks the number of objects drawn.
- Can delete an object along with its children if any.
- Can unload all the objects.
- Ability to have different shading modes:
- Lighting the objects without textures.
- Lighting the objects with textures.
- Flat shading the objects with a constant color.
- Draw objects in wire-frame mode.
- General Project Achievements:
- Fully object oriented and data driven.
- Uses many design patterns.
- Singleton: for all the management systems like the camera manager, the texture manager … etc.
- Strategy: for swapping the active shader.
- Flyweight: Texture manager loading of textures.
- Factory Methods: in the graphics object manager.
- Iterator: for the iterable data structures.
I’m looking forward to Game Engine Programming II so that I can continue and improve this game engine.
Note: The models that I didn’t create belongs to:
This is our 4th Blender tutorial, which teaches you a bit about an area of Blender that is not so commonly used – NURBS Modelling.
We will try to model a screw driver using this technique, which, as we will see, very quick, easy, and generates highly detailed models.
The end result will look like this:
The Video Tutorial
I hope you benefitted from the tutorial. Please leave any comment or suggestion that you have. I’ll be very happy to offer any help you need.