This little personal project consists in a Super Mario game inspired by the gameplay of Bomb Jack. It is still WIP, but I kinda like how it looks already :)
The game features a user controlled Mario going through levels trying to get every coin from each one. The task, however, is hindered by several lurking enemies:
Spiny: This little spiked turtle randomly wanders the floor and walls of the level. However, they are somewhat clumsy, and sometimes trip and fall down the walls and ceiling. You better look up every now and then when dealing with these.
Boo: The infamous master of back stabbing. Boo won’t hesistate to chase Mario while he is distracted, but will remain harmless while looked at. I’ll only give you one advice: keep an eye on him.
I’ll try to update the entry as development progresses.
PD: Also, to be honest, I have never played Bomb Jack before, but I sure am a big fan of the moustached plumber.
Lately, I have been working on adding a Command Palette window to Unity’s Editor.
For those of you who don’t know what a Command Palette is, it is a window with a single input field that shows a series of available commands based on the text on the input field. With it, you can basically choose one of those commands and it will execute, allowing you to do some complex tasks just by typing the right command name.
I have put my efforts to make mine work, look and feel just the same as that in other softwares, like Sublime Text’s, Atom’s or Visual Stuido Code’s. And these are my results:
Right now, these are its features:
Command suggestion based on the input.
Auto completion.
Support for commands with arguments.
Support for overloaded commands.
Support for custom argument parsers.
And, of course, support for adding custom commands.
Actually, custom commands can be added extremely easily and it supports methods with up to 10 argumnets and absolutely ANY type of argument; as all the magic happens behind the scenes through the magic of reflection.
After finishing a little ToDo list, I am planning on releasing this on the Asset Store (most probably for free) and opensourcing it. In fact, there’s already a working version on my git page.
I love action games, and I like them simple. And by simple I mean that I don’t need a huge background for the story, or complex mechanics or austonding visuals; by simple I mean just any excuse with which I can feel the power in my hands. Non-sense, brutal, explosive power. More accurately, I love every game that can offer me such things. As an example, be it a Dynasty Warriors -or mostly any other mousou- game (not entirely an action game, but features full action packed 1 vs 1000 battles), the Ratchet and Clank series (again, not completely an action game, but I love the way I can blow things up) or some shooters like Borderlands.
I decided to try my best and make my own action game. I decided it would be a top-down shooter kind of game, due to its simplicity, featuring tons of weapons and explosions, just like Ratchet and Clank. So, basically, I wanted an excuse to code some explosions.
Character Movement
The whole system for moving characters has probably been one of the most challenging things of the project. How’s that, you ask?
Well, basic movement is not hard at all: characters can only move on the XZ plane and, at least for now, there is no jump or complex movement mechanics; plus, I use the built-in CharacterController component, so I only needed to use that. The component gives me precise movement, collision detection and sliding on surfaces all with only the Move method.
The problem came, however, when I wanted to push characters. It’s hard to see in the video, but when an explosions happens, it pushes back every enemy it touches.
That kind of things is usually handled by physics (aka rigidbody in Unity), but Rigidbody does not work well together with CharacterController. So I either had to write my own character controller using rigidbody (which I’ve done and won’t repeat ever again); drop the push functionality; make some dirty and hacky workaround using only character controller or make use of both systems.
While I know making your own system using rigidbodies would have been the best approach to achieve a fully customizable behaviour, it would have been the hardest, most tedious and time consumming solution. So I decided to go with using both systems, enabling and disabling one or the other whenever necessary.
So, in the end, I make use of the core Move method of the CharacterController and, only when needed, I switch to using the rigidbody built-in physics.
Concluding, finding the solution was the hardest part of the moving system.
Core algorithms for the character’s movement system. AddForce switches from CharacterController to Rigidbody system, and, when finished, CheckForceVanished switches it back.
Weapons
I got inspiration from Ratchet and Clank arsenal, and I have built 3 weapons to date: granades, a flamethrower and a simple gun.
Selected weapon’s name, ammo and experience is shown in the center.
Weapons are equipped through a quick-select menu: while you press the button, the menu shows and you can choose a weapon by moving the mouse. When the menu is closed (by releasing the button, the selected weapon is equipped.
From left to rigth, grenades, flamethrower and gun.
All weapons share one common functionality inherited by the abstract Weapon class, which holds values like rate of fire, damage, range, precision etc. but it’s up to every weapon to control it’s own specific behaviour. Every weapon has it’s own type of bullet, whose behaviour also differs from the rest.
ToDo
Although the core functionality is set up, there is still work to do:
AI: there are a lot of weapons for which I will need some sort of pathfinding, so it’s not only a matter of enemy AI. The rest of the enemies AI can still wait.
Implement the experience system. While I haven’t yet talked about it, I want every weapon to be upgraded through experience points.
Moar weapons, moar…
Of course, there are many more things to do, but these should be the first ones.
Lately, I have started thinking a lot on sorting algorithms. I think I may have some really good ideas; the thing is, though, that I know little about the matter, so chances are my ideas are tremendously bad.
I have been looking for a tool on the internet that lets me play with lots of sorting algorithms and lets me compare them. Maybe I’m looking for something too specific, but I have had no luck.
So I have started making my own tool =)
These are the specifications:
The user has to be able to compare among a variety of algorithms.
See stats about each algorithms, like time spent, number of iterations, comparisons made etc.
I want the algorithm to run via Coroutines*
The user has to be able to visualize the output online
Be able to sort large amounts of integers.
*I could go with threads, which would be much faster and optimized; but I would lose control over the algorithm and that is a crucial feature if I want accurate representation.
I have open-sourced the code, and it’s available on my github page.
Drawing the graph
During a while, I really struggled with the representation of medium-size arrays (above 20.000).
My first attempt was representing each bar with a GUI Image: a simple rect. Obviously, that didn’t allow me for many items, and I quickly changed the approach and I decided to go with pure meshes (a simple quad per bar), but the performance wasn’t much higher.
My following idea was low level drawing using the Unity GL class. The performance was much higher, being able to represent several tens of thousands, even if at low frame rates. That, however, wasn’t enough for my specifications. I have to admit I didn’t clearly understand why I couldn’t manage to draw more than 100.000 tris without severely lowering the framerate (I mean, those tris were even being batched. Why was it so expensive?); until I figured out the problem was not the amount of tris but the amount of meshes. Considering I was drawing one mesh per bar, I guess it is not cheap to draw so many meshes per frame.
After that, I decided to combine the meshes into one alone. Instead of using the GL class, I would instantiate every bar individually, each one in a different gameobject and rendered with a MeshFilter and a MeshRenderer; and then combine all of them into one single game object. I had to do some fancy algorithm, as meshes in Unity cannot exceed 65535 tris, so, in the end, more than one mesh would be created. With that approach, I was able to render more than a million of tris with still quite good amount of frames per second. The solution, however, was flawed: Instantiating and “deleting” was an expensive task (even though I was using a pooling system), so having large arrays took an inconceivable amount of time. Still not the final solution, but close.
Instantiating game objects and deleting them are both expensive tasks, so I decided to go without gameobjects. Instead, I would create procedural meshes of a maximum of 16000 bars each (because of the limit of ~64k tris per mesh) and draw them using Graphics.DrawMesh. The results were splendid: Instantiating several hundred of thousand bars took only a fraction of a second, and the cost of rendering them was completely negligible. In top of that, I implemented a pooling system, so further instantiation would be virtually instantaneos.
Updating the graph
Every frame, if any value has been changed by the algorithm (and I check that through a callback), I rebuild the mesh needed to represent that new value.
This can actually be done at a pretty solid rate even with large arrays. This, however, can be changed by setting the max amount of bars that every mesh represents. By default, it’s set to 16k (explaned above), which leaves for very few meshes for rendering very very large loops when updating. So, in the end, setting the right amount of bars per mesh is a tradeoff between performance when drawing and performance when updating the mesh.
ToDo
Let the user decide the amount of bars per mesh through the interface*
Every window should show some stats about its current algorithm.
Add more algorithms.
*Right now it’s not done because I would like to prepare the pooling system for different size of meshes, so not only meshes of 16k are stores. Not complicated at all, but time consuming.
Antonio Cobo 