GPiC++Stf Chapter 2 Part 2: Unified Modeling Language, Software Reusability, and Game Anatomy
Hello Everybody, Earth Otherwise here to continue our journey into Game Programming in C++: Start to Finish by Eric Yuzwa. In part two we'll be talking about the Unified Modeling Language.
I have chosen, pretty much at random, to use ARGO UML for my Unified modeling language needs. In the video I show you where to download it and I will be using it to show examples of what I am talking about.
A unified modeling language diagram is a simple graphical way for you to represent your program. It's a quick and simple way for you to plot out how you want the programming of your game development to go.
In UML rectangles are the basic unit. Usually split into three parts. Class name, attributes, and operations. You can also designate if variables are public, private, or protected. There is also the ability to add notes.
When it comes to the relationship between classes there are three types that the book goes into.
A dependency relationship is simple, one class depends on another for functionality. You can't run the graphics class without the triangles class. Simple as that.
Association relationships come in two flavors. An aggregation association says that one class has an object of the second class inside of it. This is depicted by the line with a white diamond at one end. The side with the diamond has an object of the side without the diamond inside it. It may be listed in the attributes section. This relationship says that each class can technically function without the other, though functionality might be hindered. An example from an old game that Ben made is that the gun had a bunch of bullets in it, though each functioned independently of the other.
The second type of association is a composition association. If the secondary class is composed of the primary class then if the primary class ceases to exist then so too does the secondary class. However, if the secondary class ceases to exist then the primary class does not. This is depicted as a line with a black diamond at one end. The side with the diamond is the primary class, the one without is the secondary class.
Finally there is a generalization relationship. This depicts inheritance of one object to another. This is a child parent relationship in C++. The player inherits code from the human class. This is depicted as an arrow. The class pointed to is the class inherited from. That is, where your class that is doing the pointing will receive some of it's attributes. Obviously the class at the other end of the arrow is the class that the inheritance is going to.
That's all we're told about the UML.
(I show an example in the video here)
Next on the docket we have Software Reusability. Code reusability is probably something you've all heard about or figured out for yourselves. From game to game you'll run into similar problems and find yourself writing very similar code over and over. This is why we have the game engine. Generic code that can be easily plugged into any new game and be expected to work because we've already tested it and gotten rid of the bugs. Over time your personal game engine will grow and shrink as you add to it and refine it.
Design reuse is not as obvious though. But in reality, if you've seen any of my Reiterated videos then you'll actually come across this. Things like having a strong core idea for your game or prototyping different approaches and only sticking with the few that support your design goal are all reused and repeated designs.
An example of a design that can be reused over and over again is an Object Factory. A simple class that will be inherited by many if not most of the objects in the game world. It would have a simple constructor and some member data or functions that almost all your objects will need to have.
Another example is the Singleton. Now, forums have indicated that it might be a bit dangerous to work with singletons. You'll learn why in a moment. A singleton is an object that ensures that it is the only object of it's type in the program. This is useful when you want to guarantee that you never have useless duplicates of, say, your audio engine running at the same time. However you might run into problems if there is any kind of bug in a singleton, because there's nothing for you to do about it without having to restart the program or have edge cases where the singleton can be destroyed and a new object made.
A design pattern that you might recognize is the Publisher-Subscriber pattern. It's the pattern that my messaging system uses. It's used to keep the state of various objects synchronized by having the publisher send a message to each of its subscribers.
Then there is the Facade Pattern, or the Manager pattern. This is where a class has the job of managing the relationship between a bunch of similar objects and another system. Like a class that handles taking in the position data from a bunch of objects and passing it on with other relevant information to the graphics engine.
You will likely see all of these design patterns come to use as we begin coding our game.
Finally in this chapter is the Anatomy of a Game. Since this is game programming, this comes in the form of phases of operational runtime in the program. First is initialization, or loading up the program. In this phase you'll initialize the graphics and set your screen size. Start up the sound software, unless you have a silent menu, I suppose. Get the input up and running, start up the networking if it's an online only game or if your game automatically connects to servers for updates. Then finally load in objects, data structures, and graphics and audio resources.
You don't neccessarily have to do this all at once. You can load up the resources for the main menu and then wait to load in game textures for when the player hits play, but it's up to you on where you want to put your loading screens.
Next is the processing phase, where the actual game runs. First you update all the objects, process collision, get input, get network info, and start up or stop audio files.
Then you render the scene as quickly as you can. Of course, all those lighting effects take time and cycles to make, so make sure your players have graphics cards that can handle that stuff.
Finally is the destruction phase. Here we clean up all the resources and shut everything down. Remember to release memory and make sure there's no leaks and no network connections remain open.
Simple, right? Three easy parts to a game. Now let's go over design documentation.
First we'll draft a project overview. This should be one or two sentences describing the game. This is our elevator pitch if we were walking out of the elevator, the doors were closing, and we just remembered that the guy we were riding up with is a publisher. In this instance the goal of the game is to annihilate your opponents in space arena combat. Using laser guns, you need to maneuver your ship to rack up the most kills while avoiding death as long as possible. Essentially multiplayer asteroids without the aforementioned asteroids.
With an overview in place we'll want to ask ourselves why people will choose to buy our game over the other games in the market. I've said it over and over again. You need to differentiate your game from every and any other game. Once you have that, all you need to do is make it and market it.
My advice is to look at all the popular games and all that games that are going to come out. Look as far into the future you can up to and just past the date you expect to release your game in. What do those games have in common? You want your game to be different from any of those games. It can be similar, but you need to find something that none of those games do and something that people want in their games and deliver it.
With our core idea and one or two things that our niche of the games market wants but it's going to get for a while, it's time to draft up a list of timeboxes. These will be our iterations. First will be the foundation and state timebox, which will create the underlying framework needed to start the game, open a window, and get things running. With the code of the Otherwise engine this should be easy enough to accomplish.
Next is graphics. We'll need to set up the framework and graphics pipeline to put stuff on screen. Then we have input and sound which as the name states will be making sure we have the ability to accept input and send out sound to the system. All of this will be easy since we have the basics down with the current version of the engine.
However, the last two timeboxes are networking and special effects. Two things which the engine doesn't currently contain. Hopefully we can use this book to point us in the right direction to get network communication going and learn how to get some special effects on the screen.
Now, you'll notice that there's no story or gameplay timeboxes. Each and every timebox you have will have to contain sub-goals and a prototyping phase so that you can experiment with your mechanics. As we work through the iterations we can adjust our goals as we go.
You will also need to think of who is involved in the game creation process. This is more project management than design, but still important if you're the lead on your team. If you're one person, as I'm sure most of us are, then it's simple enough. We'll be doing all the programming, finding a buying art and sound assets or making them by hand. However, if we want to be proper full time game creators that means we'll probably have to hire a team sooner or later. We'll need to think about what roles they'll fill. Testers, artists, writers, etc. are all important jobs. It's outside the scope of this book, but perhaps there's a GDC talk about it or something that I'll talk about in my Reiterated series.
Now we have to think about a budget. Listen, even if you're doing this as a hobby and aren't even thinking of selling your game you'll probably need to consider developing a budget. You probably can't do everything yourself and working with free assets can work for free projects or projects that are so small that their audience won't break one thousand but if we want to actually live off our game making efforts then we'll need to think about commissioning textures, concept art, sound assets, and voice actors. All on a shoestring budget, but commissioning assets will give you a leg up in the market. If your game looks different than anything else out there it will feel different than anything else out there.
To properly track how much the game is costing you to make you'll want to keep an accurate account of every dollar and minute you spend making the game. This might seem like a pain in the ass, but keeping accurate accounts can help you to measure exactly how much your time was worth in the end and what your profit margins are. It might not mean much right now, but in the future you'll find that it's very important to know exactly what you're making for your effort. It will also help you get a better and better estimate of how long it will take to make each part of your game.
Finally in this chapter we'll talk about your Demo. Some people think that demo's are a waste of time, but think of it this way, tonnes of people pirate games on the excuse that if they like it they'll buy it. Others will never buy your game because they can't be sure they'll like what's inside. With a demo you can, as the name says, demonstrate what they may like about your game. An uninformed customer is far more likely not to buy your game and even those who do might go in expecting something else. That's the fast track to bad reviews and arguments on forums.
So, we're making a demo. Deal with it. Now, since you've made a design document you'll probably have a fairly good idea what features you'll have in your full game. In the demo you should have two things only. You should have the very basic mechanics so that it's playable and you should have the mechanic, character, or story beats that make your game different. Obviously if your game has a huge twist or whatever you probably don't want to put that in the demo, but if it's a horror game you should demonstrate that.
Now, your demo has to tease your customers harder than a stripper on a slow night. You cannot make any kind of full experience. Your customers need to have blue balls from here to India. They cannot, in any way, say that the demo was enough for them. Give them glimpses of all the mechanics and abilities that are available in the full game that they can't have in the demo. Really lay it on thick that even though this demo is amazing, the actual game is a hundred times better. At the end of the demo you will probably want to add what's called a nag screen. A simple screen telling the player what features are in the main game and telling them where they can buy it.
If you can pull it off, you'll probably want to add a simple option that will open their browser to your store page. The fewer clicks a frustrated customer is between your demo and buying the full game the better.
That's it for this chapter boys and girls. Next time we'll quickly skim through the Introduction to SDL and Windows. If you need a full and proper introduction then I recommend, as I always do, the youtube channel MakingGamesWithBen.
Until next time, this has been EarthOtherwise.
▶️ DTube
▶️ IPFS