Yes Teetoe was her name.
I was thinking that the point of the server would be to manage connections between players. I don’t know how to explain it but in that way, players don’t have to host their own server whenever they want to play; they can use someone else’s server. (And off topic but you’re talking about Novetus/RBXLegacy right?)
i do like this idea (it’ll be time-consuming but it’s okay).
with this reset, i’d like to make some suggestions.
as for couch multiplayer, i voted to keep it on the side, but i understand the complications this will come with. if we keep this, we should at least call quick play “couch play” or “free play” or something like that.
it’s a closed beta project called buildium
I still don’t see the advantage of starting a new project from scratch. I feel like the current project is too big to do that. How is doing that better than just reviewing what we currently have?
I agree with your suggestions but I don’t think we should reset.
And there’s also the clipboard limit
@mlgcoolguys_1, thanks for tagging me. I agree, we should put the local multiplayer aside, but the story mode is not easy enough to finish in under a year. I’m not saying that we should stop progress on both, but I do have a suggestion: how bout we prioritize an online multiplayer version?
Yes, it is possible and at the same time difficult to add with Wick, and I don’t have enough knowledge of how servers work in order to add this in, but I’ve seen @pumpkinhead do it before (with a platformer game too).
I think pumpkinhead could edit the project a bit and add in functions for sending and receiving code to a server (or any other types of functions that we may need) and we could use these in order to make the game playable (in the summer of course).
The reason that I feel like we should work on and prioritize multiplayer is because not only will we have more keys free, but we might be able to actually have this version of the game finished earlier than if we were to work on story mode.
Then we’ll have something to release - But we won’t release it just yet because
But we won’t release it just yet because if we do release it, we might lose motivation to add the story mode later on, and I don’t want that to happen because the story script is so amazing it’ll get us farther than just creating a game. We could, after finishing the story mode, however, release the online version and give people a “release date” for the story mode, and after the release date, we start releasing a chapter every week… this will help us a lot, I promise. If people will have to wait a week before every chapter, they won’t finish the game in a single day, and they could always play the multiplayer version in between. I should also add that not all chapters will come out in a week… we’ll have to rate the chapters based on their length and how interesting they are as well as how they end in order to determine how long the players will have to wait for the next chapter.
@pumpkinhead, do you think the server could make the game run slower by a huge factor?
I like the idea of starting from a fresh canvas and moving everything there, but I’ll have to agree with pumpkinhead, I think it’ll take some long time… and I don’t want this project to take longer than it already has because I believe that all the work we’ve put in is good enough in order to keep going. Plus, the project has complex animations and code, as well as many assets and notes, and was created with the help of many people… moving things from this project to another one can’t be done by one person. Yes, it’s still possible, but if we miss something during the process it might cause bugs that we might not even notice only after several updates.
I’ve been busy lately, but there’s actually an idea that I’ve been thinking over and over in the mean time… what if we could turn the clips for the characters, with their animations and everything, into text code… have it stored outside of the project… and when the user launches the game for the first time, it starts “downloading” these assets, since they’re text code, by saving them on the computer of the user… and this way… it’ll be able to load the assets while offline. That could help us since then we’ll only load the characters that the user selects into the project, as well as the map frame (if possible).
I also think we should switch from having our audio assets (which take up a lotta space) inside of the asset library to elsewhere, using this code.
Saying that, here are some things we’ll need to consider:
Wow, I always say I don’t have much time to work on the project even though I’ve just written an essay lol
But no worries, I’ll be done with school soon (by soon I mean in June)
Also, happy Ramadan to everyone fasting! Only a few more days are left 
do we need any music or no?
just asking ig
I don’t think the networking should cause much performance problems. As long as the netcode is done right.
The only thing the server would do is matchmaking and allowing contestants to communicate with each other. It wouldn’t store a game state.
I was reading about a way to minimize the effects of network latency earlier. The problem with networking in games is that there will always be an unpredictable delay in input from the remote (other) players, which I call network latency. In order to account for this, we’d need to separate the update function from the render process, which doesn’t seem too complicated. This is necessary since, in the case of the remote player’s input arriving later than usual due to network conditions, it would allow the game to rewind back in time to when the remote player’s inputs were supposed to be received, and recalculate player movements with the correctly supplied inputs.
I also think this means we’ll have to use only frames to measure time instead of seconds. The article I read only mentioned frames as a unit of time. Maybe we could translate that into seconds without any problems? But I guess we’ll have to see. I just feel like there would be a problem since the game would send inputs to the other player once per frame, and the length of a frame isn’t consistent, so having the game depend on that I feel would spell disaster.
Of course this also means we’ll have to fix the huge performance problems
@KringlePrinkles got us covered. Assuming they still check these forums.
Also kringle, have you heard of jummbox the beep
box mod? It has more features, e.g. a mod channel to change tempo or eq filter of instruments while it’s playing.
Well, I’ve been convinced~
WE WILL BE PERSING “ONLINE” MULTIPLAYER!
For anyone is who is free (and is actually part of the team, recognised by me, kringle, pumpkinhead, H.a or baron), the first real task in the right direction is safely removing couch and re-signing the buttons.
Let’s say wasd and mouse 1 for now, all others can be deactivated as of now
I personally use jummbox to make my music
(Also am i part of the team, still confused in terms of my standing in this project)
@pumpkinhead may i ask, you do know how to do all that server stuff right? and you can do it when you get the time right?
I feel like I’m competent enough on this networking stuff to get something working. I did make a working multiplayer demo. And I also did read that entire article, I have knowledge inserted into my thinking organ. I’ll start on it tomorrow, but I’m not so sure I’ll be able to work on the weekdays, since I have school stuff.
well, as long as we find a good way to review all of our code and find bugs, it’s fine. you bring up a good point that i didn’t think about for some reason… this project is giant.
What’s the latest file?
I had a thing I was about to write… but it might’ve been just me not paying attention.
I am in fact alive. I wanted to be sure if everyone is on the same page or wanted a refresher, because I think I might need one.
I want to work on the AI first (to simultaneously learning to program in JS and progressing the project). I’ll then finish the rest of the fighters… at least after going about the idea that Hamzah proposed for improving performance. I’m not very intelligent in the programming sides of things.
Anyways… do we go off of this version?
Right, so I tested the HTML export, but it is doing a weird thing with the camera.
I like the mockup for the winner screen, but when replaying, the hit effects and bullets were not removed (and the hit effects are above the countdown).
The music is not playing anymore when returning to the menu… hmm…
And my re-keybind is not working. Maybe I didn’t implement it correctly. 
When returning to the player select, after playing a match, it is not registering that the two player characters are still selected… but… well… we are already replacing that system with a marker style picker, as baron suggested.
I’ll worry about trying to somehow separate audios into tracks next time, so that I can make the audio volume easier to control.
No, because I’ve made it in FL Studio 20. Also I think I still have it in the other laptop I used.
Is it fine if i use FL Studio instead of Jummbox? I will try Jummbox at some point (and use it) if I needed to get quick music done.
Is there a way to translate this to offline and to have assets come with the game (at least, should we ever introduce a downloadable offline version)? I wanted to try it. Maybe it would help make the game run at a consistent framerate and performance.
And with the “reset” not passing, I do want to have these that Baron mentioned into consideration:
and last one.
I think this is just okay. There was not any sense of progression or variation, so hearing this in a level for long periods of time would, at some point, become boring. Worse still is that we had not considered where this could be used, so it might be unfitting. You could refer to the “document that is linked in quotes here” or we could discuss what you could make. But otherwise, I will handle the music and animations as usual.
Yeah you can use FL studio
I did a hack in the Wick Editor engine to make the game run faster.
This function ticks the children of a clip
As you can see it ticks all the frames even if they aren’t active. Which seems pointless.
I changed it to this
As you can see it only ticks the active frames, the ones that are currently being viewed.
Running the project, I see a huge performance increase. It’s actually playable now. And pkhead blinks way too fast.
Hey all, I’m wondering if you all would use my modded version of Wick Editor in developing this from now on. It’s a lot more performant than the original Wick Editor. However, my version has a different way of accessing sibling clips because of performance reasons. The way Wick Editor did it, with variables, introduced a bottleneck in performance, so I just made it a function I’ll call getClip or something like that. I’d be hosting it via GitHub pages so hopefully none of you have GitHub blocked.
Please answer because I’ll have to rewrite a lot of scripts in this due to that change. Should I make a poll?
With the help of the devtools profiling tool, a bottleneck I’ve encountered is with what I call the script environment initializer. Specifically the fact named sibling clip/textpaths can be accessed via variables.
I’ve tried several ways to optimize it via caching the results of the get activeNamedChildren() function, and measured the time it took to finish the routines on one frame while in battle:
| tick ms | runScheduledScripts ms | |
|---|---|---|
| called per script run (vanilla) | 3.72 | 26.30 |
| called once in tick routine | 33.05 | 5.94 |
| results are cached per frame | 3.69 | 34.31 |
Without get activeNamedChildren() being anywhere in runScheduledScripts(), it takes only ~6 ms to complete the routine – a 76% performance increase. And without that function being anywhere in the tick routine, it only takes ~4 ms to complete that.
So I believe the best course of action would be to completely remove get activeNamedChildren() from the process of script running. This would mean replacing the method scripts use to access other clips, from using variables, to a function that returns the clip with the given name.
Doing this would make the game loop only around 32 ms. Our target is 33 ms. It’s not perfect but it’s at least better than it being 53 ms (a ~40% performance increase). At least on my machine.
