DDR game

SpillerSpiller Senior Member
edited December 2012 in Code & Art
I have been wanting to do a larger coding project for a while now and I have always wanted to try make a DDR engine, so my next project is going to be a nearly fully-fledged Stepmania alternative.
Disclaimer: This is something I do for the challenge, if something useful will come out of it and how much I will actually end up doing is yet to be known. I will release and open-source it someday so people can look at the code and puke at it.
(I have pretty much dropped porting that BPM grapher to PHP though, when starting on it I remembered how much I hate PHP and months have now passed without me wanting to finish it...)

So I spend today trying to list up my ideas and thoughts on what I would like to do. Any thoughts/ideas? Basically I just want to fix up some of the most annoying issues in SM and avoid the whole ARCADE EMULATOR trap SM seems to be stuck in, but other than that I don't have many ideas for something a bit more fresh...

Wanted features:
  • Multi-level song organization
  • Edit song information and song organization ingame
  • Detection of duplicates, so that you always score on the same chart, no matter what song pack you play it in
  • Replay Gain, because it is annoying to adjust the volume all the time...
  • Possible to view past scores, perhaps even a historic view to evaluate progress?
  • Advanced song evaluation screen, I'm thinking a bit like the Stepmania 4/5 life chart, but with info like note density and BPM changes, so you have a chance to see why it went wrong.
  • Saving of complete replays, possibly in some format you can easily share on the web, displaying like it had been an ordinary screenshot? (with a little bit of support, perhaps forum support or iframe+browser extension? I don't want something like a .jpg with massive amount of custom meta-data, but perhaps you could do some XML which would be compatible with SVG? Would be nice if you could do something smart here, but I haven't really given it much thought yet...)
  • ingame adjustable a/c-mods
Things which should be different from Stepmania:
  • Should take full advantage of the keyboard (for navigation and so on) and have those annoying shortcuts disabled for good.
  • When starting the game you should land on the song selection screen directly like TS, instead having to go though: splash + game start + loading profiles + select mode + wait.
  • Only use difficulty rating and ignore easy/med/hard. Partly because of hard beginner-charts, partly to allow more than 5 charts per song in a clean way. hard/expert isn't systematic either
  • Multiple charts in one song is independent of each other, so no sharing of BPM and such. So if a song appears twice, but have different charts, it can be grouped.
Game mechanics:
  • Precision multiplier instead of "Judge" levels
  • Removal of grades (A/AA/AAA etc.), introduce 'achievements': Full combo (good/great/perfect), single Digit (good/great/perfect) and perhaps others. Accuracy will be the main way to evaluate scores.
Performance goals:
  • Should be ready form cold start in 10 seconds on my desktop computer with 10000 songs, without storing them on a SSD
  • Should hit 60 fps during gameplay (without video) even on low-end systems (more specifically, my laptop with integrated intel graphics)
  • Should be able to play FullHD videos on my desktop computer.
  • Images on song selection should display fluently and must not cause lag even if it can't load fast enough
  • Fast user interface on a decent system, no waiting on "loading", "saving scores", etc during normal interactions (i.e. selecting a song and options, playing, viewing scores, repeat...). It just needs to 'feel' responsive though, cheating it is okay.
Architecture goals:
  • Client-server model, separation of song collection, user data and game engine. An (inbuilt) offline-server was the intention, but extending the interface to include online servers could be possible.
  • As much separation between game engine and user interface as possible. I don't plan to make the UI themeable (as I don't care that much and don't want to do an half-assed job on it (who is going to make a different theme anyway)), but it should be possible to redo the UI code completely without too much trouble so that it can be added. Not sure where to draw the line between engine and UI.
  • Support media containers, instead of requiring audio and video to be splitted. Would also be neat to use ASS instead of some random custom lyrics format. (libVLC could be used to do all the heavy work I would believe. Video is a fairly low priority though, I don't want to mess too much with it if the libraries are tricky to work with...)

Comments

  • MrTeaMrTea Official Back-Up Simfile Judge
    edited December 2012
    Good luck with that.
  • NocturneNocturne Simfiler and <span style="font-style:italic">Freakin Graphics Master</span>
    edited December 2012
    Right on bruv
  • DTDsphereDTDsphere Senior Member
    edited December 2012
    Add compat. with .sm and shit.
  • awein999awein999 Profile Mod
    edited December 2012
    Interesting, good luck with your project. You remind me of a guy that came to the bowling alley and showed a video on his phone of his homemade pinsetter that he made from scratch just for the fun of it. It was so good.
  • AsphyxZeroAsphyxZero Simfiler
    edited December 2012
    o


    sip
  • cheezpuffscheezpuffs Senior Member
    edited December 2012
    Good luck, sounds like it will take a hell of a long while! :/
  • SpillerSpiller Senior Member
    edited December 2012
    Thanks
    DTDsphere;29521 said:
    Add compat. with .sm and shit.
    Of course I will, I don't want to step 10,000 songs in order to make sure I reached my performance goal. ;)
    awein999;29526 said:
    Interesting, good luck with your project. You remind me of a guy that came to the bowling alley and showed a video on his phone of his homemade pinsetter that he made from scratch just for the fun of it. It was so good.
    That does sound awesome, I would love to see that. Some of us just loves designing and building stuff I guess. (I also enjoy mechanics, but I'm just doing simple stuff once in a while.)
    cheezpuffs;29543 said:
    Good luck, sounds like it will take a hell of a long while! :/
    It will, I'm estimating around 6-12 months until I have something decent but it depends largely on how active I will be. Well, the idea was that I had to spend at least a half a year before getting something I could call ver1.0, in order to challenge my commitment towards a software project. That is why I choose something that I care about, is large-scale but still is relatively straight-forward to implement so I don't end up stalling it because it is too hard.


    (btw, libVLC was much easier to get working on Windows than I feared, so I will do video. I just need to include 300 dlls and everything works fine. xD)
  • iskisk BADministrator
    edited December 2012
    Some really good ideas in there and best of luck/skill to ya.

    What programming language(s) will it be written in? Will it use any pre-existing frameworks or engine?
  • SpillerSpiller Senior Member
    edited December 2012
    I will be writing in C++ for the main application and use libraries where fit. I choose C++ partially because of personal preference, but as I also have some specific performance goals it is not a bad starting point I guess.

    I plan on using SFML for window/input and OpenGL for graphics. OpenGL is purely because I want to get some experience using it, but I will most likely just use the graphics package in SFML in the beginning to quickly get something running for testing. I will use libVLC for audio and video, as long as it is possible to properly sync it.

    The media library will be use SQLite and either XML or a binary format. This media library is one of my major changes, and since I haven't explained it I will do so now.

    Media library
    SM has a 'Songs' folder which belongs to that installation of SM. I want to change that, so the game is a client which connects to a 'media library', which acts as a server and provides songs and user-data to the game.
    The second change is that only the server is allowed to add and modify the song collection, so you can't simply add songs by dropping them into a folder.

    This might sound like I'm just over-complicating things, but here are my ideas with it:
    • Since the user will not modify it directly, there is no need to perform excessive validation tests each time you start the game, to check if songs are added or removed. All data about it is stored in a database which can quickly be accessed. This will reduce the startup time significantly
    • The game will load data on-demand, reducing the startup time further (at the cost of a hopefully insignificant delay when requesting further data).
    • The media library could be modified while the game is running, however since this is handled through the server, the server could inform the game of these changes. (Osu! allows you to add songs while playing if you want to see this in action.)
    • Instead of using folder hierarchy to organize songs, I will let the database handle that. All songs will simply be stored in a folder named by its ID.
      The organizational features you can add is mind-blowing. I will at least make it multi-hierarchical and make it possible to have the same song appear in several groups, however features as flavoring, tagging and dynamic groups where it is defined for example as "artist == renard" is quite possible and not even that hard to implement.
    • You could create different media libraries with different purposes, for example one only containing pad-files. Might not be that useful, I don't know.
    • When the server imports it, it can convert it into a specific format so that the client only needs to be able to understand one format. We can also standardize the filenames to reduce the amount of data which needs to be stored in the database.
    One of the difficulties with this is however to implement it in a way so that it is not much harder to set up than SM. So I will use SQLite and include the server into the same application as the client. To import songs I consider just adding a folder you could dump files into like normal and it will import those on startup. Deleting and organizing it further should be done in-game.

    The client-server model also have quite some interesting possibilities when we start taking networks into consideration (but I will probably not do much with it though):
    • You could have one server connected on a LAN. Consider a bunch of arcade machines, all sharing the same song collection and scores. Or setting it up on for example the school LAN where everyone can connect and try beating each others scores.
    • If you computer supports Wake on Lan and you have a decent upload speed, you could go on a holiday, startup your computer and media library remotely and have access to all your songs and previous scores. If the client is portable, you could just as well run it on any computer from a USB-stick.
    I don't plan on implementing it in a way that makes this possible, it is just ideas, but I will try to take it into account so I end up with a design that could somewhat easily be extended to support such features.


    Btw
    I have seen that sm-ssc added some features regarding the .sm format, however I have not been able to find any documentation on that. I think it was something about changing the scrolling speed without changing BPM, and something about being able to store BPM changes per chart basis. Does anyone know more about this?
  • DJSuperNOVADJSuperNOVA Junior Member
    yup... it's the .ssc . They made it so that some simfilers can make charts which can behave like some of the ones from PiU... it's just a tweaked .sm ...
Sign In or Register to comment.