Competitive Online RPG Prototype – #003

Square

Long time no post! Main reason is that lots of background coding and cleanup has happened to prepare for bigger changes and the playtest. But now the game has advanced a bit and I feel that it justifies another post.

State Of Development

  • There is now a lobby level with class select and simple game settings (such as maximum points to win, map, team select and so on)
    • Players can also use “Find Match” instead of the server browser, theoretically this makes it possible to do matchmaking. Though it’s just a basic implementation at the moment.
  • The HUD has been improved
    • still looks crappy, but more functionality
    • target widget now shows selected player’s name and team; removed energy widget
    • there’s a chat in both lobby and gameplay modes 
    • Skills are actually clickable and have working tooltips
  • Map visuals have been adjusted. For the first playtest, I am aiming for a night scenario. This is just me playing around basically (see header image)
  • Skills now have proper animation loops(with placeholder animations) and VFX
  • Additionally to keyboard movement, click to move with pathfinding was added (though not optimized at all)
  • Lots of performance fixes and networking improvements; mainly by reducing the amount of update calls and postprocessing done, but also by simply fixing crappy blueprints!
  • Closed some holes in the net code; clients were able to call certain functions they should not be able to call.

Game Lobby and Menu Updates

Epic Games released a very nice tutorial series on their YouTube Channel where they are implementing basic multiplayer functionality. I have promptly gone through all of these and implemented it into the game!

Lobby Screen
Class Select window during lobby phase

Now, additionally to the server browser, players can find a match via a simple button press. Hosting now enables you to name servers and do basic set ups such as maximum amount of players. During the lobby phase, all players can select their class and team. Hosts can then edit the game’s details, kick players and start the session.

Players are also asked to create a simple profile before starting the game. For now, the values will be stored offline because I do not need any login functionality for the first playtest. Later on this will probably be replaced through a proper database and login system, though.

The timing of the tutorial series was really fortunate. I was planning to add this functionality anyway. This made it really easy, though.

 

Gameplay Updates

Gameplay wise there were not a lot of changes because I focused more on background stuff and UI/HUD. I want to have these things out of the way so they do not disturb development in the future. I know it’s just a prototype yet, but I want to keep things as reusable as possible.

Click to move was also added to the game. It works pretty well so far – you can take a look at it over here!

Visual Updates

The HUD has been improved a bit to make it a bit more readable and cleaner. It’s not a big change, but I think the HUD is a lot less horrible now.

Gameplay HUD
HUD is actually readable now! Hooray!

Other than that: Proper animations! Yaay! Although the first version of it looked … weird. Basically, I am using an animation montage. The character’s animation blueprint goes into the montage when the player activates a skill. In the first version, there was an animation-intro, a loop-animation, a finish-animation and an animation in case the player got interrupted or cancelled the skill. The result is choppy blending and overall does not look too well.

After some tweaks, the current version looks a bit better. Instead of having a seperate animation for each seperate step, the system is now using two animations in total: One animation split into different sections for the cast, and one animation for the interruption. The blending works much better and with the help of a fixed damage point per animation, I am able to ensure that the animation will reach it’s peak right at the end of the cast. This results in a much better look, but also requires hand-crafted animations. The current placeholder animations from the free mixamo package are not really built for this, so the result looks off.

But with the help of a skilled animator, there will be smooth casting animations in the future!

You might have noticed the added VFX in the link above. Skills now play particle effects on their target. Theortically they can also play them on the caster, but I have not added one yet. Overall these two steps help a lot with the game’s feel. It almost looks like a game now!

What’s Next?

I still am improving the skill system to be able to do all the skills I need to do. I have a list of skills that would create fun dynamics even with just three playable classes, but the skill system is not up to the task yet.

Top secret!1
Top secret!!1

In order to improve the current blueprints, I will move the current system to a more “data driven” system. Right now everything works with blueprints and all data is handled at runtime and inside the skill’s event graph. Instead of having all the data directly inside the blueprints, all data will be stored in a relevant structure, and the skills’ values handled in the appropriate table. This not only allows better overview over all the skills itself, but it also allows to get data of any given skill during runtime and apply modifiers from effects, who are going to use a similar data structure, more easily.

Basically right now the way things work is: A skill is casted once, checks if it can be casted through the PreCast function, returns the result to the casting player and on success, the skill is spawned again with proper parameters. This means for every skillpress I have to spawn the respective skill twice. Also, any modifying effects are done by communcating between skill and effect which should not be the case.

A new approach with everything structured into data tables is simpler: Whether a skill can be casted or not can be done by simply looking at the data table, executing the skill can still be handled by the blueprint, and applying modifiers from any running effects will be handled by an overlaying skillsystem through interface calls. It will create a bit of a mess to resolve all the necessary parameters, but in the long run that is easier than trying to hack everything into its own blueprint logic. The system is not yet ready, but I will finish it until late August together with the proper skill visuals, so that all planned skills can be implemented and a playtest can be done!