Why does every thread turn into an azure thread... Don't take it as an example.
@
saamus You suggested this project, it's only natural that you have to come up with suggestions.
I will help you out by giving these suggestions:
- Is there already an isometric Javascript lib that allows you to render the game?
- What libraries will be used for the HTML?
- Where will the open-source project be hosted?
- Which version are you going to work on?
- How are you going to get the assets?
- Which features have priority etc...
Consider these things before you plan on working on the server. Getting a demo done would be nice.
Good points. Okay, will create a list with some points.
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:
- 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.
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.
Thanks! For support this project.