Another hiatus since October 2019. But I keep coming back so thats good. Here is another quick update.

Procedural Generation

In the previous dev update I talked about how the game would feature server side procedurally generated dungeons. Meaning that the server would pass down to clients what the current dungeon looks like. Players would then be able to join the same dungeon and every X amount of time new sets of dungeons would be generated.

So far…

I’ve completed the both initial server and client side implementations. Meaning that the system is working end to end. In a high level view the usage happens something like this:

1. After X amount of time the server creates a set of new dungeon template using predefined parameters.

Server logs

2. When a player walks into a dungeon its notified by the server that it is entering a new instance. It receives a small package with the template information, it basically specifies what rooms the client has to load and how they should be placed.

Client logs.

3. At this point the server has generated an instance of the dungeon and placed the player/s in there.

Zoomed out screen capture of the player inside the dungeon.

And thats it. All the systems needed are roughy in place. But I’ve not decided on a lot of specifics yet so I’ll be tweaking them as I go. I expect theres a couple of challenges I’ll be facing down the road. For example, if I have 100 players entering a dungeon how many instances of the dungeon should I create server-side and how would player share a dungeon instance. Instances aren’t cheap, since each of them hold X amount of monsters that the server has to process for. This kind of challenge is specifically tied to the game design and how the game is gonna play so I have to make those decisions before I’m able to tackle it.

References

Not a lot of new articles I used for this part. I mostly just went with my gut. I do, however, want to share a bit of how I’ve using Tiled to help debug and create rooms in a generated dungeon.

I used the world feature in Tiled to generate a json file for any generated template. This allowed me to open multiple rooms in a single window and work on real generated maps.

Tiled with multiple map files

What’s next?

I’m planning to work on figuring this out. I want to write up a plan for next steps and figure out how the first playable version of the game would look like.


Subscribe to my newsletter

Remember to subscribe to receive monthly updates about Clash Legacy!

It’s been a while since my last update but here’s a quick one on some of the progress I made this week on procedural generation.

Procedural Generation

Since the game is meant to be a sort of Rogue-like MMO having procedurally generated dungeons is what I have in mind as the most core feature to the game.

So I’ve devised a system to generate a sort-of room-based dungeon template on the server side that can be easily passed down to clients. The idea is to create (by hand) different types of rooms that can be stitched together using the template. The rooms can vary in shape but they most all have the at least one door. This is a simple method of generation that has its pros and cons.

Pros

  1. Passing a dungeon template between Server and Client is very easy.
  2. Having hand-made rooms can guarantee high-quality
  3. It can be easier to manage.
  4. It’s faster than other methods.

Cons

  1. Dungeons can feel repetitive if there is not enough room variety.
  2. You have to.. well.. manually create the rooms..
  3. Rooms have a maximum size.
  4. More room types increase app size.

I believe I can address the main cons by simply creating many room types but also by adding certain procedural elements which can reduce the amount of work and increase variety.

So far…

I’ve finished version 1 of the template generator. It can take in a couple of parameters which can be used to change the end result, including:

  • max horizontal and vertical size
  • min and max room count
  • probability for a room to merge to adjacent rooms
  • breadth or depth first, etc.

I used some unicode symbols to output the result in action and it looks something like this:

Procedural generation of dungeon template

References

When I was starting with PCG I found many complex articles which was a bit overwhelming. I found this video tutorial for a very simple dungeon generation that was somehow similar to what I wanted. That implementation however, is very limited and not that great in my opinion but it gave me a lot of good ideas that got me started.

I also found this site which has large list of good resources that I highly recommend. I’ll be coming back to it as I progress further into my dungeon generation.

What’s next?

For next update I’ll keep working on this procedural generation. Starting with creating some of the base room types and stitching them together in the server using the template generated.


Subscribe to my newsletter

Remember to subscribe to receive monthly updates about Clash Legacy!

This is a small and quick update of the progress from the past few weeks.

  1. Combat Feel
  2. Game Design

No flashy images or videos this update but take a look at my twitter on some of the most recent action. @chronowax

Combat

I spent a bunch of time playing around on combat feel. I worked on implementing different features to make sure the game play would feel good. I felt that this is a really important aspect to start on early on as most game mechanics will basically revolve around it. I want to make sure combat feels fun and fair, specially since it’s meant to be played on mobile.

These are far from final, but some things I implemented include:

  • Hit/Attack sounds
  • Damage numbers
  • Screen shake
  • Health bars

Take a look at Jan Willem Nijman’s talk on game feel to get a good idea on things that can improve the game with little work.

Game Design

Once I was happy with the progress on combat I decided it was time to actually design the game.

I’ve always had this crazy idea of what the game is gonna be. A Rogue-like MMO game. I’ve had a rough idea on many of the mechanics the will make the game shine since the beginning but I’ve not defined them fully. So now I’ve started working on defining all game mechanics that I want for release.

I’m using Dropbox Paper to create multiple brainstorming documents for all main mechanics of the game. I’m not ready to share details on them yet, but my plan is to fully develop the features and come up with an execution plan and stricter deadlines.

I’m gonna take a couple of weeks working on this to make sure I’ve got a solid foundation. I’ll likely start working on the game’s main feature procedurally generated dungeons.


This past few days have been kinda slow, considering that I only work on the game during my free time and it’s been mostly limited to the weekends lately. My actual job has got me working on some interesting projects with some tight deadlines, so most of my energy has been focused there and I don’t want to burn out.

Slowly but surely, the game is being built.

It’s been over a year since Dev Update #5 and although its a big jump in progress since then, I mostly took a break from game development and focused on other things for a while. With that said I’m back working on this and this update focuses on the following:

  1. Movement
  2. Combat System
  3. Particle System

Movement

I revamped the movement system and it now works much better. I used to try to predict all entities movement in the client via different information (who the monster was following for example). But on medium to high latency connections this would cause a lot of de-syncs between Client and Server entities. I changed it so that the position shown in the client is completely based on the position simulated in the server. Since the client is simply imitating the server now, de-syncs are a thing of the past.

I still do some entity client prediction, specifically for inertia. When an entity is pushed I simulate inertia individually on the clients (as well as on the server) and compensate a bit later. So it’s technically still possible to have de-syncs as like those seen in the older videos, but it’s very rare and less distracting. I plan on doing more optimizations, like lag compensation, as they’re needed.

If you’re more interested, take a look at Gabriel Gambetta’s Fast-Paced Multiplayer series. It was very helpful to understand the best ways to implement movement on this type of games. Take a look at his live-demo.

References

Combat System

Previously I only had some attack animations for the player entities, but these did no damage. I’ve started working on the combat system and now entities can damage each other.

I foresee this system will increase in complexity to cover the combat types and variations I have planned. Currently melee attacks are working. The way I envision it is having multiple weapon types for the player as well as attack types for the monster entities. So I developed it in a way that supports varying:

  • attack ranges
  • attack frames
  • attack animations
  • cool-downs
  • interruptions

I won’t go too much into details of the implementation but at the moment I do simple hit-box checks on client and server based on the different attributes. A players attack is calculated in their client, but verified by the server.

The red boxes are the enemies hit-box as simulated on the server

Particle System

I decided to implement this early on to test out to what extent I can use it, as in for animations or attacks. LibGDX supports particle effects so I’m utilizing their editor and framework for it. I made my own system to suite my needs. Wayward Souls does a great job of utilizing particle effects for attacks and ambiance.

Prototype dust, attack and blood particle effects

What’s next?

For Dev Update #7, I’ll probably do more work on the combat and status systems (attacks, health, deaths, etc…). A lot of tuning on combat to make sure it feels nice and snappy. More tweaking with the AI to make sure the fights feel fair and fun.

I’m planning on making 2 other separate posts:

  • Touch-screen Joysticks
  • Workflow optimizations

Subscribe to my newsletter

Remember to subscribe to receive monthly updates about Clash Legacy!

This update is still focused on NPC’s movement. I’ve been making tests on how the movement system should work around the limitations of a server to client connection. NOTE: The videos shown have some level of induced lag, to simulate a low connection session.

  1. Debugging
  2. AI movement

Debugging

Debug HUD

I made some updates to how I render debug lines and debug information. Specifically, I setup a specific HUD for debugging which I can enable and disable whenever I need. I used LibGDX’s GLProfiler to include information about the rendering performance, such as number of texture bindings per frame and other information. Additionally, for my development environment I’m sending server information every frame to be able to compare what the actual information will be.

AI Movement

I’ve been looking into pathfinding for a couple of weeks now. After some research I tested out a simple implementation of A* algorithm and then did more research into other pathfinding algorithms that might work better for this type of game like Theta*. I then did a different type of research, I went and played similar games to test out how they handled AI movement and collisions. I opted to put a pathfinding implementation on hold for the moment and go with a dumb follow movement from NPCs. The idea is to later combine this with different spontaneous movements per monster type to improve gameplay.

Using a simple follow mechanic I am able to guess at the current position of an entity in the client. This heavily saves data and performance. It allows for smooth and responsive movement on the client side but also introduces the possibility of a desyncif the client has a bad connection. So I introduced a sanity check that corrects an entity’s position. I still have to do further testing to see how it actually plays out with many users and varying latencies.

Before/After of a fix on a speed desync

References

What’s next?

I’m gonna keep working on this and on collisions. I believe collisions can be a big part of the gameplay, and having them work correctly and fun important. So I’m gonna be working heavily on that.

I also want to do monthly reports to visualize the time I’ve spent on development and other interesting bits of data I’ve gathered by using RescueTime. So keep a look out for that post.

Subscribe to my newsletter

Remember to subscribe to receive monthly updates about Clash Legacy!