Basic core engine

About the actual programming of the game.

Basic core engine

Postby croxis » Wed Aug 28, 2013 4:54 pm

For this project to survive there needs to be some forward motion in the coding department. While a lot of decisions will be informed by the game mechanics there are some base engine elements that will be needed reguardless of specific mechanics.

This is not a comprehensive list of what is needed for a game engine nor a final list. Some of these elements can be considered as placeholders until a final decision, although those decisions should be sooner than later. An example is physics -- the final version of the engine may use bullet or physx or a custom solution, but the basic placeholder should be just functional enough.

It should also be complete enough that those working on the game mechanic end of things can being prototyping using the engine.

For the sake of workflow each item should probably be split into individual issues on github's issue tracker.

I am assuming an entity-component-system architecture. One advantage is the ease of adding placeholder systems and components to have a functioning game environment while the final, well thought out systems and components are cooking.

  • Base entity component system (ecs). -- This is the super general system of creating entities, registering components, the system controller, and the system class other systems will inherit
  • Base render system. -- Non fixed function differed pipeline that can display simple mesh, texture, lights. Camera stays at 0,0,0 and world is transformed around camera (this will solve some scale issues later)
  • Basic asset loading -- loading meshes, textures, and shaders from desired or placeholder format into internal desired placeholder format
  • Basic math -- Vectors, matrixes, points
  • Scene management -- I'm not sure what this should be. This is the limit of my experience with it.
  • Basic client and server networking -- Client and server are able to send basic messages. Protobufs or similar can be used for now. (Small aside -- I've read cases of ecs systems that had a universal binary and code base for client and server. Launching as client, server, or both was just a matter of which systems are activated.)
  • Basic audio support
  • Lua script layer -- Should work with the ecs system so it doesn't matter if a system or component is written in c++ or lua
  • Basic UI layer -- Implement berkelium or some other html/css ui system (lets take advantage of our web developers)
  • Basic celestial modeling -- If a dynamic universe then basic modeling of planet motion and position
  • Basic plugin system -- Some naive way to load external code in c++ or lua for rapid prototyping of ideas using the engine.
  • Basic API -- There will need to be a lot of discussion about sandboxing for client security later. While APIs should be stable and thoughtful there is also danger in spending too much time planning it when it will probably change some down the road as the game coders use it.
  • Basic Newtonian physics system -- Mostly as placeholder. Could use Bullet or some other premade solution just to get the ball rolling while the final physics system is being developed
  • Basic collision detection -- Naive sphere based collisions is a decent placeholder. See above on using bullet.
  • Basic voxels -- A basic voxel system. Maybe use a "dumb" visualization system such as blocks JUST for prototyping.
  • Basic DCPU api -- An abstraction layer for creating, destroying, tracking, and checking dcpus.

Hopefully this would be enough to create a static ship players can walk around in a single or multiplayer context.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Basic core engine

Postby Pseudonym » Thu Aug 29, 2013 7:10 am

This is a great first cut at a list. I do have a few comments based on what I've done so far.

croxis wrote:I am assuming an entity-component-system architecture. One advantage is the ease of adding placeholder systems and components to have a functioning game environment while the final, well thought out systems and components are cooking.

I definitely agree with this. I will add that it is the responsibility of each component to register itself with any subsystem which should know about it: a material or mesh will register itself with the rendering subsystem, a sound emitter will register itself with the sound subsystem, and so on.

croxis wrote:Base render system. -- Non fixed function differed pipeline that can display simple mesh, texture, lights. Camera stays at 0,0,0 and world is transformed around camera (this will solve some scale issues later)

I'm working on this at the moment.

"Simple mesh" needs a little bit of expansion, because I've made some design decisions. What the render subsystem draws is primitives. There are several types of primitives: points, lines, triangle strips/fans, and so on. What they have in common is that they are a sequence of vertices, a sequence of indices, and a single material.

There's also some infrastructure for building primitives in such a way that different model formats and animation models can be layered on top of this.

croxis wrote:Basic asset loading -- loading meshes, textures, and shaders from desired or placeholder format into internal desired placeholder format

I would like to point out that all game objects are, in a sense, assets. I'll describe some more later (state machines, events and actions) which illustrate what I mean by this.

croxis wrote:Basic math -- Vectors, matrixes, points

Kudos for knowing the difference between vectors and points! Ideally, we'd go the full Clifford algebra, but it's probably a bad idea from the point of view of efficiency.

I've started on this. I've pulled in std::complex and boost::math::quaternion. Other geometric objects that I have drafts of: box (and the associated algebra), plane, and frustum. I toyed with dual arithmetic a little bit, but I don't think we'll need it in the game system itself. Maybe when we get to IK.

croxis wrote:Scene management -- I'm not sure what this should be.

This is an excellent question, and something I've put some thought to.

One of the reason why scene management is going to be a little bit complicated in Trillek is the way we want to handle ships and planets. We are modelling planets using one mechanism (voxels or something) and the interiors of ships using another mechanism (probably rooms connected by doorways). Different types of environment are modelled and rendered in different ways.

But sometimes you're inside a ship sitting on the planet surface, and can see the planet outside the window, and sometimes you're on the planet surface looking at the ship. This means that different types of environment can be "active" in a single frame!

It's not an insurmountable problem, but it will get a little bit subtle.

croxis wrote:Lua script layer -- Should work with the ecs system so it doesn't matter if a system or component is written in c++ or lua

We need to do some hard thinking about this. My gut feeling is that all components and systems are written in C++, and that Lua should be reserved for very limited tasks as far as the core engine is concerned.

What I envisage, is that the core engine manages three kinds of component which manage high-level behaviour: state machines, events and actions.

A state machine would be something like the Qt state machine framework, which allows state machines to be composed in a very clean way. Basically, you specify a finite set of states that a machine can be in, and the allowed transitions.

An event is something that happens when certain state conditions are met. For example, if a NPC enemy is in the "alive" state, and a player hits the enemy with a weapon, then an event is triggered. The event may then trigger some actions: a sound effect may be played, an animation on the enemy's mesh may be started, the health of the enemy may be decreased, and so on. Each action may in turn cause new events to occur, possibly after some fixed delay. For example, if the enemy's health reaches zero, then after the "hit" animation is finished, the enemy should transition to a "dying" state, which starts a new animation, different sound effect and so on.

Game designers can specify state machines, events and actions using high-level tools. Lua scripts fit into the system by being types of "action", which can in turn trigger new events. Ideally, Lua scripts should be entirely stateless. If they need state, use state machines or perhaps generic "record"-type objects (e.g. character sheets) which are also components.

I'm not sure that this is the best approach, so please feel free to shoot this down.

croxis wrote:Basic UI layer -- Implement berkelium or some other html/css ui system (lets take advantage of our web developers)

We were talking about CEGUI as a first step. HTML/CSS is, I think, far too heavyweight for our purposes. But I'm happy with a declarative syntax that's like HTML.

croxis wrote:Basic Newtonian physics system -- Mostly as placeholder. Could use Bullet or some other premade solution just to get the ball rolling while the final physics system is being developed

Actually there's more than just Newtonian physics to think about. A player's controller is also a kind of "physics", and ensuring that the player doesn't go through a wall is a kind of "collision detection". That is the first kind of physics to implement.

croxis wrote:Basic collision detection -- Naive sphere based collisions is a decent placeholder. See above on using bullet.

I believe we have someone who is interested in working on this, but I can't remember who it was. I don't think that spheres will be good enough for the collision hull around a player, which is really the first use that we'll have. Axis-aligned bounding boxes might be more appropriate.
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Basic core engine

Postby lamogui » Thu Aug 29, 2013 7:43 am

Bullet physics is a good choice for 3D collisions AND/OR Physics, really easy to use
please correct my english errors
lamogui
 
Posts: 42
Joined: Mon Aug 19, 2013 5:33 pm

Re: Basic core engine

Postby adam » Thu Aug 29, 2013 3:14 pm

For math wouldn't glm be a decent choice as it is designed for OpenGL and GLSL inherently.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Basic core engine

Postby croxis » Thu Aug 29, 2013 3:17 pm

Pseudonym wrote:One of the reason why scene management is going to be a little bit complicated in Trillek is the way we want to handle ships and planets. We are modelling planets using one mechanism (voxels or something) and the interiors of ships using another mechanism (probably rooms connected by doorways). Different types of environment are modelled and rendered in different ways.

But sometimes you're inside a ship sitting on the planet surface, and can see the planet outside the window, and sometimes you're on the planet surface looking at the ship. This means that different types of environment can be "active" in a single frame!

It's not an insurmountable problem, but it will get a little bit subtle.


Would multipass rendering help with this with each pass being a different element?

We need to do some hard thinking about this. My gut feeling is that all components and systems are written in C++, and that Lua should be reserved for very limited tasks as far as the core engine is concerned.

What I envisage, is that the core engine manages three kinds of component which manage high-level behaviour: state machines, events and actions.

A state machine would be something like the Qt state machine framework, which allows state machines to be composed in a very clean way. Basically, you specify a finite set of states that a machine can be in, and the allowed transitions.

An event is something that happens when certain state conditions are met. For example, if a NPC enemy is in the "alive" state, and a player hits the enemy with a weapon, then an event is triggered. The event may then trigger some actions: a sound effect may be played, an animation on the enemy's mesh may be started, the health of the enemy may be decreased, and so on. Each action may in turn cause new events to occur, possibly after some fixed delay. For example, if the enemy's health reaches zero, then after the "hit" animation is finished, the enemy should transition to a "dying" state, which starts a new animation, different sound effect and so on.

Game designers can specify state machines, events and actions using high-level tools. Lua scripts fit into the system by being types of "action", which can in turn trigger new events. Ideally, Lua scripts should be entirely stateless. If they need state, use state machines or perhaps generic "record"-type objects (e.g. character sheets) which are also components.

I'm not sure that this is the best approach, so please feel free to shoot this down.


I'm not disagreeing I'm just looking for clarification (mostly for my own education)
My understanding of a "pure" ecs (from the t-machine article) is that components just hold data and have no functions of their own -- their internal states are read/written to by the appropriate systems. That being said two ecs systems I've seen (unity and spout) have convenience functions in the components. I understand the need for a more pragmatic design though.

An event system is also obviously very important. The Bukkit server mod for minecraft adds events and listening system into minecraft. Plugins written for bukkit then adds the appropriate methods to listen for a given even, evaluates if it should act on it, then modifies the game behavior. Plugins can also add their own events to the event system. While I know the engine isn't being made to be a general game platform I do invision that the engine itself only defines a limited sets of events and that the vanilla mod/plugins will define the bulk of it. While the DCPU is very cool and has a decent community around it, I can totally see a larger dev community form itself behind making plugins as lua has a lower barrier to entry. The forge mod system didn't really develop into maturity recently, before then hmod/bukkit plugins were and are driving forces that helped grow the community behind the game. But I am digressing.

croxis wrote:We were talking about CEGUI as a first step. HTML/CSS is, I think, far too heavyweight for our purposes. But I'm happy with a declarative syntax that's like HTML.


Fair enough. An html/css/javascript system probably works better with more complex UIs like what the planetary annihilation guys need. I would push for it more if we had some sort of high tech hud (an in game google glass) or if the in game monitors outputed to a svga type resolution.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Basic core engine

Postby Metaluim » Thu Aug 29, 2013 4:33 pm

So under this system, the server would be a sub-system and not a separate process? If so, does this mean that for people who just want to host a server they have to launch the game?
Metaluim
 
Posts: 11
Joined: Sun Aug 18, 2013 8:52 pm

Re: Basic core engine

Postby tecywiz121 » Thu Aug 29, 2013 4:35 pm

Metaluim wrote:So under this system, the server would be a sub-system and not a separate process? If so, does this mean that for people who just want to host a server they have to launch the game?


You'd launch the game executable, but in server mode. Since there wouldn't be a need for a GUI, it wouldn't be loaded.
User avatar
tecywiz121
 
Posts: 36
Joined: Tue Aug 13, 2013 12:23 pm

Re: Basic core engine

Postby croxis » Thu Aug 29, 2013 6:49 pm

Right.

So a simple example:
There is a opengl render system, server network system, client network system, physics system, dcpu system*, player input system, and an ncurses-like server gui system.

For a server only the server network, physics, dcpu and the ncurses system is loaded into memory. The server knows it is a server so only it can creates entities and components.
For a client only the opengl, client network, player input systems are loaded. It will also load physics and dcpu systems as well. The client cant create new entities or components, but can request it from the server (such as when the player builds a new ship). The server will send the client only the entities and components it needs to know so the client has a local copy. The physics system and dcpu will then only be running what the client knows for client side prediction.

For server and client (single player) all systems but ncurses are loaded. For physics the client still requests changes to the server, and the server modifies the physics components, but the client can directly reads the physics system (so there is only one physics engine running instead of two if you ran and client and server seperatly on the same machine). This sharing might be vital with voxel data, which is usually very large in ram, so we would try to avoid having two copies.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Basic core engine

Postby Pseudonym » Fri Aug 30, 2013 1:38 am

adam wrote:For math wouldn't glm be a decent choice as it is designed for OpenGL and GLSL inherently.

GLM is a decent choice, but it has several problems. Rather than badmouth GLM (it is a decent library despite its weirdnesses and quirks), I'll just note that its main strength is also its main weakness: it's inherently designed for OpenGL and GLSL, which means you need to do as much work to interface it with anything else (e.g. a physics engine) as it takes to just write the operations you need in the first place. It's just not that hard to write fixed-size matrix multiplication.

Having said that, GLM might be useful within the GL-specific subsystems, especially when it comes to shaders. I'm not ruling out using it, but I'm not planning to unless it's significantly more convenient to do so than rolling one's own.

croxis wrote:Would multipass rendering help with this with each pass being a different element?

That's certainly an option. In the case of being inside a spaceship looking out the window, for example, you could treat the window as a portal, then simply render the terrain using that as the frustum.

Like I said, it's not conceptually difficult, just a bit subtle.

croxis wrote:My understanding of a "pure" ecs (from the t-machine article) is that components just hold data and have no functions of their own -- their internal states are read/written to by the appropriate systems. That being said two ecs systems I've seen (unity and spout) have convenience functions in the components. I understand the need for a more pragmatic design though.

Do you have a link to that article?

I don't see a problem with either approach in principle. Whether you tell a sound effect to play itself or get a sound effect which you play... it doesn't matter to me as long as we stick to one. However, I can certainly imagine that some components may have to make some decisions which require logic, like deciding whether or not the enemy and the player have line-of-sight.

Having said that, if an object lives both on the client and the server, it makes the most sense if the object is pure data with no state-transforming behaviour.

croxis wrote:While I know the engine isn't being made to be a general game platform I do invision that the engine itself only defines a limited sets of events and that the vanilla mod/plugins will define the bulk of it.

I agree with that. Moreover, the events/actions which the engine natively "knows" about will be very low-level, like "the player took a step forward" or "play a sound effect".
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Basic core engine

Postby NekelLuna » Fri Aug 30, 2013 2:09 am

Personally, I agree, and I think that components should start to be put up into the Git repos, with locations for the different components set. I think that if we have code being written, and a bug tracker list (and/or todo list), we can get more traction on the project itself. That way, we can show people who want to do art assets that we have stuff, and can get them to get a move on. I don't want to be all like "well, we should just code and let the design figure itself out." because that's a stupid way of doing things. But, by having some code, and rapidly designing in a modular way (as you suggested) we can mitigate problems that could arise, such as redesign of sub-systems to be more efficient.

Base line- less talk, more code. We're not a game company where we can afford the luxury of taking 3 man-months to perfectly design this (which would be ideal).
NekelLuna
 
Posts: 9
Joined: Mon Aug 19, 2013 10:32 pm

Next

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron