[RGSS3-WIP] Grid Battle System

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
VXA Grid Battle System
Based:
Theolized SBS (the thread need to get updated omg)
Background:
There was a story of a long-awaited myth in the RM community. It's when there was never once a grid battle system for public released even though there are some RM games that use a grid battle system. Honestly, after tried to create the system back in 2015, I realized how much trouble to create such a system, especially if you plan for the versatility of the system. Thus I'm kinda abandoning the project for years. Now I want to revive it back.

Introduction:
This system aims to create a field of grids on the battle screen where actor and enemy have their own place, pretty much like Megaman Battle Network (Disclaimer: I never played the game). You know the rest...

Features (currently have & planned) :
  • Targeting range (Skill can be ranged, or melee)
  • Dynamic AoE damage (1x1, 3x3, linear, spread, all area, or even has an unusual shape. Can change in the middle of action sequence too)
  • Separate grid for actor and enemy OR merged grid.
  • Allowing to target an empty grid (or not).
  • Field-effect.
  • Aura effect.
  • Smart(er) enemy AI (Probably not gonna happen soon).
Early preview:


Early video preview (2015, pretty old I guess):


Latest preview (April 2020):

Documentation teaser (not completed yet):
How does it work: http://wiki.crescentsun.space/grid:api
Targetting: http://wiki.crescentsun.space/grid:targeting

The biggest challenge:
Currently, one that left me speechless is how should I create the config for enemy AI. There're so many conditional branches that I can't get my brain to work to make a simpler configuration for those who can't script yet still versatile enough. Directly editing to the enemy pattern using your scripting skill may provide the best work, but I'm pretty sure not all people gonna like that.

On the other hand, everyone has a different vision when it comes to the grid battle system. Some people like to see increased stats when an actor is in a certain grid. Some people prefer can only target any enemy in front of them. Any many more that I believe you also have different idea from it. Making a framework that could satisfy these ideas isn't like a walk in a park. Thus I believe this leads to no one actually created the system.

I created this thread frankly just to see if this script is still worth pursuing after all the shift of RM trend and all the trouble I was putting it into this little script. If you're (still) interested, please let me know. Also if you have a suggestion, please also let me know.

-------------------------------

Q: Port to MV, please?
A:
No.

Q: When this is going to get finished?
A:
As long as how long does it take.

Q: I have an idea, you should add feature X and Y. Will you implement it?
A:
I will consider it. If it's too project-specific, maybe not. But if it serves of "grid battle system should have this features/option" I may consider implementing it.

Q: I'm using battle system x, will you port this for this battle system?
A:
No.

Q: How do I use this?
A:
No usable build yet, stay tune.
 
Last edited:

richter_h

Eh? Sweetroll?
Veteran
Joined
Apr 26, 2013
Messages
597
Reaction score
1,027
First Language
Indonesian
Primarily Uses
N/A
I've seen this for a while, and surprising you decided to make it public. Not that I'm concerned, tho, but I think I can help in the AI department, maybe?

A lot of potentials, but that'll be another can of worm. Maybe I'll get into this once my current project is done because why not? Grid System rules, mate.
 

Isabella Ava

Veteran
Veteran
Joined
Sep 13, 2016
Messages
635
Reaction score
756
First Language
English
How lovely, i wish this was for RPGMV 。:゚(;´∩`; )゚:。
 

ScoopJohn

The guy who asks too many questions
Veteran
Joined
Sep 6, 2013
Messages
254
Reaction score
33
First Language
Italian
Primarily Uses
RMVXA
After a year since i've wished to have a sort of Live-A-Live battle system, i can't believe in my eyes this came out from nowhere and i am loyal to wait for this to finish.
 

Engr. Adiktuzmiko

Chemical Engineer, Game Developer, Using BlinkBoy'
Veteran
Joined
May 15, 2012
Messages
14,696
Reaction score
3,008
First Language
Tagalog
Primarily Uses
RMVXA
That AI configuration thing is the main reason I never wrote a grid type battle system.. Too much additional areas of consideration especially if we add things like different target areas, friendly fire, movement and so on.. Feels like I will never finish a game if I do that. Then if you make it a public script, you start needing to think how to make it configurable for people who cant script, which is a whole new level of hardship.

I really do hope you finish this though, I think there are still a lot of people who will find it useful, as long as you dont take too long to actually finish it xD
 
Last edited:

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
I honestly just want to create a configuration for the enemy. If it's done, all I need to do is to re-debug all the things to make sure it's working. Then I will release it with a very basic features. They need to deal with it for a quite moment. Until maybe after I gather lot of opinions and try to put em together, then update the functionality.
 

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,410
Reaction score
4,809
First Language
English
Primarily Uses
RMVXA
Hey Theo - looks like the start of a nifty combat system. Figured I'd offer up some general thoughts and ideas on the system as it looks in your old preview, and on the AI, which you mentioned you're struggling with conceptualizing. In fact, I'm creating a similar system (in GameMaker Studio 2) for a future project "How Badly", which also uses separate grids for enemies and allies (screenshot in spoiler below), so I've dealt with a lot of the same issues and opportunities that you probably have.

How Badly Battle Screen July 2018.png

On Grid-Based Systems and Movement
One of the major weaknesses of most combat systems that utilize a grid is the amount of "downtime" inherent in moving units around in order to get them in range to attack (not only are some turns spent without attacking, but even on turns where units can attack, there's still the time they spend moving). Where the spatial element doesn't add that much to the battle, it's wasted time. Where it does add a lot to the battle, it's worth it but it still slows things down (which is why tactics games tend to have far fewer encounters than standard turn-based RPGs).

Now, your battle system has two separate grids, which seems to mean that movement is a little less important and it's easy to at least target someone on the enemy team on turn 1 no matter where you start your turn. Yes, this means less wasted time. But it also means that while positioning will be a big consideration in combat (for AoE damage, etc.), actual movement will be a much smaller one. Based on your thread and video, I'm led to believe that:
  • It's possible (and trivial) to move to any tile on your own grid, for free
  • The only two reasons to move around are to avoid enemy AoE's (or create better ally AoE's), or to get into range to attack an enemy
  • All things being equal, it's safer to be in the backline than the frontline
From this I'd conclude that the act of moving around is more of a menial "bookkeeping" task, and less of a strategic consideration. If you need to move forward to attack an enemy because of a range limit, you do it; otherwise, you move to the backline and use your action. There's going to be a lot of this "bookkeeping" going on, and it's going to unnecessarily slow down battles. You could go the route of having characters move into the necessary range automatically a la Skies of Arcadia or Trails in the Sky, and that wouldn't be too bad. But my instinct is that it might be ideal to discourage battlers from moving around too much by turning free movement into a very limited resource. For example, based on a battler's Speed, they generate some amount of free movement each turn (probably a fraction of a tile), which accumulate if unused. On their turn, they can spend (full) tiles they've earned to move around the grid as in your current system - spending that free movement in order to move. Now the player needs to actually think about how they position their characters because it will have more long-lasting effects. You could also provide the designer the option to allow unlimited free movement as in your current system, for designers who don't want this kind of complexity in their game. (In my own system for How Badly, I allow the player to move their characters around, but I force them to expend that character's turn in order to do so. Range isn't a concept in my system, and movement tends to slow down combat, so I want the Move action to be a rare choice that's only used where powerful AoEs make it worthwhile.)

Ideas for Mechanics and Skills
Allowing skills to change the position of targets on the grid, or even the skill user, on the grid would be a cool feature that would really deliver on the greatest strength of your system, which is creative AoEs and positioning around them. For example, a gravity spell could pull nearby enemies toward a certain tile, a hammer blow could knock them backwards, and a rogue's Hit and Run state could move the Rogue to the back row after attacking.

While not appropriate for all games, highly-tactical games could benefit from a Line of Sight feature where some skills require a direct line of sight from the user of a skill to the target in order to be used. Most likely this would only be used on certain types of attacks and skills (bow and arrow attacks, "physical" magic such as fireballs, etc.), so you could have this consideration only be used where a notetag exists on the Skill to check LoS. Therefore, designers who don't want to use this feature at all could simply not add the notetag to any skill.

One final idea is to allow skills to create "walls" (or other "objects") in empty tiles on the grid, in order to stop enemies from moving around their grid, and even to block LoS attacks. Walls would essentially block any battler from moving into a tile. You could even allow the designer to specify, for some Troops in the database, that walls should pre-exist in certain slots for that troop if possible. This would allow the designer to design troops that require a very different movement strategy than usual! Perhaps characters need to snake around each other to get in range to attack... or perhaps the backline is off-limits and everyone is vulnerable!

About AI
The simplest way I can think of to handle AI for such a system (and admittedly, it's still a moderate job) would be to tap into RPG Maker's default algorithms, and modify them so as to ensure that an action is possible before choosing it. I'd probably have it pick a random skill from the enemy's movelist, based on priority in the Enemy Actions box on the Enemies tab, and pick a target right afterwards. Then, I'd check whether there's a tile that the enemy can move to where they can launch this skill on the targeted battler. If it's possible, the action is chosen, the enemy moves (if necessary), then the enemy uses its skill. If it's not possible, the random move selection is re-done. A "default" action (such as Do Nothing or Guard) could be allowed for enemies who go through the loop some large number of times and still can't find a valid skill, to prevent hangs.

If you want to allow for a more sophisticated AI - and I'd avoid adding this until after you've released the first "complete", working build of your script - then a Points system could be a good way to avoid ridiculous amounts of Branching, as well as offer the player a bit of flexibility as to how they utilize your AI. Enemies could forecast what the direct effects of using a certain move would be, assign points to each aspect, and choose the move that offers the highest point total.

Examples of direct effects would be: "I will deal damage", "I will apply a state", "I will heal an ally", etc. The AI might award 1 point for each 1% of HP it expects to damage an opponent battler by (also meaning that AoEs will award points for each target), 1 point for each 1% HP it will heal an ally, a designated number of points for applying different states, -10 points for every tile it needs to move forward in order to use the skill, etc. You can give the designer tools (via a config section) to weight different aspects; for example, a designer might make a game where positioning is very important so they want the tile penalty to be weighted at 300% (-30 instead of -10 for example). You could even allow notetags to be placed in the Note box on the Enemies tab to allow designers to give unique AIs to certain enemies (for example, a Berserker enemy that ignores its own positioning value, and overweights damage that it deals when making decisions)!

You could add even more sophistication to the AI by having it consider its opponents' abilities; for example, against a mage that could nail the monster from anywhere, the monster might not care how far forward it has to move in order to attack, and against an opponent with lots of AoEs, the monster might assign a points penalty to any skill that would force it to move too close to its allies. Aside from the extra workload on your part, this might also create an AI that is "too smart" in that it would make it difficult for players to actually use their skills in effective, satisfying ways. It's fun when the AI sometimes puts itself in situations where you can use an AoE and crush its dreams (especially since most RPGs demand that the player win every battle or take a Game Over). So there's definitely an element of diminishing returns in the amount of effort you put into the AI vs. how much it improves the player's experience. You don't want the AI to be a random, slobbering fool - but in an RPG, you don't want it to be Gary Kasparov either.

Targeting is another issue you'll need to tackle in such a points system. You could brute-force the approach by having enemies determine the points total for every combination of skill and (valid) target. That actually wouldn't be bad at all from a design standpoint; I just wonder how much processing power it would consume. Other approaches would be to choose a target based on some measure (such as targeting characters who are dealing the most damage, or characters who are the most injured), or to choose a random target but weight the random draw based on the above measures, or to add an Aggro System as a secondary system that's compatible with your grid system. The enemies choose a target, then they look at each skill knowing who they're targeting. (To be clear about Aggro systems - they're a system where characters develop "Aggro" (threat) within a battle based on the amount of damage they deal/heal, and certain other factors, and enemies tend to target whoever has the highest Aggro points. Aggro wears off over time so characters can drop their threat levels by lying low while their allies deal some damage. Sometimes each enemy tracks Aggro separately based on whether you damaged THAT enemy; sometimes it's just a total that all enemies follow.)

The reason I think the Aggro System could be a good idea, despite the amount of extra work it might mean for you as the script maker, is that it's very transparent to the player, and that it would actually interact with your grid system in a few really cool ways. When a vulnerable character has a high aggro score, the player can see that and decide to move that character to the backlines where they can't be attacked by strong melee skills, or get them away from allies if they think that character will be targeted as the center of AoEs. Additionally, it would be easy to allow the designer to create moves which manipulate aggro, such as a Vanguard skill that draws far more Aggro than it should based on the damage it deals, or a Rogue skill that deals damage but draws zero Aggro.
 

gstv87

Veteran
Veteran
Joined
Oct 20, 2015
Messages
2,189
Reaction score
1,167
First Language
Spanish
Primarily Uses
RMVXA
There're so much conditional branches that I can't get my brain to work to make a simpler configuration for those who can't script yet still versatile enough
define a behavior system, and you'll have it much more simplified.
for any skill action you need the skill user, the skill condition of usage, the skill range, the skill target, and the skill effect type.
a behavior system would let you manage the condition of usage and the target, based on the user and the skill effect type.

for example, say you define an "attack" behavior, that enemy would look up and engage enemies with a certain trait (or, anyone, at random; or, anyone, whomever is weaker, etc).
"support" would favor own healing skills over friendlies rather than damage skills over enemies.

if you create an aggression system like Wavelength suggests, you can also create tables of all enemies sorted by aggression level, and use that to drive behaviors, or create characters who would alter that table somehow ("confusion" skills, "vanish" skills, etc)
Code:
enemies.select{|enemy| skill.range.include?(enemy.position)}.sort_by{|enemy| -table[enemy].aggro}.select{|enemy| distance(self.position, enemy.position) < 2}[0]
something like that.
from enemies, grab enemies in range, sort by threat level, pick the closest one

(I made my AI around an aggro system by Dasher42, which added to GubiD's positioning system, plus custom modifications, became the behavior system I mention :D GubiD's original AI would sequentially scan each single square of the range area for enemies, and for status, and for possible outcome of engagement. You'd imagine the amount of calculations. I wiped it clean in a fell swoop by making it compare whole sets rather than sequentially going one by one.)
(That approach has the downside of being too unforgiving, tho. If there is a gap in the player's strategy that the system can find and exploit, it will...... because, it is there.)
 
Last edited:

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
Heyo, @Wavelength. Thanks for taking time of typing these. As expected from you. I might be missing some point you write along those text, but I'm trying my best, and pardon me in advance.

Regarding the demo video
I'd love to discuss the in depth discussion regarding how to plan grid battle system based on many design principles and their consequences. I mostly have seen what you have been saying there including the backline is the safest place if we are using melee-ranged skill system. A more time spend to get a battle done.

However as a disclaimer, I'd say that the video is a merely for a demonstration (of a proof that the script is working). Probably not a best demo video, but you get my point. I deliberately put movement has no cost for a sake of demonstration of ranged attack (so I can move freely from grid to grid), it's not necessarily a final product. The user should put a limit on how much movement is permitted based on their judgement. Could be one movement per turn that they can only move one tile whatsoever. Remember, we're talking about making a tool, not making a design based on the tool.

If you think it's "my game design" I'm sorry to say that it's not my intention here. Again I'd love to share discussion about it, but that is in other topic. In fact I'm yet to design a grid battle system that really satisfy me. Probably also the reason why I haven't finish this little script.

Regarding the new mechanic
Battler repositioning is really a cool idea that I should have thought of it. That might put an extra work but I'm willing to get my head spin to get that work. So, thanks!

As for line of sight, are you saying if an actor is behind an another actor they simply can't attack because it's blocked? If so, I will think about it as it might slightly revamp a bit of code about the targeting part since the framework of the script didn't support this at the moment. Depending on the difficulty, I may or may not try to add this on the first release later, but not really a bad idea.

For grid obstacles, the code I'm working on is already have this feature set in mind so it should not be too hard to implement obstacles (and destructible obstacles, or even traps). But taking this personally, I'd prefer the obstacles are randomized instead of setting it per troop. But I haven't really think about how the config looks like. Probably excluded in first release, but it's on the to do list.

Regarding the AI
I was thinking the same about using default roll and check enemy pattern in default RM database. But I could already seeing people raising pitchforks on me to make even more conditional branch like if actor is gathered in a spot, enemy will deal AoE or so. If simple check by priority then check if the skill can target someone, it won't do it. However, as for the first release, it's not really bad I guess?

Your award point system sounds interesting. But I'd be honest I'm having a hard time trying to understand the whole system you're proposing. It sounds complex (or not?) that it seems even more appropriate to someone's grid system design than for everyone's system. But I will take the aggro system you mentioned there.

@gstv87
Regarding the behavior system, say a battler has skill ABCD, they're all managed by the behavior? An aggresive behavior would always try to use skill A because it's offensive as often as possible. Is that are you trying to say? If so then the config would revolves around giving skill for an enemy then we create a behavior of it. Not sure how it will turns out but it's not a bad idea.

As for aggro system that is exactly how it's in my mind. Although I believe it might be even more complex than that in script.
 

gstv87

Veteran
Veteran
Joined
Oct 20, 2015
Messages
2,189
Reaction score
1,167
First Language
Spanish
Primarily Uses
RMVXA
in my case the behavior defines the target they would choose, and the position they'll take on the grid.
but, you can make it define the skill being chosen, yes.
I left it using the standard routine for choosing a skill, .... it chooses *the skill/s based on the battler's status* but *which skill out of the lot available after validating a number of them*, is determined by the behavior which defines where to stand and whom to target.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
For some reason, I decided to look at my old abandoned project, optimized a few things, and manage to make a few adjustments.
And yes, it means this project isn't dead yet. I'm just sidetracking from my actual game project.

Field-effect:
The proudest feature also the one that was quite tricky to code.
field3.gif
The field-effect has a various effects you can add. At the basic, it behaves like a state when you stand on the grid. So when you're in the grid, it "adds" a pseudo-state. But on an advanced level, you can customize the effect on every turn end or when the battler touched it (like proximity mine).

Also, it doesn't lag
Screenshot_1363.jpg

Knockback Effect:
a.k.a repositioning battler. Currently, work on sandbox test, this needs extensive testing in various cases.
knockback.gif

-------
This is probably going to be my next masterpiece after my battle system. And I'm excited to see this into a completion.

Plan for futures:
  • This will be a free script, no need to pay to use. And it is going to follow my usual Terms of Use. Let me play your game for free if it's commercial.
  • Like what I did in 5 years ago, I'll probably make a sample game to test the script, so yes, another project is born we all share this sin
Not planned for futures:
  • Have an enemy occupies more than a 1x1 size grid - i.e, you may not have 2x2 or 3x3 sized enemies. I don't exactly know how to handle this. So don't expect to have one.
  • High-compatibility - I will make this strictly only compatible with my battle system and a specific turn system like Yanfly's free turn battle. I spent my time thinking about how to make it highly compatible, but in the end, I just gave up make things whatever I like to make. So if you mash things up it with a various script and custom turn order, I'm not taking responsibility.
  • Adjustable grid rules - Due to technical issues and user-friendliness, I may not give much room for you to define your own grid rules without knowing how to code. However, I consider creating various grid rules addon to accommodate the lack of setting.
The code in my Github isn't yet updated, You don't need to look at it.

Q: but what about the AI?
A: Well,... I will think about it later when I actually create a game.
 

Wyrelade

Wyrelade - The one and only.
Veteran
Joined
Apr 11, 2014
Messages
62
Reaction score
22
First Language
Finland
Primarily Uses
RMVXA
This is AMAZING and unique from your typical grid type battle systems.

cant wait to see the FINAL version, this is so great.

Keep me updated!
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
Some progress report (so people are not wondering if it's dead). I ended up rewriting 1/3 part of the code.

Range-based diminishing return (the value is hardcoded for presentation convenience)
(Farther, less damage)
chillrend.gif
(Groundzero based, more damage at the center of explosion)
nucleargroundzero.gif

AoE based field effect application.
(Like, molten ground?)
radlaser.gif
Screenshot_109.jpg

Field-effect tested and works
(DoT damage)
radfield.gif
(Also, auto animation effect when you stand above the grid with field effect)
grid tile battler anim.gif
I haven't tested every feature I planned for the field-effect yet, but overall I made a considerable progress.
 

Christian777

Veteran
Veteran
Joined
Dec 14, 2014
Messages
45
Reaction score
14
First Language
spanish
Primarily Uses
RMVXA
This needs WAY more feedback... Your battle system is pretty underrated, but i think that is what makes it so awesome too haha
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
A little progress report (because I haven't been doing much lately)
Friendly fire is ON


Also, I have decided that to fully utilize this (if you plan to in later time), you have to understand ruby syntax, especially manipulating array. So, don't tell me that I didn't warn you.I wasn't hoping this wasn't the case, but to achieve a decent versatility, this must happen.

More progress report coming soon.
 

Christian777

Veteran
Veteran
Joined
Dec 14, 2014
Messages
45
Reaction score
14
First Language
spanish
Primarily Uses
RMVXA
Awesome buddy! Everytime you post something showing new stuff added to this system brightens my day haha.
Can´t wait to put hours and hours into this to fully take advantage of this system.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
Because I often forgot how my script works, I began to document stuff in the wiki that is already fixed and worked (i.e, it won't change most likely). Kudos to @richter_h for providing the site to host this document
The wiki will grow for each module from the system worked as intended and I'm satisfied with it (the code is still confidential though).
Cheers :D
 

Christian777

Veteran
Veteran
Joined
Dec 14, 2014
Messages
45
Reaction score
14
First Language
spanish
Primarily Uses
RMVXA
Really awesome explication and everything... i can understand most of it already.
What intrigues me is about the AI, you told me some months ago that it was really hard to program... Hope this time you got a idea for it!

By the way consider me as a beta tester if you want, i am down to support and help you with anything.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,477
Reaction score
6,310
First Language
Indonesian
Primarily Uses
RMVXA
Really awesome explication and everything... i can understand most of it already.
What intrigues me is about the AI, you told me some months ago that it was really hard to program... Hope this time you got a idea for it!

By the way consider me as a beta tester if you want, i am down to support and help you with anything.
Thank you for your support! I may send it to you once it's available for the beta test. However, are you familiar with my side view battle system? Because the system is built on it. There will be no support for other battle systems, so the prerequisite is to understand my battle system first.

Speaking of AI, it was already implemented, I already got an idea of how to make it work, however, the aggro system is currently not working as for now, it's is currently in a low priority due to the fact the base code still needs a lot to fix.

Edit: grid targeting wiki updated
 
Last edited:

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

The MZ first look stream was quite good. Looks like we get a lot of generator parts right off the bat this time around. Lots of cool clothes, helmets, facial marks, etc. Looking forward to playing around with it. :)
Any tips on how to share resources in here? Should I upload them in a image hosting site or Google Drive?
That moment when you realize your game size without the sound is 51.1 MB.... But with it (unoptimized as it is) it's 156 MB.... I guess it's time to do a bit of sound optimizing. :kaoswt: Also I learned that deployed for Windows it's 308MB... Apparently MV adds a pretty hefty helping of stuff on deployment. :kaoback:
I wanna try making my game into an app because that sounds cool but I am so lost on how to :kaocry:
I found some tutorial but they all seem to use an older android studio(2.3.3)? I think the current version is 4.0.1?
is there an updated tutorial or do I need to find a way to get 2.3.3.?

Forum statistics

Threads
100,821
Messages
979,936
Members
132,465
Latest member
GachaPringle
Top