Mike McShaffry, David Graham
Welcome to Game Coding Complete, Fourth Edition, the newest edition of the essential, hands-on guide to developing commercial-quality games. Written by two veteran game programmers, the book examines the entire game development process and all the unique challenges associated with creating a game. In this excellent introduction to game architecture, you'll explore all the major subsystems of modern game engines and learn professional techniques used in actual games, as well as Teapot Wars, a game created specifically for this book. This updated fourth edition uses the latest versions of DirectX and Visual Studio, and it includes expanded chapter coverage of game actors, AI, shader programming, LUA scripting, the C# editor, and other important updates to every chapter. All the code and examples presented have been tested and used in commercial video games, and the book is full of invaluable best practices, professional tips and tricks, and cautionary advice.
I'm trying to learn OpenGL 3.3+ to do some simple game. There are some tutorial that illustrate how OpenGL Pipeling work but none of this show how to apply this things in a real game. I don't wont make impossible game, just something simple.
I've created my own engine with simple class to create and compile shaders, to load images (jpeg, png, bmp, tga, dds), to do complex matrix manipulation (with Eigen), to abstract the concept of Camera. But I cannot find the right way to make something more complex, like have multiple shaders, to manage a scene with lots of objects, to implement collision detection, and other stuff needed in a game.
The problem is that is hard to use OpenGL. Seems that OpenGL isn't a coherent framework: VBO, VAO, lots of drawing functions, shaders are in some way linked and in other way very far. OpenGL is implemented as a State Machine and I can’t figure how to implement this in an OOP design.
So, do someone know a good book that explain something else other than opengl pipeline, that show how to render for example a complex scene (that use different program). I’ve not found a tutorial that explain how to apply the base knowledge for something more complex like a simple game.
I’m starting to think that OpenGL is not a good framework for Game Programming. On the other side DirectX is a good object oriented framework. So maybe for game programming OpenGL is the wrong choose.
Coding games in OpenGL is everything but simple if you want more than a pong or a ball that moves through a landscape. You may want to other frameworks as you said
A book that could suit your needs is : http://www.amazon.com/Game-Coding-Complete-Fourth-Edition/dp/1133776574/
It is not really OpenGL. If you want a book on more advanced OpenGL you can look into :
or this one which is about more simple concepts :
I am trying to implement the same kind of design as anyone who has successfully scripted a game without using lua as a config/callback file. I would like the functionality as follows:
1 moveToPoint(500, 500) 2 --returns here when moving is done. 3 4 dance() 5 --return here when done dancing etc...
In the player class of my game I would like to have these functions update the fields that the player's position, animation etc... is a adjusted by every update frame. Then, when the desired state of the player is reached, the lua file should continue where it left off. I know it can be done and similar questions have been asked;however, all I have learned from them is how to use lua as a configuration file to read and call callback functions from on certain events(I even know of one question in which the person asking the question knew how to do this but was asking a higher level question about it). I know there is someone out there there who would be willing to share this well guarded secret.
I found a decent solution to the problem that uses an idea found in Game Coding Complete Fourth Edition
It describes a ProccessManager class that allows queuing of processes that are tended to each frame until that process is complete. The Process object that is queued would have some way of signaling that it is complete and a function pointer that would be called to tend to that process for that frame.
Although I do not actually want this functionality any more because I have learned a lot more about how scripting works in game engines, it is possible to expose functions to lua that enable your scripts to create and queue processes.
In the creation of these processes, a method of tending to that process(a function in a different script or something similar), a way to determine if that process has finished, and dependencies on other processes being finished can be specified.
The script would end up looking something like this:
-- queueProcess(fileName, functionName, dependencies) -- the lua function that corresponds to these processes would then -- need to return a special value to signal that it is done. queueProcess("basic_processes.lua", "moveToRock", 0) queueProcess("basic_processes.lua", "waitTenSeconds", moveToRock) queueProcess("basic_processes.lua", "sayHi", waitTenSeconds) -- the cool part about doing things this way is that -- it wouldn't be hard to add logic to this file -- and just keep queuing processes when others -- finish or certain conditions have been met.
You can use this idea to accomplish a lot of cool things with scripting. I hope this helps anyone that was in my position when I asked the question.
EDIT : This is a good answer to the question that took a few paragraphs. As such, it should not have been closed. At least I was able to leave this here so someone with a similar issues can find an answer.
I have good knowledge of C++ and after reading The Elements of Computing Systems I have a basic knowledge of how computers work. I made a list of topics I want to learn next and books I want to buy on those topics. One of them is operating systems, but the one on the top of the list is Game development.
I am still a noob on those topics, so I wonder if I should know how an operating system (unix specifically) works before trying to learn game programming (Opengl, etc). On operating systems I have the book Operating Systems by Tanenbaum, and I want to buy The Linux Programming Interface by Michael Kerish.
I am really lost on what to do first and I hope this is an appropriate question. What should I learn first, what books should I read and in what order. Should I learn how a VGA works before trying Opengl? Are there any other topics I should know before delving into games programming. I am asking this because I like to know what I am coding, what the functions I am calling do under the hood, I don't like holes in my knowledge.
Fluffy opinion answer incoming. Take with grain of salt.
The nice thing about programming is that that you don't need to learn everything about everything to do one thing effectively. Knowing exactly how to implement a video driver isn't required for using OpenGL effectively. The point of OpenGL is to abstract that out so you don't have to worry.
Since you want to do game development, make a project. Like recreating Asteroids using OpenGL for graphics and writing all the game logic yourself. And set about completing it. In the process you'll learn much more than simply reading. Use books as reference. At least thats what I've found works for me.
The Operating Systems book is pretty good. Its the one I read in college. But those concepts presented in it, though interesting, are not something you'll have trouble learning simultaneously with game development or anything else.
Also you should read this: http://www.linuxforu.com/tag/linux-device-drivers-series/. It's a great article series that teaches linux driver development and operating systems concepts in the process.
I am trying to follow along the book Programming a Multiplayer FPS. It is at the part to include DirectPlay, but I cannot find the header or library file for dplay8 in my DirectX installation. What should I do?
What should I do?
Well, a strong advice is to forget about it. Don't spent your time to learn deprecated things. If your book using DirectPlay, probably it is better to put it out. Okay, maybe you will want look at game design features it recommends and nothing more. Anyway, you cannot learn gamedev when only reading one book.
But... If you reaaly maniac... =) Wiki says that first version of SDK that doesn't have DirectPlay is Aug2007. Then, lastest DirectPlay version that you can find on Microsoft web-site is DirectX SDK - (April 2006). You probably could find another version between April 2006 and August 2007.
Offtopic (sorry for that): Best book I've ever seen about writing whole game from scratch is Mr. Mike's Game Coding Complete. In the end they implement a FPS-like game about teapot wars =) Modern DirectX, network, scripting, and many more.
I'm trying to write a simple event manager class and listeners for a game engine. In the usual implementation (i.e. McShaffry) the event manager registers listeners which in principle saves a shared_ptr to the listener as a private member.
I have seen in many instances people saying that shared_ptr and the likes should be avoided (eg here). Thus, I'm trying to find ways to implement the event manager without sharing ownership of the listeners.
One method I've thought of, is assigning unique ids to the listeners and register their ids with the event manager. Then the listeners are responsible of 'asking' the event manager after it has updated, if any events are available under their id.
I would like to ask if there are cleaner and/or standard methods to avoid shared ownership in this case, but also generally. For example, I have the same problem with the listeners. The listeners need to store a pointer to their parent (or the object for which they are listening) so that they can call its methods when handling an event.
As Mat’s comment says, there’s no reason not to use smart pointers in general. That said, the cautionary warning does seem to apply in your situation: as far as I understand you don’t have shared ownership; the event manager has sole ownership of the listeners. A
shared_ptr would thus be inappropriate here.
An alternative would be to use a
unique_ptr which is in many ways the other side of the
shared_ptr coin. But depending on how you model listeners even that can be avoided by simply saving concrete instances to the event manager. Without a more detailed description it’s impossible to say whether you need pointers at all but if you don’t need them then, yes, the advice applies: don’t use (smart) pointers when concrete objects would do.
Finally, if your listeners are objects whose ownership is managed elsewhere consider simply using raw pointers to those objects: in that case, the event manager isn’t at all owner of the object – neither the sole nor a shared owner. While this would be the preferred way for me, it requires careful analysis about the listeners’ life-time to ensure that the event manager doesn’t point to listeners which don’t exist any more.