Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Asteroid Project [HTML5, Angular, Node, Socket]

Initiate Mage
Joined
Apr 27, 2020
Messages
5
Reaction score
1
Hi guys, I recently started developing the Asteroid Project, which is basically Habbo in HTML5.

Client-side:

  • Pixi.JS (For Canvas Renderization)
  • TweenJS

  • Angular
  • Socket.IO
Server-Side:

  • Written in TypeScript

  • Pathfinder (A*)

  • Socket.IO
  • MySQL

Screenshot's:



Updates:
Rederization of the floors (Remake) [02/05]
Basic avatar movement (In progress)
GitHub: Very soon
Discord: mtwzim#7912
Bye!
 
Last edited:
Joined
Jun 23, 2010
Messages
2,318
Reaction score
2,195
Nice to see new developments poping up. We're are more interested about the stuff you've done so far. The post is quite plain and doesn't give much information about your project; other than the stack you're using/going to use.

Non the less, good luck! I hope to see more information "soon".
 
Junior Spellweaver
Joined
Nov 5, 2013
Messages
147
Reaction score
57
Nice, good work. i have some questions: How will you handle the communication server-client, (json, habbo's default)?
Is the pathfinder inside client for development purposes only or will it be on releases?
 
Junior Spellweaver
Joined
Jul 28, 2019
Messages
162
Reaction score
308
I feel like you should allow the server to handle the path finding, otherwise what will happen is...

Client runs an A* algorithm query to locate a path from A to B but also isn't blocked off by any of the stuff happening in the room.
Client sends the path to the server.
Server received the path, now server validates the path, doing the exact some process as above.
Server sends the path back to the clients.

It's just useless overload for something that can be done just once, on the server.
 
Initiate Mage
Joined
Apr 27, 2020
Messages
5
Reaction score
1
Nice, good work. i have some questions: How will you handle the communication server-client, (json, habbo's default)?
Is the pathfinder inside client for development purposes only or will it be on releases?

How will you handle the communication server-client, (json, habbo's default)?
JSON

Is the pathfinder inside client for development purposes only or will it be on releases?
The pathfinder will be on the server, sorry i was wrong when i wrote the post.



Why Angular over a smaller library such as Vue or React? Less overhead from Angular would allow for a better performance on the client itself
I really have no reason for it, I'm just very familiar with Angular and I think it can be as good as the other libraries (Although Vue and React are smaller)
 
Joined
Aug 10, 2011
Messages
7,401
Reaction score
3,299
I really have no reason for it, I'm just very familiar with Angular and I think it can be as good as the other libraries (Although Vue and React are smaller)

Its perfectly fine to use whatever you feel most comfortable with, if it results in a more speedier development then I personally think it it's better than picking a whole new toolchain.

I'm not too familar with the javascript libraries, would it be difficult to switch over? Are there any patterns you could pick that'd make it easier to switch? MVC / MVVM?

What is the blue pixel for?

89e3f3d73743e53947c658621d3efbb3 - Asteroid Project [HTML5, Angular, Node, Socket] - RaGEZONE Forums


I think you have a bug in your floor raster drawing as some lines seem twice as thick. Gotta be pixel perfect :tongue:
 

Attachments

You must be registered for see attachments list
Initiate Mage
Joined
Apr 27, 2020
Messages
5
Reaction score
1
Its perfectly fine to use whatever you feel most comfortable with, if it results in a more speedier development then I personally think it it's better than picking a whole new toolchain.

I'm not too familar with the javascript libraries, would it be difficult to switch over? Are there any patterns you could pick that'd make it easier to switch? MVC / MVVM?

What is the blue pixel for?

89e3f3d73743e53947c658621d3efbb3 - Asteroid Project [HTML5, Angular, Node, Socket] - RaGEZONE Forums


I think you have a bug in your floor raster drawing as some lines seem twice as thick. Gotta be pixel perfect :tongue:

Floor:
45917581e9bc5e5f6046ce30037c4279 - Asteroid Project [HTML5, Angular, Node, Socket] - RaGEZONE Forums
- I think the floor is still not perfect, but I made some improvements; * The floor is not a PNG image, I use PIXI.Graphics to draw.
Blue Pixel: This pixel is an intruder, this image is "static" from habbo.com.br, I still need to make an avatar move and consequently make my own avatarimage;
Change framework javascript, would it be difficult to change? (Angular, React and Vue): In the state of development I am in, it would be easy to change frameworks, but at the moment this is not my focus, angular is working very well with the needs.
 

Attachments

You must be registered for see attachments list
Last edited:
Initiate Mage
Joined
Apr 27, 2020
Messages
5
Reaction score
1
Actually the blue pixel served me for something, I found that the calculation that moves the player sometimes has small flaws.
 
Junior Spellweaver
Joined
Jan 28, 2013
Messages
157
Reaction score
104
Floor: - I think the floor is still not perfect, but I made some improvements; * The floor is not a PNG image, I use PIXI.Graphics to draw.

Habbo actually DOES use an image for the floor tiles. The plane parser creates a bunch of rectangles (100+ if needed), places this image: on top of it, then skews the rectangles to appear isometric.

Also to add, even the door is an image that is then made transparent:
 
Initiate Mage
Joined
Apr 27, 2020
Messages
5
Reaction score
1
Habbo actually DOES use an image for the floor tiles. The plane parser creates a bunch of rectangles (100+ if needed), places this image: on top of it, then skews the rectangles to appear isometric.

Also to add, even the door is an image that is then made transparent:
Interesting, I'm still working on the floors with PIXI Graphics, something happened in the code that some floors are on top of each other and the click sometimes went to the wrong floor, this was the main reason for removing the floor images. In addition, I'm also working on the avatar pathfinder.

[video]https://i.gyazo.com/8041234cbe35d8560679f65bf817a64a.mp4[/video]
mtwzim - Asteroid Project [HTML5, Angular, Node, Socket] - RaGEZONE Forums

I really need to make the avatar animations and also finish the pathfinder, currently it does not move correctly in all directions.
 
Junior Spellweaver
Joined
Nov 5, 2013
Messages
147
Reaction score
57
about the json communication: the reason habbo use raw byte array buffer using short type headers instead json objects is because it makes the packet length the minimum as it can.
So imagine your emulator will send the client a room 100x100 with 500 objects. Each item is a json object with its keys ({}) and fields (x: , y:, id:, z:, ownerName:) your emulator will send a huge json string data to your client, which will demand more memory and connection band.
Using the raw byte array buffer the communication data will be resumed to its own values in a defined order, eg:

id (int) [0 0 0 1]
x (int) [0 0 1 4]
y (int) [0 1 4 5]
ownerName (string) {length (short) [0 5] string to byte data [ l u c a s ]

that's why i think u should use the old habbo communication.

ah and it can make easy the compatibility with flash emulators

i hope you get my point about it.
 
Initiate Mage
Joined
Feb 25, 2018
Messages
30
Reaction score
39
about the json communication: the reason habbo use raw byte array buffer using short type headers instead json objects is because it makes the packet length the minimum as it can.
So imagine your emulator will send the client a room 100x100 with 500 objects. Each item is a json object with its keys ({}) and fields (x: , y:, id:, z:, ownerName:) your emulator will send a huge json string data to your client, which will demand more memory and connection band.
Using the raw byte array buffer the communication data will be resumed to its own values in a defined order, eg:

id (int) [0 0 0 1]
x (int) [0 0 1 4]
y (int) [0 1 4 5]
ownerName (string) {length (short) [0 5] string to byte data [ l u c a s ]

that's why i think u should use the old habbo communication.

ah and it can make easy the compatibility with flash emulators

i hope you get my point about it.

I think Habbo already uses this notation for packets because it's an architectural choice from the roots of the game (we should remember that Habbo born in 2000 when the most common connection speed was 56k and we still measured RAM in MB than GB) today we don't have these problems anymore.

Also, because there's only one thing that requires an intensive packet exchanging, I think it's better stick to JSON (because of the tight support with JS, this gives really many benefits) and only worry to handle at the best this single situation with a room preloader (as Shockwave Habbo does) or something that splits this packets in many others.
 
Initiate Mage
Joined
Feb 25, 2018
Messages
30
Reaction score
39
Habbo uses that protocol because its the default Buffer serialization in Actionscript. Use the tools available instead of reinventing the wheel by writing your own serializers.


JSON is the better choice in this terms as it doesn't need serialization on Clientside (as it's a JS native notation), so it only needs serialization on Serverside if using a language like Java or C#, if he writes the client using JS/TS (Node.JS) it will never needs to be serialized on any of both places, that could be time consuming.
 
Joined
Aug 10, 2011
Messages
7,401
Reaction score
3,299
Well there is a choice, if you want easy integration with existing emulators then you'd pick the protocol of those emulators if adding an extra protocol is not trivial.

If you were writing your own server then pick whatever works for you.

Serialization is not that time consuming, just let it run in a different thread as to not to block the main rendering thread and it should be fine. Dont prematurely optimize because you're worried of something you have not encountered yet. And if in the end your serialization is slow and its not trivial to replace, then thats a design flaw and your software has bigger problems than slow serialization.
 
Initiate Mage
Joined
Feb 25, 2018
Messages
30
Reaction score
39
Well there is a choice, if you want easy integration with existing emulators then you'd pick the protocol of those emulators if adding an extra protocol is not trivial.

If you were writing your own server then pick whatever works for you.

Serialization is not that time consuming, just let it run in a different thread as to not to block the main rendering thread and it should be fine. Dont prematurely optimize because you're worried of something you have not encountered yet. And if in the end your serialization is slow and its not trivial to replace, then thats a design flaw and your software has bigger problems than slow serialization.

Writing something new and getting stuck with old poop, like this packet-structure conceived for 56k connections, losing time only to get emulators to be compatible is a stupid thing: better move the butt and write new backends.

Forcing compatibility with old Emulators only limits the imagination and ability to insert new features and change actual one in a better way than they are now. There's anything good in doing this (is only good for who want to use this project with zero-effort on understanding a modern backend design or who worries about him not releasing the backend).
 
Super-Moderator
Staff member
Super-Moderator
Joined
Apr 28, 2007
Messages
1,494
Reaction score
755
Why Angular over a smaller library such as Vue or React? Less overhead from Angular would allow for a better performance on the client itself
I disagree. From my experience Angular is the fastest library when it comes to large-scale and complex applications. However, the development time takes much longer for new Angular developers. Angular isn't easy to understand and the forced usage TypeScript may be overwhelming. Also, I think Angular is much easier to work with in large groups because the code is overall cleaner and better in the modular aspect. VueJS and ReactJS are capable of running an application like this smoothly (back in 2019 VueJS wasn't known for its speed when it comes to large-scale and complex applications, not sure if it's better now), but Angular is definitely not a bad choice.
 
Last edited:
Joined
Sep 10, 2011
Messages
778
Reaction score
138
I disagree. From my experience Angular is the fastest library when it comes to large-scale and complex applications. However, the development time takes much longer for new Angular developers. Angular isn't easy to understand and the forced usage TypeScript may be overwhelming. Also, I think Angular is much easier to work with in large groups because the code is overall cleaner and better in the modular aspect. VueJS and ReactJS are capable of running an application like this smoothly (back in 2019 VueJS wasn't known for its speed when it comes to large-scale and complex applications, not sure if it's better now), but Angular is definitely not a bad choice.
I have experienced the opposite and the forced modularity in my experience has lead to more over engineering decisions than practical ones. The Angular module is better suited for back-end developments, but perhaps it is a good solution for a large scale application (The exact opposite use case of a Habbo Retro) - the point still stands it's bad for small projects.
 
Back
Top