joonsey/ngn

Another Game Engine

Just another rudamentary game engine to experiment with rendering pipelines in OpenGL.

Quick start

Options

• run with built-in local server

  build/ngn --local We can run with a built in server on a seperate thread, this is just quick way of hosting. The game will also share some memory with the server

• join a target server

  build/ngn --join <ip> To join a server you need to target a valid ip address

• host a standalone server

  build/ngn --server <ip | optional> To host a standalone server without a game client you can run this command. omitting the ip will default to loopback interface, which is likely what you would be running on anyway.

Pre-requisite

Linux

We use raylib in the backend NOTE: remember to build it so that it can be dynamically linked

git clone https://github.com/raysan5/raylib.git raylib
cd raylib/src/
make PLATFORM=PLATFORM_DESKTOP RAYLIB_LIBTYPE=SHARED # To make the dynamic shared version.
sudo make install RAYLIB_LIBTYPE=SHARED # Dynamic shared version.

to compile and run the engine

./build.sh && build/ngn

Windows

Windows build does not statically link raylib, recommend using x64-mingw-gcc, alternatively you can compile a binary using the docker image in .Dockerfile

Debugging

The build.sh file builds with debug symbols so that you can run ./build.sh && gdb build/ngn if you want to run it in GDB. This can be nice, also particularly because we often times want to hot-reload the engine while testing. (Keep in mind there are some clear limits to the hot-reload feature)

NOTE: If you find it annoying to leave and enter gdb everytime, you can build and source the new binary from within gdb as well

gdb

shell ./build.sh && file build/ngn

Logging

At the moment the best way to change logging is to change the LOG_LEVEL in the logging initializer in src/main.c

	initialize_logging(NLOG_LEVEL); // log level is lowest level logged, inclusive

ngn's Issues

MAP_DATA optimization

reduce complexity of the server information we send through the
network. It can be vastly simplified to just ID and position. This will
allow us to send many more rooms before having to fragment them in the
packet. (from 64 bytes in size down to 12 byts)

Byte order in networking bytes

At the moment we don't convert from hton and ntoh on any of the numbers in our data.

We might not need to? although there is documented conflict on the byteorder between linux and windows. We can await and see if this becomes a real problem!

If it does, we need to explicitly convert he byte order on network transfer send, and receive.
This will have to be done for each property on any struct which is why i am currently ignoring it. Problem for another time!

archive build breaks on build_tiles_and_walls

results are varying, looks like there is an inconsistency with memcpy on the build from the pipeline

refactor build system

We should reconsider the build and probably build most of our code to shared libs and link it together instead

Tiles

Versatile tile system

We want to have a lifecycle for the tiles, that means a create, update, render and free for tiles.

We know that tiles are contained within rooms and that they should be created upon creation of a room.

For now the tile is very simple and is a struct purely consisting of TileType:

typedef struct Tile {
	TileType type;
} Tile;

We may need to store the position of the tile, to check for collision. We can also infer from the TileType whether or not the tile has collisions or we can store it on the tile.

Alternatively we can store more of this data on the Entity struct and revolve more around a entity system.

typedef struct Entity {
	Vector2 position;
	Texture2D texture; 
	Texture UV_texture;
        bool can_collide;
} Entity;

typedef struct Tile {
	TileType type;
	Entity e;
} Tile;

This should be stored in it's own file named tile.c / tile.h. similar to the room.h / *.c

Up to you though!

exit cleanup

We want to send exit / disconnect signal to our server at exit,

we can set up a atexit hook to do this, as well as perhaps handling whether it is unexpected or not

refactor network code

goal

• distribute responsibility
• isolated imports / headers
• split server and client code

projectile on server side

rendering fault when moving

Striping effect when moving;

We think it is a floating point approximation error.
To reproduce just walk around the tiles a bit.

first player to join doesn't project state in packets