- Joined
- Sep 2, 2011
- Messages
- 2,171
- Reaction score
- 916
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
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:
- User Data
- Room Data
- User Management
- User Management in Room
- Friend List/Console
- Room Settings/Edit Room Settings
- Enter Room/Walk Room
- User Effects/User Actions
- Change Clothes/Clothes Management
- Catalogue
- 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 - v44images
Habbo Illumina
News Example
Community Project
convetions & standards
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?
Code:
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.
Attachments
You must be registered for see attachments list
Last edited: