I did encounter some problems with the design in my other engine used for the Top down shooter I was developing, mainly when trying to integrate multiPlayer. So I decided to rewrite it. I've now come so far that I'd like to post an WIP. I have thrown togheter a small "techdemo" MultiRoids an multiplayer asteroids like game, still without asteroids or shooting though
The Demo is attached below. It contains the Server and the Client executable so you can test it out.
Server is currently hardcoded to 127.0.0.1 so you can only host and connect from you own computer.
The engine consists of several modules. Most of the modules are decoupled from each other so they can be reused in other projects to.
- Creates and manages different game states. Menu, Game, Post game screens etc.
- Can pause states, switch state and resume states
A console system where you can type commands
- create and register custom consoleListeners.
The listeners then parse the commands typed and can react to them
- using ENet (http://enet.bespin.org/)
- Dedicated Server
- gets input frpm the players and handles all calculations
- distributes the needed information to the players
Logging & Profiling
- Write result to file or show on console
- can connect to databeses, run queries and return data
- Currently supported databases
FileManager & ResourceManager
- read, write files
- manage loaded media
- instance already loaded resources
- Signal & slots system, the guiComponents can emit signals eg. when clicked or on mouseOvers and functions can be connected to the signals.
- Several components: Buttons, Editboxes, comboBoxes, CheckBoxes...
-Buttons, Custom shaped buttons with collision detection
- All components can use different effects.
-fading over time
Component based entity system:
- All gameObjects consists of an entity that can have several components attached to it.
These components give the gameObjects their properties.
- Component examples:
- RenderComponent = the entity is assigned a mesh and is rendered
- PhysicsComponent = the entity is included in the physics simulation
- SoundComponent = entity can emit sounds
- HealthComponent = entity has health, can receive damage...
- CameraComponent, LightComponent, MovementComponent, AIcomponent...
- The components can communicate with each other. A component can send an message to the
parent (the entity) which then passes this message to all it's other components.
Then the other components can react to this information also.
A scenario to describe this.
The physicsComponent registers that the entity hit the floor with X amount of force, a message with this info (x,y,z + normals and force) is sent to all of the entitys components. The soundComponent receives
this message and plays a sound with a volume proportional to the force. The same goes for the healthComponent but instead health is decresed proportional to the force. THe FXComponent creates a smoke puff or
sparks at the collision point. The lightComponent can't/doesn't care about this info so it just ignores the message.
So if you combine an CameraComponent + movementComponent you have an observer like entity
that can move around
If you combine an AIcomponent + movementComponent + LightComponent you have a light that can move around or follow the player
Main menu, test with custom shaped buttons