[HTML5] Habbo5 [Typescript, Vue, Webpack, WebSocket]

[Konquer]

What is Habbo5
Habbo5 is aiming to be a standalone replica of Habbo Hotel using non-dying technologies, mixing new gameplay with oldschool looking userinterfaces to bring out the best of both eras.



Cool, what does the stack look like?

Client:

• Typescript
• Webpack
• VueJs
• WebSockets
• Html5 Canvas

Server:

• Coffeescript
• MongoDB
• Websockets

Showcase

Spoiler:

Leaving feedback, good or bad, is a great way of contributing as it helps encouraging the developer to keep working on the project.

[MentaL_BOT]

[Roanoke]

Nice name *u*

[cabeludo007]

2018 - HTML Retro Habbos Age!
Great Job!

[Konquer]

Some minor changes:

Due to the client handling all avatar rotations, unlike habbo, there was an issue with users facing the wrong way when you entered a room. Fixed by retrieving the rotation of other players in the room when you enter.

Users are now blocking the square that they stand on.

I'm fiddling a lot with the delay between the frames of walk animations to make it more like on habbo. Currently at 105ms delay per frameupdate, still not sure if it's too slow or too fast.



Going to work on some ui stuff later. Been thinking a lot about whether or not to have it all in canvas or dom and ended up with dom simply because I believe people would want to customize it to their likings, which would be fairly hard to do if not through dom. Everything else will be in canvas though!

[Roanoke]

using dom in the ui instead of canvas isn't like use dotnet forms in a directx application ? >.>
GL with the project looks very 'smooth' =3

[Konquer]

using dom in the ui instead of canvas isn't like use dotnet forms in a directx application ? >.>
GL with the project looks very 'smooth' =3

It's fairly common for browser games to have the user interface made in the dom while the core gameplay that actually requires good performance and lots of redrawing in canvas. There wouldn't be any performance gains from having the ui in canvas.

The common reason people have for creating the ui in canvas and not dom is that it will be easier to port it into a native application to have it run other places than on the web. But I have no plans for that, so i'd rather just make it in dom which will also take up less time and make it more asthetically pleasing.

When starting this off i was planning to have it all in canvas with no exceptions, but there just really aren't any benefits from it other than being able to brag about it.

[Delight]

How did you manage to get all the frontend part done?
Did you decompile the SWFs and use the images, or how?

[Konquer]

How did you manage to get all the frontend part done?
Did you decompile the SWFs and use the images, or how?

The tile sprite is from google images and the avatars are spritesheets generated from a standard avatar imager atm. It's projected onto a canvas with (canvas context).drawImage.

[Roanoke]

why have a blur when the player move to diagonals ?

[Konquer]

why have a blur when the player move to diagonals ?

It's because of the screen capturer I used to create the gif. Guess it's to compress the file.

[Jonteh]

This looks good, man. Looks better than the other developments of the same (or similar) kind on here in recent memory.

[The General]

For what its worth, Habbo uses 24FPS.

[Konquer]

My current plan of action is room creation -> room chatting -> furniture. I have not been able to push any cool updates the last two weeks because i'm currently redoing everything with actual thought in mind. After some back and forth I have settled with creating the server in c# simply because i'm so bored of js.

The frontend ui will probably be component based to keep it as simple as possible for others to customize the design.

For what its worth, Habbo uses 24FPS.

That's actually very helpful, thanks!

[FullmetalPride]

Do you think you could post code that demonstrates how avatars are depth-sorted?

[Konquer]

Do you think you could post code that demonstrates how avatars are depth-sorted?

There is none atm. I plan to use the same system for furniture and avatars, but haven't thought the furniture part completely through yet. Currently the first one to enter gets drawn first.

It would be fairly simple to just draw the avatars from back to front based on their current coordinate. This however, would not work with furniture.


EDIT:
Turns out I have overthought the furniture part quite a bit. Up until now i've thought they cut off some of the multitile sprites manually to achieve overlapping top-part furniture. Example:

But in reality, all the furniture that allows for this behaviour is split up into multiple sprites for each tile. I've always thought lodge dividers and similar furniture to be a single image.



That explains why most carpets look stupid when stacked..