Have you ever written a game/engine from

If so, care to share a little about it? Maybe even some screenshots or video?

giblit (3750)

Writing an engine from scratch would be very time consuming and not worth it for individuals or even small teams in my opinion.

If you write rendering code and some game logic then you technically have a game engine, don't you?

rendering code

Renderers tends to be most complex things. If you want 3d support, you need to use pretty hardcore math. Because of that even those who write their own graphic engine tend to rely on OpenGL/DirectX/whatever.

I prefer to threat graphic engine and game engine as two different entities.

Because of that even those who write their own graphic engine tend to rely on OpenGL/DirectX/whatever.

Of course that's what I meant. To me the graphics engine is part of the game engine.

To me the graphics engine is part of the game engine.

And it is the wrong approach. You want modularity. If switching from your own graphic engine to something other requires rewriting half ot he game — actually, if you have to change a single line of game logic — you did architecture wrong.
If you have to change game logic to add new input device, you did it wrong.

I suggest you to look into Model View Controller pattern:
http://obviam.net/index.php/the-mvc-pattern-tutorial-building-games/
http://www.koonsolo.com/news/model-view-controller-for-games/

I think you're reading too much into what I said. How does it entail loss of modularity? Rendering is one system required in a game engine is it not? So therefore rendering is part of the game engine, no?

LB (13399)

A game doesn't have to be rendered. It can just run and never be seen.

In particular, the engine I am working on involves having the server do all game logic and the client do all rendering. (In other words, how every single game ever should work)

Last edited on

So therefore rendering is part of the game engine, no?

No. Aside from LB said there is often time when you want to run your game without rendering anything. This is like autobattle works in HoMMIV - V: it simulates whole combat with complete simulations without showing it. If you didn't like the outcome and decided to enter battle and turn on autocombat, you will get same outcome.
Additionally this is how wait function in Cataclysm worked.
If you make rendering an unseparable part of your game, you will have a hard time implementing that.

Ganado (6782)

(In other words, how every single game ever should work)
Every game that is server-based like an MMO?

Every game that is server-based like an MMO?

Every game which intend to include a multiplayer mode. Especially if dedicated servers are in the picture. Or you will have a hard time separating model from view (Minecraft, as example).

LB (13399)

I would argue that even singleplayer-only games should utilize separation of client and server logic. Even though there is no network connection there can still be a client and a sever. For instance I believe the Valve Source engine works this way even in singleplayer.

Think you are mixing two ideas here, there is no server or client in a single player only game. If you are attributing rendering code to "client" and game play logic to "server" that's not really true to say that, as there is much more distinction that can be made between a client and server. Keeping logic and rendering separate has it's own reasons, it is not only for creating a server and client.

chrisname (7395)

It's possible to have a client/server architecture without a network, and it's possible to use the network to communicate between two processes running on the same machine (though that seems more common in UNIX programming).

Client and server just mean that one or more processes, threads or modules send requests to (usually) one other process, thread or module, which serves those requests.

On an operating system designed around a microkernel like MINIX, there are multiple servers whose job is to distribute resources to client programs.

Indeed you don't even need software to observe this pattern. Just go to any restaurant and you will be able to observe a server and client. But that isn't really in the context of the discussion now is it?

chrisname (7395)

What I'm saying is, there's no rule that a client-server architecture has to use a network to be considered that, nor does a program using a network have to be distributed over multiple machines because you can use the local network for local IPC.

ezchgg wrote:
that isn't really in the context of the discussion now is it

It is, because you're saying a single-player game doesn't have clients and servers by virtue of being single-player, which is wrong. A single player game can use a client-server architecture, with networking (via the internet or just locally) or without.

You are taking servers and clients out of context. I didn't mean ~every possible derivation of server and client possible right down to code-level pattern implementation~ when i was talking about clients and servers but to the context LB was referring clients and servers to. Which is why what you are saying is out of context of the discussion.

A singleplayer game can implement a server-client in the context that it simply grabs some mission data from an online server. I don't think that's what LB was thinking of off when he was referring to singleplayer in the source engine.

In any case i'd like to know why LB thought a game like Half-Life has a server and client, if he hasn't already crawled away to hide in his hole.

chrisname (7395)

You're still thinking about it in terms of a network, which is wrong. The network is a special case of a client and server. A network is just a method of IPC (Inter-Process Communication) - over the internet, it's IPC between machines running on different computers. Networking is an implementation of client-and-server, not the definition.

All client-and-server is, is a pattern whereby IPC has a many-to-one relationship, i.e. a large group of objects communicating with a smaller group of objects, with little or no intra-group communication. This doesn't require a network, it can be done via sockets, or files, pipes, shared memory, signals, etc. and even if it is done with sockets, it doesn't have to be to a remote machine, it can be local.

You are thinking of the physical machines we call servers, or the software systems like Apache we call servers, rather than the abstract concept of an object who communicates with many other objects. You are thinking about a specific kind of client-server-architecture instead of looking at what a client-server-architecture is. So actually, it's you who has the wrong context.

A video game would be using a client-server-architecture if it had many threads each with a communication channel leading to a single thread. This could be implemented using the network, but for threads (rather than processes) it would be pointless as threads share the same memory space. All you're doing when you use a remote machine to run a "server" for the game is moving some of the game's logic to a different process and using a very slow form of IPC which we call the internet.

If the source engine uses IPC, even if it's not network IPC but just shared memory or pipes, where one dedicated process or thread communicates with many, taking requests from them and then returning the results, then it uses a client-server architecture.

LB (13399)

@ezhgg: Portal 2 uses the Source engine and in singleplayer there is a distinction between server vars and client vars.

MVC design pattern is another example. The server houses the model and the controller, and the client houses the view (and optionally a clone of the model).

Last edited on