1. Dismiss Notice
  2. Within our Resources section we have over 150 Audio files, with room to grow. You may find exactly what you have been looking for. Just CLICK HERE to start your listening adventure.
    Dismiss Notice
  3. Why would you want to upload your resources directly to RMMV.co? It makes it easier for other members to download them. Click HERE for more information.
    Dismiss Notice
  4. Click HERE to see our four new featured resources by TheUnproPro, Starbird, iblamevictoria, and VGM MarkH.
    Dismiss Notice
  5. Here are the The Resource Rules.
    Dismiss Notice
  6. Please read these RULES before posting.
    Dismiss Notice

Ayone use Unity?

Discussion in 'Technology/Utility Discussion' started by Rukiri, Sep 18, 2017.

  1. Curious if anyone uses Unity along side RPG Maker MV? One of the reasons I don't use MV for all my projects is because some of my projects battle systems are actually quite complex "as the battle system actually evolves within the game" it just doesn't add a difficulty layer.. And the process to make an ABS in MV is well.. just say you're reporgramming almost everything, how MV reads the tilemap as you probably need half tile to pixel perfect collision, your characters need to check per pixel for movement "I personally still do grid but 4x4". So that's why I am using Unity for one of my projects, now...just have to code the RPG part of it.. the battle system actually is pretty easy as Unity handles a lot of the things needed "yay me".

    But for traditional RPG I'd probably just stick to Rpg Maker unless I wanted crazy graphical presentation for 2D.
  2. Yes I use Unity because I have to. My studio sells technology and some of it is for Unity, including a publicly available Unity Asset for Android devices. I'm not a fan of Unity, but I know the engine inside-out, right down the the low-level stuff it does (some of my work involves C/C++ engine extensions for Unity, which is really deep in the engine).

    I think I would agree that Unity would be better for making an action battle-system as with RPG Maker MV you have to rip the system apart to start building what you want, whereas with an engine that has no implied game genre you build from scratch, you're not spending any time ripping apart existing work and trying to figure out how it all works.

    The biggest example of this would be my experiments with pixel-movement for MV (which would allow a far easier implementation for an ABS, as well as other Plugins). So much of it is re-writing the old system, there's pretty much always something to think about. I have to start by disabling the default system, then pick an area and rebuild that for pixel-movement, then try to find the next area, and make sure nothing else breaks whilst I'm doing this. It isn't easy at all and would be much easier to just make it all from scratch.

    That being said, once someone makes a flawless pixel-movement Plugin, then things like action battle systems will be far, far easier and we'll likely end up with more Plugins based on pixel-movement that add all these things, so once the work is put into it; RPG Maker will become the better option for this than starting from scratch - just that no-one has put the work into it.

    I think for a regular grid-based 2D JRPG you'd be insane to use Unity when MV exists - and I still see many people use Unity rather than RPG Maker for these types of games, it's rather upsetting as they're almost certainly going to end up with a worse game because of their engine choice.

    Rant time: You will consistently find that the best Unity game developers will tell you how much they hate the engine before anything else. On my Twitter I see some of the top Unity developers on the planet laugh at each other's posts about how bad the engine is and how stupid some of its crashes are. The fact that I need to have 24 different versions of Unity installed on one machine is ridiculous. It is improving though, but it carries with it a legacy of bad ideas and at the moment the improvements Unity makes are all down to undoing historically bad implementations. Their graphics engine re-write is a testament to this. Right now their scripting runtime is getting the same treatment.
  3. There's already pixel movement scripts for MV I think a few allow for the event commands to be used as well, but simply adding pixel movement does not mean easy abs... You have the tilemap to also think about, plus now your limited within the new movement system.

    Most Action RPGs have 180 degree knock back (360 with all directions), a simple script like this get's the direction to move the object
    Code (Text):

    // vec1 is the player and vec2 is the enemy
        movdir = Mathf.Rad2Deg(Mathf.Atan2(vec1.transform.position.y - vec2.transform.position.y, vec2.transform.position.x - vec1.transform.position.x));
        if (col.gameObject.tag == "Enemy") {
            rb.AddForce(movedir * thrust);  
    Without doing a custom collision system in MV "which is basically deleting almost everything...." it's almost like a waste of time, even Project Zelda (which uses XP and I think there's an VX/Ace version in the works but it's close to dead" didn't get this part right. Xas or Bliz, or any of the few MV scripts don't spend the time where it actually matters first. You first worry about collisions, then work on the script.

    My issue is I'm not great at all with javascript, I'm decent in C# and the bare code confuses me more than if I just went to the API...
  4. The existing pixel movement Plugins aren't very good. I've tried them all and I find bugs and issues in every single one regarding collision. It's the collision that I'm worried about mostly, not the actual pixel movement.

    A robust movement and collision system is the first step towards an easy ATB Plugin. You'd still need to code up the actual ATB logic, but with a good physics implementation it will be much easier.

    At that point, I think it's worth actually sticking with MV over Unity, but we're not at that point yet. It would allow Zelda and Secret of Mana style gameplay.

    Tilemap collision is something I've considered, but step one is a new event collision system with the gridded tilemap.

    I'm considering options for funding my development of this, but that deserves its own thread.

    As of right now, Unity is going to be the better option for the reasons we've already discussed. It still stands though that you probably shouldn't be using Unity if you're making something close to the default RPG Maker systems, I consider an action element to be suitably different to MV as of this time, but once the movement system is in place for MV I think the argument for using Unity would be much more difficult.

    I would say that 100% of the issue with MV is the default code. Being proficient in JavaScript is important to be able to navigate and gut the code. However, with Unity you can be a terrible C# programmer and still get things done as it's all on your terms built from the ground up.
  5. #5 Rukiri, Sep 19, 2017
    Last edited: Sep 19, 2017
    All we need is good box2D implementation and it should be good too go, sadly I'm not an implementation guy... but I'm sure box2D exists and I believe Unity uses box2D for 2D.

    But MV has had performance issues, it's not optimized software and feels rushed but I haven't touch MV in ages because of everything I stated above, I'm more into real-time battle systems like Zelda/Mana than side view systems but for certain projects I want side view or even tactical battle systems. My Chrono project is actually tactical game so it fits with MV.

    I probably won't give up, mainly as I do not want to re-invent the RPG wheel...
  6. Box2D is something I've looked into, but my worry is that it's a large thing to drag into MV just for doing collisions and no other physics type. I made a collision system myself and it works fine, don't need Box2D, but the issue is getting around some of MV's features, like the looping maps introduces some issues with collision detecting.

    MV's performance isn't that bad. Not sure it's fair to say it's rushed either, we don't know what the development priorities were, but from looking at the code it looks like everything was done as explicitly as possible, which says to me they care more about Plugins than anything else, which is the right call to make. The event collision system comes to mind here; it loops over all events rather than uses a splitting tree to quickly check for collisions. Looping is more obvious and easier to understand and modify, but it isn't as optimal for a large number of events.

    Unity's performance used to be really bad, it has improved a lot over the years. Unity's IL2CPP is really amazing for what it does, but it's never going to be in the realm of Unreal Engine. Unity's paradigm doesn't encourage optimised programming or efficient resource management, so larger projects tend to suffer later in development life (larger Unity projects tend to suffer in general, it's a bad engine for managing large projects, especially across a team).

    There's probably a Unity Asset for a Zelda-like system, so you don't have to "re-invent the wheel". Programmers will get to a point in their career where re-inventing the wheel isn't an issue as is even the better choice, part of why I'm okay with not using Box2D with an MV pixel movement Plugin is because I know it can be done without it with a lighter, easier to understand code-base that others can modify.

    This extends into other Plugins too; the 3D map demos we've seen tend to use 3rd party 3D Javascript libraries (threejs is a popular one), which makes fast results, but doesn't help others extend the Plugin to make the type of game they want. You're also locked into the features of the 3rd party library, so if you wanted to add software rendering for compatibility then you'd have a much tougher time than if you wrote it yourself from scratch.
  7. I've used unity quite a bit in the past, granted I've never actually made a game with it, but I do like the engine, it seems like a pretty good platform imo. I especially like that unity gives the user the freedom to add on to the editor itself, I thought thought that's what MV was going to do when it released it's MV Tools, but unfortunately I don't think it's open for developers to build onto, as I couldn't find any info for it. :/

    As for all the talk of collision detection ._. Here's a project I've been working on( this is an old video, I've got everything nearly complete, just got 1 final bug to worry about before finally making it publicly available ). It's a true pixel based movement with SAT collision detection, it also keeps an update of the players grid position to keep it compatible with as many plugins as possible. Also don't mind the cpu/gpu readings, they were off due to the recording software.

  8. #9 Xilefian, Sep 20, 2017
    Last edited: Sep 21, 2017
    Hey nice job, Chaucer. This thread inspired me to pick and and continue my movement Plugin that I've been showing off every now and then in the form of GIF images.

    Here's my take on it (events only, I've shown plenty of footage of map collisions in the past):

    Goal has always been a rock-solid collision Plugin, no wobbly shaking or dodgy clipping at all. There are so many edge-cases that existing Plugins fail at and that's what I'm aiming on eliminating.

    SAT is pretty much the most manageable way to handle 2D collision. My early experiments didn't use SAT and the big problem there was the size of the code getting extremely large.

    I honestly do believe that with good collision Plugins the reasons to stick with Unity for top-down RPGs will be reduced. We should make a separate thread for discussing collision Plugins, though.

    Unity's editor customisation is pretty nice if you're publishing Assets. A sign of a good Asset is one with all the configuration done right in the editor with little need to write any code, that's my philosophy with publishing Assets.

    However, for developing a game project, I'm not sure the customisation of the editor is really that beneficial. The benefit gained would be the ease of integrating Assets that it brings, rather than enabling some kind of useful tool for developing your specific project. I find that project-specific tools with Unity tend to always be disposable. That's not an extremely terrible thing, though.

    RPG Maker MV does come with that little Tools button with some extra programs. I imagine that the idea behind that was to make it so you can add your own tools to the editor and have them come under this menu, but that doesn't seem to be the case in the implementation we have, from what I can see. You know, it's probably worth sending a message to the MV developers and asking them about this.
  9. I actually made that topic on the degica forums, been about 2 weeks now, archiea is away so who knows when it'll be approved and if kadokawa will actually implement this feature.... :(
  10. @Rukiri actually, I wrote my own libraries for my collision detection, I've done it this way so I can allow the use of concave shapes as well as convex, I've got it all working, except one bug that i can't seem to nail down :/ then I'm going to release it for public use. :D

    @Xilefian Whoa, nice work man, here I thought i was the only one working on something like this, would you be interested in collaborating on the plugin? Tbh I've got nearly everything complete, event interaction, followers, etc, I just vehicle traveling, and to find and fix a bug >_>, anyways I apologize for dragging this off topic, shoot me a pm if you're interested.

    As for editor customization I agree it's not really necessary to develop a game, but having the ability to add on to the editor can make it easier to develop one, and for the performance issues of unity, I think that games with performance issues, really just leads back to how the game was developed, Imo it's up to the developer on how resources are handled, and not so much the engine. I've never actually used unreal ^^; although I do have several books on it( I've never read them, don't have time lol ), and I have it installed on my computer( launched it once to check it out xD ), but yeah one day I'll get around to messing around trying it( again getting off topic my bad ^^; ).
  11. The only thing that I'd love to see RPG Maker get is polygon collisions, granted this adds the complexity of rigid and kinematic bodies but would improve a lot of things, first off standards! using these basically means you can transfer almost to any engine, not having to relearn anything is a +.

Share This Page