Shooter game demo

TL;DR: I made small fps game, check link for download.

Hi folks. For some time I’ve been working on a few tools with the intention to make FPS games.
More specifically I wanted to make retro style “Boomer shooters”, similar to Doom or Quake.
I opened this thread to share some ideas and a small playable tech demo.

Level Editor:
The first tool is a level editor inspired by the Build engine editor and Doom editors.
I had a lot of fun as a kid making levels for duke3d so my thought was I’ll be more likely to find the motivation to create levels if I’m comfortable with the tool. In retrospective I could have became an expert in blender by now, but this is my hobby and I enjoy programming, using blender, not so much.

The result is M8 Editor. The worflow is simple: draw sectors in a 2D top-down view and adjust height, slopes and textures in a 3D view.
The editor is not specific to my game but is quite focused in dungeon-like levels, so not very good for open scenes.

Some featues:

  • Negative space 3D modeling
  • Sloped floors and ceilings
  • Room over room (sectors can have platforms)
  • Navmesh generation
  • Lightmap baking
  • Extension points


Game logic engine:
The other tool is an engine/framework for the game logic. I had the unconventional idea to experiment with akka-actors.

Actors is a concurrency model in which an actor is a component that encapsulates state, like an object, but unlike OOP an actor can handle only one message at the time and only one way async messages are supported (in contrast to methods with return values). And so there’s no need to synchronize state. Akka is a scala and java framework that implements this model, the framework decides how to assign actors to threads and queue the messages.

Cpu intensive tasks like physics and pathfinding are modeled as actors that run concurrently. Also each entity of the game becomes an actor that contains the state and the behavior of that single entity.
The entity actors publish their state (transformations, animations, etc.) and this is synched to the scene, so the scene and the game logic are completely decoupled.
This can lead to some complexities with determinism, because each entity is async if one entity lags behind processing a tick of the simulation the others wont wait and will keep running. Since I wanted to make action games I’m not so much concerned with that yet, but I think it can be dealt with by making the entities ack the ticks before sending new ticks.
I found this programming model quite nice for making simulations and I think is a good match for games.

Each entity is an actor however it’s behavior is implemented by a groovy script, each script is a class that can override methods to interact with the world (detect collisions, send messages, move, die, etc.). Very convenient albeit limited to what the api provides.
In a similar fashion weapons and particle effects are defined in scripts.

Groovy is great for creating domain specific languages (e.g. gradle), I used it to make a DSL for defining levels and their entities very easy, more flexible and readable than with json or xml.

Like those old games I want to support modding from day one so by using the same tools a modder would do I can make sure new levels, enemies or even “total conversions” can be created later on without compiling the core, just pack the levels, models and scripts in a jar and add it to the classpath.

I made a small tech demo project to test my progress so far. I made an almost exact copy of Doom’s E1M1 using my editor, I used this as a benchmark and I managed to do it without major difficulties (except for many bugs I detected and fixed along the way).
The rest of the assets are free assets I had laying around, so there’s no consistent art direction, just what I had at hand. In any case I seek a similar level of detail for my game, that’s why I used the legacy shader and static lightmaps, there’s some nostalgic appeal about that.


There are several things I want to improve but I feel I’m ready to start a new game project based on this prototype.
If someone wants to give it a try I appreciate some feedback (specially about bugs, performance and general game feeling).

Here’s the link: Dropbox - fps-game.jar - Simplify your life



Is the source code available?

The source of the level editor is available here: Juan Cruz Fandiño / leveleditor · GitLab
Unfortunately I haven’t written any documentation yet, but I’m happy to help anyone who wants to try it.
I think it is usable although it might result in unexpected results if not aware of the current limitations.
The code is in scala btw, but I’m not a professional scala developer so it’s not very idiomatic and should not be hard to understand.

EDIT: I noticed the download link doesn’t work, I’ll fix later today.
EDIT2: Didn’t manage to upload the jar using gitlab’s CI, here’s a link to a local build for now: Dropbox - level-editor-210110.jar - Simplify your life

I’ve not released the game framework yet as I don’t think it would be very useful because it’s limited to my needs, also it’s very experimental and I wouldn’t advise using it, at least until I can validate it making a more proper game. I also don’t want to maintain backwards compatibility when making changes.
However if there’s interest I can try extracting key elements (actors, dsl, scripting.) into other projects so people can copy the patterns if they want to try them.