The game has no singleplayer, and multiplayer requires you to join a server or host one.
Phill
Creator of
Recent community posts
Thanks for letting us know, the pillar addition was implemented hours before submission and was not fully tested with everything, so perhaps there was a case that wasnt handled. For the art style, I agree its a very bright and hot to the eyes, and that was the point originally, however the colour grading in some of the stages was indeed a bit too harsh.
I quit while doing the 4x4 grid puzzle. The game needs to explain this puzzle to the player, and more importantly assist the player to know what they should be doing. Its an interesting idea, but I dont think its getting the deserved light that its currenty getting. Dont get me wrong, I understand what the puzzle is doing, Im just not able to hold that much information in my small brain to be able to comfortable click on the right squares with certain confidence, it feels a bit too random, and brute forcing it seems to do much much faster. (its often noted that people dont like to put in effort into thinking too much with certain tasks when another option with less effort is possible).
The general trope of running around a dungeon and solving to progress is fairly spot on, with various key and door mechanics spread around encouraging progression for the player. 5/5 on theme for that. Game is fairly polished, theres not much to innovate or implement here, its all fairly standard.
Overall, the grid puzzle mechanic should be either studied a bit more to figure out if its a good fit, or to replace it with a near equivalent. The other door unlocking mechanic where you predict the circle on a vertical line is pretty easy to pull off, and easy to understand. Theres not a lot of room for error, you either click on time, or you dont.
Fun but poorly balanced at the beginning. Audio levels are way too high on default, but I dont blame you for this since every game that has audio has ear shattering levels (thought at least add an option to change the volume).
The juicing on this however, is nicely done. The blood feedback, and the sounds for every action is a good touch. I'd say its more polished than you think, its just missing the endless part.
Nice and simple puzzle game, straight to the point. Player hit bounds arent represented well, I kept dying to spikes because of that, until I tested the player hit bounds myself. I was looking for the "restart" button at the boxes part because I failed at first try, so I reloaded and then later found out there are spawns at spawn. You should really put an escape menu that lets the player restart from anywhere at will, or just R to restart keybind. Boxes felt like they were sliding on ice, anyone looking a wooden crate expects 0 sliding. The visuals are nice and consise, but the music doesnt match as well. For the theme itself, it fits it nearly dead on, generic underground environments, spikes and pillars everywhere. The telegraph on the skeleton enemies that shoot is a very nice touch, its good that they have the pullback animation before shooting, it would be even better if the trajectory of the arrows was communicated a bit better. It looks straight, but people are going to mix up at what Y level the arrows are actually going to be. This is because players arent actually going to look at them, since the behaviour is the same every time, and there is no reason to observe the enemy, theyre instead going to focus on timing the crossings.
Overall, nicely executed.
Really nice how the game is packaged into an extracting zip, saves some time when getting the game loading.
Gameplay itself is interesting at first, but the incentive to keep playing quickly runs out, since the objective is to destroy all of the mold then finish. The player will only be doing those things because they have to, not because they want to. If the game had a way of converting the money resource into something the player could have, the mold enemies in the level will have double purpose. Levels dont seem to be randomly generated. The game had no way to communicate to the player that the flashlight was on, as such, every time you picked up batteries, your flashlight instantly ran out unless you kept track of the state. A probable fix is to either change what the flashlight icon looks like if its off, or turn it off completely if it runs out. Flashlight also seems to serve 0 purpose, since you can already see without it.
The intro sequence is a really really nice touch, its nice that you explain the universe that this game takes place and it really helps. Feedback on pickups, shooting, and progression is also a really nice touch. Its important that the game communicates important events with the player, especially if theyre to do with progression. Overall, the game feels really cohesive and consise, its a simple idea that works really well if expanded upon in the future.
I really like the visual style, it looks clean and polished. The gameplay itself feels heavy, the character has a very long acceleration time, I really wouldnt mind this if this could be somehow explained (if the character was really fat and with large mass). There is no way to tell how much health the player has. After getting to the helmet part, I was a bit confused about the controls, only to later find out that I was playing as the enemy that I thought I was supposed to fight. This kind of abrupt perspective shift really needs to be handled more gracefully. There was also no way to tell if I was making progress or not fighting the player, so it felt like I was doing nothing. Some visual or audio feedback to progression would really help. As for the theme, I think it adhered relatively well since it included a dungeon of some kind.
But more importantly, give the player feedback for anything that should be meaningful in any way.
It has audio that works as feedback and music, thats great! The idea itself is really interesting too. One thing I will point out, is that the game should hint where you have to go, at first I thought I had to bring her down to ground (because its safer on the ground), only to realize that there are more things above. Adding a simple camera cue or just an explicit arrow point up would be good enough. Simple and fun. I dont think the game adhered to the theme really well, because this settings is more of a tower more than a dungeon.
Death screen wouldve really made this much better, I thought as a player, that I accidentally entered a new zone, and as such thought I was playing the same level over and over. Jump height should be increased slightly so that it clears the platforms much better. Theme was barely adhered to in my opinion, there was no reason for me to think that this was a cave instead of a dungeon, some indicators and visual cues that this is a dungeon wouldve helped. Needs audio, that goes without saying. Its good that you showed the player that tab is the build mode, except I think that the key should be shift, because the left most finger on the wasd cluster is already resting on shift. Build mode doesnt seem to have a clear use, I can just use ropes to traverse the levels. All of those aside, its really fun to play, and I wish it could have more visual feedback, some audio and perhaps some tuned controls.
Lack of audio and visual feedback from any player vent makes it hard for it to be fun. Music transitions way too quickly, and it is way louder than the shotgun sound. Player controller is very floaty for this kind of game, player moves too fast and accelerates too slowly, moving on platforms should move your player as well. Opening the door was confusing as there was no clear indicator that it opened (add a sound), it was clear that you had to climb up the platforms, but there was also nothing there to support that hypothesis. Game adhered to theme well and it used common design language for dungeons.
If you were interested in the dev console from Source games, then this console is pretty much that. GitHub link.
It finds all static methods, properties and fields marked with the [Command] attribute. Though it will also find any of those as instances too! As long as you register the instance that owns the command prior to calling. What this means, is that you can mark any static method, property or field with that attribute, and automatically expose it to the in-game dev console.
It's also useful on non-static commands as well (instance), for example, any player object, any pickup object or any script that is attached onto a game object. Like mentioned before, as long as the object is registered, you can then reference these objects with the @ prefix.
@player gun "super gun" - Changes the gun on your own player to the super gun @boss gun "nerf pistol" - Changes the gun of the boss to a nerf pistol
The most common usecase for this console is of course debugging, quick dev cheats and even game bootstrapping. I personally use it in conjunction with networking code.
net host 16 25565 net kick user:5 net shutdown
Let me know if its easy enough to use, and if theres any suggestions or improvements. I work on this utility actively because it's something that I use in all of my games.
TLDR: Add a [Command] attribute to your static method/property/field and then call it from the console.
I know I shouldn't be necroing this shit, but I wrote a neat little package that wraps all of this. GitHub repo.
If you're using 2018.3.x you can add the following to your manifest.json file in Packages folder:
"com.popcron.gizmos": "https://github.com/popcron/gizmos.git"
After that's installed, you can just call Gizmos.Line(a, b) and so on, and it will draw your gizmos for both the editor and builds. Let me know what you guys think of this, I'd be happy to listen to suggestions and feedback on its usability.
I currently use these gizmos in all of my personal games, so that I could hit F3 while I'm playing my game to test out hitboxes and bounds and such stuff.
Guess I'll share my music here as well.
https://soundcloud.com/dingamatron
I'm no trained musician, so all of my music is a product of me being self taught.
They way I would do it, is to make the game open from a launcher. When the game opens, the launcher just hides itself.
And it would track the status of the game executable. If it detects a crash, ask the user if they'd like to submit the crash report (the output stack from the game and the machine details), and encourage them to add steps to reproduction if they can, or comments in general.
In the Unity game engine, theres a useful thing that can help you debug your games, this is the Gizmo toggle.
First, an intro to how gizmos are drawn. Every MonoBehaviour has a magic OnDrawGizmos and OnDrawGIzmosSelected methods. The engine listens for these and executes them when a camera finishes drawing, this includes the hidden scene camera and any other camera. These methods are still compiled into the builds, which means that any code in it, will stay there, but will never be called.
Its a really nice feature when debugging in the editor, however they arent visible in builds. Which is why i made this thread, to explain how you can implement the GL class in unity to display the same gizmos, in builds.
Now to the GL class. This class provides a handy method that can emulate the OpenGL implementation of glVertex3(x, y, z). This method is used to specify a vertex of a shape, and pairing this with GL.Begin() and GL.End() methods tells OpenGL if its a new shape, or a continuous one. So how do you draw a line, in screen space? Well, you have to perform your GL code inside the OnPostRender code, which has to be attached to a camera.
using System.Collections.Generics; using UnityEngine; public class GizmoManager : MonoBehaviour { public Material material; void OnPostRender() { material.SetPass(0); //optional, i have mine set to "Sprites-Default" //OnPostRender method GL.Begin(GL.LINES); GL.Color(Color.yellow); GL.Vertex(Vector2(0, 0)); GL.Vertex(Vector2(100, 100)); GL.End(); } }
Ok, you have a diagonal line drawing now, but the Gizmos class still exists, can I override it or hide it? Yes.
One way, is to create a new class called Gizmos, and create your own gizmo methods inside it. This can be placed in the same GizmoManager class file. The only caveat with this is that you have to implement all of the old methods yourself.
public class Gizmos { public static void DrawLine(Vector3 a, Vector3 b, Color color) { //DrawLine method } }
If you compile this, and try to call Gizmos.DrawLine(), it will default to your implementation of this class. If you want to specify the Gizmos you've been using before you have to explicitly specify the namespace it belongs to.
//DrawLine method UnityEngine.Gizmos.color = color; UnityEngine.Gizmos.DrawLine(a, b);
In fact, if you place this line in your own DrawLine implementation, you will be able to draw lines again. So moving on now, how do you call the OnPostRender class from the old one, so that your DrawLine methods draws a line?
A way to do this, is to add the two vectors two a list of lines in the GizmoManager class, and then in the OnPostRender method, for loop through this method and draw all of the lines. Then clear this list after for loop through all of the lines. Why? Because OnDrawGizmos runs before OnPostRender, so theoretically, every line asked to be draw, will be drawn.
So what do we do know to our code? We add a new structure type:
public struct GizmoLine { public Vector3 a; public Vector3 b; public Color color; public GizmoLine(Vector3 a, Vector3 b, Color color) { this.a = a; this.b = b; this.color = color; } }
Now that this is declared, you can create a list of this type in your GizmoManager, and now that you have a list, add to it when you call DrawLine in your Gizmos class.
NOTE: Make this list static, so you can access it from the Gizmos class.
//DrawLine method GizmoManager.lines.Add(new GizmoLine(a, b, color));
Then in your OnPostRender method
//OnPostRender method GL.Begin(GL.LINES); for(int i = 0; i < lines.Count; i++) { GL.Color(lines[i].color); GL.Vertex(lines[i].a); GL.Vertex(lines[i].b); } GL.End(); lines.Clear();
Now if you play your game, your Gizmos.DrawLine method should add a GL Line to the list, and have the OnPostRenderer will loop through all lines, and draw this line. Which means its visible in builds. However, the lines are still not visible when the gizmo toggled is turned off. This because the OnDrawGizmos method, only runs if the gizmo toggle is on. So the solution here is to call the Gizmos.DrawLine() method from the OnRenderObject() method on your game objects.
NOTE: The OnPostRender method doesnt run every frame in the editor, which means your gizmos wont be drawn when in edit mode, a workaround for this is to execute the real UnityEngine.Gizmos.DrawLine() method if the Application.isPlaying property is false.
You might also notice that the lines arent visible through other objects, you can fix this by setting the material to a shader that ignores the ztest.
For those in a "rush", heres the full .cs file, just drag and drop onto your Camera and you're good to go.
And here is an example of my 2D game Paintime