Proposed Updates

[Lyonlancer5]

Overview

This issue is a list of update proposals for opsu! as of 0.15.0. Since the new osu! client is now open-source and in active development, we might as well push some changes here.

This list is non-exhaustive and will be changed per-release or when you like (owners can edit others' comments AFAIK). We could also reference feature requests to this issue.

Golden words of encouragement:

IMO the biggest advantage of opsu! is NOT being osu!

Proposals

Gameplay

• [ ] IRC integration to client (either we connect to Bancho's IRC network (requires osu! authentication) or we could use a third-party service)
• [x] Two separate score systems (our own formula and the vanilla osu! score formula)
• [ ] Support reading beatmaps that do "undefined" behavior (e.g. 0 BPM timings, 2B, Aspire)
• [ ] Storyboard support

UI/Design

• [ ] Skin v2
• [ ] Key overlay (Keyboard and mouse clicks)
• [ ] Smoke overlay

Framework

• [x] I18n framework --> #295 work in progress
• [ ] Dynamically reloadable resources (yugecin/opsu-dance, https://github.com/Lyonlancer5/opsu/issues/3)
• [ ] GStreamer (Soon™ - gst1-java-core isn't on Maven yet)
• [ ] Multi-threaded loading

Distribution

• [ ] Delta-updates (https://github.com/Lyonlancer5/opsu/issues/5)
• [ ] Provide a list of minimum/recommended system requirements (such as the OpenGL version)

Development

• [ ] Continuous Integration
• [ ] Metrics (for stable releases)
• [ ] Contribution guide

Additional notes

I'm working on setting up an Ubuntu system (not a VM) specifically for the purpose of compiling and testing Linux builds.

Eh no, its not going to be a rewrite anymore, maybe

Updates

• 05/20/2017 -> Update i18n, removed JRE packing and osu! score formula, reference all issues from fork.
• 05/15/2017 -> Marking off some points, added the localisation framework, Snooper data to Metrics
• 05/14/2017 -> this comment and #282

[tpenguinltg]

If this is going to be almost a rewrite, I would also suggest adding unit tests.

[Lemmmy]

Slick2D + LWJGL 3 (requires re-writing parts of the current framework and significant amounts of caffeine)

why don't we just merge fluddokt's libgdx port in here? libgdx is designed to be multi-platform, so then we don't have to maintain two separate desktop and android versions. you'd move the main game into a main module, then you would simply make a desktop and android module, which contain basically just a launcher class, and other small tweaks per-platform. compile builds with main + desktop, and main + android.

[itdelatrisu]

Looks interesting. Not sure what kind of input you want from me (if this is going to be a fork, which it sounds like, you can do whatever you want) -- but here are some comments after reading this:

• Scoring: If you want to implement osu!'s scoring system, I'd love to integrate it into this repository. It's not my intent to have a separate scoring system; the information just wasn't available when I wrote this.
• Skinning: A lot of osu! skinning options aren't supported here yet. To find which ones, just check for methods in Skin.java with no references.
• Shaders: Would be great if you know how to write them! :)
• Java 8: There's no reason this won't work in Java 8. I'm only compiling in Java 7 to support older machines (which a lot of the userbase seems to be using this for).

You haven't explained why you want to make any of the larger changes. A lot of them seem like tons of work for little reward, e.g.:

• LWJGL3: Unless there's any compelling reason to use LWJGL3 (I don't think there is), there's no point trying to port Slick2D to this since Slick2D is really a massive library. As others have pointed out, if you want to switch frameworks, you might as well port this project itself instead of wrapping Slick2D around something else (which @fluddokt has already done a great job of).
• Packing JRE: Not sure who your target audience is here, since most people who would opt to run opsu! (on desktop) instead of osu! probably already have or know how to install JRE. Aside from development time, this would add more complexity to making releases, too.
• GC: There's really not that much garbage being generated, aside from unavoidable sources (loading beatmap data). If you run a profiler, it becomes pretty clear that normal updates aren't causing any GC strain.
• IRC: Would be nice, though I have no idea if anyone would use this. (From my experience, built-in chat in games is usually pretty dead without a consistent playerbase.)

Things you haven't mentioned, if you need ideas (off the top of my head):

• As @tpenguinltg wrote, automated tests would be great. (More emphasis on integration tests instead of unit tests, though, since very few of the bugs over the years could have been caught by simple unit tests.)
• Storyboards aren't implemented at all. There's a lot of useful info at ExCellRaD/osuElements.
• Rather than get rid of "magic numbers" (most numbers you might want to change are already constants), it might be more worthwhile to separate strings into an i18n framework and translate this to other languages.
• In general, more caching can be done. Loading times for everything are way snappier in osu! (startup, beatmaps, background images, etc.).

[Lyonlancer5]

Well, added to the list and a few explanations/questions.

automated tests ... integration tests ... unit tests

Would something like a CI service be of help?

LWJGL 3...

I forgot about that libGDX fork (this one?) so marking the LWJGL 3 thing off the list for now.

Was going to try an experiment regarding different resolutions rather than sticking with the pre-defined set of resolutions and also working with multi-monitor setups. The idea is far-fetched because I'm still learning to do a way to change the main UI to be "resizable" and along with it, a way to handle scaling of drawn objects.

IRC: Would be nice, though I have no idea if anyone would use this

I do see the point you made. With advanced communication systems (e.g. Discord/TeamSpeak) that fulfill the needs of users and provide more features, the IRC system would end up being unused (unless the end user specifically wants something "less")

Packing JRE

Oops. And it would take much longer to setup all those stuff too even.

Scoring

About that, which of the algorithms do you prefer, the current algorithm or something like in mania (1 million score cap) ?

an i18n framework

Whoops, the world isn't English-only, riiiiiiight (added) Do you want the language files to be housed in the JAR or to be downloaded/extracted seperately?

Storyboards

Since C# code is slightly similar to that of Java, I'll try decoding the *.osb files first (and the cases where the beatmap difficulties have their own storyboard code)

Skins Shaders

Ooh, the eye-candy... (I need a more powerful graphics card and a way for opsu! to be friendly with lower-spec PCs)

---

I already forked this repo (here) and added a few changes already (in the branch experiments1)

[Lemmmy]

Do you want the language files to be housed in the JAR or to be downloaded/extracted seperately?

language files are tiny, less than 100kb each even for large projects. simply bundling them is fine

[Lyonlancer5]

lag is real with 2GB

I got to work on the localisation framework first and these are early progress: Used a variant of SampleNotReal.lang

The framework itself relies on a simple system of String key-value pairs that can be reloaded upon changing the language setting. Its something like this: my.translation.key=Translated Value or my.translation.formatted=%s supports formatting

The language files themselves are packaged in the JAR and can be found by following in the package itdelatrisu.opsu.translations where LanguageManager can also be found.

I haven't actually integrated this into the Options panel yet, although there are edits already to prepare for it. I'll be making a gist to provide a list of localisable strings that can be used as a template (other than the default English US file)

//The framework for translating stuff is quite easy to do, its the translations themselves that are slightly hard to source. I know, this ain't final.

[yugecin]

Smoke and key overlay might also be nice things to add :)

IRC: would be nice imo, but probably not used very much. It would also be a nice basic snooper as you can see when people join/leave channels (if it's non-bancho) and maybe even report crashes to it :) The basics of an IRC client is not that hard (I've made some java IRC bots in the past), so you can avoid using someone else's library and be sure that it's optimized for what opsu! needs.

For your final note: I have win7/8/10/linux/macbook systems so I can help in testing, but opsu! runs fine on all my machines (haven't tested the latest build with video support yet) and I don't really see why compiling would not work in different environments as long as there's a JDK and dependencies are resolved.

[Lyonlancer5]

soon again