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

—

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.

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!

–

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

Thank you Aw0, you are too kind!

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

Thank you TheCams, glad you like it!

—

Hello,

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.

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!

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.

Sprite-Sheets
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.

Shader
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… 

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!