DISCOVER ON GAME DESIGN AND DEVELOPMENT.The Best Free Online Resources to Learn Game Development and designing for self learners.Here we dumps out a huge variance of tips,e-books,resources about game designing and development only for self Learners.And it also shows the inspirational Story of a successfull games.It is the only Hub for Self Learners By the Self Learners.It is Dod-Development On Game ,Dad-Design and Development
Maybe you’re getting ready for an upcoming game jam, or looking to get into indie game development for the first time. Whatever your reason for seeking out free and easy-to-use game making tools, I’ve compiled a quick list here just for you!
Some of these programs require a basic understanding of programming to really be used to their fullest, while others don’t even ask for a single line of code. For things like art, music and other assets that can help bring your game to life, as well as additional resources like tutorials, I’ve put together a couple links at the bottom of the page. It’s never a bad time to learn a thing or two about game design! For more indie game dev goods, check out our guide to free user interface resources.
And now, in no particular order:
1.PUZZLE SCRIPT
PuzzleScript is a free, open-source game engine designed to help you make tile-based puzzle games. It was developed in HTML5, so you can run the tool right in your browser and play the games right in your browser. While its IDE-like interface may seem imposing to non-programmers, it’s actually quite straightforward and simple to learn.
Increpare, an influential game designer and the creator of PuzzleScript, has put together a handy beginner’s tutorial here, as well as a more advanced document here. Not feeling inspired? Check out some of the awesome games that have been made with this tool so far!
You have a couple options with GameMaker. You can download GameMaker 8.1 and use either the free version or pay $39.99 for the Pro version on Windows, or $19.99 for the Pro version on Mac. Or you can download the free version of GameMaker: Studio or dish out ridiculous amounts of money for the Standard, Professional and Master versions. This list is about freetools, though, so let’s talk about the free versions.
First of all, most people know about GameMaker already. It’s a prominent game creation tool by YoYoGames, with drag-and-drop options and other easy-to-use features for non-programmers, as well as a built-in scripting language for people with a little more experience. The original, freeware version of Spelunky, as well as Hotline Miami, were developed in GameMaker, so despite seeming like a simple tool, its possibilities are vast.
The issue with the Lite and Pro versions of GameMaker 8.1 is YoYoGames will no longer be updating them as they’ve shifted their focus to Studio. However, the limitations on Lite vs. the limitations on the free version of Studio are very different. Lite limits your use of certain advanced functions, like 3D, blending, data structures, etc. There will also be a watermark on your game. The free version of Studio, however, limits your use of resources, like objects, rooms, sprites, sound files, etc. Which one you use depends entirely on your priorities.
Construct 2 is similar to GameMaker, but arguably even easier to use if you’re a non-programmer. A lot of basic coding lingo used in GameMaker’s drag-and-drop features is replaced in favor of more straightforward terminology, plus it comes with a lot of simplified visual effects! There are two paid versions, with the free version coming with some limits and restrictions, which you can read more about here. Besides that, it’s a handy tool and a great alternative to GameMaker.
Stencyl is cool because it allows you to design games easily, while learning some basic programming logic in the process. By utilizing drag-and-drop within a snappable, block-based environment, Stencyl enables you to code events without actually writing any code, while still allowing you to visualize your game’s logic. Learn more here!
Unlike the previous tools I’ve talked about here, Twine‘s focus is on creating hypertext-based interactive fiction games. Twine games are saved as HTML files and use hyperlinks to connect various scenes and other segments of the game together, rather than relying on a text parser system, as in traditional, text-based adventure games. This, coupled with the intuitive graphical interface that allows you to map out scenes in a web-like environment, makes Twine really easy to learn and use. Anna Anthropy has a great beginner’s tutorial located here.
The kinds of games produced by Twine have often been compared to Choose Your Own Adventure books, but because of the tool’s ability to track variables, player-inputted text, use a variety of unique components, plug-ins and more, the possibilities are really quite vast.
Inform is a programming language designed to create player-inputted, command-based interactive fiction. The latest version, Inform 7, comes with its own IDE, library and compiler, all of which you can download here. Inform is unique because it bases its logic off the vocabulary and syntax of natural language, making it relatively easy to comprehend for beginning programmers.
For instance, you could type, “Forest is a room,” which will create Forest as a location in your game world. Then you could type, “Cabin is north of forest,” creating a new location in relation to another. This will connect Cabin to Forest with the user-input command “north” or “go north.” Of course, things get a little more complicated from there, but overall, the language is far more accessible than most when it comes to writing interactive fiction.
Ren’Py is a free and open source visual novel engine that allows users to combine images, text and sound to create interactive simulation games. A lot of dating sims are made using the visual novel format, but it doesn’t have to be limited to just that.
This software is good for beginners because of its super simple scripting language, but it also allows more experienced coders to write games in Python.
Katawa Shoujo is an example of a popular game built in Ren’Py.
Adventure Game Studio is aimed at more intermediate developers, allowing users to create their own point-and-click or keyboard-controlled adventure games. A lot of popular indie games have been created using this software, including the Blackwell series and Gemini Rue.
Why pay for Adobe’s expensive Flash suite when you can just use these free, open-source ActionScript 3 libraries? FlashPunk and Flixel aren’t game-making tools like the rest of the applications on this list, but they are great if you’re looking to create 2D Flash games and have some experience in object-oriented programming. FlashPunk in particular is based on the GML library, making it a smooth transition point for people looking to break away from GameMaker.
Of course, to make use of these libraries, you’ll need to download a separate IDE to work in.FlashDevelop is a free and open-source code editor recommended by the developers of both FlashPunk and Flixel. The two have compiled a great list of resources, tutorials and other information here to help you get started.
Like GameMaker, including Unity on this list was an obvious choice. Unity is a game engine that supports development across an impressive range of platforms, making it one of the most popular game development tools right now. It comes with a built-in IDE, is useful for making both 3D and 2D games and has a huge asset store available.
One downside to Unity is that it’s free as long as you’re not using it for a hefty commercial gain. If your annual gross income exceeds $100,000, you’re required to buy a Unity Pro license for $1,500. The Pro version does come with some additional features, though!
Whoa! You said there were only ten things on this list!
Well, technically, I said there were ten free things on this list… even though I did go over that by including FlashPunk and Flixel, but I don’t care. Who complains about getting more than they expected?
RPG Maker isn’t free, even though [SECRET]most people I know who use it didn’t exactly pay for it.[/SECRET]
I’m not encouraging piracy here, but I just couldn’t let this list be completed without RPG Maker XP. RPG Maker 98 and XP were my first game-making tools growing up, and I love, love lovethem. There’s a free trial for RPG Maker XP you can install here, or you can dish out the $30 to buy it here.
I haven’t heard the best things about RPG Maker VX, but it is their newest product, so there’s that too.
12.After choosing the game engine,learn some tutorials and development tips from their own community page,If any doubts ask your queries in their forum page.
13.Create a notebook for writing some important notes for their game development,
which must contain some basic concepts in developing games.concepts may be like Raycasting,vector,line rendering,etc..
14.Write down the clean and rough flow chart for your developing game.It may also contain algorithm.
15.Prototype the game.If this step is completed successfully then our developing journey is going is a safe manner.It is major part in developing your game,During prototyping your game you may feel that this won't be succeed due to lack of knowledge.But Don't loose your hope,just keep it learning and trying until your output is achieved.Don't expect the exact output of the game,It need not contain graphics but just the mechanics that how the game works.That is..
16.The prototype game can be improved better by playing again and again,Since you can find many flaws
while playing,or you may change some mechanics in game since it may be boring.So the game is improved better step by step while developing the game.
17.Once the game mechanics is 100% successful then create graphical elements to attract the gamer,then sound which makes to feel it involved in game.
18.Release the beta version of the game,and listen to the feedback and response of the game among the people and friends.
19.Rectify and correct those reviews to satisfy the gamer's mind which needed to be liked by everyone.
20.Atlast you have done it with many hurdles on the way.You have achieved it,
Release the game for play in public market and social media. :)
This is Part 1 of an introductory series on game programming using the Microsoft .NET Framework and managed DirectX 9.0. WARNING: Managed DirectX is no longer supported. If you want to do 3D graphics with the .NET Framework, please use XNA (http://creators.xna.com)
Welcome to the first article of an introductory series on game
programming using the Microsoft .NET Framework and managed DirectX 9.0.
This series as aimed at beginning programmers who are interested in
developing a game for their own use with the .NET Framework and DirectX.
The goal of this series is to have fun creating a game and learn game
development and DirectX along the way. Game
programming and DirectX have their own terms and definitions that can
be difficult to understand, but after awhile, you’ll crack the code and
be able to explore a new world of possibilities. I will keep things as
straightforward as possible and decode terms
as they appear. Another part of the learning curve comes from the math
you’ll need to deal with DirectX. I am going to point out some resources
along the way that will help you brush up on, or learn, the math skills
you’ll need to keep going in DirectX.
In this series, we are going to build a simple game to illustrate the
various components of a commercial game. We will cover how to create
great looking graphics in 3D, how to handle user input, how to add sound
to a game, how to create computer opponents
using Artificial Intelligence, and how to model real-world physics. In
addition we are going to cover how to make your game playable over the
network and how to optimize your game for performance. Along the way, I
will show you how to apply principles of object-oriented
development and, as well, I will share some of my experience in
creating well-organized and elegant code.
Tools:
Before we start writing our first game we need to talk about the tools we will use.
The most important tool for any developer is the Integrated
Development Environment (IDE). This is where you are going to spend the
majority of your time writing and debugging code, so it needs be
powerful and fast.
Visual Studio 2005 (also known by the codename “Whidbey") is the
third version of the standard Microsoft IDE for .NET Framework-based
applications. Visual Studio 2005 introduces a number of Express versions
that provide most of the functionality of their
more advanced counterparts but are simplified for the novice, hobbyist,
and student developer and cost much less (There are express versions
available for VB, C#, C++, J# and for Web Developers using ASP.NET). For
this series, I am going to use both Visual
C# Express and Visual Basic Express. If you have not already done so,
download the C# or Visual Basic Visual Studio Express IDE at:
http://msdn.microsoft.com/express.
The second important tool we need to create a great looking game is a
graphics Application Programming Interface (API). Without such an API
it would be extremely difficult to access the graphics capabilities of
your PC. The API we are going use is the DirectX
API. This API allows us to create powerful multimedia applications on
the Windows platform. To work on the game, you will need to download the
latest DirectX SDK at:
http://www.microsoft.com/windows/directx/default.aspx.
Make sure that you download the SDK and not just the runtime. The SDK
includes samples and other utilities that are extremely useful when
developing using DirectX.
At some point in your game development experience you are going to
have to create or modify graphics. Every copy of Microsoft Windows comes
with Microsoft Paint, and while it is not the most powerful program,
you already own it and it is good enough for
most of our needs.
As we dive deeper into DirectX and cover 3D models and sounds, you
might find the need to use other programs to manipulate the image or
sound files. As we cover these topics I will point you towards free or
inexpensive programs and resources on the Web.
Finally, you need to know where to go to get help. One of the best
places is the public newsgroups. Here, you can ask questions and get
answers from people with the same interests as you. Microsoft MVPs and
employees also monitor these newsgroups and provide
help for you along the way. The newsgroups that are going to be of most
interest for game programming are:
Gamasutra: http://www.gamasutra.com/ [Professional audience, but many articles from Game Developer, including tutorials]
What makes a successful game?
My first experience using a computer was in 1981 on a Sinclair ZX
Spectrum. The first 5 years of my computing life were spent on nothing
but writing and modifying games for the Sinclair and later the Commodore
64, but, heck, what else are you going to do
as a teenager? While much has changed in terms of hardware capabilities
and available APIs, the properties of a great game have not.
Games today have become so complex that they require large numbers of
developers, graphic artists, testers and managerial overhead to
develop. They rival large commercial enterprise application in their
complexity and cost many millions of dollars to develop
and market. The payback, however, can be enormous and rival Hollywood
blockbuster movies in sales – Halo 2 grossed $100M in its first day of
availability.
All successful games have a couple of features in common that made them stand out.
The main ingredient for a successful game is the game idea.
Regardless how cool your graphics are, how good the music is, if the
idea is lame no one is going to play the game.
The second most important feature is the playability of the
game. If the game is too hard then players are quickly going to get
frustrated and stop playing. Conversely, if the game play is too easy
then the player is going to get bored and stop playing.
A good game provides multiple levels of difficulty that continuously
challenge the player without overwhelming or boring them.
Together, the game idea and its playability are the “game
design” (not to be confused with “level design,” which is the
application of the overall game design to specific segments of the
game). There are certain game designers who have a golden touch. Shigeru
Miyamoto (the creator of Donkey Kong, Zelda, and Mario) and Will Wright
(Sim-everything) are two prominent examples. Miyamoto’s keynote address
to the 1999 Game Developer’s Conference is available at
http://www.gamasutra.com/features/20030502/miyamoto_01.shtml and Wright’s recent discussion of the design philosophy of Spore (http://www.gamespy.com/articles/595/595975p1.html?fromint=1)
are good inspirations for designers of all stripes, while the book
“Theory of Fun for Game Design” by Raph Koster has gotten excellent
reviews in the community.
The third ingredient to a successful game is the set of
graphics. They need to be good enough to compliment the game idea and
game play but not so resource intensive or flashy that they distract
from it.
The final ingredient is performance. No one wants to play a
slow game. I still remember an adventure game on my Commodore64 that
took 10 minutes to render each scene. I still played it, mind you,
because the game idea was great and there were no other options
around but it was irritating. Graphics and performance are closely
related. The more fancy graphics you add to a game to slower the
performance. The next biggest performance issue is the AI. A lot of game
development today focuses on how to make things faster
and not coming up with new ideas. However, when you’re learning a
complex programming technique such as game programming, it’s vitally
important not to optimize prematurely. An understanding of the
performance pipelines, and the
skills to write clean code, profile it, and improve it are much more important than any single optimized function.
If you apply your design efforts in this order you, too, can create a
great game. It may not be a refined first person shooter like
Battlefield 1942, but Tetris is arguably one of the most popular games
and has neither fancy 3D graphics nor Dolby digital
sound. Even today, games like Gish (http://www.chroniclogic.com/index.htm?gish.htm)
demonstrate what can come from creative independent developers. If you
can write enough of a game to show your
game idea, then maybe you can interest the large gaming companies in
your game. The Independent Games Festival is the “Sundance” of the game
community, runs concurrently with the professional Game Developers
Conference and, believe me, is among the most closely-watched
events at the show.
Our Game idea:
Now that you know what features make a great game, the next step is to lay out the game proposal for our game.
Idea: Since coming up with a unique and creative game
idea is the core of any game, I am going to cheat and use the game idea
from the first 3D game I ever saw: Atari’s Battlezone. (If I had that
great idea why would I let of all you know anyway?)
Battlezone is a basic first-person shooter game in which you are
looking through the viewfinder of a tank into a 3D landscape. The goal
is to destroy as many of the opponent’s tanks as possible before getting
destroyed yourself. The landscape includes random
objects behind which you can hide. The game screen includes a radar to
show you the location of your opponents and the current score.
Playability: The original game started out fairly slowly
but kept adding more opponent tanks and other random enemies. The game
also increased the speed and intelligence of the opponents. All of this
kept the game challenging but playable.
Graphics: The original game used graphics that proved
just engaging enough to feel like you were in a 3D world, but because of
the hardware available in 1980 (an 8-bit processor running at 1.5
megahertz) it rendered the 3D objects as wire frames. These
graphics were advanced when the game first came out, but we are going to
improve upon them using the magic of DirectX (and the magic of 25 years
of Moore’s Law!).
Screenshot of Atari’s Battlezone game – complete with wire frame mountains, tanks, and even a wire frame moon for added realism!
Performance: This game pushed the limits of the hardware
available at the time. This is evident in the use of the wire frame
objects. If the game had been written to fill these objects then it
would have been unplayable. With today’s advanced
hardware we should not have any performance issues other than those
introduced by us writing sloppy code.
Now that we have decided on a game, the next step is to write down
the goals of your game. This does not need to be anything formal but the
simple act of writing things down has the tendency to make ideas
clearer. At a minimum you need to determine the object
of the game, what the player can and cannot do and how the player
interacts with the game. We also should define what the scoring system
is going to be like and what are the victory conditions.
For our game these are the simple specification I came up with.
A 3D first-person shooter game
The goal is to destroy as many enemies as possible
The
player can move through the landscape on the ground just as a regular
tank can. The tank can not fly, nor can it change speed.
The game play will be controlled through the keyboard for
moving and shooting. The mouse will be used to interact with the menus
and start/stop the game. We will not support a joystick.
The player will receive a score that is based on the distance
at which the enemy tank was destroyed. The further the tank was, the
higher the score. Each round fired reduces the score by a set amount,
unless that round hits a target.
The game will be divided into levels. Each level will have a
pre-defined number of enemies. Once all enemies have been eliminated,
the player advances to the next level. There is no limit to the levels.
Now we are ready to do some coding. In general, it is best to write
down just the overall idea of the application. Spending a lot of effort
upfront designing every little detail is just a waste of time. As we add
more functionally to the game we will continuously
do small design sessions to formulate our ideas. This iterative
approach to developing software is the best way to create good software,
and is more fun at the same time.
Creating the game Project:
Now we are ready to write some code. The first step is to create a new solution in Visual Studio 2005.
Select File | New | Project and choose Windows Application from the template list. In the Name field at the bottom of the dialog, replace the default
WindowsApplication1 with BattleTank2005 and click OK.
Visual Studio now creates a new solution for us called BattleTank2005 that contains a single project with the same name.
First, we need to rename the class to something more descriptive.
Naming is one of the most efficient methods of keeping code well
organized and understandable. Always choose names that clearly describe
what the item is doing and avoid meaningless names
like Class1 and Form1.
From the Edit menu, select Find and Replace, then select Quick Replace. Set the
Find What field to 'Form1', Replace What field to 'GameEngine' and the
Look in field to 'Current Project' (see Figure below). Click Replace All to make this change (there should be five changes made)
Next right-clickForm1 in the Solution Explorer and select
Rename. Change Form1.cs to GameEngine.cs.
Replacing Form1 text with GameEngine. You'll thank yourself later.
Another trick to keeping things organized is to ensure that the files
in the Solution Explorer are named exactly the same as the classes they
contain and to always create a separate file for each distinct element
such as each class or enumeration.
Now we have a Windows application that we can run, but it doesn’t do
anything. The form has no other controls on it such as buttons you can
click or textboxes to display any information. In a regular Windows
Forms application we would now add such controls
to the forms to create our final application, but for our game we are
going draw everything using the DirectX API rather than the Windows
Forms API.
We really only need the Form for its Windows Handle, which is
basically its unique name among all the other windows on the screen. We
will use this handle to set up our DirectX drawing surface. The other
use of the Form is that it contains an event that
we are going to use to create our render loop.
Adding the Render loop
A game is much different from a regular application, such as
Microsoft Word. Word presents a screen to the user that mimics a page in
a typewriter and then waits for the user to do something. This
something could be pressing the keys on the keyboard or selecting
a menu item from the menu with the mouse. While waiting for the user to
interact with the application Word does nothing. (Actually I lie: it
does do things like run spell checking and auto save in the
background but nothing you as the user can see). Generally, programs
written using the Windows Forms library generally have the same behavior
– they don’t consume CPU time unless the user is
doing something (of course, it’s possible to use the Timer control or
the capabilities of the System.Threading namespace to do things
independent of the user).
Games are different. As you know, smooth movement in games requires
the screen to be updated many times per second. The “flicker fusion
threshold” at which static images begin to fuse is generally taken to be
1/16 of a second, although it actually varies
depending on illumination (brighter lights like computer monitors
require higher frame rates) and where on the retina the image falls
(peripheral vision requires higher rates than foveal vision). Although
movies are shown at 24 frames per second (FPS), 30
FPS is often considered the lowest-acceptable rate for video games, and
most actiongame players tune their graphics for no less than 60 FPS.
Because the render loop is called dozens of times per second and runs
nonstop, game programming almost always uses the render loop as the
“stopwatch” of the game, calculating everything inside the loop, not
just graphics, but physics, AI, checking for user
input, and scores. (Again, you could use the Timer class or
threads to write a multithreaded game, but doing so would introduce
significant complexity without any clear benefits and although
multithreading in the .NET Framework’s Common Language Runtime
is quite efficient, the slight overhead could knock a couple frames
per second off your game.)
So how do we get the computer to run this loop? The form we added earlier has an event called the
Paint event. The Paint event for a Windows Form object is
called whenever the form is redrawn. This normally occurs only when you
maximize a form or when a form is covered by another form that is moved.
As all Windows Forms programming, even game programming, is
event-based, understanding the principles of events and event handlers
is critical. Although the event is triggered automatically, we need to
create a special method called an event handler to be
able to intercept the event and do something in response to it..
In the GameEngine class add the following code after the constructor.
ProtectedOverridesSub OnPaint(ByVal e As PaintEventArgs)
End Sub
This is our event handler. When is it called? “OnPaint” – when the
Paint event occurs. One thing is still missing. Even though Windows and
the Windows Forms library automatically raise the event, some actions
that we might expect to trigger the Paint event
don’t. Minimizing a window, for example, does not trigger the Paint
event, since Windows does not see the need to repaint the entire form
(Windows is just being efficient since we are actually displaying less
when we are shrinking the form). So we cannot rely
on these automatically-created events to manage the loop we need for
our game.
Luckily, we can programmatically trigger the Paint event by calling
the Invalidate method of a form. This causes the Paint event to be
triggered and Windows to enter back into our OnPaint event handler. Then
we execute any code we want to run every frame
and start all over again by calling the Invalidate method.
You might ask, “Why can’t we just add a while(true) loop directly
within OnPaint() and never leave it?” The answer is that even though
we’re game programmers, we’re expected to play well with others.
Creating a loop within OnPaint() would starve the rest
of the programs running on the system. While our game might gain a few
frames per second, the rest of the system would become, at best, ugly,
and at worst, unstable. So, instead of directly looping, we essentially
“ask” to be called again as soon as possible.
In the OnPaint method add the following line of code:
Visual C#
this.Invalidate();
Visual Basic
Me.Invalidate()
That’s it, we’ve created our render loop. But there is one more problem. It turns out that not
all painting is done in the OnPaint method, Windows Forms
triggers another event when the background is erased and by default
performs some painting (well, erasing) in response. To force our
application to truly only paint inside our method handler,
we need to add one more line of code to our application. Since we need
to ensure that this code is run when the application starts, we place it
into the constructor of the form. This means that we are guaranteed
that this code is run before we call any methods
on that class.
In the GameEngine class add the following line of code to the
constructor immediately following the InitializeComponent method call.
Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or
ControlStyles.Opaque, True)
Setting the ControlStyles to AllPaintingInWmPaint ensures that
Windows only uses the OnPaint event handler to redraw the screen. The
second parameter simply informs Windows that our window is not going to
be transparent.
Now we have the basic framework for our game. Everything we are going
to create from now on out will be actions that occur inside the render
loop.
Everything about timers
One issue with this type of loop is that fact that the speed in which
the computer can accomplish the tasks in the render loop varies from
computer to computer. It even varies on the same computer according to
how much memory and CPU time is available for
the game at any given moment. We need to have some way of accounting
for these differences to make sure that we animate consistently. So
instead of treating each frame the same, we are going to calculate the
time elapsed between frames and apply that value
to our calculations.
There are a couple of different ways of keeping track of time in Windows:
System.Windows.Forms.Timer: This is the most common timer used in Windows programming. While it is easy to use, it only has a resolution of 1/18th of a second. Since we could have up to a thousand frames per second this resolution is not
good enough for a game program.
timeGetTime: This
Windows DLL provides a resolution of 1 microsecond on some versions of
Windows and 5 microseconds on Windows NT. This is too variable, and we
really don’t want to check the operating system our game is running on
to see if we need
to adjust the timer values.
System.TickCount: This
managed call returns the number of ticks that indicate the number of
milliseconds. This is close to what we want, but we can do better.
QueryPerformanceCounter: This is the preferred timer to
use; it has a resolution of less than 1 microsecond. This is the timer
most often used in game development.
The last timer is kind of tricky to write since it requires calls to a
low-level DLL (kernel32 if you need to know) in Windows. Luckily for us
the need for a high-resolution timer is universal and a timer class is
included with the DirectX SDK. You can find
the timer class in the \Samples\Managed\Common directory underneath the
install directory of the SDK. The file we are interested in is called
dxmutmisc.cs, but we will use most of the other files in that directory
as we add more functionality to our own project.
Before we add dxmutmisc.cs we are going to create a separate folder.
Organizing a solution by folders makes it easy to group related items
together and keeps the project more organized.
Selecting Add | New Folder. Name the new folder: DirectXSupport. This is where we are going to add the various support classes as we make use of them throughout this project.
Now we are going to add the existing file to our project. This copies the file to our directory structure.
Right-click the DirectXSupport folder and select Add | Add Existing
Item and browse to C:\Program Files\Microsoft DirectX 9.0 SDK (February
2005)\Samples\Managed\Common and select the dxmutmisc.cs file.
If you want to, you can browse the contents of this file, it contains
various other helper classes that save you from writing a lot of code
yourself in addition to the FrameworkTimer class
Since the timer class is contained in a different namespace we are going to add a
using statement so we can use the FrameworkTimer without
having to write
“Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer” every time.
At the top of the class in the using directives region add the following line of code:
Visual C#
Microsoft.Samples.DirectX.UtilityToolkit;
Visual Basic
Microsoft.Samples.DirectX.UtilityToolkit
Next we need to have a way to store the value of the time elapsed. We
are going to store this value in the deltaTime variable. Notice that we
are declaring this variable as a double. If you declared it as an
integer you would lose all of the resolution provided
by our high-powered timer since everything would be rounded to an
integer.
At the end of the class above the last two braces add the following line of code.
Visual C#
privatedouble deltaTime;
Visual Basic
Private deltaTime As Double
We want to start the timer at the last possible moment in the render loop so we can get the most accurate time possible.
At the end of the OnPaint method right before the this.Invalidate call add the following code.
We need to calculate the elapsed (or delta) time at the start of each
loop, because we are going to pass it to most of the subsequent calls
we are going to make.
At the very top of the OnPaint method, before any other code, add the following line of code.
That’s it. We now have a way to track time. As an added bonus, in the
next article, we will use this timer to compute our frame rate. You
will notice that the solution now will no longer build. This is because
the classes in the file we added require DirectX
to be referenced. We are going to cover which parts of DirectX we need
in the next article.
Summary
We have accomplished a lot in this first article. First, we covered
the tools needed to created managed DirectX games and then we discussed
the features that make a great game. Next, we defined our game idea and
created our game project. After that, we created
the render loop we are going to use throughout the game, and finally we
added a high resolution timer to our project.
The next steps all require DirectX, which we will cover in the next
article. I hope that this initial article has motivated you to begin
that game you always thought about. Game development can be one of the
most satisfying experiences in computer programming,
and as we progress through this series, I am going to teach you all the
fundamentals you need to accomplish that goal.
Friday, 25 April 2014
Zero to 95,688: How I wrote Game Programming Patterns
source: journal.stuffwithstuff.com
About an hour ago, in the quiet of my living room, alone except for a
sleeping dog next to me, I accomplished the biggest goal of my life. I
finished writing Game Programming Patterns.
It’s a book on game programming (it would be a weird title for a book
ornithology) that I started writing about four years and a lifetime ago.
What I see now when I run the script that converts my Markdown manuscript to HTML.
It feels weird writing a blog post that doesn’t have any real content
beyond my own personal story, but what the hell. It’s not like I have
anything better to do! I get some vicarious pleasure mixed with globs
envy when I read about other people finishing their books, so I’ll try
to add to the canon.
The Call to Adventure
Like most stories, it starts with the hero having something bad
happen to him. (Did I just call myself the hero? Seriously? God, this is
already going my head.)
About five years ago, I was a game programmer at Electronic Arts in
sunny Orlando, Florida. That’s the studio that does Madden, NCAA
Football, Madden, Tiger Woods Golf, Madden, and also this football game
you’ve probably heard of. They did a few other one-off games too.
I’d been there seven years, which is an impressively long time to
actively dislike football while working in an office that lived and
breathed it. The last game I worked on, Henry Hatsworth in the Puzzling Adventure
was an absolute blast, the kind of dream project you imagine game
development to be all about. Just seven dudes hanging out making a cool
game they all loved.
My pixel art alter ego in the end credits.
After we shipped, EA decided to never make that kind of mistake again and refocused on suckling the withering teats of its aging cash cowsthe shareholder-friendly profitability of beloved annual franchises. My
entire team quit except me. I ended up bouncing around onto a bunch of
different projects.
I was so burned out chunks of char were falling off me, and I was
really frustrated by how hard it was to ramp up every time I was
airdropped into a new team and its disorganized, deeply coupled,
inconsistent code. I’d find bits of real elegance sitting just a few
source files away from some hairball that would have benefitted from the
exact same structure. People just weren’t talking to each other about
their craft and weren’t learning.
Game dev culture, at least at the studio I was at, is kind of weird.
One quirk of it is that a lot of the programmers I worked with didn’t
give credence to ideas from the larger world of software. Things like Design Patterns were for Nancy-boy enterprise programmers, not real game coders.
On top of this stress, I’d just had a kid, an eventuality I did not
plan for when I purchased a 900’ house at the peak of the housing
bubble. One frustrated drive home from work, I had an idea: I knew some
basic software architecture. I liked writing stuff down. What if I wrote
a book specifically targeted towards game developers about this? If I
aimed it straight at them, maybe they wouldn’t dismiss it out of hand.
A few notes from when I first started thinking about the book. Note that even then I was pandering to the masses on reddit!
(Also, let’s be honest, it’s not hard to write a more enjoyable read than Design Patterns. I’m pretty sure the Addison-Wesley style manual explicitly demands crushingly boring prose.)
Now, I am a world class project starter. I’ve got hard drives full of
stories, videogames, art, music, screenplays, photography projects,
table-top games, hell, there’s probably some poetry in there somewhere.
But virtually none of it’s done. About the only thing I’d been able to get out the door at that time is the occasional blog post.
I was fully aware that taking on this project was pretty much doomed
to failure. But, after visiting the Pacific Northwest, my wife and I really wanted to move, and a book would make for a nice bit of résumé padding to help me find a new job.
How could you not want to live here?
I felt like the book could be our ticket out west. So I needed to
figure out every psychological trick I could play on myself to actually
get it done.
The structure
If blog posts were the only thing I could finish, why not take a cue from that? Design Patterns
is a stack of mostly unconnected chapters. I could organize my book the
same way. Then instead of writing a whole monolithic book, it would
feel more like writing a few dozen separate articles. Less novel and
more anthology.
Likewise, each chapter in Design Patterns has the same top
level headings and organization. I could do the same thing, so I didn’t
need to come up with a unique outline and narrative for each chapter.
They’d just be recipes with different ingredients and instructions.
The workflow
I’m an inveterate tinkerer and I knew if I didn’t put the kibosh on
that, I’d spend all day futzing with CSS or some other stupid thing that
wasn’t writing. So I spent a day or two putting together a minimal script
that would take a file of Markdown for each chapter and convert it to
HTML. Once I got it worked, I swore to myself that I wouldn’t monkey
with it (much).
Now I couldn’t get distracted by design, style, editors, or anything. Just me, Sublime, and a handful of markdown syntax.
The shame
One thing I’d heard was that telling your friends and family that you
intend to do something is a good way to keep yourself honest. So I
totally made myself look like an ass and told everyone, “Hey, I’m gonna
write a book. Because I’m so awesome. Don’t you wish you were as erudite
as me?” Maybe I didn’t word it exactly like that, but I’m pretty sure
that’s how it came across.
After working at EA for seven years, they give you seven weeks off. I used some for my honeymoon and then started writing.
The incentive
I’d been blogging for a year or so and one thing I’d learned is that
the possibility of a good reddit discussion about my writing was incredibly
effective at getting me to complete something and put it out there. So I
planned to put each chapter online as I finished it instead of waiting
for the entire book to be done.
One of the first chapters posted.
Crossing the Threshold
I rolled this all by my wife and, unbelievably, she agreed to it.
Even though it meant she’d have to spend even more time taking care of
our infant daughter while I wrote. Even though she knew I’d never
finished much of anything before.
I’d like to think she believed in me, but maybe she just really
wanted to move out of that tiny bungalow. Seriously, that house was so
small we had to move the stroller into the living room every time we did
laundry.
With her OK, I started working on a plan. Since padding my résumé was
a primary motivation, I needed a real publisher. I figured putting my self-published book on my résumé would sound about as impressive as that “World’s Best Son” mug I got from Mom.
I spent a bunch of time reading submission guidelines. They usually
want an outline (check) and some sample chapters (oops). So I spent a
couple of weeks writing and revising a couple of chapters. This was a
nice trial to see if I could actually write something that looked like a
book chapter. Miracle of miracles, I could! For the record, the first
chapter I wrote was Object Pool.
I carefully looked at a range of different publishers and their
compensation packages before making an educated choice about which ones
to submit too. And by that I mean I sent it to O’Reilly because OMG
having a book with an animal on it like Perl’s camel book would be SO RAD.
I emailed them the submission with butterflies in my stomach which,
when you think about it, is an absolutely pointless physiological
reaction given that I was in my house all alone staring at my computer
and not being attacked by a sabretooth tiger. A heightened sympathetic
nervous system does not actually make email arrive faster.
Unbelievably, they got back in touch. They were interested! I had an
editor! He had feedback! He talked to me like I was an actual writer and
not some jackass who decided he was an author because he thought it
sounded cool. There was talk of a (small) advance. I felt like hot shit.
And then… somehow… it sort of fell through. I don’t remember the
exact details, but at some point they decided to not move forward after
all. I reached out to a few other publishers and found another one. I
signed a contract with Apress and was super pumped to be back in
business. We had a writing schedule and everything.
During all of this, I was still writing and managed to get a couple
more chapters done. Unfortunately (but unsurprisingly and
understandably) my publisher was a little hesitant to have me put them
all online, so I didn’t get that jolt of dopamine every time someone on
the Internet acknowledged my existence.
The Ordeal
I thought I was back on track but then something funny happened. It
turned out I didn’t need to pad my résumé after all. I got a new job.
Outside of the game industry and in the city we were desperately hoping
to move to.
All of the sudden, we were packing up our belongings, kid, and pets;
saying goodbye to friends and family; and moving along what is
practically the longest straight line move
you can make in the continental US. I was plunged headlong into
learning all sorts of new stuff at work that had nothing to do with
games. We got another dog and had another kid.
That writing scheduled was looking a little, uh, unrealistic.
Eventually, I realized my heart just wasn’t in the book anymore. I
called my editor, apologized profusely, and backed out of my deal.
Without the pressure to write, I forgot about the book almost
completely. I hadn’t abandoned it, really. I told myself I’d get back to is some day. It languished for a year. Then another.
It would have gone into my overflowing bucket of unfinished projects if it wasn’t for one thing: people kept emailing me about it.
You see, I’d put the entire table of contents online along with the
handful of chapters I had written. Every now and then I would get a
long, wonderful email from someone telling me how a chapter really
helped some abstract concept click in their mind and how they couldn’t
wait for the next chapter. Good god, their enthusiasm made me feel
terrible.
Resurrection and Rebirth
About a year ago, I had an unpleasant realization: as I got farther
and farther from my days as a professional game developer, my expertise
was getting out of date. I was losing the ability to finish the book.
While all my other unfinished projects didn’t bother me that much,
the book was special. I’d only ever tried to write this one, and to have
it die would break my heart. I figured it was now or never.
Around this time, I’d stumbled onto that article about Jerry Seinfeld’s trick for staying productive. It’s pretty simple: work on it every single day. Don’t break the chain of sequential days. I also met Chris Strom who’s been blogging this way for something like a million years.
Without putting much thought into it, I figured I’d give it a try. I
hadn’t written a word on the book in well over a year, but on June 7th,
I started a new chapter on Game Loops. I wrote 777 words of first draft, less than an hour of work.
The next day, I wrote 489 words. Then a meager 178. But it wasn’t zero. This weird desire not to break the chain made me drag myself off my ass and at least write something,
and once those 178 words were done, I was that much closer to the end.
The next day, I did 889 words. The day after that, I finished the first
draft.
Interlude: How a Chapter is Made!
I got so wrapped up in my own little narcissistic narrative I forgot
to tell you anything useful about the actual mechanics of how I write!
Since I decided to post chapters online as I completed them, I knew I
couldn’t just do a first draft of the whole book before revising
anything. Trust me, no one wants to read a first draft. Instead, I treat
each chapter like a little standalone piece of writing. I do it like
this:
1. Outline the chapter
Most of the chapters have the same top level structure, but within
those headings, I do a pretty detailed outline of what points I want to
cover and how they flow together. By the end, I have basically all of
the material for the chapter, just with no actual punctuation or
grammar. It’s everything I want to say, said really poorly.
Here’s a chunk of outline from the Game Loop chapter:
- old programs used to be batch: ran and quit
- then came interactive programs. these ran forever, which meant loop
- if you write gui app, the os has event loop
- you receive ui event, handle it, and return to event loop
- js is a great example
- you don't see loop, but it's there
- when app isn't handle user input, it isn't doing anything, just sitting
there
- this can work for simple games (minesweeper, solitaire)
I don’t think those bullet points or indentation even mean anything. It’s just word salad.
2. Write the code
The outline will hint at the example code so I know what blocks of
code need to be written. Then I come back and write the actual code.
Sometimes I’ll interleave this with writing the text, other times I’ll
do all of the code up front.
I write the code in separate C++ source files
so that I can compile it and makes sure it’s free of errors. For some
chapters, I even wrote unit tests. The script that converts the Markdown
to HTML pulls in the code snippets directly from those files.
Here’s a bit of markdown for the prototype chapter:
To create a ghost spawner, we just create a prototypical ghost
instance, and then create a spawner holding that prototype:
^code spawn-ghost-clone
One neat part about this pattern is that it doesn't just clone
the *class* of the prototype, it clones its *state* too...
The little ^code tells my script to hunt in the C++ code until it finds:
It stitches in those two lines of code and we’re good!
3. Write the first draft
I hate first drafts. I hate the blank page. I do a detailed
outline up front to try to make this easier. And then I rush through
this as quick as I can to get it over with. Even so, this part takes the
longest and I usually only get about 500 words a day on it.
I try to silence my internal critic during this phase so I can keep
making forward progress. I rely heavily on later revisions. Knowing I
will edit later gives me the freedom to not edit now.
4. Do the second draft
As soon as the first draft is done, I circle back and do the second.
This involves fixing all of the mistakes, bad grammar, and poor flow of
the first draft. Sometimes, there’s major surgery here when I decide
something I crammed in just isn’t working. I make a lot of changes:
A chunk of the diff from the first to second draft of the last chapter I wrote.
The second draft is shorter than the first. I treat writing like
pottery. I slap all the clay on the wheel in a big blob and then
iteratively refine it down to the final work. I can get about 1,000
words of this done a day.
I love this part. Feeling the prose get tigher and clearer
is exactly as satisfying as refactoring messy code. It’s less stressful
because I feel like anything I do now just makes it better but the
chapter is safely complete regardless. There’s no more blank page so editing is just pure goodness.
5. Do the third draft
This is the home stretch. At this point, the chapter is almost in its
final form. For this last pass, what I’m looking for is mistakes and
rhythm.
I read the entire chapter out loud. I can’t stress enough
how helpful it is. You can read something ten times and think it’s fine
but the first time you run it through your lips you’ll find all of the
wrinkles. This fixes awkward repetition and bad cadence. If the prose reads naturally and easily, that’s not because I wrote it naturallly and easily. It’s because I edited the hell out of it.
6. Illustrations
The last thing I do is draw a few illustrations for the chapter. I think visuals are hugely important for making abstract concepts concrete in the user’s mind.
I spent a lot of time trying to figure out how I wanted to illustrate
the book. I’d done a few illustrations in Photoshop, but didn’t like
how the text looked pixellated. It also made at a real pain to change
the design of the site, and looked terrible when retina displays came on
the scene.
I thought about doing something like SVG, but that seemed like a huge
time sink to get the level of quality I wanted. Eventually, I hit upon
the idea of going in the other direction. I decided to
hand-draw and scan the illustrations. I could scan them at a high enough
resolution to look sharp on a retina screen. More importantly, their intentional imperfection would help turn off the OCD part of my brain that would be unsatisfied with anything less than perfect Edward Tufte-quality diagrams.
Some of the 66 hand-drawn illustrations.
7. Publish and fix bugs
At this point, I think the chapter is done. I put it online and tell
the world, and immediately they point out a bunch of glaringly obvious
bugs that somehow survived several rounds of editing. I fix those, and now the chapter is mostly solid.
The Long Road
OK, where were we? I started logging each day’s work in a little text file. Less than two weeks later, the chapter was done:
2013-06-18 - Finish third draft of Game Loop
2013-06-17 - 1,280 words revised in third draft of Game Loop
2013-06-16 - ~1,000 words revised in third draft of Game Loop
2013-06-15 - Finish second draft of Game Loop
2013-06-14 - Revise couple of paragraphs of Game Loop
2013-06-13 - Revise ~500 words of second draft of Game Loop
2013-06-12 - Revise ~900 words of second draft of Game Loop
2013-06-11 - Finish first draft of Game Loop
2013-06-10 - 489 words on first draft of Game Loop
2013-06-09 - 178 words on first draft of Game Loop
2013-06-08 - 889 words on first draft of Game Loop
2013-06-07 - 777 words on first draft of Game Loop
I spent some time redoing the design of the site not to be totally
busted on mobile devices and then started the next chapter. Now, if this
was a movie, this is when the eighties instrumental rock would start
and the montage would kick in. Before you know it, the book would be
done.
But, I tell you what, I lived that montage, and it did not pass quickly. Working on this damned book was a pain in the ass every single day.
I work full time, and have two small kids. We bought a house and all of
the work that that entails and it turns out that, holy crap, it’s
pretty easy to fill an entire day with stuff that’s not writing a book.
I started getting up early in the morning before the kids so I could
have some quiet time. Ostensibly, I would write then, and sometimes I
did. But, more often than not, I’d just drink coffee and stare at the
Internet while I slowly roused myself. Then, after I’d worked, made
dinner, gotten the kids cleaned up and ready for bed, read them books,
gotten them milk, cleaned up a bit and gotten them in bed, then, I’d still have to write.
Yet, strangely, I would. I’ve never demonstrated an ounce of self-discipline in my entire life,
but for some reason I just didn’t want to skip a day. Even though I was
often dog tired, I would scrape up just enough energy to put in a
barely half an hour of writing. I would look at the pathetic word count
and feel bad before going to sleep exhausted.
But here’s the thing. Even tiny amounts of effort add up if you keep
at it. I’d have entire weeks where I felt like I didn’t have a single
good writing day, but after two of those weeks… that’s a whole chapter.
Because I was writing every day, it made it easier to build it into the routine. I never had a chance to get used to not writing. It was just this thing that must be in the schedule, like brushing my teeth or eating, even when I traveled or did outings with the kids. I gave a talk at Strange Loop
last year, and every evening after dinner, while others were out at
bars socializing, I went back to my hotel room so I could write. When I
flew to another office for all-day meetings, I wrote on the plane.
The only insurmountable problem I ran into was a camping trip. I
couldn’t imagine bringing a laptop to the woods and charging it in my
car or something. Instead, I did what comic strip artists do: I banked
some days. For two days leading up to the trip, I wrote two sessions a
day. Then I wrote early in the morning before leaving, so I only ended
up skipping one day. I basically loaned myself the time, with interest.
Refusal of the Return
Once I started putting chapters online again, people started
noticing. I got that feedback and encouragement that I thrive on and I
was delighted to have stuff to talk about on reddit again.
Around this time, an editor at another publisher reached out to me.
Now that I was working on the book again, would I be interested in a
publishing deal? She was super nice and was very willing to work with
me. I could keep the book online, I could be involved in the design and
layout. It could be everything I wanted and more.
I kind of dragged my feet for a while before I finally realized my
reluctance was trying to tell me something. When I’d had publishers
before, the power relationship felt really strange. O’Reilly and Apress
were both great, but I felt like they were in charge, which is really
bizarre when you think about how much effort the author puts into it
compared to the publisher.
What I was finding was that I really liked it being my book.
I’m not doing this for the money, which means I’m doing it for my
personal satisfaction. And what’s most satisfying to me is feeling like I
got to put as much of my own creativity into it as possible without
someone else calling the shots.
That’s not to say I don’t like collaboration. I’ve gotten about 130
bug reports along with a bunch of pull requests, not to mention lots of
comments and email. I absolutely treasure all of that, and the book is
way better than it would be without that.
I really like working with readers and contributors, but I’m not really interested in working for
a publisher. About half-way through the book, I decided to
self-publish. That meant I needed to start doing the things a publisher
does. In my mind that’s:
Developmental editing. When you get a book deal,
this is what the editor you work with does. It’s their job to guide the
overall direction of the book to make sure it lines up with what
audiences want.
Marketing, advertising, and distribution. Basically, getting the book in front of people and in stores. Making sure people know it exists.
Copy-editing, proof-reading, illustrations, and design. The sort of blue collar stuff that turns a manuscript into a book.
I’d been putting chapters online and interacting directly with my
audience since I started the book, so I felt like I had a better handle
on what they wanted than most editors would. Having an inbox with
hundreds of emails from people is pretty helpful when you’re trying to
figure out what they want.
All of the manual labor side of things—editing and design—are some of
my favorite parts. Before I was a programmer, I was a graphic designer,
and I’ve dreamed of typesetting and laying out a book. Bug reports from
readers helped do some of the work of copy-editing. (Special shout-out
to mystery superhero colms who basically line-edited the entire book free of charge.) Finding a freelance proof-reader didn’t seem too hard.
Of course, distribution is a mostly solved problem now. Especially
with technical books, people buy them from Amazon or get eBooks. I can
do those just as well as any New York publisher. You don’t need deals or
shelf space any more (though it certainly doesn’t hurt).
That left marketing and advertising—making sure people knew about the
book. So I created a mailing list. I added a little blurb to the top of
each page saying the book was a work-in-progress and to sign up if you
want to know when chapters come out. As of this morning, I have a little
over 3,000 subscribers, which is probably more reach than a “real”
publisher would have given me.
Finishing the Damn Thing
Once I had that decided and squared away, all that was left was to
write the rest of the chapters. So I wrote. And wrote. And wrote. Every
single day. I wrote while my wife gave the kids a bath. I wrote at five
in the morning before we went on day trips. I wrote when I was sick. I
wrote on Halloween, Thanksgiving, Christmas, and New Year’s.
When I finished a chapter, I’d spent a few days where “writing”
consisted of fixing bugs, responding to email and other minutia. But
then I’d get to the next chapter.
After a while, writing the book receded into the back of my mind. It
wasn’t something I thought much about during the day. When people asked
what I did outside of work, I’d forget to include it sometimes. It was
just ever-present background noise. Exactly 322 days after I started the
first draft of Game Loop, all of these little slices of low thread
priority background work on the book added up.
95,688 words. 21 chapters. 66 illustrations. 133 fixed issues. Hundreds of commits. Yesterday, I committed the third draft of the last chapter and the manuscript was complete.
I’ve wanted to be able to claim that I’ve written a book for so long
that it feels weird to finally be on the other side of finish line. I
wrote a book. Not “want to write”. Not “will write”. Not even “am
writing”. Wrote.
