projectussle

[projectussle]

So Long and Thanks For All The Squares

Hello again everyone. I suppose it’s probably not too surprising, but this will probably be the final Project TUSSLE post. It’s been a long time coming, but I can say now that I’ve been officially scooped. Someone else is executing the TUSSLE concept better than I ever could, and I think it’s time to just let the professionals handle things from here on out.

I’m talking, of course, about Fraymakers, which, as of time of posting, has a little over a week left on its Kickstarter. Now, this isn’t the first “MUGEN but Smash Bros” concept to be pitched, but this is the one I feel could very well do it. McLeod Gaming has a very long history with Platform Fighting games, being the developers of Super Smash Flash,and their experience working in Flash’s ActionScript lends well towards making an extensible scripting language for the game to use. Not to mention the credibility they have from being in the indie space for so long getting the prolific guest characters they have so far. Full disclosure, I’ve actually sent emails out to a lot of these developers myself, but have received no responses from any of them. I don’t know how long Fraymakers negotiations have been in the works, but it’s possible this project’s been in the works for years already and I’ve been scooped for longer than I thought I was.

If you were excited for TUSSLE and haven’t already, I urge you to support Fraymakers, whether financially or just by getting involved in the community. I’m definitely going to be making tons of content for it when available, so there’s that to look forward to. The truth of the matter is that I just wasn’t good enough to make this a reality, and if you like the idea of TUSSLE at all, Fraymakers will likely be better than TUSSLE ever could have been, and if you were looking forward to something Fraymakers doesn’t do, chances are it was beyond my abilities anyway.

There have been many people attempting to help out with the project, but the truth is that I’m worse at project management than I am at development, and I could never give anyone enough tasks or direction to be able to make any manageable progress, despite that they were all very talented developers or content creators who were definitely up to the task. Still, in the process of working on this, I’ve drastically improved my abilities in both Python and Unity, as well as leadership, and I hope that my next project, whatever it might be, will be smoother than this one was.

This project’s been with me since before I graduated college, and stuck with me through some of the highest and lowest points of my life. It’s basically been a background process running in my brain. Every time I learned a new programming technique or design pattern I thought “How could I use this in TUSSLE?”, any time I played a new game or watched a show I thought “Could this character be a good TUSSLE fighter?”, I have dozens of notebooks with scribbles of UI mockups or pseudo-code algorithms, many of which are repeated or refined versions of older sketches. I’d go through phases of my life where I’d do nothing but code on TUSSLE all day, and phases where I wouldn’t touch it for months. To be honest, I’m kind of glad I’ll be getting all that mental real estate back not having to worry about it any more. I can dedicate myself to learning things unrelated to TUSSLE without feeling guilty about spending my mental energy on something else while people were eagerly awaiting updates. It’s helped me in my current job as well, a lot of the runtime importing code I’ve written for TUSSLE has actually wound up being used at my job to turn AutoCAD drawings of buildings into an explorable 3D environment in Unity. I’ve learned more about Unity UI than any human being has any right to know. I’ve met some incredibly talented people and watched them evolve into better artists, musicians, programmers, or modelers as they stopped by to give feedback or graciously donate their talents to this troubled project. I hope to see all of you succeed at whatever life throws at you.

Thank you, sincerely, everyone who has followed this project. You’ve given me something to anchor my life to for nearly a half-decade, and I don’t regret the time I’ve spent working on it. You’ve all seen this small indie project and decided to follow it and give your support, and that’s meant the world to me. I’m sorry I couldn’t deliver the project you were all hoping to play, but I hope you’ll all enjoy Fraymakers as much as I am going to, because at the end of the day, it doesn’t matter who makes the game or what it’s called, we all just want to play Project TUSSLE, and I’ll be right along there with you all.

Good Bye, digiholic

#Project Tussle #Fraymakers #Super Smash Bros #gamedev

[projectussle]

A Bundle of Nerves And Insecurity

Hello everyone. Sorry for basically disappearing for almost two months right after going public. I wish I could say I’ve been spending time in the hyperbolic time chamber and would have made tons of progress and have all sorts of characters and features to announce, but that is not the case.

Let’s go back to the last blog post, almost a month ago at this point. Right after posting it, I did as I said I would and started working on the tutorial series. I gathered up the sprites, planned out a moveset, and fired up the character builder to start working on Filia, but one thought kept coming up to the surface as I did.

This editor is bad. Like, real bad. It felt awful to use, lacked all sorts of useful functionality, looked awful, had a terribly confusing layout, and just plain didn’t work half the time. I couldn’t in good conscience subject anyone to working in this editor so I just quietly faded into the shadows in hopes that everyone would forget about me and move on.

Now, it’s probably not that bad, but even know I get a minor panic attack every time I boot up Unity to get back to work. I really don’t know if I’m good enough to make this project work and I’m not sure if I’ve just been wasting my time for the past jesus christ has it really been six years. Many significantly more talented people than I have offered to help with the project, but I am also pretty bad at managing and I end up not having any plans or anything for them to do.

I’m not going to make any sort of triumphant “this time I’ll work harder and push through it!” speech right now, because honestly just hovering my mouse over the Unity Hub on my taskbar is causing my heart to jump up my throat. I feel like it’s unfair to just quietly disappear because I know there’s a decent number of people following this hoping for a release, and I don’t want to leave anyone hanging. I would very much like to finish this project at some point, but right now, I think I need to take it slow. I might need to spend some time writing up some documentation, maybe learning more of what it would take to lead a real proper team. I don’t know when the next time I post will be, but I hope it will be good news then.

TUSSLE is not canceled, but I think I might need to walk away from it for a little bit. Thank you, very much for sticking with me all this time, and I hope it hasn’t been for nothing.

Until next time, Tusslers. Whenever that might be.

#Project Tussle #burnout #anxiety #gamedev

[projectussle]

Git Gud

Greetings, Tusslers! Sorry for being delayed a day, but yesterday I wound up needing to spend some time moving furniture around and found myself unable to access my computer or internet for much of the day, preventing me from getting out the new build!

Been recording the first part of the character tutorial series (expect it very soon!) and ran into several pain points in the builder I needed to address first. Additionally, since I’ve been using a proper team-focused Git workflow at my actual job (goodbye forever, SVN!) I’ve found a lot of ways to streamline and improve my process to hopefully add in more team members in the future.

For one, I’ve actually started using branches! From today onward, the Master branch will contain the current most stable release, intended for general use. The Test branch will have changes that might not be stable, but people who don’t mind potentially game-breaking bugs might find some releases here. It is currently the same as Master, although as things stabilize this will become less of the case. And finally, the Dev branch is where all of my up-to-the-minute changes will be held, at least until I start doing an issue-based merge workflow (which is a bit overkill for just one contributing developer). If you’re interested, and have access to Unity, you can always download or pull from those branches and give them a go, or check out our nifty new Releases tab on GitHub where I’ll be tagging and marking the ready-to-download builds and including a precompiled zip for those of you who don’t want to use Unity. You’ll also find a list of major changes!

This week, it’s mostly builder-related issues, such as various crashes, or missing files, or just plain inconveniences. One cool thing you’ll see in this newest download is an extra shortcut to boot the game directly into the editor! This will speed up production immensely.

With these changes in place, I’ll be able to make more progress on the tutorial series, so expect written and video tutorials soon! Until next time, Tusslers!

#Project Tussle #Feature Friday #Releases #gamedev #Super Smash Bros

[projectussle]

First Week Patch Notes

Greetings, Tusslers! First week back at work, and I’ve spent most of it addressing some of the most glaring issues with the beta release. 

The big one, if you tried to make a character, you might have run into an issue where you would just keep getting Hitboxie, no matter how much you changed. This issue stems from my philosophy with designing the builder, that is “whatever you do, don’t crash.” I didn’t want the builder to crash and have people potentially lose all of their projects, so I made sure that the system would be robust to unexpected things. What happened here, is that whenever you hit “New Fighter”, it actually wound up not generating a proper Sprite Info or Action File, and when the builder was told to load it, it simply said “no”. It seems, in my zeal to make everything crash safe, I neglected having any actual error reporting. I’ll be working on that soon.

On a similar note, depending on your resolution, you might have had an issue of hovering over the save button, only to have it fling itself off into space, preventing you from clicking on it! This has been rectified.

I have also temporarily enabled Unity’s built-in resolution popup to the executable until I get the in-game graphics settings working. This should allow you to run the game in Windowed mode!

You can download an updated build here (all other download links have been updated as well). I don’t think I’ll be doing weekly builds from here on unless something major changes, at least until I can set up a continuous integration system to automate the process.

I know a lot of you are waiting for the tutorial series to learn how to make a fighter. About that...

Yeah, I’ll get back to you when I manage to figure out how to make a fighter. Having some trouble getting everything working, so it’s gonna be a bit longer, sorry! I might be able to have it out this weekend, or maybe next week. Until next time, Tusslers!

#Project Tussle #Feature Friday #beta #gamedev #super smash bros

[projectussle]

Vacation Over, Back To Adventure!

Greetings, Tusslers! Hope you all enjoyed trying out the beta earlier this month, and thank you to everyone who reported bugs! A quick non-friday blog post today just to let everyone know that I’m back home and ready to get back to work! I’ve got a few major pressing bugs to take care of that hopefully won’t take long, then I’ll begin working on a tutorial series to let everyone know how to make a fighter! Feature Friday blogs will be continuing as usual from here on! Thanks for your patience everyone. Until next time, Tusslers!

#Project Tussle

[projectussle]

No blog post this week, still out of town at ALA 2020! If you're in the Los Angeles area and going to the convention, feel free to stop by my wife's art booth! Table L2

#ALA #AnimeLosAngeles

[projectussle]

The Day Has Arrived

Greetings, Tusslers! Today’s a big day! As promised, I am releasing Tussle in its current state as a playable beta for all you wonderful Tusslers out there to get your hands on and experience! It’s definitely lacking a lot of features, but it’s always good to at least have some proof of progress being made. I’ll go over some of those missing features after I get to the fun stuff!

Downloading and Running

You can find a download to the game at Itch.io or on this blog’s Downloads page. Currently the game is only available for Windows, as I do not have access to a machine to test any other platforms and would not feel comfortable releasing an untested executable on any other environments. Linux users, stay tuned for more details.

Missing Features

Here are a few of the notable missing features and known bugs to be aware of. This is not an exhaustive list, but are a few of the things that will be added in the coming weeks/months.

Most menus are using placeholder assets and lacking animations

UI Components in general might not anchor to specific aspect ratios properly leading to misplaced buttons or floating text

There are no loading screens. This is particularly noticable when loading a battle from the fighter select screen, or returning to the fighter select screen after the results.

Shielding, Dodging, Ledge Grabbing, Knockdowns, and Grabs are not yet available in-battle

Articles, including particle animations, projectiles, and other spawnable objects are not currently available

AI fighters are not available, the only way to play is multiplayer.

If the game hangs, it will not auto-close. If Escape does not work to exit a match or a menu, you can close the game with Alt+F4

Crouching is temporarily disabled for Hitboxie due to a bug

Several of Hitboxie’s moves, including every special move, are currently not implemented.

When a joystick or gamepad is connected, the game is no longer able to differentiate analog and digital directional input, which means key presses are registered as smashes (rather than needing to double-tap). This means that you can no longer “tilt” on a keyboard if joysticks are in use.

Some joypads do not play nice with the button setting screen. I am unsure what causes this, but in many cases, those joysticks will have default mappings that might still be playable.

The results screen can sometimes list “Phantom players” who were not actually in-game.

The Character Builder is full of mis-aligned text, fuzzy text, small text, improperly resetting scroll windows, most scrollable windows have no visible scrollbars, and is generally full of bad UX and is ugly. This is being worked on.

The character builder will always open Hitboxie as a default fighter. You will need to manually load a different fighter to begin editing.

There is currently only one stage, and no way to add any more.

There is currently no way to change the music for the menus or stages.

Many of the settings are not being used (such as some graphics settings, and settings pertaining to dodging and teams), but they will still save to your settings file and will not need to be re-enterred when these features are enabled.

...and tons more that you can report or find workarounds for in our Discord server!

Character Builder Tutorial Series

This past week, I’ve been gathering input from various sources to decide what character should be featured in a series of video tutorials, and the people have spoken. Without further ado, I introduce the next character to be developed for Project TUSSLE with a series of video and text-based tutorials:

Filia from Skullgirls joins the roster! Over the next few weeks, I’ll be releasing video walkthroughs on how to use the character builder to create a fighter from the ground up! In the meantime, I’ll be writing up a simple tutorial, along with some proper documentation, over the next few days. Stay tuned for a non-Friday Feature Friday on how to use the builder!

What’s Next?

With this release, I’m going to be monitoring comments and discussions through various mediums, but I will be spending this next week out of town working at Anime Los Angeles, so I’ll be away from my computer to fix any bugs or add any new features. I will be active on the Discord, the Subreddit, and Twitter to answer questions, but major fixes will be delayed until after I return the following Monday (January 13)

I hope you all have fun with the beta! I look forward to seeing some of the content you’ll all create! In the mean time, I think I need a nap. Until next time, Tusslers!

#Project Tussle #gamedev #super smash bros #feature friday #release #early access

[projectussle]

An Apology, An Announcement, and A Promise

Hello everyone. Another out-of-character post today to talk a bit about a problem I have. I’m very, very terrible at finishing things. My hard drive is a graveyard of nearly-completed projects. Whenever I get to the point where the ending is in sight, I just sort of... lose my motivation. Maybe it’s something about getting the satisfaction of completing something without actually getting it over the line; maybe it’s a fear of launching a sub-par project. I haven’t really worked on TUSSLE in a few weeks. I’m very near done with the builder, but there’s still a lot that needs to be done in order to make a presentable project. You can only launch once, after all.

That’s why I’ve decided to try to break the cycle this time around. I’m going to set a hard deadline, at which point, whatever state I’m at, I launch. No more “in a month or two” or “sometime in winter.” I’ll have until then to make sure the project is at a playable state and maybe once it’s in people’s hands it’ll be easier to do the remaining work on it.

With that said,

Project TUSSLE Will Release in Open Beta on the First Blog Post of 2020, on January 3rd

Now, I want to reiterate that the game won’t be done, it will be playable. Many features you might consider quite important will be missing. I’m going to be spending the remaining time attempting to build a professional-enough framework that people might be interested in coming back. Fighters made for this version might not be compatible with a finished product, although I’ll do my best to make something that will convert or update them if necessary to avoid wasted development time.

This game has been an albatross around my neck for nearly a half-decade now. Since then I’ve graduated, gone through multiple jobs, some good, some miserable. I’ve had lots of help from people across all disciplines, and I’ve grown in those fields as well to learn to communicate with teammates and collaborators. I’ve gained family, and lost family. I’ve seen an entire Smash Bros game be started, released, and expanded in the time I’ve spent just on the character builder. Still, I’ve pressed on, often alone, though not for lack of help. My own lack of organization and consistency has made it difficult for me to communicate with collaborators and many have drifted off to better things.

When this alpha releases, I will be reassessing the response. I’ve dragged my feet so long I’ve been beaten to the mantle of the first customizable platform fighter by Rivals of Aether’s workshop, and I’m unsure if this is a project people are still interested in. If there are still people who want this to happen, I’ll do my best to get it into the hands of people who are better at this whole development thing than I am and stop trying to one-man army the whole thing. After this release, I will gather a team, and I will finish this game. Even if I have to pay for it out of my own pocket. I will see this game finished even if I’m not the one who gets it over the line.

Thank you, everyone who has been following. I’m sorry about the length of time you’ve had to wait, but I hope that it will be worth it.

Until next time, Tusslers.

Until next month, Players.

Until next year, Friends.

#Project Tussle #gamedev

[projectussle]

Triumphantly Returning to Where We Were Months Ago

Greetings, Tusslers! Now, before you get discouraged by the title, I want to start off by saying that this is a very good week of progress! You see, for the longest time, I’ve been using a combination of hard-coded C# scripts and a conversion from pyTussle for Hitboxie’s actions. This action file broke a while back when I changed the way actions and animations were structured, and since then I’ve been nearly unable to actually control the character in game.

What I’ve spent the past week doing, though, is rebuilding Hitboxie’s action file from the ground up in the builder. This is a good way to iron out the remaining kinks in the process. There were some things I needed to manually edit in the JSON files related to animations that don’t have UI yet, but doing things like building the hitboxes was quite easy with the new layout!

From here, I’ve got a lot of user-friendliness stuff to work on, like saving/loading, hotkeys, and testing, as well as working on the article system for projectiles and other animations separate from the character. I’m not sure which one I’ll be working on next, but hopefully at least one of those will be done by next week’s blog post. Until next time, Tusslers!

#project tussle #feature friday #gamedev

[projectussle]

Play Time!

Greetings, Tusslers! Hope you all had a great Halloween! I’m back in action trying to wrap up the last few things the builder needs to be ready to be rolled out for testing. There’s still lots of small things to do, but the ending is at least in sight!

Today, I want to show off a feature that’s pretty much expected to be there, but hasn’t actually been implemented yet -- the play button on the timeline! This will play through the animation at whatever speed you’ve defined it at. You can continue to edit settings as the animation plays, but know that you won’t be able to edit the “current frame” subactions, since the current frame is constantly changing!

Additionally, I’ve fixed numerous crashes involving having text boxes empty when the game was expecting numbers to be there (empty number boxes are treated as “0″ for the sake of things like determining the frame rate of an animation or the length of an action)

#Project Tussle #Feature Friday #gamedev

[projectussle]

The Usability Update

Greetings, Tusslers! There’s a term that gets thrown around in office environments called “eating your own dog food”. It basically means using your own product to do work in order to figure out how it feels to use. This has been what I’ve been doing lately with the builder, and it’s given me some great insight into the pain points that needed to be ironed out.

One example of this, selecting your action from the menu. A fully-featured fighter will have a lot of actions, and it can be hard to find the specific ones you’re looking for, so I put in a search box where you can type in something and find all the actions that contain that string of text somewhere in the name, so you can type “forward” to get your forward tilt, your forward smash, your forward throw, and so on.

There will also be similar filters for other things that might get difficult to navigate, like the CreateSubaction menu. I haven’t actually made the graphics for those boxes yet since it’ll take a bit of re-kajiggering of the grid-based layout those panels use, but all the code’s there and working for it, so it should be a lot faster to make content when the alpha is completed.

Speaking of which, things are starting to stabilize, and the builder is at least somewhat usable, so there might be a way for you all to get your hands on it pretty soon. It’s still missing some pretty key features like articles and grabs, but I hope it’ll serve as a decent proof-of-concept in the future. Until next time, Tusslers!

#project tussle #feature friday #gamedev

[projectussle]

Let’s Make Some Hitboxes!

Greetings, Tusslers! First off, I know it’s not Friday, and I have no excuse but that I lost track of time. I can make up for it, though, because today’s update is a really good one! One of the most important things in making a character is getting the hitboxes right. It’s where you define what your attacks actually do, so I want to make sure they’re super easy to view, edit, and change. With that said, I present to you, the new and improved “CreateHitbox” subaction editor!

Now, I know what you’re thinking, but this isn’t me refactoring a perfectly usable thing into a better form as I figure out more about Unity and C#. The plan was always to allow for custom editor windows for subactions, and the one’s you’ve been seeing have been the default editor window (that I expect about half of the subactions will use in the end). The system has been in place for a while, but I haven’t had any custom editors to use with it until now! Here, you can see a one-screen representation of all of the hitbox data you can create a hitbox with. Let’s break it down bit by bit here.

Up on the top row, you see two text areas, one for the hitbox name, and one for the lock group. “Name” is pretty self-explanatory, it’s what this hitbox is called, and how you’ll reference it in other Subactions, such as activating and modifying it later. Lock Group is a little more involved. I believe I’ve explained it before, but for the sake of keeping it all in one place, only one hitbox per lock group can actually damage the target. When two or more hitboxes hit the target at once, it will choose the first hitbox (in order of the “CreateHitbox” subactions) to actually receive the hit from. This means you can use multiple hitboxes in the same lock group to essentially combine to create a single oddly shaped hitbox, or to define sweet and sourspots that you don’t want to both affect the target at once. You are free to leave this one blank, and if you do, it will be treated as if it were in a lock group of its own and always work (even if you have multiple hitboxes with blank lock groups). In most cases, especially if your attack has only one hitbox, you will probably be fine leaving this blank.

On the left side, there is a box labeled “position”. It’s fairly straightforward as well, just know that the X and Y boxes are the center of the hitbox, and are positioned relative to the center of the sprite on the fighter. So you can see here, a box centered at 0,0 is positioned right smack in the middle of Hitboxie’s sprite. Any changes you make here are reflected immediately in the hitbox up above in the viewer, so you can adjust your positioning precisely and see your results to make sure you’re getting what you’re expecting! And, thanks to the resizable viewer boxes, you can eyeball the general location of your hitbox before making a few final touches manually in the numbers.

Moving on to the right side, there’s two columns of data. One for the base values, and one for the “charge deltas”. We’ll get to charging later, so let’s go down the list of values first. At the top of the column is the launch angle. This is in degrees, with zero being straight forward, 90 being straight up, 180 being straight backwards, and 270 being straight down. You can also use negatives and values greater than 360 to loop around, so -90 is the same as 270, 390 is the same as 30, and so on. Also note that “forward” and “backward” are based on the direction the owner of the hitbox is facing, not the target. So, if you are facing to the left, an angle of 30 will launch the foe to the left and slightly upward.

Damage, Base Knockback, and Knockback Growth are all part of the launch power formula. The formula is a bit mathy, and this blog post is already getting quite long, so I’ll probably have a post about the formula itself in the future, but if you’re interested, it’s based on the Brawl formula (which is mostly the same as the Melee, 4, and Ultimate formula except when it comes to how air resistance factors in to slowing the fighters down. Again, a future blog post for those mechanics, but to answer the question, it’s mostly just because I know more about Brawl’s physics from my modding days and if I can do the research I’ll have an option to toggle Ultimate-style “balloon knockback”). The long story short: Damage is how much percent damage the move does to the opponent. Base knockback is the amount of flat knockback the move does regardless of damage, while knockback growth is the factor that determines how much the knockback increases based on the target’s damage.

Now, onto the charge deltas. In most hitboxes, these will be zero, but for things like smash attacks and other chargable moves, you can input an amount that each “stage” of charging increases the values by. There is a subaction called “ChargeHitbox” that lets you, in one subaction, modify those values by that amount, and specify a maximum charge level. If that level has not been reached, it will rewind the action a set number of frames to play the animation, and when it reaches that charge action again, at which point, it will loop until fully charged or the frame is manually advanced (usually by checking if the button was released). These values are a flat addition every time ChargeHitbox is called, and if you multiply them by the maximum charge level and add back in the starting value, you’ll get the final values for damage, base knockback, and knockback growth of a fully charged hitbox.

And finally, the bottom left section is what I refer to as the “advanced options”. In a majority of cases, you won’t need to touch these. Still, it’s good to know that you have these options, so here’s what they do: The shield damage multiplier is a multiplier applied to the damage on block to change how much shield damage the attack does. You can use this if you want an attack to be particularly effective against shields (Consider Marth’s charged neutral special) or even to have a powerful attack that’s safe on shield! Similarly, shieldstun multplier is the same, but applied to the amount of time your target is locked in shieldstun. This can be handy for a move that might be a bit unfair if too safe on block, or to make a move that can set up for future shield pressure by making the opponent locked down longer. At this point, it should be easy to figure out what hitstun multiplier means, but it is another multiplier to how long your opponent is kept in hitstun when struck. An example of a high hitstun multiplier would be something like Zero-Suit Samus’s neutral special, or Lucas’s down smash. Also try setting this to zero for a move that doesn’t interrupt your opponent at all, like a Fox laser!

The last one requires a bit of history. What the heck is a “Sakurai Threshold?” If you’ve ever looked at a data dump of Smash Bros hitboxes, you might have seen a lot of angles that have an angle of 361. This is a placeholder value for what is known to the community as a “Sakurai Angle”. It is a special angle that changes based on the amount of knockback dealt. If the knockback is low, it will move the foe horizontally, keeping them on the ground for follow ups, but if it’s high enough, they’ll get sent flying at a specific angle depending on the game. It is an interesting mechanic meant to keep grounded fighting rewarding, while still allowing those moves to potentially kill at very high percents. The drawback of this mechanic, however, is that the damage threshold to switch angles is fixed, and the aerial angle is always the same. This can lead to some angles feeling very common, and lead to a lot of moves feeling the same. In TUSSLE, however, both of these values are editable. The threshold you set here is an amount of knockback that needs to be exceeded before the angle you’ve specified is used. If the knockback is less than the threshold, they’ll be moved forward along the ground. This only applies to grounded opponents, aerial opponents will always be moved to the hitbox’s knockback angle. This parameter is going to take some experimentation to find good values for, but if properly used can make for some very interesting dynamic hitboxes! If you don’t want to bother, keeping it at zero means that your knockback angle will always be used!

And that’s all the current parameters a hitbox can be created with. If any new parameters get added, I’ll definitely write about it. Again, apologies for the late blog post, but I hope I’ve made up for it with a big information-packed post! Until next time, Tusslers!

#project tussle #feature friday #gamedev #super smash bros

[projectussle]

The Forest is Thinning...

Greetings, Tusslers! As promised last week, I’ve got (most of) a base action file done in TussleScript! I was planning on talking about that this week, but an interesting development has happened this week. In case you haven’t heard, the netcode framework GGPO has gone open-source!

If you’ve been hanging out in the Discord, I’ve brought up GGPO before, and if you’ve played online fighting games like Skullgirls, you’ll have encountered it before. Basically, GGPO is a framework for making online games that depend on strict timings less frustratingly laggy online. Basically, the system assumes your opponent will be doing whatever they’re currently doing, and whenever it actually gets the input from the opponent, it’ll “roll back” the game state to when that button should have been pressed, and then re-compute what the game should be if that had happened, then continue on to the next frame would be.

One part of this is that the game state needs to be deterministic and reversible. What this means is that every frame needs to be constructed out of things that can easily be stored and retrieved in a data structure, and that given the same inputs, the game would always play out the same. I knew this was a requirement for GGPO-style rollback netcode, so I’ve tried to make TUSSLE compatible with this system.

Now that GGPO itself has been released, I can make sure what I’m working on is compliant, so your network experience will be as smooth as possible. Currently, the library is a C++ library, but I have been looking into it anyway. Chances are someone will be making a Unity conversion (if not, then I should be able to, when I find the time). This means that, for the first time in at least a year, I have left the builder to look at some of the underlying engine code. I’m finding some things that wouldn’t quite work out with GGPO and, despite what I said about refactoring earlier, are going to need to be addressed if netplay is to be possible.

Still, I do want to get at least an alpha out by the end of the year, so I might shelve this engine rework for now, and leave online play as a 2020 goal. I’ll need to see how much time I wind up spending on this, but I’ll definitely try to catch myself before I spend too long wandering!

Until next time, Tusslers!

#Project Tussle #gamedev #ggpo #feature friday

[projectussle]

Introducing TussleScript

Greetings, Tusslers! The builder is great and all, but what if you need to make dozens of actions all at once? Say, for example, you’re making a base action file that needs to have a default implementation of every single action? Well, you could try manually clicking through pages and pages of actions, or, you could use the new addition to the game, TussleScript!

What is TussleScript? Well, put simply, it’s a way to take a block of text and turn it into an action. In order to explain it a little better, let’s take a look at an example TussleScript for the Stop Action:

You can see the first line is an action definition. You declare an action by putting in “Action [Name]” and end it with “EndAction”. You can see that this sort of start/end tag system is a theme here. After starting an action, you can define properties like length, the animation name, and the action to change to on exit. You can also see that the text blocks are indented whenever they are inside a block, this indentation is not required, and is only used for making the script easier to read (and I highly recommend it, these things can get complicated pretty quick!)

Inside of an Action, you can define a “Group”. These are a specific set of subactions that are called at a particular time. For more information on these groups, see last week’s post. Inside of a group, each line is a subaction. To call a subaction, enter it’s name, and it’s arguments, in order, inside of parenthesis. Note that every argument is required, even if you just use the default value. You can find an automatically updating ever-changing document explaining each Subaction here. Subactions are being added as needed, and many more will continue to be added throughout the game’s lifetime.

As useful as this is, you might be wondering two things. One, why did this take so long, and two, why is the builder even necessary at all? The answer to both is that TUSSLE should be, first and foremost, accessible. People might just want to open up a fighter and mess with a few variables, which would be a bit tedious to do in a TussleScript. I wanted to make sure that the subaction system worked in the visual builder before spending any time working on a text-based character script. And as for the usefulness of the builder, there’s a lot of things that will be significantly easier to do in the builder, namely hitbox and hurtbox positioning. Being able to see the hitbox’s position directly as you’re setting it will be a great way to make sure your moves fit the animations. Additionally, being able to scrub through the animation frame by frame can help catch stutters and other inconsistencies in the animation itself that might be difficult to pick up on in normal play.

I hope that this new scripting language becomes a useful tool in the arsenal of a character designer, and I look forward to making things even more streamlined and simple in the future. Until next time, Tusslers!

#Project Tussle #gamedev #Feature Friday

[projectussle]

How To: Actions

Greetings, Tusslers! It’s been quite a week for me. The release of Rivals of Aether’s workshop has taken the wind out of my sails a bit, and I’ve been a bit down since it’s my own fault things have progressed this slowly. On the other hand, it proves that there’s a bunch of creative people out there yearning for a tool to express themselves in the purest art form there is: smashing each others face in with silly characters.

If I can’t be first, then I’ll have to be best.

After an initial downturn, this one-sided rivalry has lit a fire in me that I intend to harness to keep this machinery going at an overdrive! I spent this week working on creating the base action file (the default actions you’ll get when you make a new fighter and choose to generate action stubs) and fixing bugs as I go. Turns out there were only one or two big bugs causing almost all the headaches I had to deal with, and buckling down and clearing them means that the builder is a lot more stable and further along than I expected! There’s still some things missing (and one incredibly frustrating case of two panels with identical settings behaving entirely differently when dragged) but it’s somewhat useable!

I’ve been talking with some people about making their own fighters, and one common question getting asked is “what do all of these categories mean? How do I navigate an action?” The answer to which is the post image today! This quick little animation explains it in brief, showing you how the game would read through a three-frame-long action, which categories get activated when.

Set Up is called when the action is first switched to. Then, every frame, it will check for state transitions (see if you’re in the air, been hit, or are pressing buttons) to change actions. From there, it enters a “tick”, which is one frame of the action. There is a small chunk for before and after the tick activates, then a big chunk of processing in the middle where the subactions for that frame are executed, the physics is calculated, and movement happens. The very last frame has a special after tick, usually used for transitioning back to idle after the animation is done, and finally a Tear Down that is always called before changing away from an action. (NOTE: The Set Up of the new action is called before the Tear Down of the current action. This is so variables can be passed between them easily)

Additionally, I’ve spent this week talking with some people about some possible crossovers, collaborations, and cameos, as well as working on a few of my own! Nothings been officially confirmed yet, but rest assured, there’s some big things happening behind the scenes for TUSSLE!

Until next time, Tusslers!

#Project Tussle #gamedev #feature friday #super smash bros #mugen

[projectussle]

Let’s All Agree To Never Refactor Anything Again

Greetings, Tusslers! Today, I’m gonna vent some frustrations a bit, as well as making a bit of a promise. Y’see, I like to code. I like to structure projects and optimize things and write as clean a code as I can. This can sometimes... cause problems. I’m not a game developer by trade, so a lot of the structural and architectural elements of game design are beyond me, but I’m always learning more! What this means is, after learning about things like properties, events, delegates, and other nifty little things that I haven’t used in my daily programming life, I want to use them. Problem is, I already wrote a bunch of code before then that really should have used it!

So I refactor. For the non-programmers, “refactoring” is a term that basically means rewriting code to perform an identical function in a different way. This can mean cutting a repeated block of code into its own method, splitting or merging classes, or even just changing variable names to be more readable. I’m a bit of a refactoring addict.

So much time has been spent writing and rewriting and reworking and retooling the same few systems over and over that I’ve been spinning my wheels and getting nowhere. So, when I found myself earlier this week spending two entire days completing a “simple” refactor, I decided that something’s gotta give if I’m to complete my promise of releasing this game by year’s end.

First, let me tell you a tale. A tale of frustration and woe, and how much of a “iceberg” one small change can be. The Fighter Info file was initially planned to be essentially a data store, with a few public fields and some saving and loading methods. However, as needs evolved, it became clear that the Fighter Info file should have more data, namely, the actual instantiated data that the info file points to. Basically, while it originally only had “sprite_path” to point to the directory, I found I needed a “sprite_list” that actually gets all the sprite objects out of that directory. These were also added in as public fields, set during the “Initialize” method of the fighter info, that could be referenced after the fact. Earlier this week, I saw this file and thought “Well, if I need to access these fields and the fighter hasn’t been initialized (like when creating a brand new fighter) then the game will crash! And if I’m never setting these, only reading them, I can use a property with a private setter!”

So I did. I replaced the public fields with properties with a public getter, and setting the values of the instantiated data whenever the text form is updated, so you never need to actually set “sprite_list”, you’d just get that for free whenever “sprite_path” is set. Super clean right? Wrong. The first problem that came up is that properties don’t serialize to disk. I had to keep a private field around to store the data of the public property, but private fields don’t write to disk either. I quickly put in a [SerializeField] flag to get them back in, but it was too late. I had re-serialized every FighterInfo in my build with no data, several of which were experimental and not in version control yet.

So, after spending some time remaking the ones of those that needed to exist, and saying a somber goodbye to the ones that didn’t, I tried to fire up the builder again. Errors. Turns out I was using Reflection, a style of programming where you can call methods and variables and whatnot by value, rather than hard-coding in the name into the script (It’s a complicated thing to explain here but it basically lets me put C# function names in things like Action Files and call them from there) and the GetField() method is different from GetProperty(). So I had to fix every input box in the builder to use a new boolean flag telling it whether to look at properties or fields. There’s a lot of those in lots of hidden places and I feel like I’m gonna be picking reflection issues out of my teeth for days to come.

And all of this because of one small “refactor”. “For convenience” I said. The fool.

So here I sit, a week down and nothing to show for it. I’ve got to stop letting “perfect” be the enemy of “good”. I’ve been spinning my wheels in the mud way too often lately. I have decided that I am not going to be refactoring perfectly functional code until at least Beta. So if I post any blog posts for the rest of the year containing the word “refactoring” I want all of you to go DM me a slap gif on Twitter.

Until next time, Tusslers!

#Project Tussle #Feature Friday #gamedev

[projectussle]

Hurt At Any Size!

Greetings, Tusslers! This week, I’ve got a nifty little change here that finally puts a neat little bow on the whole “hitbox positioning” saga I’ve been working on for a while now. You can see here the handles that you can drag around and reposition the hitbox right on the canvas without needing to enter any fiddly little numbers to make big adjustments (although it’s still recommended to use them for small adjustments to make sure you’re getting what you are expecting!)

Also this week, I’ve worked on the “new fighter” process, which should hopefully now be robust to weirdness (it would crash if you used a template fighter, for one). I’m going to try to make a fighter straight through, which should give me a good idea of what squeaky wheels need a bit of greasing!

You might also be noticing the much better quality of the video in this post. I finally decided to just stop trying to use Tumblr’s abysmal gif system and just upload the video onto the Project TUSSLE Youtube channel that had previously just been used for livestream VODs. I haven’t really used it in a while, so I think this is a good use for it!

Next week, I’ll have the results of my “New Fighter” testing and I’ll have ironed out a few kinks in that process. Until next time, Tusslers!

#Project Tussle #Feature Friday #gamedev