Search this blog

31 May, 2010

Some links...

No time to work on the blog lately. Just posting some links.

Agenda Cycling Forth - Another masterpiece by Fairlight & Carillon & Cyberiad

Every Program There Is - A 9-part exploration into computational linguistics.

OpenCL Studio - nice OpenCL IDE


Practical Examples in Data Oriented Design - again shows why the scenetree is a retarded idea, but it's more that just that



LibC++ - an alternative to libstc++


Clojure Protocols - nice insights on language design

RSA Animate Drive: the surprising truth about what motivates us - must see if you're in a leadership position

I won't post the link here, but I feel relieved that finally Intel killed Larrabee. Even if it could have been a cool toy for some kids, I think it they succeeded to put it into a gaming console (the only way in my point of view, it could have survived commercially on a consumer-level. I doubt on PC-DirectX it could have ever made much sense) it would have been for the industry only a chore, worse than what ps3 turned out to be.

10 May, 2010

Poll results

Poll: Which means of live-editing does your game/project use? Answers: 75

16%: None. 
We like to cause pain and waste money. We are too rich or too stupid or both. We live in the continuous pain of having to relaunch the game every time we change a texture or a shader. We can't solve bugs. We can't optimize performances. We're doomed.

41%: File hot-swapping. 
We can switch textures and meshes. Probably even shaders. It was relatively simple, just make sure that the file-system does all the resource creation for a given file, and that files are always accessed via handles, and not directly storing pointers to the loaded resources.
Everything works nicely, as long as you don't want to actually... code stuff. Every code change brings back the pain. Rendering engineers love working on shaders, and would kill themselves every time the have to fall back to C++ stuff. 
Can't easily navigate the scene, can't select stuff, tweak parameters, tweak materials, display debugging stuff, live-edit... Memory on the platform is limited, the game crashes after some reloads due to fragmentation.

41%: Script hot-swapping. 
Like above, but we have a scripting system, probably Lua. We can swap those files too.

29%: Tools, partially replicating game functions. (i.e. Shader editor, Animation editor etc). Tool saves the changes.
Iterations on the consoles is painful. Build times are slow. Memory is limited. Input devices are awkward. Reload times are bad. So? Well, let's build tools for faster iteration! Tools where you can edit things quickly.
In theory it's a nice idea, but instead of solving the original problem, you create a new framework that works well, but it's not the game. Still, every time you have to iterate on the game, you fall back to the ugly slow and painful workflow. Also, now you have to write everything twice, once for the tool and once in game. And you force most people to work in their tool, thus not reviewing and iteration on the final, in game, on platform result.

21%: Tool manages and serializes data, but can send RPC to live-update the game.
Same as above, but now we can see changes in game. At least for some stuff, after some time.

18%: The game/engine is embedded in a tool by static linking/DLLs. The game serializes the changes.
We're smarter than the group above. The game is a module with a small "loader" for the console and a platform specific implementation of basic system services (i.e. filesystem).  The tool is a PC environment that loads the same module (i.e. compiled as a DLL) but has a windowing and input system and adds debug functionality and reflection to the various services. The editing functionality is done via components in the editor that can access both to the tool functionalities (windowing) and to the game interfaces.
Great! But still we are not viewing and editing on the target platform. Also if we're not shipping for the PC, we have to maintain an extra platform (the game and the engine have to compile). Also, coding is still slow. C++ is still painful.

9%: Tool, using reflection/RPC/... it communicates with the game. The game serializes the changes.
Everything is done in game! Finally, few members in this group, the elite. The editor has windowing services, and a system to reflect game features, and send message to the game to change its components. 
The editor is written in a cool language, like C#, or uses scripting, or both. It's easy to create new editors. Direct manipulation, picking, editing is done by communicating the mouse input to the console, to have mouse support on the console screen. On the PC screen we display only windows with editing widgets and debugging stuff. C++ = pain.

10%: Purely in-game on-platform editing. Game can build with GUI/editing functionality built in. Game serializes.
Everything is done in game! As above, but on-platform only. On consoles, the limited memory is a big problem. C++ = pain.

9%: Code hot-swapping.
We care about ourselves too! Not only game designers and artists. We care about our work! We don't want to suffer. We are the best, fuck the rest. If you have code hot-swapping, everything else does not matter. Because now you can code fast! You can do whatever. Even code all the above in the time they will take to ship a single game. Enjoy.