Jump to content
  • Announcements

    • Fright

      Open Q&A   12/03/2017

      Hello guys, We decided to have an open Q&A thread for you guys to ask us questions. Me and @Shields will be the ones to answer your questions. Feel free to ask anything and we'll do our best to provide an answer. Go to the Open Q&A thread >>
Sign in to follow this  
Fright

Development Blog #2 - Enhancements, UI's and issues

Recommended Posts

fyg22iN.png

Development Blog #2 - Enhancements & Contributions

Welcome to our second devblog. We're happy to share the things we have been working on for the past few weeks.

 

Team additions, welcome new developers!

Let us welcome two new staff members who are also members of our Development Team.

  • @Jan who was around since 2012 and was leading the development of LC:RP and V: Role Play in 2015, is back with us again. He will be slightly less development oriented and will be responsible for our Development Operations (DevOps), such as servers, automatic deployment, security and services. He will also act as an infrastructure consultant as he possesses a lot of experience in the low-level architecture field. On a personal level, he works as a Software Engineer for a big technology corporation in Berlin, Germany.
  • @RanST who was also a staff member back in 2014, when we were working on LC:RP. He will do development on both client (UI Overlay) and server sides, but mainly UI. He is a very talented developer and specializes in front-end development in his career. Ran works as a Software Engineer in a technology company in Amsterdam, The Netherlands.

Although it's great that all of ours developers are either full-time Software Engineers or Engineering/Computer Science students, we are still looking for more developers who are willing to join an environment full of knowledge and professionalism. We encourage developers to check out our recruitment threads and reach out if they are interested in joining our team!

Clientside Scripting - custom event handling library for V: RP

The past two weeks I've enhanced our internal library for handling communication between the CEF instance (overlay), the client's V8 engine and our gameserver. This was not absolutely mandatory, but (without going too technical) the communication method between those parties provided by RageMP is very basic and does not scale very well (it's not meant to).

I took the tools that RageMP provide us and created a library that is currently closed-source (considering making it open-source as well), that simplifies the way you communicate between those parties. The implementation makes it very natural for developers to perform UI operations that are dependent on the server as well. For example, if you send money to another player, the player will then be prompted to accept it. There is a lot going on under the hood (on the server's side). The main problem is the asynchronous nature of almost any action in game, the server not knowing exactly what happens when.

Let's take the example of sending money to another player. These are the steps:

1. Verify that the sending player is near the receiving player, and that he has the amount of money he's trying to send.
2. Display a popup to the receiving player, waiting for him to accept.
3. Once accepted, next step. If rejected, show a popup to the sending player, notifying him about the receiver's rejection of the request.
4. Remove the amount of money from the sending player, add it to the receiving player.
5. Display a notification to the receiving player about his new money addition, same for the sending player.

Those actions are almost always followed by some UI feedback, and that event pipeline is very hard to maintain with the default event handling methods provided to us by RageMP. The library makes it way easier to handle.

What does it mean for you? It means that we have a solid system to build UI feedback upon. The amount of time that this is going to save us in the future is impossible to describe. You will be able to see that as soon as we start focusing on more UI implementations.

More technical stuff for the technical people:

Spoiler

 

What the system does is basically map the events and their responses into Promise. It's also possible for parties (overlay, server, V8) to subscribe to certain events (for example, when a friend is logged in, show a notification), in which case the events are mapped into an Observable.

I've also implemented a new concept called Operations. Operations do stuff. Operations will eventually contain most of the business logic of a certain action. So if you type the command "/pay" or you use the UI to send the money, both methods are eventually triggering an operation that does the same things (validating your permissions, money amount etcetera). The big advantage of Operations, is that depending on where they were triggered from, they will have different error/success handlers. So if you pay somebody via the command line, and an error has occurred, you will receive an error to the chat box. But if triggered via UI, the feedback would appear wherever we want it to appear (error popup, for example).

This is basically applying the concept I was talking about in the first development blog, where you can trigger a certain Operation from either the command line, the UI or even our UCP website! The concept of Operations and the above described event handling system work together in harmony. 

 

Login Screen & UI Overlay Infrastructure

After designing the system described above, I decided it's time to put it to the test. What better feature suits a test more than the login screen?
Since it already existed as an operation, that was previously triggered by a command ("/login"), let's see how well it all works together. It all turned to work out like a puzzle, and within no time we had a functioning login system. That verifies our vision that features should first be implemented as command-based features, and when we have the time (and priority), we can enhance them into UI views.

This took us more time than expected, due to the reasons described in the next section.

Please bare in mind that this login screen was made in the last day before this dev blog was posted, and it's NOT final!

Our login screen:

Spoiler

unknown.png

This one issue. RageMP is immature, and we accept it.

As I described before, V: RP's implementation on RageMP consists of three layers: the gameserver, the client V8 engine and the CEF instance (overlay).
Communication between the server and the player's overlay (in the current setup) must go through the client's V8 engine, hence we refer to it as "the middle man".

For the sake of good order (and from real life experience of most of us), we write our code both on the server and on the overlay (Angular) with a technology called TypeScript. This code must be compiler into JavaScript, which eventually runs on the gameserver/client V8/overlay.

For the server and the overlay, everything is fine. Compilation process from TypeScript into JavaScript is not a problem. However, many parts of our code are modular and reusable (we maintain shared modules in our code repository, to prevent writing the same code twice). However the module resolution system of the client V8 engine doesn't work as expected. I've spent quite some time this week attempting to find a fix, and it was blocking me from proceeding with the things mentioned above.

The RageMP team has confirmed that this is indeed an issue and it should be fixed, but I did not have an idea of how long it would take to fix it, therefore I started looking for an alternative solution (which I found), and I also reported the issue (and the solution) in RageMP's issue tracker and Microsoft/TypeScript's official repository as well. Right now, this is not blocking us anymore.

Deep dive into containerization and continuous integration/deployment

As we have a testers team and we start developing more features, I had to start looking into automating our deployment system for testing. The ideal way I want it to work is that once a feature is ready, it will automatically be deployed to a test server where testers can go and test it. This way, developers don't have to spend any time manually setting up servers.

I've learned a lot about the world of containerization and I already have some neat ideas on how to improve our server's performance by taking advantage of containerization and microservices. This will need more planning, and is not my top priority though.

The little things

Those little things that don't deserve their own title:

  • @Jan has implemented SSL certificates (https) to some of our services. We are also planning to apply it to the forum and eventually any service that we have, because security is key!
  • @RanST is going through on-boarding and will start rapid development soon.
  • @HBTV will finish his orientation around Angular and will be able to contribute to UI development as well soon.
  • I will be done with a semi-intensive language course that I am taking in two weeks, then I will have way more time to dedicate to development.
  • @Viccie started working on the Factions system. Basic operations such as creating, removing, managing ranks, inviting and removing members etc. are already existing. We'd rather post more about this at a later dev blog, when we have a fully-featured feature documentation and presentation.
  • We had a multi-team staff meeting in which we discussed key matters of the community, set milestones and key features that should be present upon release. @Shields will post more about this meeting in the upcoming devblog after processing the input given by the staff members.

RageMP 0.3.2 has been announced!

Check out the official thread posted by the RageMP staff team.

________________________________________________

That's it for this week! Leave your comments below to show your support and tell us what you think.

  • Like 6

Share this post


Link to post
Share on other sites

Very nice devblog again! We've all made great overall progress and we'll do the same for the next devblogs :) Stay tuned everyone!

Share this post


Link to post
Share on other sites

The detail in the dev blogs are brilliant, everybody working hard! 

Edited by Kellerman

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×