.mischief.mayhem.soap.
http://msinilo.pl/blog/?feed=rss2

Atom
http://farrarfocus.blogspot.com/feeds/posts/default

Beautiful Pixels
http://feeds.feedburner.com/BeautifulPixels

Dead Voxels
http://deadvoxels.blogspot.com/feeds/posts/default

Diary of a Graphics Programmer
http://diaryofagraphicsprogrammer.blogspot.com/feeds/posts/default

direct to video
http://directtovideo.wordpress.com/feed/

Gamasutra
http://feeds.feedburner.com/GamasutraNews

Game Angst
http://gameangst.com/?feed=rss2

Game Rendering
http://www.gamerendering.com/feed/

GameArchitect
http://gamearchitect.net/feed/

GameDev.Net
http://www.gamedev.net/xml/

Geeks3D Forums – 3D-Tech News Around The Web
http://feeds2.feedburner.com/Geeks3DTechNewsForum

GPGPU» :: GPGPU.org
http://www.gpgpu.org/cgi-bin/blosxom.cgi/index.rss

Graphic Rants
http://graphicrants.blogspot.com/feeds/posts/default

Graphics Size Coding
http://sizecoding.blogspot.com/feeds/posts/default

Humus
http://www.humus.name/rss.xml

Ignacio Castaño
http://castano.ludicon.com/blog/feed/

John Ratcliff’s Code Suppository
http://codesuppository.blogspot.com/feeds/posts/default

level of detail
http://www.jshopf.com/blog/?feed=rss2

Level of Detail
http://levelofdetail.wordpress.com/feed/

Lost in the Triangles
http://feeds.feedburner.com/LostInTheTriangles

Make It Big In Games
http://makeitbigingames.com/feed/

meshula.net
http://meshula.net/wordpress/?feed=rss2

OpenGL News
http://www.opengl.org/news/rss_2.0/

NVIDIA Developer News
http://news.developer.nvidia.com/rss.xml

Outside Hollywood
http://www.outside-hollywood.com/feed/

Real-Time Rendering
http://www.realtimerendering.com/blog/feed/

realtimecollisiondetection.net – the blog
http://realtimecollisiondetection.net/blog/?feed=rss2

Sanders’ blog
http://sandervanrossen.blogspot.com/feeds/posts/default

Scattered Pixels
http://feeds.feedburner.com/ScatteredPixels

Solid Angle
http://solid-angle.blogspot.com/feeds/posts/default

The Hacks of Life
http://hacksoflife.blogspot.com/feeds/posts/default

w00t
http://bpeers.com/blog/xml-rss2.php

Advantages

There are a number of key advantages to using C# as a scripting language in your game engine.  I’ll list these first then describe how I achieve them.

• Designers use Visual Studio. Most designers are stuck using notepad (or similar) when writing their scripts.  With my technique, designers can use Visual Studio, gaining the full power of the IDE.  Including:
  • Intellisense. Letting them know what functions exist on all of the objects you’ve exposed, as well as documentation you’ve provided in code.
  • Compilation. Designers can compile their scripts while making changes to catch any compile-time problems.
  • Full Debugging Support. Another area lacking in most scripting languages is the debugging support.  Designers have access to all of Visual Studios debugging functionality to help them find and fix issues with their code.
• Run-Time Changes. Designers still have complete control to change their scripts at run-time.  Scripts can be reloaded automatically when files are changed, or (more likely) a “reset” button can be exposed in the game engine that allows them to reset the level and reload all scripts.
• Compile scripts into the executable for release. You have the option to use the scripts compiled into the executable if you prefer, protecting your files.
• Complete Access to game objects, or whatever you want designers to access. Designers are working in the same language you are developing in.  They have full access to the game objects or to a subset you decide on.  I use an interface and expose what I want them to use.
• FAST Run-time performance. The C# code is compiled not interpreted meaning the run-time performance is as good as the rest of the engine.  The slight performance bottleneck of reflecting the function can be removed by compiling scripts into executable if required.
• No Binding Required. Binding is automatic between the game engine and the script.  You don’t need to write any plumbing and exposing a new function is as easy as adding it to the engine.

How It Works

The setup is surprisingly easy, designers follow these steps and their up and running:

1. Add the script file to the Visual Studio project (preferably in its own directory)
2. Create an Init() function in the script class which will automatically be called by the engine
3. Create callbacks for events and implement the game logic
4. Run the game and make changes to scripts in real-time as needed

I use the run-time compilation functionality of the .NET framework to compile and run the code on- the-fly.  This has a small performance hit during compilation however the run-time performance is excellent.

Some Examples

Below are a few examples I put together today to show the power of the system.

The first script below creates an entity at the beginning of the game and then sets up a callback that will fire every 5 seconds.  The TestScript object’s lifetime is until the scripting system is reset allowing stateful object creation.

public class TestScript : BaseScript
{
    int team = 1;
    int xPos = 15;
    int yPos = 2;

    public void Init()
    {
        script.CreateEntity("Healer", team, xPos, yPos);
        script.CallEveryXSeconds(MyCallback, 5);
    }

    public void MyCallback()
    {
        script.CreateEntity("Tank", team, xPos, yPos++);
    }
}

The next script shows how simple customizing a game entity can be.  Whenever an effect is added or removed from a game entity, the following two functions are called allowing designers complete control over gameplay.  Notice the designer is given access only to what they need while still having complete control to change any settings or values of the entity.  An interface could be used to restrict what operations can be performed on entities as required.

class SpeedUpEffect
{
    public void AddEffect(GameEntity entity)
    {
        entity.Speed += 1;
    }

    public void RemoveEffect(GameEntity entity)
    {
        entity.Speed -= 1;
    }
}

Conclusion

As I said, I was amazed both at how simple all of this was to set up (only a few hours) and how powerful the system is.  If anyone is interested I’d be happy to share the source code for how I achieved this.  As I continue development of my engine I will be experimenting more with this scripting system and will release more information as I develop it.

Problem

When you chose an engine or platform to develop for, you’re locking yourself into its scripting language.  This has the following core problems:

• Difficult cross platform development.  Cross platform development is hard enough without the worry of porting gameplay code.  Gameplay code should not be platform specific, and therefore there is no reason to have a different language per platform/engine.
• Immature languages.  With each company re-inventing the wheel when they implement a new language designers are left with immature languages.
• Too many languages.  Designers must learn a new language whenever they develop for a new engine/platform.  This increases development time and reduces fluency in a language.  A designer cannot be free to fully express themselves until they are fluent in the language they describe their gameplay in.

Solution

The solution to these problems is to have a unified scripting language shared by all engines/platforms.  Written specifically for game development it would take the best of current scripting languages.  The games industry as a whole would “own” the language allowing it to evolve with the needs of the industry as each new generation of hardware is released.

Advantages

There are a number of key advantages for moving towards a unified scripting language.

• Single gameplay codebase.  Gameplay doesn’t change dramatically between similar platforms (e.g. 360 and PS3 or flash and iPhone).  A unified language would allow a single codebase to kept across multiple platforms helping with porting and maintenance.
• Specific to game development needs.  A language created specifically for game development could cater to the needs of the industry.
• Single language for designers to use. Small nuances in existing languages can create major issues for non-programmer designers.  A single unified language reduces these problems and makes the learning path for students clearer.
• Less Wheel Re-Invention.  An open-source unified scripting language would allow anyone to submit changes to the language to improve it, rather than re-inventing a whole new language.
• Unified Toolset.  A unified set of tools could sit on top of a unified scripting language.

Genre Specific

The core language will hold the basic building blocks for all games.  In the future, small libraries can be built by studios or the community for each specific genre.  For example a library of functions common to most FPS or RTS games could be created and shared between developers.   A unified scripting language makes this sharing possible and encourages people to develop well thought out, robust libraries they can reuse from engine to engine.  It also serves to soften the blow for designers when changing engines as their common set of functions will move across with them.

How

There are two main options for the creation of a new unified scripting language:

• Large studio forks their current language.  For example Epic could open up Unreal Script and give out the source code for its implementation (let’s call it OpenUnrealScript).
• Community Driven.  A simple codeplex/google code project with a couple of leaders and a team of developers would allow for rapid development, while meeting the needs of multiple teams.  Early adopters would drive the initial feature-set and help to drive its development.

Conclusion

My dream is to see the next generation of consoles and other platforms (PC, iPhone, Flash) all supporting a unified language.  I’m interested in people’s thoughts on this idea and candidates for which language to use.  It’s less about language features and just agreeing on a core language everyone can use to develop games and bring all developers onto the same page.

Introduction

The Model View Controller pattern isolates gameplay logic from input and rendering.  This “Separation of Concerns” allows each layer to be developed, tested and maintained independently.  Graphics programmers work solely on rendering, gameplay programmers or designers work on gameplay and whoever’s left can work on input.

Model – Gameplay (game entities, eg. Player, Sword)
View – Rendering
Controller – Input and non-gameplay flow (menu’s etc)

The controller takes input from the player and changes the model.  The controller then passes the model (and any other relevant information) to the view to be rendered.

Advantages

Cleaner Code.  Large teams can work independently on each layer of the application without conflict.  Clear interfaces are used to define communication across layer boundaries.  As the engine grows, this separation of concerns helps to minimize complexity.

Better Cross Platform Support.  Gameplay is separate and not reliant on platform specific technology.  Rendering and input (both heavily platform specific) are separate and can easily be changed.

Decoupled Rendering.  In most engines the game world and renderer are tightly coupled.  MVC decouples the game world (and input) from the rendering.  Rather than calling “Render” of each game entity the rendering system uses the model when rendering.  This also simplifies the process of adding multi-threaded support to the game or renderer.

I’ve used this technique in my latest engine and it feels so much more natural.  Rather than blurring the line between gameplay and rendering they are distinct and the renderer is responsible for bringing them together.

Scripting/Designers.  All changes made to the model by the controller are through a known interface.  This interface can be exposed to designers/modders through a scripting language giving them greater flexibility and control.

Conclusion

I won’t go into implementation details right now.  If anyone is interested, I’ll put together a blog on implementation and look at releasing the MVC framework I created in XNA.  Let me know your thoughts, where you see there might be problems and if you’re interested in me discussing this further.

Read the article here first.

A bit of background
Game programming is one of the hardest forms of software development I’ve worked on.  From my experience, most poor saps can’t even program, let alone create complex games.  I used to work as a business applications programmer and I’ve found that games have one particular ingredient that makes them far harder to develop than most other apps.  That ingredient is ‘fun’.  You can’t easily measure it, set up a list of requirements nor do test cases to make sure it’s there.

Another area to discuss is languages.  The article talks about Basic and Assembly, and thankfully we’ve moved on from these horrid things.  While it’s great fun to hack away in close to machine language, the fact we have much higher level languages means we can spend more time making the game, and less making the computer do what we want.  Many people believe that C++ is old and useless; however it’s still the best choice for making games.  While it’s better than assembly, it’s still quite low level, allowing us to directly access memory and have lots of fun with raw pointers.  Many people still can’t get their head around such things (they’re called Information Systems majors).  While java and .net may be good for beginners, all the work they abstract or hide means the programmer doesn’t fully know or control what’s going on.  Don’t get me wrong, I’d love to start using a language like C# to make games, however at this point it isn’t really an option, but that’s for another blog.  Enough background, lets get on with the real story.

The Good News
A lot of the game programmers I’ve worked with have been up to the challenge.  Game programming is still in its infancy and we have much to learn from general software engineering practices.  A lot of the proven techniques to help with the complex task of developing software aren’t that difficult to learn, we just need to devote some time to learning them.  One of the hopes of this blog is to share some of the general software engineering principles I’ve learnt and share them with the game programming community.

The other good news is that not every position requires a John Carmack.  Even with little 3D and complex math skills there are plenty of areas of games development that programmers can work on to make successful games.  For every one hardcore engine coder on a project there are many gameplay, UI, script, etc programmers who must rely on creativity more than just pure programming skills.  With engines such as Unreal 3, a lot of the complex work is done for programmers, leaving them with the task of making a fun game, rather than writing the fastest rendering system they can.

The Bad News
While I’ve met many good programmers they are, unfortunately, few and far between.  There are plenty of programmers out there that can’t even put simple desktop applications together.  While making games sounds like fun, it’s also extremely complex, and a lot of these useless programmers just can’t hack it (if you’ll excuse the pun).  If you haven’t been coding since you were knee height to a grass hopper then you’re in for a long ride.  Programming is one of those things that people either get, or they never will.  Even if they ‘get’ it, games are so complex there’s a high chance they won’t be good enough to understand all the complexities.  It’s one thing to write code that performs a desired task, a lot of programmers can do that, but to write it efficiently enough that the game can still run >30 frames a second is a hard task.  It takes only one piece of poor code within the inner game loop to be slow and the entire game will bog down.  This is only getting worse as games become larger and more complex.  Add to this the fact each different console comes with its own complexities, pitfalls and challenges means that programmers must be completely comfortable with their language and general programming skills.

As game programming requires only the elite of the programming world there is an unfortunate side effect, the ego.  Game programming is one of those jobs that nearly any kid would love to have, and with so many people not being good enough, some game programmers take that as an opportunity to think they are the most amazing people in the world.  They often forget that their colleagues are in a similar situation and instead think they are better than everyone around them.  This is often called the “Prima Donna Syndrome” and I’ve seen it all too often from game programmers.  Awesome game programmers are like good looking people, it doesn’t matter how good they are, if they think they are the best, and act that way then it basically negates all of their ‘goodness’.  The problem here is that game development is a team exercise.  Programming is only part of the puzzle and people need to communicate well if the team is to succeed.  Within the small group of good enough programmers, there’s an even smaller group that can communicate well and don’t think they are God’s gift to the game development world.

The Pay Problem
Back in the beginning of game development, programmers were paid less than their regular counterparts.  The article paints a pretty picture of how it will be in the future (now) though.  Aren’t we lucky then that games are pulling in billions of dollars around the world?  Surely things would have changed since 1981 and this complex profession of ours would be receiving the remuneration we deserve, unfortunately not.

The majority of game programmers I know would take a massive pay rise if they left the games industry and used their genius elsewhere.  Combine this with much overtime, poor working conditions and generally badly run companies and there’s little incentive to stay in the industry these days.  Why else would the average years in the industry be as low as 5 these days?  Without having the pay to back it up, the industry is only ever going to get diehard gamers who wouldn’t dream of doing anything else.  Thankfully I’m one of them, and the current shortage in good programmers works out well for my peers and I, however for the industry in general it’s a problem. This pay problem is only making it harder to find programmers that are good enough.  A large chunk of the programmer market is simply not interested in the low pay and bad working conditions a lot of studios make them put up with.

Conclusion
So the simple answer is, yes, programmers these days are good enough.  The long answer is ‘kinda, it depends who you ask’.  There are plenty of Carmack style genius’s around at the moment.  There’s also plenty of people looking to the future of games from Tim Sweeney to David Jewsbury (who gave an excellent speech at game connect).  We have some excellent tools at our disposal, many different languages to choose from and an ever increasing budget to work with.  While I’ve met countless bad programmers, I’ve also met enough awesome ones to know that the games for at least the next five years are in good hands.

C++ For New Architectures
Zsolt Mathe, Software Design Engineer, Microsoft Game Technology Group

This was a great speech about tricks and techniques to get C++ code running efficiently on new hardware such as XBox360 and 64-bit processors. There were quite a few code snippets which he used, however you should be able to pick up most of his points just by listening.

Challenging The Given: Is There A Better Language Solution For Programmers?
David Jewsbury, IR Gurus

This was my favourite speech of the conference. As David states, it’s more philosophical than specifically answering questions. I think it raises some interesting points and while some of them are quite ambitious, I think even having dialog about such things will help to stimulate growth in this area.

Medieval 2: Total War: Postmortem
Ken Turner, Creative Assembly

Ken gives an excellent talk about the sequel to one of my favourite series of all time, the Total War Series. He talks about a wide range of topics from processes in place to dealing with legacy code and general discussions about what went right and wrong with Medieval 2: Total War. I found this to be the most informative speech at the talk with excellent advice on so many topics.

How To Use Testing Feedback To Shape Your Game Design
Matthew Ford, Auran
I recommend Matthew’s speech to anyone working on games at the moment. Matt was my project manager for a game a while ago so I have first hand experience with his techniques and can attest to how well they work. This speech was the best presented with clear, concise information, and lots of it, while being fun and engaging the whole time. There’s a large Q&A part at the end which gave even more information and showed that Matt really knows what he’s talking about.

Interactive Storytelling
Chris Avellone, Obsidian Entertainment

Chris has worked on some of the best games ever made. From the fallout series, to Planescape: Torment up to the latest Neverwinter Nights 2 (which just happens to be sitting on my desk in front of me right now). Chris has some great stories about his time working on these games and gives some great advice to any designer/writer who wants to make great RPG’s.

SPU Programming for PS3
Colin Hughes, Sony Computer Entertainment Europe

I won’t say too much about this speech as I’m not a fan of the PS3 nor developing for it. There are some interesting points Colin brings up however I found the speech quite dry and boring. If you’re a PS3 developer or passionate about new hardware then give this speech a listen however be warned, there is a LOT of content.