Elysian Shadows

Since I am here after a long time I should start by creating a new thread on a topic that has not been discussed much. I rarely find good study material on this topic. Its really like a black art, only a handful of developer know. So here It goes.

Functional Game Design:
I have grown to like Object oriented programming, on my quest to Learn to program games has taught me only thing-> "Abstraction is very very important !". How you glue independent part of a game engine as well as make them reusable at the same time is very crucial.
BUT
As we move into bigger games (like world of warcraft, Diablo or Skyrim) things start to get a little messy. The level of Abstraction must reach an optimal point , if we overdo it we start to get the price in terms of performance. Specially with out latest line of processors, having long pipe line. Each Virtual function call start to cause a long series of cache misses in CPU. After watching a small presentation by Sony computers over Pitfalls_of_Object_Oriented_Programming_GCAP_09, (search this term in google) Which clearly speaks about these points. So I begin to wonder, we have some languages that are not Object oriented like C, may be Lua or Haskell.

How would someone achieve a good Game Engine design in these programming languages. Game Engine should be modular, easy to maintain, loosly coupled, easy to extend and doesn't use Object oriented paradigm (mainly inheritance or virtual function).
In Short How to design a game engine using functional programming ?

Well, the best way I've found to learn something like this is to just find some existing code and read through it. If you can: compile it, change it, and observe what happens.

Gish is an award-winning platformer which was part of the very first Humble Indie Bundle.

It's engine is open-source. It is written in C and uses SDL.
https://github.com/blinry/gish

A more popular game (you may have heard of it) called DOOM by id Software also has an open-source engine written in C. DOOM's engine can be found at:
https://github.com/id-Software/DOOM

Also of interest, the DOOM post-mortem:
https://www.youtube.com/watch?v=EKg85-TXY5w

I would start there. Try to identify what worked well for these projects, and what you'd do differently. Then perhaps refine your question(s) to a slightly more specific topic.

I suppose you're coding in C++ and there's no need to switch to something else. You can write very efficient code with it, just be wary of certain language features, e.g. inheritance.

Try this approach:
- Have a clear vision of what your game should be like.
- Use this to define the technical needs of your engine.
- Implement exactly those needs. Only abstract where you need to.

Usually you want to introduce layers of abstraction to increase modularity and flexibility. This holds only partially for performance-critical programs like games. Of course, you don't want your engine to become a big mess, but don't introduce layers where you don't need them. Example, simple tile map:

The tiles in the map only have one property, which is their type. There are only a couple of different tile types <= 256. The map is never going to bigger than a certain maximum size.

So instead of introducing a class TileMap and a class Tile and whatever I just do this:
This variable can hold all the data I need in one coherent space of memory. When accessing the map data, many tiles can fit into one cache line because each tile only takes one byte. This reduces cache misses, which saves a lot of time.

Thank you dandymcgee and K-bal for your precious comments.

Although my concern is mainly not cache misses. I personally like to leverage upon the features of a programming language. For example if I want to exploit the string processing or macro features of Lisp in a game (Like a game in which you can talk to NPC by typing and they will understand ). or using haskell for parallelizing my code (hypothetical). I will be forced to use non OO methods.
I know OO programming gives great support for game design (OO programming was meant for complexities).

Looks like its time to look into what John Carmack has written (thanks dandymcgee). I always admired John, as he always supported openness.

One more thing (may be falco can reply that one) : Suppose we have a game that is entirely written in C++.
Suppose I have a player class which has a move or attack function.
If I want to expose that function to my Lua Script what will be the best way to do it ? Is this the correct way?
or is there some other trick?
or should one return the base class of player and then cast it to player?
or this is not the way at all?

enlighten me please.

I have no experience with Lisp or Haskell, so I can't say anything about that. Also you should open up a different thread for your Lua question.

Back to topic:

Game Engine should be modular, easy to maintain, loosly coupled, easy to extend and doesn't use Object oriented paradigm (mainly inheritance or virtual function).

This does not depend so much on the language you use. You can write that kind of code in both C and C++ or other mainstream languages. Could you provide us with an actual problem case?

K-Bal wrote: This does not depend so much on the language you use. You can write that kind of code in both C and C++ or other mainstream languages. Could you provide us with an actual problem case?

Ok So I will make this question as easy as I can, and I may sound silly.

How to design a game command line interface, where we can fire commands when game is running?
Like if a player is dead, make him alive again. or teleport a game object to another location. spawn new enemies at some locations. (by using game command line interface).

I know ES engine uses same feature. (I have a little idea how lua can do this, but i am not sure (lua_dostring() I hope) ).

But problem is lua is functional language, and we use OOP ? so how can we securely expose stuff to lua? Its kind weird to me. sorry if I sound too vague. That "Land of Lisp " book twisted my brain too much.

Well, yes. lua_dostring() is probably the way to go. You need to expose the data you want to be able to change to Lua. Classes can be mapped to Lua tables, if I remember correctly. There's a whole bunch of literature on the internet about this.

Check out Erlang. It's a functional language developed by Ericsson, it could provide some cool concurrency.

K-Bal wrote:Well, yes. lua_dostring() is probably the way to go. You need to expose the data you want to be able to change to Lua. Classes can be mapped to Lua tables, if I remember correctly. There's a whole bunch of literature on the internet about this.

thanks bro :D

Subscribed to your youtube channel. Cheers

Thanks a lot!

So after going through several stacks of code, It seems interfacing classes to LUA is messy as hell. :P

Looks like I'll have to do it in some another way....... I have a technique that I recently thought of......... I'll let you guys know if that worked. :P

Why don't you implement your own little scripting engine? You probably only need a little subset of functionality anyway and you can create the interface just like you want it to be.

K-Bal wrote:Why don't you implement your own little scripting engine? You probably only need a little subset of functionality anyway and you can create the interface just like you want it to be.

Well I have never created a scripting engine before.... :P.. lets see how it goes.

It is a great learning project, too