Blogs - Siphonen

Here's a work in progress list that I will keep update from time to time whenever I, or someone finds a really great book for software engineering, or game development. I'm not going to review though, just a list with some wonderful random access support. The purpose is to be able to nudge at both class mates and Internet friends, and say "Hey! I recommend checking out... theeese books." \o/

Game Design:
The Art of Game Design: A book of lenses, Jesse Schell
Rules of Play: Game Design Fundamentals, Katie Salen, Eric Zimmerman
A Theory of Fun for Game Design, Raph Koster
Game Design Workshop, Tracey Fullerton
Level Up!: The Guide to Great Video Game Design, Scott Rogers
Universal Principles of Design, William Lidwell (Design in general, but can be applied to Game Design)

Programming Basics:

C++ Primer 4th Edition, Stanley B. Lippman:
The best starter C++ book that I've ever read. Explains everything you need to know in an understandable way.

Effective C++ 3rd Edition, Scott Meyers:
Explains how to use C++ efficiently.

Effective Java 2nd Edition, Joshua Bloch:
Explains how to use Java more efficiently.

Clean Code: A Handbook of Agile Software Craftsmanship, Dean Wampler:
Focuses on explaining and giving exercises in how to write elegant code.

Code Complete: A Practical Handbook of Software Construction, Steve McConnel

Programming, Game Development:

Game Programming Gems:
Goes through solutions to daily problems within game programming.

Real Time Collision Detection, Christer Ericsson
Artificial Intelligence for Games, 2nd Edition, Ian Millington, John Funge
Real-time cameras: a guide for game designers and developers, Mark Haigh-Hutchinson

Programming, Graphics:
OpenGL SuperBible:
Great for learning how to code with OpenGL, however I've heard some nasty issues with the latest edition.

Introduction to 3D Game Programming with Direct X 9.0c: A shader approach, Frank Luna
Great for learning how to code with DX.

Real-time Rendering 3rd Edition , Tomas Akenine-Moller

Programming, Network:
Unix Network Programming, Volume 1: The Sockets Networking API
Great book for learning Network programming in general, even though it says Unix in its name its content is abstract enough to be applied to other platforms. The author's personal wrappers in the code examples makes the book annoying as a 'reference book'.

Software Engineering:
Component-based software engineering : putting the pieces together, Addison Wesley (2001)
Component software : beyond object-oriented programming, Addison Wesley (2002)

Last updated: 2010-11-09

Since the completion of the latest quest - the quest for the holy game engine - I noticed that if I were to use the traditional entity inheritance structure, I would have to rewrite most of the code in order for it to be suitable for future game projects. Other than that there is some major issues with an inheritance structure and that is the fact that you will be implementing tons of new classes that will eventually change the structure of the inheritance layout which means you will have to refactor, or put the features in the base class.

Now this frightens me, not only takes it longer to implement new classes due to refactoring, and you will not be able to reuse the code due to the coupling through major inheritance. There is a lot of code that needs to be modified if you simply try to copy & paste it into a new game project... ouch. There is at least one good thing about this structure and it's the low time complexity compared to other structures.

But still this annoys me greatly to have to rewrite code all the time. For a company, that would be quite a lot of unnecessary money that could have been spent in other areas, such as stocks or a bigger salary for the CEO. So the general question that barked at me was how would I make my code reusable, so I would not have to rewrite health, damage, control mechanics etc. all the time?

When in doubt Google... Several hits revealed that there is a structure called "Component-based software architecture", this was the first time I've ever heard of component-based software engineering, except for the subcategory about pipelines.

What is this? What are components?
If you have a function that spans over several big classes, you separate these functions, put them in their own classes, and keep the "big class" as the container for these smaller classes (components). Now we will not have to rewrite a lot of code, but simply create an instance of each component in a class. The key is to isolate these components from coupling to keep the components as reusable as possible for future projects. Now the major disadvantage of this is that we lack communication among components. It will happen that some components need information from other components, coupling is one answer but it's a step back, makes the code less reusable since it's dependent on the code of a specific component.

The typical approach for communication is to create an event-based structure to send messages or events when something interesting is happening - a form of a finite state machine. Now this will increase the time complexity somewhat and might increase the response time. Therefore you may have to combine with some level of coupling if speed is desired between specific components.

There is not a lot of information how to implement this in practice on Google or in the books that I've checked, but there is loads of theory behind component based software engineering to keep your code reuseable. This is far from new, and has been a topic since the 60's it seems, although the theory was probably quite different back then when object oriented programming languages did not exist. It was probably discussed in the forms of modular programming at that time, I am only speculating though.

I am already implementing this kind of structure for my current game project, and see exactly how slow the responses will be, and try to optimize enough to make the game enjoyable. It will be worth to invest time into this, and in learning these approaches that are probably used all the time in the hardcore world of software engineering.

Once I have succeeded in this task, I will definitely share the source, but until then I will keep it closed since it will probably mislead people or include bad practices for starters.