Git Product home page Git Product logo

habbgo's Introduction

habbgo

An emulation of Habbo Hotel as it was in the early to mid 2000's when its client was made in Macromedia's Director & powered in the web by the Shockwave plugin (RIP)

habbgo is extremely experimental and is a project I started when I was in college but never finished. I will be reworking the project and breathing some new life into it over time.

Goals

  • To document the FUSE protocol, which was a custom application layer protocol over TCP powering HH
  • Write a clean and easy to read code base for documenting how the game worked
  • Create the means for simulating the various scripting tricks and hax
  • Make the server/client easy to setup and deploy without Shockwave woes
  • Configure both FUSEv0.1.0 & FUSEv0.2.0 in one environment to allow emulation of all Shockwave clients

Disclaimer

This project is for educational and archival purposes, I assume no liability for how this software is used by others.

habbgo's People

Contributors

jtieri avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

yunginnanet

habbgo's Issues

Checklist

Creating this to serve as a checklist for myself as I wrap up some pieces of code that I've left unfinished in a local branch.

Right now register/login works minus a few packets at login related to unsupported features e.g. habbo club, recycler, messenger, etc. Public rooms are loading with heightmaps and players are initialized so the next steps are getting the pathfinder implemented. Once that is complete the goal will likely be some hardcore cleanup and solidifying of designs before moving deep into the core of the games functionality. Better testing coverage would be nice as well so I may spend some time on that before moving on to other things.

  • Finish high level design around room and player state
  • Implement pathfinder
  • Implement pathfinder commands/messages
  • Cleanup sign in commands/messages to ensure SSO works and wrong passwords return proper packets
  • Audit database related code. Possible refactor here or at least hardcore cleanup
  • Cleanup entire codebase
  • Possibly build out better test coverage (possible docker framework for simulating flows against live hotel)

Log Users IP

Currently when a user registers/signs in we do not keep their IP as persistent data in the DB. We will need this information in the future though for managing users (i.e. gonna need IPs to manage bans so need to log this to DB)

Best Idea is probably to store up to x IP addresses associated with a user in a table that keeps track of recent connection addresses per user.

Major Refactor

May work on this casually again but everything needs a refresh. In the end most of the code/design may change but I figured it would be easier to refactor the hell out of this versus starting from scratch,

  • Either ditch SQL/MariaDB for gorm or stick db stuff into Docker
  • Add simple web server to serve client and eventually site
  • Build client projector in Director
  • Tooling/Testing
    • Add Makefile & build scripts
    • Add Docker setup
  • Consider hosting client assets somewhere
  • Add wiki for packet documentation
  • Redo config stuff
  • Overhaul error logging
  • Fix general design of package

Rename project to habb-go

Or simply lowercase habb, to avoid stuttering imports.

Please it's a convention in the Go community. Don't trigger me.

Refactor DB Design

Currently the DB connection pool is only accessibly via a Players underlying Session, however, this is a bad design choice and needs to be addressed sooner than later because there will be places where DB calls need to happen that have no Player context.

What version of the game were you targetting?

Specific revision? r14?

Also, as I go through this on my fork and get to understand where you were going with it, I'll see if I can give back by helping you with some of your issues on a clean branch of your original repo.

Complete Portions of Wiki

The Wiki rn is a mere outline, in time it needs to be filled out.

  • Write up a welcome segment about the intentions of the project, the wiki, mission statement, and tips/guides on helping
  • Write up a bit about HH, its origins, its story, its private server/scripting community, yada yada
  • Add links to the other Sulake project mentioned on main wiki page
  • Give credits to Puomi, RZ & other OGs, etc
  • Add breakdown of FUSEv0.1.0 protocol
  • Add breakdown of FUSEv0.2.0 protocol
  • Add samples of base64 and vl64 encoding
  • Document all the packets in FUSEv0.1.0
  • Document all the packets in FUSEv0.2.0
  • Add resources for old discussions on game, client assets/servers, related discussion/pertinent resources

Cache static-esque game data on packet level

When triggering commands that generate the same data each time, cache the packet response to not waste CPU and I/O resources. For some packets the database gets hit every time * N users, and this leads to excessive database load. All emulators currently available experience this design flaw.

Meth0d and/or matty13 built a novel (for the retro community) way of caching packets by key-value. An example of it's usage can be found here.

Data was cached on the protocol level, similar to how reverse http proxies like Varnish (L1 tier) and Apache Traffic Server (L2, L3 tier) used by Wikimedia and New York Times cache content to achieve high throughput and low latency responses.

Caching on the protocol level bypasses most if not all game logic on second (or first, depending on implementation, stale-while-revalidate is a well suited pattern that could be adopted for e.g. navigator; initializing cache on constructor/loading data, scheduling a refresh decoupled from response when client asks for it, limited per X time) packet received, this lowers database load and considerably (just ask popular retro's on their specced VPSes) during peak traffic and/or when dealing with scriptkiddies.

In this age of 1TB RAM servers and 2TB PMEM devices with ridiculous throughput and nanosecond latencies; what is being taught in computer science classes (memory being expensive, CPU re-calculation being cheap) no longer applies. It now makes more sense to calculate once and store in memory and to recalculate only when absolutely necessary. Such application architecture allows the CPU to spend most of it's time towards expensive game logic like pathfinding, instead of shuffling data around.

Implementing this would take a concurrent (being N thread R/W access safe) key-value store implementation like ristretto or a remote one like Redis.

Response packets could then be accessed by each game service, allowing each to implement custom behavior. (e.g. item inventory being cached per user by attaching user ID to the key).

Documentation

Most of the code needs to be documented, it would be wise to get a good chunk of this done before it becomes a daunting task.
Creating a getting started guide in the README would be nice as well

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.