Private Let's do it! Community Project - Habbo v36+ or Illumina [HTML 5!!]

[ovflowd]

community project

--------------------------------------------------------------------


Community Project
introduction

​

Yeah, i'm really doing this. I'm one of the people that think that together we can create amazing things. And now i'm proposing this.

The fact it's that Habbo is dying. That will happen soon. We need union us together, and create a rescue plan for us, not for Sulake, for us. Give back the good, nostalgic things. That are in our memory.

So i'm suggesting to we create a HTML5 client based on Habbo Beta design. (v36 - v44) or in Habbo Illumina concept. I'm adding screens of both of those.

We will also create an Emulator, with basic features planned, and futurely with more features.
We need work together. We have a lot of Emulator projects. Why not create a unique maintained emulator. With no Flash, only HTML 5.

Community Project
discussion points


​

Which Version the Community Project will be based?
the community project will be based on Habbo Illumina Design, not based on a specific version. In terms of features we're planning to base in the "Habbo Beta" concept. Which it's good in term of features and design. The general UI will be based on Habbo Illumina and completed with Pre-Shuffle parts. We also will add some custom features based in actual Habbo features.
Some of those features were planned for Habbo Illumina but only coded in Post-Shuffle and actual Habbo releases.

Those features are:

• Habbo Helper Tools
• Habbo Stream Notifications
• Habbo Camera (not Elisa Habbo Stories)
• Habbo Center (only planned on Illumina, never coded)

Where the software will be hosted?
The software it's planned to be totally open source. Hosted on GitHub platform. Backups can be hosted on GitLab. We plan tu use Continuous Integration e Build Tests Softwares. If we choose Java as language we can use Jenkins. The software will be Apache2/MIT licensed, and follow Agile Software Development standards, such also Scrum Project Management. Our idea, it's non-stop issue tracking. The software also will have nightly builds and follow versioning methodologies. We can use a lot of C&I's, C&C's platforms for Code Coverage and Continuous Integration. In case of C# we will made it compatible with Mono and use only NuGET. In case of Java we will use Maven.

How the Client will handle Assets?
This it's a critical thing. And need be correctly planned. Initially the songs will be in AAC (Advanced Audio Codec) and the component assets in SVG. The reason of SVG it's the high fidelity image quality, and easy programmable images. The entire asset rotations/angles will be available in the image. Each asset will have a info file that says all available rotations/effects/more. And the position of each thing. The most complex thing are assets with effects. This case they need be high-quality gif's. One of the good thing it's that Habbo relays on 16bit colors. Being easy to convert it to GIF Animations. The assets will be requested by HTTP Protocol (REST), and being managed by an Asset Manager in the Client side.

How the Communication between Client & Emulator it's planned to Happen?
The communication initially will be in WebSocket, secured by TLS + WSS (WebSocket Security). The packets will follow a similar structure from the Habbo way. And will be probably with WireEncoding and Base64 Encoding. Since it's simply to encode/decoding it.

Will this Project have a CMS?
No. The register, news, login and all CMS features will be directly in the "Client". Since the Client it's in HTML5, no need of a CMS it's required. Server will control all Registrations/Logins and User Data, like as if you was playing. Login Controllers can be like Habbo Illumina concept or Old School Habbo.

Which Main Features we will do, and which have priority?
The priority it's coding the Client Core and Server Core. Remaining in Security and all basic Models. The Database, Communication, Security, Authentication, Caching, Workers, Data Managers, Pathfinding, Filtering, Mutant, Logging, Error Threat related things are in the top of the priority.
After those being concluded. The Registration/Login/Request Data and entire basic Packet Library will be coded. A defined Documentation API with the structure of the Packets need be documented in the GitHub Wiki. It's totally important those documentations, with Structure Specifications.

Following other important Features (in order) are:

1. User Data
2. Room Data
3. User Management
4. User Management in Room
5. Friend List/Console
6. Room Settings/Edit Room Settings
7. Enter Room/Walk Room
8. User Effects/User Actions
9. Change Clothes/Clothes Management
10. Catalogue
11. And the list continues...

How the JavaScript and Game motion will happen?
Some popular engines are:

• Phaser
• PlayCanvas
• Construct2 (Scirra)

We need manage if we will use a Game Engine, or build our own Game Engine. This need be discussed futurely. And it's an important topic.

Other important thing it's about Isometric Game Engines.
(

You must be registered to see links

)
(

You must be registered to see links

)

Some Isometric HTML5 Game Engines:

You must be registered to see links

You must be registered to see links

Which Language and Libraries will the Emulator be coded?
Possible languages

• Python
• Java
• C#
• C++
• Swift
• NodeJS
• PHP
• F#
• D

We need exactly discuss what will happen.
For C++ we have Boost as main library.
Java has Apache Libraries, Hibernate, Netty.
C# as NHibernate, log4Net, DotNetty, SuperSocket, etc.

How will the Client be Designed?
This need be defined correctly with precision. We will use external_variables? local languages like external_flash_texts? The UI components will be like Assets? How the Client Core and external requests will happen?
It's totally important to define that, with exactly precision.

This project only can happen if the community engage on this. Please, let this wish come true.

Community Project
images


​

v34 - v44

Spoiler

Habbo Illumina

Spoiler

News Example

Spoiler

Community Project
convetions & standards
​

The Community Project it's searching for the following standards:

Communication Standards
The communication standards for the project, as suggested by @CodeDragon, are about WebSocket communication through jSON packets.
(

You must be registered to see links

)

We can figure out, that for massive amount of data, big hotels, the data can be considered a BigData scenario. jSON wasn't made for bigger amount of data. But consider that the limit of an inventory it's 5.000 entries, we will have a jSON Array with 5.000 objects. We can limit it the Inventory by Pages, and only send the amount of the correspondent page.

How will be Requesting a Packet?

exampleSocket.send("{packetId : 'XXX', arguments : { ... } }");

The requests will be jSON and the responses will be jSON.

If we use Java, Netty supports WebSockets natively.
(

You must be registered to see links

)

Game Design Standards
We can follow Game Design standards, respecting a Isometric Geometric Path.
(

You must be registered to see links

)

(More to be discussed futurely)

thanks for reading. If you want this, click a like.​​

 

[The General]

Pro Tip: Make your client first before writing your server.

Should do something challenging. Why not write the server in Swift :? There is a toolchain available on Linux.

 

[Emily]

Nope. If you want to revive something, try make something based on the old client with new features. I think this client doesn't bring too much interest. But it's just what I think. The old client was the best (especially v1 - v9 era). In fact, I don't see why this would really revive anything. Also, if you mean with encryption real encryption, why take Habbos' encryption? It'd be a poop ton of work to convert the code from AS3 to PHP, I'd suggest you create your own encryption. (and yes, you SHOULD use encryption).

Also, multiplatform? Anything is basically multiplatform you mention. C# can be done by Mono, java, C++ and Python are already multiplatform and so is Node.JS.

Also, why a questionmark after OOP? Isn't it just logical we do OOP in 2016? Also, MVC would be a really useful thing.

 

[ovflowd]

Nope. If you want to revive something, try make something based on the old client with new features. I think this client doesn't bring too much interest. But it's just what I think. The old client was the best (especially v1 - v9 era). In fact, I don't see why this would really revive anything. Also, if you mean with encryption real encryption, why take Habbos' encryption? It'd be a poop ton of work to convert the code from AS3 to PHP, I'd suggest you create your own encryption. (and yes, you SHOULD use encryption).

Also, multiplatform? Anything is basically multiplatform you mention. C# can be done by Mono, java, C++ and Python are already multiplatform and so is Node.JS.

Also, why a questionmark after OOP? Isn't it just logical we do OOP in 2016? Also, MVC would be a really useful thing.

Agree everything with you.
Because that i also suggested doing the client in Habbo's Illumina Concept. v1 - v9 clients are simple, easy to do in HTML. But Illumina Concept it's clean.

I suggest first starting with the basics HTML components, and try to think how do the JavaScript core. The communication between server & client, will be REST (better no) or Socket?

Will we do our own encryption?

Will be multiple sub-servers, like general games (Ragnarok, Tree of Savior) (Login Server, Game Server, etc.)

How will be all those things.
Different of the last community project​ that was a real failure. We need to discuss how this can be. And document everything. Really everything. Make a solid CORE. And a defined API/Design Pattern.

Pro Tip: Make your client first before writing your server.

Should do something challenging. Why not write the server in Swift :? There is a toolchain available on Linux.

I agree with you. (Part of HTML).
I never developed or touched in Swift. Maybe be good, maybe not.
Explain better why Swift.

 

[Emily]

@saamus, just create own encryption. It's more fun, and challenging It might take some time but you should take time for it.

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

I would suggest visiting those links, especially the Wikipedia links as they are really informative. Habbo also uses DH, RSA and RC4 (note: RC6 is just like RC4 but a later version).

Goodluck. Cheers.

 

[ovflowd]

@saamus, just create own encryption. It's more fun, and challenging It might take some time but you should take time for it.

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

I would suggest visiting those links, especially the Wikipedia links as they are really informative. Habbo also uses DH, RSA and RC4 (note: RC6 is just like RC4 but a later version).

Goodluck. Cheers.

Thanks for the links. Just i said, i agree with creating own encryption. I know what DH, RC4, RSA, etc means and how they work.
The encryption isn't the challenge, but the algorithm behind it.

Will be fun creating one.

 

[The General]

Explain better why Swift.

Swift is kinda cool actually. Especially with simplifications of code.

Thanks for the links. Just i said, i agree with creating own encryption. I know what DH, RC4, RSA, etc means and how they work.
The encryption isn't the challenge, but the algorithm behind it.

Will be fun creating one.

Oh boy talking about re-inventing the wheel again huh.

 

[Emily]

The General just like new programming languages being created? I think it's a great experience to create your own encryption and algorithm Of course I'll leave it all to saamus. I understand your sentence but yeah, I hope you get my point. No offense though.

 

[ovflowd]

@Glaceon see my suggestion above.

Observation.: Will be hard to think what we can change on it. But will continue to be an Asymmetric Encryption? Where the client will store it?

Why not just use TLS.

My suggestion
Communication between Emulator and Client happens in a WebSocket. Yes raw TCP connections.
Security tunnel will be TLS 1.2+
Hashes would be PGP + DH
Encryption will be ERSA + AES-OCB
Start Authentication will be: ERSA + StartTLS

I think it's a good solution. Some links:

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

You must be registered to see links

 

[Emily]

@saamus well you'd better ask that to an expert; I have no clue if your suggestion is a good one. As a matter of fact, I am terrible and have no knowledge of encryption at all.

 

[ovflowd]

@saamus well you'd better ask that to an expert; I have no clue if your suggestion is a good one. As a matter of fact, I am terrible and have no knowledge of encryption at all.

Let's ask to Joopie
Idk if i did something horrible or good. Only merged a lot of Web Encryptions and Ciphering and Hashes.

Observation.: Yeah so many algorithms. The question is. Will be fast this communication? And how will be happen?

Obs.: It's a raw of how the communication will happen... So much lazy to do something proper in LucidChart.



Idk if will be better HTTP or WebSocket or raw TCP.

Here a little StackOverflow: http://stackoverflow.com/a/1217954

In terms of performance raw TCP it's really good.
In terms of security.. HTTPS will be amazing.
In terms of half security and half performance will be WebSocket, that is an extension of a raw TCP socket for JavaScript something like that.

 

[Emily]

@saamus you should keep in mind, the slower the encryption is the more secure it is. The question is, how many performance do you want to give up for encryption? If you have a good encryption there's a high change it'll be a bit slow, but this doesn't have to matter if it isn't too much.

 

[ovflowd]

@saamus you should keep in mind, the slower the encryption is the more secure it is. The question is, how many performance do you want to give up for encryption? If you have a good encryption there's a high change it'll be a bit slow, but this doesn't have to matter if it isn't too much.

Agree with you. I'm not even professional or advanced in encryption. Only know some stuffs. We need someone intelligent and that know well this area to explain what will be good.

Regarding that i really want this project to continue. (start i mean) (happen i mean).. But we need discuss not only encryption, languages, etc. But software stuffs. Like libraries, how will be designed the client/emulator, how will be the packets/communication and other stuff.

Waiting Master Joopie to write.

Also inviting master marit maritnmine or Martinmine to discuss here.

 

[The General]

Thats not creating your own encryption.

Thats part of your own protocol, not encryption.

 

[Joopie]

Regards encryption. There is WSS (WebSocket Secure) which uses SSL already. Http would suck because you would have to use technices as long pooling. Raw TCP sucks too because you need something like Flash to get it working (which we want to avoid!).

Using more encryption would be useless, because JavaScript, and slow. So WSS is the way to go.

Fun fact... WebSockets is a subprotocol of the http one .

 

[Taiga]

I personally really prefer the ~v26 era, I can feel the nostalgia.

As for the encryption goes, @Joopie did an excellent explanation of what I was going to say.

It's better to start working on the core mechanics of the game before you start thinking of extras.

I see you are already focusing on specs, they are not specs they are considered constraints. You shouldn't be thinking so much about constrains in the early stage of your planning.

 

[Joopie]

Also, to make my post more clear. Because it is JavaScript, it is useless to add encryption, apart from the build in ones (https/wss). The reason I am saying this is because you can easily edit js on the fly and add a simple console log line to print out all outgoing and incoming data.

Also, I should reconsider some points on how you want to make the client.

 

[ovflowd]

Also, to make my post more clear. Because it is JavaScript, it is useless to add encryption, apart from the build in ones (https/wss). The reason I am saying this is because you can easily edit js on the fly and add a simple console log line to print out all outgoing and incoming data.

Also, I should reconsider some points on how you want to make the client.

Amazing answer. Agree totally. Didn't though about that. It's "useless". Okay, using WSS it's also a good idea.

 

[Alozi]

Ragezone! It's time to shine.

I this is as a light for the habbo community.

 

[ovflowd]

Gosh it Alozi
this thread its so much dead. I think this project haven't any future.
I dream for this :/