And I mean besides the whole licensing change thing that happened this year, and that they went back on, because obviously it was stupid, and management didn't listen to the people who told them it was stupid, and pushed for it anyway, and got a ton of well deserved shit for it.

These are some of my thoughts after working with unity for a few years almost every day, both at my actual day job and on some other projects. I don't think many of these things can be fixed without much effort by them, that they won't do, because it does not bring them more money. This leads us nicely to the first point I want to make:

Have you ever read the official unity blog? It feels like every time I open that page, the latest article is something I as a developer do not care about in the slightest. You're adding support for mobile browsers? I don't care, I don't make mobile games. You added some "next-gen" AI bullshit to the engine as a package? I really don't care, I'd rather hand craft everything, and have a real artist make the art, and learn blender to make 3D models, and write an actual connected story myself, or have an actual writer do that. But I'm sure the investors care about it, it's the current big thing.

The other thing they have been pushing for a while is AR, which I never understood the actual purpose of for a game engine. I don't think I've ever seen an AR "game" that worked well and didn't look out of place. It feels to me like the techology has not progressed since the time of the New 3DS (which had AR cards that would show you funny 3D models of characters. And going through all of those took like half an hour tops).

And whatever else next thing they push, despite the actual engine and editor having so many things that could be improved. Instead, they prefer to create another half-baked new feature to chase after a trend. I don't think I was ever excited for something they added in a new version. Since 2019 the most exciting thing for me was when they updated their C# runtime to actually support modern C# versions, that was nice. As to the things that could be improved…

It is so, so painfully slow. Why is it so slow? Everything takes time even on a modern PC with a fast SSD. Maybe that's a me issue, but I have heard similar complaints from other people. Sometimes a new version makes things not as slow, but at my job I really hate having to wait for 5-10 seconds after I change a line of code for it to recompile, reload, update the assets, and whatever else it's doing. Why can other engines have a responsive interface and compile times that don't completely stop your work flow for 10 seconds and unity can't? I'm not sure. Maybe it's the C# runtime, maybe it's because it checks the entire project every time. Even for smaller projects it still takes a fair bit longer than I'd like.

Actually, why are they using C# at all for a game engine? I don't think this is a very popular opinion, but I feel like C# does not fit very well into something that requires, preferably, no pauses for garbage collection and little to no constant garbage allocation. You have to work around the language a lot of the time, like making sure to pool your objects, and not create too many strings, and not use C# events and static fields because they live outside the engine and unity can't control them, so if your object gets destroyed that stuff now has dangling references to dead objects and will break things. And the compile times, again. It just takes so long on big projects, is there really no solution to this issue? And the whole IL2CPP thing, too, that blows up the already long project build time tenfold in terms of both RAM and time, that just transpiles the whole project to C++. It's an interesting solution and arguably helps with performance in the compiled game, but it takes so long. And by now I don't have enough RAM in my PC to build the project locally (currently I have 34GB installed and that's still not enough for it most of the time, unless I close every single other program on my computer).

The custom editors. It's a great idea but it is a very bad implementation. The whole immediate mode GUI thing that is not connected at all to how you build the UI in game (which is a topic I will mention again later) and that you have to constantly work around if you want to do something slightly out of the ordinary, because it's oriented on using their terrible "SerializedProperty" system which only allow access to a hard coded substet of types that unity has arbitrarily decided upon. And it also breaks every single major release. I don't remember updating unity without a custom editor breaking in some stupid way, like text suddenly being the wrong size, or the "open folded property" button being inside of the text instead of on the left of it, or one of the properties just deciding that it's of a different size now and being moved into the middle of the big textbox above it, or letters in that big textbox just collapsing into echh other. Really, "hard coded substet of X unity has arbitrarily decided upon" seems to be a reoccuring thing. You want a serialized function? Only zero or one arguments, or it won't work. You want a nested list? No, wrap each of the nested lists in a class, or it won't work. You want a dictionary? Just straight up does not exist. Use two lists as keys and values. You want polymorphism? Well, there's SerializeReference, but it doesn't have a proper UI to create instances of the polymorphic classes, so you better write a custom editor for that one. Also, if the name/namespace of your class changes, it will break. This is really the only thing that breaks if you rename a class properly (which means also renaming the meta file, since everything else actually uses its meta ID, it's just THIS thing that uses the actual full class name), and sure there's an annotation to fix the renames but was it really that difficult to just make it work? Sure, alternative solutions exist, and they have solved all of these issues a long time ago, but why the hell is the built in solution so bad?

As a comparison, godot's editors are just normal UI nodes. In fact, the whole godot editor is just normal UI nodes. And their serialization system actually has dictionaries and polymorphism built-in, and functions with any number of arguments. Hell, you can even bind or unbind certain arguments in editor and then add more when calling the function. It's actually insane how much better both of these things are compared to unity's broken system. I'm sure if Unity wanted, the could make all of these things work, it's just that their priorities are ad techologies and AI "innovation".

The whole animation system. Why the hell are animation events so limited? Once again it has been arbitrarily decided that you can only call functions, and that these functions have the the restrictions as mentioned above of "zero or one parameter". And the editor for that whole thing is just atrocious. Why can't I reorder events that are on the same frame without doing an acrobatic fucking pirouette of moving it to another frame to the left if I want to move the event before the others or to the right if I want it to the right of the others; and if I want it in the middle? Well, do the same thing with all other events that are after or before it, depending on which is faster to rearrange. Godot was able to do it just fine, they have events of arbitrary types and arbitrary properties and even different interpolation types. I'm not actually sure if unity can do anything beside linear interpolation and curves. Also, why not just let me type out the property I want to animate, or at least allow me to search for the game object, or the property on the object? You really have to manually open the whole hierarchy each time in the tiny selection window and browse to the property you want to animate, and then remove the parts you don't want to touch like RGB in the Color type when I just want to change the alpha.

It actually baffles me how bad it is with the whole "asynchronous queue" which is actually very much synchronous, just in another thread. If you try to load two things, they won't actually load in parallel or anything like that, and if you, Dog forbid, try to load a scene without instantly activating it, that will stop the whole queue until you activate the scene. Also, no canceling the loading of the scene. And they built the whole "addressables" system on top of that, so it still doesn't solve the issues of "loading a part of the world where the player may go next without activating it and causing a spike of Awake calls". In fact, I don't think there's any way in Unity to do that short of having your own life cycle for objects so they don't immediately activate all in one frame after scene loading. You can theoretically work around this by having your scenes as prefabs instead, these can in fact be loaded and activated later, but it's a different editor than scenes and half of the things that work with scenes don't work with prefabs when they're loaded like that (static batching at runtime, for example, unless you manually call that on the prefab yourself, which by the way uses FindObjects to get every single object currently in the running game, then runs a for loop on all of them to see if they're a child of a parent you passed into the function, and then uses LINQ to copy that entire array but now make it sorted. If you ever have the time, you may have some fun by decompiling StaticBatchingUtility.Combine and reading through the shit they do in there). And also, no rearranging children and having a preview of the actual game world in prefabs, et cetera. Why did they even have Scenes and Prefabs as separate things? Other engines just have them be the same thing and it works just fine. They're the same fucking thing, Unity.

I have no idea how people build UIs with that garbage. The components it has are very basic and the layouting capabilities are just not reliable at all, I am still to figure out how to make the UI in unity look any good without just using sprites for everything and disregarding their components. Sure, there's some new "UI elements" thing, which still has almost zero built in components and the "recommended" UI system is stil the atrocious barely working old one. And even with the whole UI elements thing, I'm not sure I want to write HTML and CSS for a game's UI after my experience with WPF (which I hear some people like, but I am not one of those people). Also, the default styling for them is just straight up bad and half of the built-in components are actually other components stacked in a weird way that kind-of-barely-works but the styling clashes and you have to replace all of it anyway, like the scroll box (which by the way has no way to scroll to an element in it built-in, you have to also code that one youself. Was it really that difficult to just make a normal scroll component with basic features and not "let's pretend that masking child content outside of boundaries of this component and moving the child up and down is actually scrolling").

They love to pretend that it is sometimes, but the lack of actual 2D components is just stupid. For the longest time there was just no way at all to have lighting in 2D, though I hear that's been solved a little bit ago finally. There are no 2D particles, there is no 2D pathfinding, all the coordinates of all the objects are still a Vector3, at least the damn physics system is an actual 2D physics system (Box2D, what else could it be?), that would have been even more embarassing if they got that wrong, and they have 2D collisions "kind of" but they're not as advanced as 3D and have separate callbacks (Why? It doesn't make sense to have an object collide in both 2D and 3D anyway. Probably because they couldn't figure out a good type for it or something). The audio attenuation still works in 3D so if your camera is too far from the 2D world you won't hear anything. Then again, the audio system in unity is also just not very good, better use FMOD if you can. At least they have various audio effects if you want them and can't affort FMOD. Can't vouch for the quality of those, did not have to use them much. Also, while not a 2D issue per se, why the hell is there no built-in tweening solution? I don't want to use the idiotic animation system to show a menu slide in, and what if the position is dynamic? There's a great package called "DOTween", and it solves this problem, but why the hell is it not built in? I feel like animation is one of the very important parts that a game engine should provide, especially for 2D games which (sometimes, not always) tend to be more UI heavy and would benefit greatly from an easy way to animate all of that.

Unity does not and never had a built in way to show a file selection dialogue in a running game. There are, as usual, plugins that kind of work. You can also manually copy a mono Windows Forms DLL file and use the ugly Windows Forms file selection dialogue, but I'm not sure if this works anywhere but on windows, so you probably will need to create some kind of workaround for every system yourself or use the aforementioned plugin.

Thing is, unity has a file selection dialogue for the editor, it's in EditorUtility. It works on every system, too. So why not add the same thing to the built standalone player? Is it really that difficult? I don't think it is. Hell, they could make their own system-independant file selection dialogue. Godot did that, and it works fine. That one even works in browsers (with the virtual filesystem, which is a bit different, but still).

Did you know unity has advanced search that can filter things in the scene or in the project by various things, and even by the values of properties, I have always thought this would be nice and turns out it does exist (with caveats, the property filter is very basic, like everything unity does. Honestly, is it really that difficult to add things like arrays into this filter?). This is a really cool feature that's never ever advertised or used by anyone I know, and the only way to access it is to press Ctrl+K, I don't even remember where I learned this.

However, there is a very big issue with it that makes it not really usable for me: if there are a lot of results it will crash the progam because it takes too much memory. It's not even a normal unity crash where it asks to submit a crash report, it will just hang up after searching for some time and then hard-close the program with no message. I tried searching for meshes in the whole project and it happened 2 times after a little bit of waiting. Come on, couldn't there be some kinda limit on it or something? I have 34G of RAM, and I still run out of memory a lot. And every time it happens, it's always Unity.

I probably forgot something else, in which case I might update this article later. These are the things that come to mind when I use any other engine and think "I wish unity had this, this is so much better". But Unity is not a game development company, they don't actually use their own engine. If they did, it wouldn't be so bad, I'm sure. They're an ad company, they're a making huge cash money and pleasing the investors company. So what goes in the engine is whatever gives them more money, it seems like. And not the things people have been begging them to add for the last 10 or whatever years. Just use a different engine. Especially if you're making a 2D game. DO NOT USE UNITY FOR 2D GAMES. Use ANYTHING else:

GameMaker recently became free and they're actually adding new useful features to the engine, it looks like (and you need to just pay them 100$ once if you want to sell your game now instead of some stupid subscription that they had before). But also look at this stupid stunt they pulled in 2012 and think what you will about that.

RPGMaker MV/MZ is arguably not a great engine, but since it's javascript you can literally go inside the engine and change the parts you don't like; It's very easy to get started with these two.

Defold, this one uses Lua (which is for sure better than C# for games), and I've heard some nice things about it before, plus it's open source. Want to try that one myself at some point. Apparently it can do 3D too, might be interesting to look at.

Godot is probably my favourite from these, and you can do 3D games in it too, in fact it seems pretty alright for 3D games. I've been using it for about a year now and sure it has issues, especially with the editor stability, but it starts up in like a second and reloading code changes is instant. And they have a programming language specifically designed by them for making games. Seriously, try it.

I've been meaning to gather everything I dislike about unity in a single post for a while, and this is the result. It's getting a bit late now, so I'll probably go to bed after publishing this. Goodnight, and thank you for reading my blog post.

This post was actually written a long while ago, the week the game released. It used to mention that if you buy the game now, you would get the so-called "perpetual edition", which gives you all DLC for free when they come out. The time has passed, as the article never got released on the website it was supposed to be on at the time, so I'm publishing it here instead. It was also supposed to be my first impression of the game, but I have since finished the game, so I expanded on some points compared to the original article.

Book of hours is a new game by Weather Factory, of the Cultist simulator fame, that came out in August of 2023. The game's steam page describes it as "an elegant, melancholy, combat-free crafting RPG set in an occult library, from the creator of Fallen London, Sunless Sea and the double BAFTA-nominated Cultist Simulator". Indeed, unlike their previous game, this one is much more relaxed and does not hurry you along all the time.

If you've played Cultist Simulator previously, you know how stressful that game can be, you always need money to continue paying the bills, and to get money you have to work various jobs almost non-stop, or sell things. Book of hours also features the mechanics of work and money, though this time it's not strictly required to keep playing. You don't need to pay the bills or get food or anything like that, you only spend money to pay people or buy things. Mostly pay people, as you'll be needing a lot of help with how the game's exploration mechanics work.

Unlike Cultist Simulator, you are no longer tied to just a table with cards on it. The game still features cards, and card slots, and aspects, all the same core mechanics, but now there is a map that you have to explore. You start the game washed up on the beach with nothing but a wet book. From there, the game expects you to figure things out yourself: there is no tutorial, no arrows, no message that helps you get started, besides a tip on how to navigate the map. Really, this is all you need to start out: look around the beach, try the different buttons you have available: the lock icon that shows where you can move to a different location (into the town near the beach) and the "consider" button.

Though the game features no tutorial or other help of that sort, many descriptions of cards, aspects, and actions now feature helpful snippets in square brackets that shed some light on the cryptic words in the box itself, and sometimes even tell you where this card can be used (however, this is usually not the only place it can be used in, just the most important one for someone who is just starting out).

Through various actions on the beach, you will get one of several starting parts of the soul that will define how your game starts and what mysteries you will be looking into first. As the game says, there will be more that you can discover later, but first you will need to get into town using some old acquaintance (which one depends on your chosen aspects), get that wet book dry again, and figure out how to get into the library, which you have come to the island to maintain.

As you've likely figured out from your travel from the beach into town, to unlock new locations you will likely need help of other people. It comes in many ways, both from town's inhabitants and the passers-through. Later, you will be able to also boost their abilities with your own, or various items. Unlocking the rest of the town shouldn't be much of an issue if you've gotten through the rest so far, talk with people, ask someone you already know to introduce you, that sort of thing.

From there, you should be able to ask someone from town to help you getting into the library, or as it's called in the game, "The Hush House". When you reach the first room of the house, you'll likely see that it's a huge castle with dozens of rooms that you will be unlocking throughout the game. The basic rule for unlocking them stays the same: you find someone to help you with aspects matching the room's, then you boost their aspects with your own parts of the soul, skills, items, or memories, by discussing these topics with them. Though be careful, as if you don't use their help by dawn, they will leave (as will the memories disappear). There are also a few rooms that are unlocked in a different way, but it's different for each of them and there are just a few.

In the rooms you unlock you will find uncatalogued books. This is the second major new mechanic of the game. You catalogue books, they contain a mystery of some level, you try to study them and match the level of the mystery with your own aspects, and if you are successful, you will learn a lesson from them, which can be made into a skill and put into a special tree that gives you more parts of the soul (this is how you unlock additional ones that you did not choose at the beginning). Skills always go into one of two slots in the tree, which gives you a lot of freedom on which skills you actually want to get. In the release version of the game, this caused issues where certain skill choices would lock you out from upgrading some parts of the soul, as the aspects wouldn't match the workbenches required for upgrades. This has since been patched, and I believe all skills are possible to upgrade just fine. Though there are actually less skills in the game than there are entries in the tree, so it is not possible to upgrade every part of the tree to the maximum.

With the books, the game actually introduces the two mechanics that will hamper your progress: infections and maladies. When you catalogue the book, the game will warn you of the chances the book may be infected: most of the starting books aren't, but there's always some small chance. If you get an infected book, read the description of the infection carefully, and you should be able to understand how it can be removed. If the description says the infection can spread, put the book in a room that doesn't have much of anything else - that way it shouldn't hurt you much. However, if you got unlucky and used the aspect of the soul that the infection can corrupt while cataloguing the book, it will become a malady; another way to get a malady is failing to study a book, so there is a chance the part of the soul you used will instead get corrupted the same way. It can be cured, as the description of the card says, and it cannot be used in many places, but there is also an upside to it: if you use it as effort in the things that allow it, it will not become tired, like normal soul parts.

As far as I know, trying to explore more rooms, catalogue books, and unlock more of the skill tree is the primary game loop. You don't actually need to explore the entire house to finish the game, but I have done so nonetheless, since it's such an interesting and huge place. There's also crafting, which you'll eventually need to create items to help exlore the house or solve mysteries in the books, and recently they've added a catalogue of things you have already crafted so you don't actually have to write it down manually. That said, it is still helpful to do so, as there is no way to see how to craft a specific item you need, just what can be crafted from the skill in the workbench. I highly recommend using some kind of note taking application or steam's built-in notes to write down your recipes, books and such.

It is very enjoyable to explore the game on your own and figure out its mysteries. If you're a fan of cultist simulator, you probably already bought it, and if you're one of the people who haven't played it: maybe you should try that one out too. It's a lot more punishing, but it has its own charm. If being constantly rushed by the game sounds like too much by you, the Book of Hours will definetely be more your speed. Both of the games make you figure things out and experiment in interesting ways. If that's something you're looking for, this is a great game, though the price of 22.49$ may be a bit of a turnoff for some, that price is well worth it.

This is a repost of an itch.io post, and only includes my part of it. You may want to read the complete thing, since it also includes something from the game's writer. It's about a game I've been working on with a friend for a bit, and it's out on itch and steam, linked at the end of the post.

Hi, we just recently released and I wanted to talk a bit about how we got this game working. When the idea to actually make a game from the story came to be, we discussed what engine we should choose. At that point, it wasn't exactly clear what kind of game it would be, though we settled quite fast that we should limit the scope of the game to something we could actually make in a reasonable amount of time with such a small team. The engines we thought of at that point were Unity, Godot, Ren'Py, and a custom engine. Custom engine and Unity were the first ones to be scratched off, since a custom engine meant it would likely take a long time to get anything presentable working. Unity, we both agreed, was too big and clunky for what we wanted to make, and, despite me having a lot of experience with Unity, or perhaps because of that, I have grown to dislike working with Unity and its many design flaws. Another proposition was RPGMaker, but we quickly decided that perhaps we didn't actually want a top-down RPG game, since that meant lots of sprite art, and we would've had to slow down the story with RPG gameplay, much like Danganronpa is slowed down by some of its gameplay, although it's a great game at many points.

In the end, we've stopped on Godot; we've never worked with it, so neither of us had much bad to say about it. It seemed like a good general-purpose engine that has good documentation and actual support for 2D games (unlike Unity). Godot is open-source, too, so patches could be made to the engine directly, if need be (and there was indeed a need, at some points). Working with it, we've also noted the quick release cycle they had for Godot 4, which meant that fixes for major issues would usually arrive within a week or sometimes even a few days. Speaking of Godot 4… initially, we tried 3, which is the current stable version, but it seemed to me that 3 lacked a lot of small quality of life things and GDScript language features that they've made available in 4, so early in the development process we made the decision to switch. Of course, since Godot 4 has no stable release yet, we encountered some issues and crashes within the editor and with exporting the game, but all of these issues were resolved within a few days or weeks with the new Godot releases, and we've steadily progressed on the demo up until its release.

We've opted to use Godot's resources system instead of just text files for the game's written content. That was mostly a decision of mine, and I've tried my best to make it as painless as possible to add content to the game by implementing custom resources and inspectors. Overall, there's a lot of clicking on buttons and expanding sub-objects, but it's far from how annoying it was at the start. The idea behind using resources instead of just text files was to make sure that we never had issues with typos in file structure or dialogue navigation. Plus, this meant not having to write a parser for all of that. Seems that this approach is not oft taken, and people do usually opt to make custom formats and parsers, but nevertheless, this is the path we chose; perhaps in the future something will change about our setup, but, for now, we're sticking with it.

Some time before the game's actual release we got the Steam and Itch pages set up. For Steam, things have been mostly smooth, and, after incorporating feedback from Valve, we released our demo. The paid release of the game will feature achievements, too, and the demo's save system will ensure that the achievements will be unlocked automatically when players move from the demo to the paid release. This way, we hope the migration from the demo should be mostly imperceptible, and you can just continue playing like nothing changed. On Itch's part, there was no review up until the game's actual release, at which point we discovered that if your game costs money, Itch won't let it be searched on the site until they've reviewed it. Unfortunately, we're still waiting on that review, so the game can only be accessed from someone's profile or from a direct link. Other than that, we haven't had issues with releasing on Itch either.

For the Steam release, we wanted to have Steam integrations like achievements. Turns out, the library that provides bindings to the Steamworks API, GodotSteam wasn't yet ported to Godot 4. Thankfully, it was fairly little work to do that, and in a few evenings I got it working with Godot's GDExtension and submitted the patch to the library. It was accepted, since it got the library working at least, but it's still not considered stable, because it hasn't been tested that thoroughly— but it should mostly work fine. If you're using Godot 4 and want Steam integration, take a look at it.

Close to the demo's release, when the story was mostly done, we got to work on polishing and fixing bugs that we and our playtesters had found. There were quite a lot of minor issues and some major bugs that slipped through up to that point, but now we've got them fixed, and the demo release should be mostly bug-free. It took a while, and I'd like to thank everyone who played the game and told us about the issues; with the help of those people, we also touched up some parts that didn't make sense to them, like providing a little tutorial at the start of the game which teaches you the main mechanic, but still lets you figure out the rest yourself.

So far this has been an interesting experience, and I like the Godot engine a lot more than Unity. I hope we can continue to have fun making this game and eventually make it a complete story. Thank you for reading this long post and sticking through to the end, and I hope you enjoy, or enjoyed, the demo!

Since I've been doing some things other then "the game thing" for some time, I've decided to maybe write about it too. Of course, the game is not forgotten. I just struggle to find motivation to do more writing for it, even though the ideas are there. It will be done when the time is right, so let's proceed to the actual theme of this post: me digging through rpg maker mv sources and figuring things out.

Basically, I was given rpg maker mv to help out on a certain game that shall not be mentioned here, since nobody would understand either way. In particular, I was asked to help out on the "plugin" part. What this means: the whole engine is actually written in javascript, unlike the previous versions which, I believe, were written in something else and had ruby for a scripting language. Now since it's written in JS, the whole engine is basically an open box. You can modify anything, the whole thing. They give you the whole engine to mess around with. Except the editor, which is still a separate program, though the editor simply spits out JSON that the engine interprets (so you can also change how it interprets it too).

Now, the developers of rpg maker did something clever: instead of just giving you the engine and saying "yeah you can mess around with it" they added a system of "plugins". In essense, plugins are javascript files that are loaded after the main game. Since they are loaded afterwards, you can then override any part of the engine in your file without touching the actual engine code. Since javascript is prototype-based, simply changine the prototypes overrides the behaviour of the engine, while also leaving the original code intact if you want to use it later.

That said, unfortunately the creators of the engine abandoned it in favor of their new, slightly modified version of it, called rpg maker mz, a few years ago. And are selling mostly the same engine with somewhat improved editor. So no more updates to MV. Though since the whole engine code is available, that's not a big problem. One can make it whatever they want, it's just another 2D game engine that is somewhat steered towards RPG top-down games, but can do just about anything. Hell, you could make a custom editor for its json data system too, and replace their proprietary one.

As mentioned before, plugins are the way to modify how things work without actually touching the engine code. An improtant part of plugins are parameters they can receive, and which can have different types to make the editor show different inputs for them. A good/only/official explanation of all the types is available here.

RPG Maker has official forums, and these do have a specific place for plugin discussion, tutorials and other things for each version of the engine. It seems that most people using the forums, except the few veterans who have been using the engine for years, don't have much idea about how plugins work, or about the inner workings of the engine. Since the editor is so good, a lot of the time they don't have to.

Though it is somewhat painful to see people giving clueless suggestions on the forums, with outdated ways of doing things in JS or simply not understanding how it works. Sometimes people say something is impossible to do, even though you have the whole engine source, so really anything can be done with enough effort.

One thing in particular I have noticed, is that nobody uses modern javascript constructs, though they have been available for a while in NW.js (the thing rpg maker mv uses to run on desktop, it's basically a webkit renderer with node for javascript). For example, evreybody seems to use the pre-es6 way of defining classes, simply because that's how they write it in the engine code, because the engine itself was made in pre-es6 times, I believe. So you see things like this (take from here), though admittedly the post is from 2017, ES6 was already available at the time (ES6 came out in 2015):

  function Window_MyWindow() {
      this.initialize.apply(this, arguments);
  }

  Window_MyWindow.prototype = Object.create(Window_Base.prototype);
  Window_MyWindow.prototype.constructor = Window_MyWindow;

  Window_MyWindow.prototype.initialize = function(x, y, width, height) {
      Window_Base.prototype.initialize.call(this, x, y, width, height);
  };

  Window_MyWindow.prototype.refresh = function() {
      this.drawText("This is a test message", 0, 0, this.contentsWidth(), this.lineHeight());
  };

instead of the easier and equivalent way of doing the same thing in ES6:

  class Window_MyWindow extends Window_Base {
      refresh() {
          this.drawText("This is a test message", 0, 0, this.contentsWidth(), this.lineHeight());
      }
  }

These are basically equivalent. Thankfully the whole engine is written in the same way that classes work in ES6, so everything actually just works with the new syntax.

People also still use var instead of let and wrap their things in function that is called immediately instead of just creating a scope with {}, which would just as well hide all names if you use let instead of var.

Of course, these observations are made only from the forums and some rare GitHub code one can find. Perhaps the people behind big games, knowledgable in javascript, use all these features, but we'll never know that. Still, the bad old code suggestions given on forums are somewhat disappointing, I hardly found anything useful there, and had more success just reading the engine code instead.

Now, event processing is quite interesting in this engine. You might want to know this, if you plan on using the events provided via the editor in a custom scene that does not inherir or use the Scene_Map utilities. Maps are scenes which draw tilesets, have events, and are basically where the gameplay is. But there are other types of scenes too. The other important one is Scene_MenuBase, which has some utilities for implementing menus. So, if you want to have a custom menu and have events in it, or show images in it with the built-in commands, you'll have to work a bit for it, because Scene_MenuBase doesn't process events or draw sprites!

After some digging through the code I have figured out several things about how eventing and sprites work, and that's where some interesting differences from other engines surface. Usually, you either have a global manager that draws things and a global manager that processes events, or the objects themselves draw things and process events. But rpg maker mv seems to use both at the same time: to process events, you have to first create a Game_Interpreter and save it somewhere, then ask a global manager $gameTemp to create a reservation for the common event you want to run, and only then ask the interpreter to actually get the event from $gameTemp. After that, just call its update function every frame to make it process whatever the common event does.

The code looks something like this:

  class Test_MenuBase extends Scene_MenuBase {
      start() {
          // Reserve a common event received as a parameter to the plugin
          $gameTemp.reserveCommonEvent(Number(params["testEvent"]))

          // Create an interpreter
          this._interpreter = new Game_Interpreter()
          // Actually get the reserved event into the interpreter and clear the reservation
          this._interpreter.setupReservedCommonEvent()
      }

      update() {
          // Update the interpreter every frame
          this._interpreter.update()
      }
  }

Now, it will run the events, but that's not all of it.. It won't just draw pictures for you! Pictures also use this strange combined approach to get drawn. So, if you want to draw pictures, you have to add a Spriteset_Base to your scene. Which has a very annoying built-in behaviour of drawing a black background, that you might want to remove. The Spriteset basically takes all requests for drawing images with the built-in draw image command and draws them. You can also draw them manually by adding a Sprite_Picture to your scene with a specified picture number, but Spriteset_Base does this for you. The Map scene has both the spriteset and game interpreter in it, so it will process events and draw pictures, but other scenes don't. So if you add them to your scene, they will be able to do it. Quite obvious. You can also ask another manager to draw a picture instead of doing it from the editor, since all editor commands go through these managers. For drawing pictures, the manager used is $gameScreen. For example, call $gameScreen.showPicture to do the equivalent of what the editor event "draw picture" does.

Here is an example of a scene that can both draw pictures and process events:

  class Spriteset_Menu extends Spriteset_Base {
      createBaseSprite() {
          // Call the base function to create all the sprites first
          super.createBaseSprite()

          // Remove the black screen background. There's really no use for it in menus,
          // since it obscures the background
          this._baseSprite.removeChild(this._blackScreen)
      }
  }

  class Test_MenuBase extends Scene_MenuBase {
      start() {
          // Call the base function to do whatever it does first
          super.start()

          // Create the sprite set and add it to the scene
          let spriteset = new Spriteset_Menu()
          this.addChild(spriteset)

          // Fetch the common event that will possibly draw pictures
          $gameTemp.reserveCommonEvent(Number(params["testEvent"]))

          // Create the interpreter and get the event into it
          this._interpreter = new Game_Interpreter()
          this._interpreter.setupReservedCommonEvent()
      }

      update() {
          var active = this.isActive()

          // If you want for timed things to work, like picture movement, you have to update the $gameTimer manager too
          $gameTimer.update(active)
          // Update the game screen manager every frame, so it draws things
          $gameScreen.update()

          // Updates the interpreter, so it works on the events
          this._interpreter.update()

          // Call to the parent class' update so it does whatever it is supposed to do too
          super.update()
      }
  }

That's about all I have managed to learn recently, for the particular task that I may be doing in the near future. I'll probably have to dig some more into other systems later, like the combat system. But I haven't done that yet. I imagine all the peculiarities apply to other systems as well, if they were designed by the same people.

I've hardly been doing anything recently, so I thought I might as well write out my thoughts on whatever it is I have figured out with RPG Maker MV, and hopefully this may help someone in the future.

Thank you for reading my blog post :)