Rogue Cores – 2D roguelike action-platformer (GIF heavy)



Thank you both! Coffee

Still working on pretty much the same things as last week, putting in pretty long hours, but progress seems super slow at the moment.

Finally figured out a way to get pixel perfect foot movement in most situations, this approach doesn’t really work for the player though, since it basically locks the sprite into the right position, it works fine and is easy enough to implement for enemies though. But there got to be an easier way to get this working, feels like I’m still missing something.

All enemies and bosses for the first area are now updated with new sprites and this method of achieving good foot movement.

Additionally the rather successful turning animation on one of the bosses in last weeks update have made me want to implement turning animations for some regular enemies as well. This proved to be very time consuming and put me a bit out of my depth. But I think the results will be worth it, having larger enemies just flip instantly is a bit too jarring.

Here are some of enemies with updated animations:

New walk and turn animation.

New walk animation.

New walk and turn animation.

The tank-walker things turn animation is a bit rough, spent a lot of time on it, could maybe be improved some more, but to really make it good I would need to model it in 3D to figure out how the legs are supposed to move… and that doesn’t seem like a good use of time. Who, Me?

Thanks for reading, hope everyone is having a good week!




Had a blast working on things not directly related to animations for the first time in what feels like forever..

Updated the “store” or the “constructor” as its called in-game. The constructor lets you create items with “money”, each constructor spawns with 4-8 blueprints of items that can be created. This is pretty common “special” room, with around 50% chance of spawning on any given floor.

I created the basic functionality for the constructor a long time ago, so it is due time that I finish it.

The Constructor v0.4, lacking some features.

As seen above the right side of the screen looks pretty empty, ideally I want to put some item information here, but the screen is way too small to have readable text. I have to settle for something that looks like item information, so it still needs to be unique-ish for every item.
The obvious thing to do is just manually drawing some data looking lines next to the pictures, so that’s what I started doing.

Pretty happy with how it looks, but there are 163 items in the game currently, doing this manually is going to be pretty tedious.
I realize whats obvious, I can just use the item names, and convert that into lines, a line alphabet.

Wait a minute, there is such an alphabet! Morse code!

Just using dots and dashes of the exact same length looks kinda bad, it’s supposed to look like text not actual Morse code. So I change the length of the dots and dashes depending on how long the letter is, and its still easy enough to see if its supposed to be a dot or a dash.

At this point I figure out that I can use the items descriptions as well, and add that to the screen by making the lines scroll. I also add the bigger “letters” by converting the first couple of letters in the items name into unreadable symbols.

In the end it is a pretty pointless feature in the game, but I had a lot of fun doing it, and now there is actual item data on the screen, you just have to decipher it! Wink

The final thing that I want to fix comes down to item spawning, when items spawn normally they are always removed from the spawn table for the rest of the run, it doesn’t matter if the player picks it up or not. The constructor works the same way, the item blueprints in the constructor are for all game purposes spawned into the constructor and removed from the spawn pool for the rest of the run, I don’t like this.
I think the bad of getting a item you really want stuck in a constructor when you have no money is worse then the good of getting rid of items you don’t want from the spawn table by leaving them in the constructor, if that makes sense.
The chance of running into the item you do want later in the run is obviously small, but it’s there, not sure how this is handled in other similar games, but basically I don’t want the player to feel punished by stumbling into a constructor room when they have no money.

It’s a small thing, but I fixed it.

The Constructor v0.9 in action.

Was going to post this update yesterday, but had a lot of fun with it and it took longer then I intended, hopefully I can get back on track with Sunday updates. Still trying to figure out the tone and structure I want in these, bear with me.

– …. .- -. -.- / -.– — ..- / …- . .-. -.– / — ..- -.-. …. / ..-. — .-. / .-. . .- -.. .. -. –. -.-.–

That tank spider bot looks especially cool Grin

Thank you Aw0, you are too kind!



This is really cool!
I also like the spider animation a lot. Smiley

Thank you TheCams, glad you like it!


I have been going through the enemies of the first area of the game again, tweaking them and making sure they work as intended. Many of these enemies are the first ones I did, so they sometimes work poorly because I didn’t know what I was doing.

At this point they all should be up to date and working as I want them to work.

I’ve played the first area of the game a lot this past week and I’m starting to become pretty happy with it, so it makes sense that progress is slow, the last 10% takes 90% of the time as the saying goes…

Below are a couple of the things I’ve done, most things I’ve done are minor tweaks and would be pretty boring to detail..

Fixed it so that all enemies that are supposed to interact with elevators/lifts in the first area of the game do so correctly (some enemies ignore them while others stay and wait).

They see me ridin’ they hatin’…

Added more death variants to various enemies, all robots / drones are supposed to have a couple of different ways of exploding and/or short circuiting.

A “Defense Drone” short circuits after taking lethal damage.

Explodes but leaves the lower body behind.

Above is two examples of what can happen when the Defense Drone is destroyed, the most common is that it just explodes outright without leaving any larger parts of itself behind, but the player needs to account for what could happen. It adds a little bit more depth to simple enemy designs, and introduces some uncertainty into the system.

What remains for the first area is still sound and music, I’m not really sure how I’m going to tackle it at the moment. In the finished game I want professional sound and music if I can afford it, but I need to be reasonably sure I can finish the game before that. Two thirds of the game is still in a very rough state, and realistically I probably need another year atleast (god)… to get them to the same level of polish.

Thanks for reading, and as always I appreciate all suggestions, critique and comments you may have.

Over and out.




Pretty bad week, not really happy with any work I’m doing at the moment, just endless reiterations trying to get something done, very little to show for it, demoralizing. Trying to refocus, might take a break or try powering through. I need to become better at doing something rather then just getting stuck trying to get a specific thing that isn’t happening to happen.

I’ll go into some detail on one of the problems I’ve been struggling with this past week…

Problem – Organic Death

These bastards, thought they where finished with their new sprites and animations, then I killed one, and remembered that their death animations have some pretty big problems, this is something they share with other organic enemies in the second and third area of the game.

Its easy enough to create explosions and debris for dying drones, organic enemies dying requires more though…

Above are the current death sprites for smallest of the imps, the others follows the same idea, one frame for flying through the air, one for laying on the floor and one up against a wall. This is pretty dynamic and looks fine, although I’m not really happy with either of these individual sprites. The problem is that its not dynamic enough and the corpses often end up in bad positions, hanging over edges or halfway into walls.

What is gravity?


Now I realize that my game doesn’t have the best graphics, I’m neither a great animator or pixel artist, but I do want the game to have great internal consistency, things should look and feel realistic within the games limited world.
These enemy corpses can’t be floating in the air, and they can’t just fall over in a fixed death animation, explode or despawn because why would they? Their deaths needs to be dynamic, they need to be sent flying over edges, tumble down stairs and crumple up against walls. Immersion should not be broken and as importantly, it needs to look fun and feel good killing them.

Ive tried making sprites, and other various approaches to stop the current sprites for ending up in the bad positions, I’ve had some small success, but nothing I’m happy enough with to keep. I think the only solution I’m going to be happy with is creating some sort of pixelated ragdoll, but it seems like a pretty daunting task and I’m not sure I want to go down that road… Seems like it could be very time consuming and the end result might turn out to not be what I’m after.

And that’s it, didn’t really want to make an update this week, but it felt pretty good just typing out what I’m trying to do and why, hopefully it was at least somewhat interesting.

Thank you for reading.



Well I was sort of right…, I didn’t really understand what was going on and why though, just tweaking animation speed didn’t do anything helpful except illuminate how little I know what I’m doing.

For someone who doesn’t know what he is doing, you’ve nailed it pretty well! Somehow it pushed the game for me from some gamemaker beginner game to really looking like a pro game now! (more than I’ve expected). all the movement look properly grounded in the world, the art style is super nice, the enemies look interesting and fun just from the gifs already, the particles that collide with the maps, feedback on most actions. Really good job!

I see potential in your player animations, currently the player character looks a bit stiff. You already have that breath-bobbing, you could extent that. it would be nice to see some momentum feedback, e.g.
 – when dropping on the floor, I’d imagine to see a bit of knee bend and shoulder drop (from higher drops, maybe even more impactful animations)
 – the jumping is a bit weird looking, I think that’s mostly because we imagine it’s a jump. if you’d add a tiny jet-pack to the back, I think it would look plausible to our brains (that he doesn’t use his legs to jump)
 – you could add some motion direction based bits to the sprite, it could be just the arms that lag one pixel behind (usually it would be something like hair that moves up when you drop, left when you move right etc.)

Keep it up, I want to play it!


Looks super fun! I agree with SamSerious, the character animation frames could use some work.
Another aspect that jumped out to me that you could improve is that it’s ennemy bullets easily become mixed with impact particles, making it not obvious which pixels the character is meant to avoid. Bullet hell games are very careful to apply some specific consistent rules to help the player know what will deal damage and what will not.

Thank you Karlipoppins!

Yes, that is something I’ve thought about, currently I don’t think its an issue when playing the game, but I could be wrong, definitively something to keep an eye on, thank you.

Decided to combat the lack of creativity I felt last week by doing some technical stuff. I updated to Unity 2019 from 2017, don’t want to fall too far behind and get stuck with a legacy version. Had some installation issues on my computer, but after that updating the game went smoothly. A couple of things stopped working, but where easily fixed, and after playing for a couple of hours I’m confident the game works as intended on the new version.

(But it might take some time getting used to, and the editor seems to run slower…)

After that I decided to take a couple of days off, spent pretty much all of that time playing “Oxygen not Included”, very happy I waited for the full release, amazing game, almost unbelievably so, my weekend just disappeared! Shocked

Got back working yesterday, didn’t have time to make a full update, and not much new to show. Working on an idea that seems promising for handling the enemy corpses, hopefully I’ll have something to show at the end of the week.




So I have been working on a solution for handling the corpses of humanoid enemies as well as handling larger pieces of debris, the current system is good for handling smaller objects and things that are not elongated.

Both of these require more advanced physics then the rest of the game, which relies on simple raycasts to determine collisions.

Unity Physics2D

When I first started out I decided after some trial and error to not use Unity’s built in 2D physics, mostly because I found it cumbersome and difficult to work with and since the game wouldn’t really need it, it seemed like a waste of time battling with.

Now years later I return to it, and I still don’t like working with it, it feels like I’m just endlessly tweaking parameters, hoping to get the effect i want. But this time that doesn’t really matter, I don’t need the physics for the main game, I just need it to handle a couple of things for me, it doesn’t have to feel good, just look good.

(I’m sure its great if you learn it properly and don’t just try to jump into it.)

Simple objects behave pretty much exactly how you would expect them to with minimal work required.

Now this has one major problem for me, Unity is rotating the gameobject and thereby the sprite. Maybe some people don’t mind or even prefer this over a “pixelated rotation” but I don’t. And this is the reason I didn’t use this method back when I created the debris system I currently use. While I knew it was possible to fix this I didn’t find a solution that I could make work back then. Now I know of multiple ways, but I’m still unsure if I could code a good implementation myself.

Pixel Perfect Rotation

The most basic way that somehow eluded me back then is just creating a child gameobject for the sprite, resetting its rotation and assigning the correct sprite based on the parent objects rotation. The benefit of doing it this way is that you can move the highlight and shadow of the object depending where the imagined light-source is in the scene, the down side is that you have to create the rotation sprites, this can be done with the help of programs (like aseprite), its still very tedious to assemble the sheets and set it up in Unity.

Another way to solve it is by some coding magic, luckily for us less talented programmers, Unity introduced the “2D Pixel Perfect” package in Unity 2018, testing this package was one of the reasons I wanted to update the versions I was running. Here is the relevant part from one of their blog posts:

Upscale Render Texture – This causes the scene to be rendered at as close to the reference resolution as possible and then be upscaled to the fit the actual display size. Because this setting results in a filled screen, we recommend it if you want a full-screen pixel-perfect experience with no margins. ‘Upscale Render Texture’ will also significantly affect how sprites look when rotated.

1. Original (not rotated) 2. Without Upscale Render Texture (rotated 45 degrees, pixel-perfectness is lost as pixel size varies on diagonal edges) 3. With Upscale Render Texture (rotated 45 degrees, pixel-perfectness is maintained as all pixels are the same size, but the sprite is less accurate looking compared to the original.)

Rendering magic.

And as a third option I found a shader that can do it that was posted to twitter by a Anton Kudin.

Sprite shader with pixel-perfect rotation, requires some metadata provided via script.
Try it out:
#unity3d #gamedev #pixelart

(Link expired, now found here:)

There are probably more ways of achieving this, and maybe it wouldn’t even be too difficult to make some sort of RotSprite implementation on your own, but this is what I’m working with currently.

Without and with pixel perfect rotation (using Unity “upscale render texture”).

I have now tried all these methods, and they all have different issues. But I currently don’t have the time to include my results in this update, and I’m still undecided on what works best for me. I hope I have reached a verdict and settled on one of them by next update.

So for now, thank you for reading! Support, comments and feedback is as always greatly appreciated.

You continue to do great work! I really like the presentation of the constructors, and the the Morse code thing especially is so cool. The variable enemy deaths are such a great choice too.

It’s this incredible attention to detail that’s going to make this game stand out. It’s hard and tedious work, but you’re fighting the good fight!

Thank you man! I hope it will make my work stand out, but damn, everyone is so damn good these days, I wish I would have gotten started earlier. Wink




I never really know how to start these, so I’m just going to jump back in where I ended it last week, my pursuit of “pixel perfect” sprite rotation.

Non of the methods I identified last week really worked for me, I’m going to do a quick breakdown of why.

While it is possible to achieve pixel perfect rotation by manually creating sprite-sheets for rotations this proved to be too time consuming for my use. The ragdoll system I’ve created relies on too many different sprites combined together to make it feasible to create sheets for all of them in a timely manner.

Upscale Render Texture
The function built into the Unity “2D Pixel Perfect” package, seems to work great, it make the entire game pixel perfect by first rendering the game in the reference resolution then scaling it up. This creates one problem for me, it ruins the parallax background system which is not designed to be pixel perfect but relies on smooth sub-pixel movement. Forcing the parallax background to become pixel perfect makes it very jittery as different layers are moved to new pixel grid locations at different times. I tried to combat this by synchronizing the movement between the different layers, and while this removed most of the jittering it made the parallax seem jerky.
I think that for a background that is further away this wouldn’t be as much of a problem, but my background is very close and pretty shallow, and that the entire background contains vertical lines also makes the jittery and jerky motion really stand out.

Jittery parallax while using “Upscale Render Texture” feature.

Might be a bit difficult to see on the gif (it’s pretty dark), but while actually playing it is very noticeable. I also saw at least one other person expressed the same problem on the Unity discussion board for the package, so I’m rather confident that I’m not missing an easy solution.

My final fallback, initial tests with the shader where very promising. However I ran into some trouble with this as well, for some reason the shader doesn’t render the “right angles” correctly, it just skips over them. This might be a problem with my configuration, or easily solvable by making tiny adjustments to the shader code, but I’m still very inexperienced with shaders and don’t really understand what I’m looking at.

Freezing then skipping over the right angles (0, 90, 180, 270), noticeable when rotating slowly.

Again I’m sure this could easily be solved by someone with better understanding of shaders, either way very generous of Anton Kudin to share his shader, definitely check out his game Mega Sphere, his pixel art has been a great inspiration for me.

While neither of these methods worked satisfactory for my game, this experience helped me better understand whats happening behind the scene, especially the “upscale render texture” feature made me think a lot about how graphics work in Unity.

Rogue Cores “native” resolution is 512 x 288 pixels, I chose this resolution because it is 16:9 and because it is 32 16×16 tiles wide and 18 tiles high, I want the screen to show full uncut tiles.
This should mean that the game is always pixel perfect in this resolution, and at higher resolutions pixel perfection is lost because the game is rendered at the higher resolution where a single game pixel is multiple screen pixels. And the game can only truly be pixel perfect at resolutions that are multiples of the native resolution (without using borders).

Despite having read countless articles and forum posts on achieving pixel perfection in Unity this never really clicked until now…  Huh?

Armed with this new knowledge I redesigned how I handle different resolutions in the game, rather then support Unitys list of 16:9 resolutions when in windowed mode the game will only support windowed resolutions that are multiples of 512 x 288, full screen will also be supported but running the game full screen will result in a loss of pixel perfection, unless its a multiple 512 x 288. This will eliminate the need to change the orthographic size of the camera, and make me finally get a handle on resolutions.

This also leads me to find and explore Unity “Render Textures”.

Render Textures are special types of Textures that are created and updated at run time. To use them, you first create a new Render Texture and designate one of your Cameras to render into it.

When configuring a render texture you can input its size, so if I make a camera render into a render texture that is 512×288 it would be pixel perfect, and if I use and change the size of this texture in the game it would scale it rather then render it at its new size. Meaning this is probably how the “Upscale Render Texture” from the package works, but without you having to manually do the configuration. When creating your own you can however control exactly what the camera that renders to that texture sees, in my case it only sees objects that should be rotated by Unity physics.

After this is done its only a matter of finding a way of displaying the texture to the main game camera. In my case this is done with a “Raw Image”. And it works surprisingly well!

For now I’m just going to show a couple of samples of how it looks with the “Imp” ragdoll, these updates always takes longer then I think they will, as I struggle with finding the right words and putting my thoughts into English. There is also still some issues that needs to be resolved with the ragdoll before it is finished, so hopefully I’ll be able to show how it works in more detail next week.

Thank you for reading! Comments and feedback is as always greatly appreciated.

Help me out by giving me a follow on twitter or sharing my work, cheers!



Latest posts