forum

Complexity of programming a simplified mania w/ python/game?

posted
Total Posts
11
Topic Starter
-[Shady]-
Not too sure where this belongs so I'm just gonna drop it in here I guess.

Title was pretty long so had shorten it but the main question is,

How complex would it be to program a simplified version of Mania using Python/PyGame, starting computing project next week and it's the idea I have the most interest in doing but we've been told that leaning into more complex projects is a bad idea, so I'd like to know how complex programming a simplified mania would be in comparison to programming simple games like Noughts and Crosses, connect 4 ect. I'll likely go ahead with it if it's not too much of a complexity rise but I'm kinda abstain on it right now. By a simplified version I'm talking about removing acc, removing different scores for timings and focus on solely hits and misses, with those 2 things out I think it shouldn't be too much of a steep curve but I'd like to know what others think of that though.

This would be done using Python with PyGame installed with the time frame of starting next week and ending at Christmas 2017.
Roan
The most important difference between creating something like mania and creating something like noughts & crosses would probably be that mania needs a main loop. I'm not a python programmer so what I'm about to say might not be entirely correct for python but I hope you get the idea.

For a game like noughts & crosses everything can be event driven. Meaning that logic is only executed when the user takes an action. For a game like mania you constantly have to update the play field using a mania loop. You'll also have to use multiple threads to allow the user to take action at the same time. Therefore these two examples differ completely in structure. Noughts & crosses is easier to program, but if you already know about threads & rendering/game loops then recreating a simple version of mania shouldn't be too difficult.

One other point you have take into account is audio. While noughts & crosses doesn't require audio, you'll want to play some for mania. But I have no idea how complex this would be to implement in python or if there are any libraries for it.

I could probably write a lot more here, but these are the main differences. Nought & crosses is event driven while mania is driven by a constantly running main loop (that also has to stay in sync).

If you still have questions, feel free to drop me a PM :) .

P.S. Mania for sure is a nicer project... Also if it's a bad idea to lean towards more complex projects then I guess your teacher wouldn't like me :3
Well anyway whatever you end up doing, good luck! :D
Topic Starter
-[Shady]-
Thanks, helped a lot, I did some research myself on the audio and it looks like it's pretty simple to upload a .mp3 file into Pygame so that's pretty straightforward.

In terms of "constantly updating the play field" that's something I was worried about at first however a couple of friends were talking about it over today and one of them had a good idea of just making a big pre-made graphic that just scrolls down the screen over time to save the trouble of having to program the movement of each individual block, I've managed to solve most of the keypress issues I would have by making 2 arrays, one for required keypresses and one that appends your actual keypresses to it overtime, then have a loop that compared the two every second or 2 and make score adjustments based on if the index values of the keys match up to each other.

I got suggested to try it out for the first 3-4 weeks and if it gets too complex for a full scale project to drop on noughts and crosses and maybe add a few extra elements like time limits per turn to it, so that's the approach I'm gonna be taking here.
Roan

-[Shady]- wrote:

Thanks, helped a lot, I did some research myself on the audio and it looks like it's pretty simple to upload a .mp3 file into Pygame so that's pretty straightforward.

In terms of "constantly updating the play field" that's something I was worried about at first however a couple of friends were talking about it over today and one of them had a good idea of just making a big pre-made graphic that just scrolls down the screen over time to save the trouble of having to program the movement of each individual block, I've managed to solve most of the keypress issues I would have by making 2 arrays, one for required keypresses and one that appends your actual keypresses to it overtime, then have a loop that compared the two every second or 2 and make score adjustments based on if the index values of the keys match up to each other.

I got suggested to try it out for the first 3-4 weeks and if it gets too complex for a full scale project to drop on noughts and crosses and maybe add a few extra elements like time limits per turn to it, so that's the approach I'm gonna be taking here.
Sounds like a good approach, good luck ^^

I do wonder if it's a good idea to create one big graphic though. Especially for longer maps it will require a lot of memory to be able to store it in RAM. And you probably would have to generate that graphic anyway. Rendering everything at runtime would make your program more efficient ;)
Also it's usually quite easy to draw multiple objects to the screen. Just create an array with all your hit objects sorted by hit time. Then your program can just traverse the array in a lineair way each loop update. For each element you then just have to check if it is allowed to be hit this frame / already hit / missed / a future object / a past time object. Then you take the appropriate action(s). Ofcourse to make this more effecient you can also keep track of where in the array to start each loop so that you don't have to traverse then entire array. Also as soon as you find a 'future' object that would be rendered offscreen you can just stop traversing the array.

Uhm I hope that made any sense :)

P.S. Actually the biggest challenge is keeping your music & your visuals in sync.
Topic Starter
-[Shady]-
Map wise it will only be 1:30 long so that shouldn't be a big issue.

I'm gonna start by doing a basic piano tiles style without music at first just to get the functionality working and then mess about with adding the music in and editing the position of the notes on the graphic itself to match.

The biggest problem I would have in this imo is since I want to compare the two arrays (KeysRequired and KeysPressed) by their index value in the array, I was concerned what I would do if the user decides to bash the keys a bit before the map starts like I do in mania most of the time but checking if it's allowed in to be hit within a time frame is a good idea, then maybe find a way to null the scoring of keypresses when they're not required? Not too sure how I'll approach that but we'll see how it goes I guess.
Roan

-[Shady]- wrote:

Map wise it will only be 1:30 long so that shouldn't be a big issue.

I'm gonna start by doing a basic piano tiles style without music at first just to get the functionality working and then mess about with adding the music in and editing the position of the notes on the graphic itself to match.

The biggest problem I would have in this imo is since I want to compare the two arrays (KeysRequired and KeysPressed) by their index value in the array, I was concerned what I would do if the user decides to bash the keys a bit before the map starts like I do in mania most of the time but checking if it's allowed in to be hit within a time frame is a good idea, then maybe find a way to null the scoring of keypresses when they're not required? Not too sure how I'll approach that but we'll see how it goes I guess.
I still think the big graphic could be a bit of an issue. I calculated that it'll be roughly 50 MB in size with a minimal resolution and you're drawing that multiple times a second.

As for the key presses. You could do something a little less precise. When a note is supposed to be hit you just check if the corresponding key is down. This works since you only care about a hit / miss. The only thing you need to keep into account is that you need to invalidate a pressed key after a certain amount of time (other wise the user can just hold all the keys all the time). The other thing is that pressing the key too late will not register a hit but that can be compensated for by slightly offsetting the hit times. This is ofcourse far from ideal but it works for a simple implementation, if need be and you have time left it's also relatively easy to finetune.

P.S. I'd also take look at the equivalent of a HashMap / Hashtable in python (I think they're called dictionaries in Python), since they're going to be invaluable data structures no matter the implementation your going to use.
Topic Starter
-[Shady]-
Yeh I've used dictionaries plenty of times, for the project itself I've settled on going with the O's and X's mostly because of how much extra details I need to take into account in a mania style game compared to O's and X's where the majority of the complexity lies in formulating how the program knows when someone wins, I'm planning to add extra features such as turn time limits to the game as well to expand a bit more - documentation is a lot simpler with it too and the project would be a lot easier to manage in terms of time frames and workload with the time limit we have to work on it, there's lots of issues that could come up with mania that I'd probably get hella stumped on for a good couple weeks with limited resources to help find a solution but that's not the case with O's and X's so I think that's the best route to go down for the project.

I'll likely be working on mania in the background overtime since I've just developed an interest in general in making it now and I don't want to put all my ideas I've had to get around stuff to waste after the last couple weeks. Thanks for all the help in this thread through, it'll come in useful later
Roan

-[Shady]- wrote:

Yeh I've used dictionaries plenty of times, for the project itself I've settled on going with the O's and X's mostly because of how much extra details I need to take into account in a mania style game compared to O's and X's where the majority of the complexity lies in formulating how the program knows when someone wins, I'm planning to add extra features such as turn time limits to the game as well to expand a bit more - documentation is a lot simpler with it too and the project would be a lot easier to manage in terms of time frames and workload with the time limit we have to work on it, there's lots of issues that could come up with mania that I'd probably get hella stumped on for a good couple weeks with limited resources to help find a solution but that's not the case with O's and X's so I think that's the best route to go down for the project.

I'll likely be working on mania in the background overtime since I've just developed an interest in general in making it now and I don't want to put all my ideas I've had to get around stuff to waste after the last couple weeks. Thanks for all the help in this thread through, it'll come in useful later
In that case good luck with O's and X's :)

P.S. I'll be looking forward to your mania implementation in the future ^^
[ Scarlet Red ]
I also think you would need an audio engine-type of thing (like ASIO4ALL). I think osu! uses ASIO. Stuff like this helps focus on music and timing.
Full Tablet
osu! uses the BASS audio library (which uses DirectSound when playing audio for Windows) http://www.un4seen.com/
Amryu
I tried something similar for some friends that day. I made a Java-based mania, which would use
4 keys and single-bpm only maps. If you want to look at it for reference you can decompile it
using JAD. I could also give you the original source code if you want to.

I don't want to take your fun at writing this but if you feel lost, feel free to take a look.

https://www.dropbox.com/s/xte6xgpjdi9ssdz/ManiaLite.zip?dl=0
Please sign in to reply.

New reply