[Slick2d] Retro-Pixel Castles > Now on Steam! <


Steam Store: http://store.steampowered.com/app/328080/
Official Website: http://retropixelcastles.com/

Follow RPC all over the web! :slight_smile:



Retro-Pixel Castles is at heart a village simulator. But it’s really much more than that. Where most village simulators focus mostly on balancing your village, RPC also throws in a heavy blend of raw survival and tactical gameplay. If you could imagine a roguelike village sim, that’s what this game is all about! In RPC you will lose. Endless survival is impossible, the goal is to see how long you will survive. RPC takes it’s inspiration from other village management games like Dwarf Fortress and mixes them together with elements of survival games like Don’t Starve with a sprinkling of some RTS elements seen in games like Command and Conquer and even some classic Tower Defense concepts to help you bottleneck and handle the onslaught of monsters trying to kill off your poor little villagers.

You can’t win!
Yeah, that’s right. Not being able to win is a feature! The problem with nearly all village sims is you tend to reach an inevitable point where you can’t lose the game. You just become so skilled at knowing exactly what to do, and in exactly what order, the game loses all of it’s appeal and you run off to play something else. That’s not the case with Retro-Pixel Castles! RPC aims to make a game you can’t win. Every game day, the game gets progressively harder with no end in sight. The goal of the game isn’t to win, but to survive as long as humanly possible.


Build a village, and die trying!
A major part of the game is village management, and trying to discover new and creative ways to keep yourself alive as long as possible. In RPC, you will plan many days in advance how you’re going to build your village and survive the inevitable onslaught of the monsters that will attack you!

Unlock Content Through Gameplay
In RPC, you will find yourself in a harsh and unforgiving environment, constantly trying to find new ways to keep your little villagers alive for just a few more days. As you play, you’ll unlock more content, like additional buildings, items and units you can use in your next attempt to see if you can survive even longer than the last!

Even though you can’t beat this game, you most certainly can make progress in it! Every round you play you’ll gain experience, unlocks, and other interesting goodies that will expand the game.
Massive maps!

Massive maps!
Each map is a massive 512x512 tiles in size, and a typical play through you may find yourself only playing in a small area, usually about 128x128 in size. Each time you play, you start at a different location on the map, and each location has it’s own challenges! So each of these massive maps are like having multiple maps all in one!
Tons of map set themes!

Tons of map set themes!
Every set of maps will follow a certain theme (Forest, Desert, Underground, etc). Most of the current screenshots only feature ONE of these map sets, the Forest! But many, many more are planned.



FULL-FEATURED Built in Map Editor!
Built right into the game engine itself is a very robust, feature filled map editor. The same one used to make the official content for the game! You’ll be able to make maps using the same tools I did and share them with your friends, or even share them over on the Steam Workshop if we can all band-together and get RPC Greenlit!

Orchestration-Retro Hybrid Soundtrack!
A full, original and custom soundtrack, made by Bibiki Garcia that blends orchestral instruments and old 8 and 16 bit retro era music together in a beautiful blend that fits Retro-Pixel Castles perfectly!

SixtyGig Games is a DRM free independent game developer! Retro-Pixel Castles will not now or ever in the future have any sort of DRM! Piracy protection only hurts you guys, the loyal paying players. So you rest assured knowing that once you buy yourself a copy of Retro-Pixel Castles you’ll never again have to concern yourself with nagging questions about if you can continue playing the game down the road due to something like always-online logins, lost registration codes or because you bought a new computer and you’re only licensed to put the game on one. All I ask from you is to be reasonable and responsible, you can buy the game and play it as much as you like, wherever you like. Just tell your friends to support my DRM-Free philosophy and buy their own copy! :slight_smile: Free Content Patches, no paid-DLC

I don’t believe in paying for Downloaded Content. If you buy Retro-Pixel Castles you will have access to the entire game and all the content I’ll ever create for this game, forever! I believe DLC is greedy, and you deserve to have the full gaming experience from day 1, right out of the (figurative) box!

Your feedback is extremely important. You can reply here or head on over to RPC’s official website, Steam, or you can visit the various other forums I maintain a thread on and post your suggestions! I’m always looking for feedback. Just pick your flavor below! :slight_smile:

5-Month Mark Technical Demo!


3-Month Mark Technical Demo!


(More can be found at http://retropixelcastles.com or on IndieDB)













This honestly got me really excited!

I can’t wait to play this beauty. I’d easily drop 10 bucks on this game right now! The concept is amazing!

What are you using to make this? Slick? LWJGL? LibGDX? Java2D?

LWJGL+Slick2D. :wink:

I’m having lots of fun making it, it’s also progressing a lot faster than my other game, mainly because the concept was a lot easier to develop. SixtyGig will no doubt have a much longer development cycle, where as this one may be done a lot sooner. :slight_smile:

How soon though? No idea!

LWJGL & Slick?

How do you even do that?

Slick is really just a library that encapsulates/wraps around LWJGL into something better suited for strictly 2D programming. If you start digging around in Slick’s source code you’ll notice almost all of it’s main functions are just doing some workhorse/boilerplate stuff in LWJGL so you don’t have to bother coding it for a 2D engine.

But, there are a few things slick doesn’t do, that you need to go directly into LWJGL for… really right now I just skip slick for a few very minor things (that Slick might actually be able to do anyway, just using LWJGL directly made more sense at the time)

Your like a designer, artist and programming rolled into one sexy form.

Well done, looks good. Yet so simple.

Thanks! I can’t wait to get more graphics done, right now it’s pretty much the absolute bare minimum.

Eventually I’ll have dozens(hundreds?) of tiny little character sprites for all sorts of various mob types, and a lot more tileset options. I want players to be able to customize their little villages somewhat, offering several colors/types of almost everything.

My main focus now is getting the basics working, I’m going to probably start by getting the villagers to “work” and build/gather mats, etc. I have tons of mobs planned though, I can’t wait to draw them all.

The sprites remind me of the original Lemmings game. I’m loving it! :slight_smile:

The projects looks really cool!

Out of interest, could you explain a little more about how the path finding works? I have never implemented A* before, so I don’t know, but would performing A* path finding on 5k entities usually perform poorly?

I ask because I will need to eventually implement some kind of path-finding in my current project and am just now looking into the different options. Are you somehow pre-determining and storing known paths (you mentioned getting rid of extra un-needed data) …

Also, I’m not sure if you have already implemented these features yet, but it would be good to see some screenshots of how the resources look, are gathered and how they are transported? This game looks like I would enjoy just making stockpiles of items for my village geenration :slight_smile:

It has been quite a while since I programmed games with path-finding, but if you search a really easy A* path-finding guide, here is one for you: http://www.policyalmanac.org/games/aStarTutorial.htm
And yes, its way too precise to be efficient on 5k entities (though that’s not really needed, I think the 5k entities in this game were just for testing), it also depends on how you use it, though (do you check paths every (120) frame(s) or do you want to have it more accurate etc.).

Moreover, I like the blood-effects most I think, although its unfortunate that all body’s remain in one piece :wink:

Sounds and looks great, its the kind of game I love to play: turtle in and slaughter anything that comes!

You’re the third person to tell me that, lol. :slight_smile:

I guess there’s only so many ways to animate a 7 pixel high character. ;D

Best way I can think to explain my pathfinding is:

  1. My pathfinding works by storing a ton of 0, 1 and 2s in a 2D byte array that’s the height/width of the map. 0 is an unchecked tile, 1 is a tile needing to be checked and 2 is either a blocked, or already checked tile.
  2. It runs a large while loop (the biggest resource hog), in that loop, the very first run, it only checks the destination tile
  3. When it checks the tile, it then checks the 9 tiles around it and “parents” those tiles to the destination tile (Points an arrow to it, as seen in my visual example above)
  4. Stores the coordinates and parent info of each checked tile into a master ArrayList used for later.
  5. Then, it checks all 9 tiles just checked again, looking at the 9 around it. Any tile that is marked 0 in the byte array then has it’s coordinates stored into the temporary ArrayList to be checked on the next cycle.
  6. Next cycle runs, it checks all the coordinates stored in the temporary arraylist, and repeats all the steps over and over expanding out it’s search pattern. Since it ignores blocked tiles, when you visualize an animation of this process the arrows look like water flowing through the map around walls/cliffs/etc.
  7. As soon as at least ONE arrow touches the starting point (remember, we started this from the destination) the while loop stops, and calls that arrow the “shortest route”.

then… it builds the path (using the master ArrayList from step 4)

  1. It takes the coordinates in the ArrayList for the path that contacted the other end first, and asks what it’s parent coordinates are. Stores the data of the current block in a final ArrayList.
  2. Repeats again on the parent coordinates.
  3. Repeats over and over until it tracks all the way back to the destination.
  4. Takes that ArrayList of coordinates it built, and returns it to whatever class was asking for the path (the entities usually) to be used to actually walk the path in it’s own code.

Here’s a screenshot of an entity on a really short path, so you can see the start, end, and the “spread” pattern
CLICK HERE FOR FULL SIZE: http://sixtygig.com/junk/InDev-2014-05-09-3.png


The main reasons it’s so fast:

  • It never has to cycle through the entire map. It just needs to know where the edges are so it doesn’t go beyond them.
  • It heavily relies on byte[mapHeight][mapWidth] (in this case [256][256]) arrays to track most of the data.
  • When it runs the while loop, instead of checking the entire byte[][] array for “checkable points” it only has to check all the points assigned by the temporary arraylist, so there no need to search the byte[][] array at all, it just calls up all the points in the ArrayList and checks them.
  • It removes all of A*'s terrain movement cost and basic heuristic data, so I cut out 2 or 3 int[][] arrays in the process to track movement costs. (Movement cost stuff is well explained here, and you can probably imagine how it adds a lot of additional data to check: https://www.youtube.com/watch?v=KNXfSOx4eEE )
    (EDIT: To kinda explain what I mean, if you watch the video, mine parents arrows like in the tutorial but does NOT have the H, G or F costs at all, and still always finds the same path A* would have anyway. Technically A* may be able to do this in less checks, but my checks run so much faster it doesn’t matter.)

They’re not coded yet, but think Warcraft 2-like.

The plan as of this moment:
With wood for example; Basically the villagers will go from a source building (Like a lumber mill) back and forth from trees, slowly cutting down the forest as they go.

Each villager will also have a mini-inventory, that will store a few items. For example, if you want your villagers to go chop wood, they first have to head to the lumbermill and pickup an axe, and they can only hold a few tools at once. So if you overwork a villager he’ll have to waste time putting tools back. Alternatively, your villager may be able to hold a few bandages, healing potions, or something like that in those slots instead if he doesnt fill them up with tools/junk. This could help him if he’s attacked, he could chug a potion while he’s running away.

As for how they stockpile, I’m not sure yet. I want it to take of physical space on the map (so hording becomes a problem). But I am unsure how at the moment. Maybe a combination of “storage buildings” and allowing you to stack items outside in designated spots.

They’ll be many more death and “dead body” animations. Right now I just have the basics. Eventually the guys will be able to be blown up, torched, disintegrated, melted, etc. (depending on how the poor guy died)

Thats the idea! :smiley:

Hey, BTW, ray, can you share the source for this? It doesnt have to be publicly I’m just really interested in this path finding and orgasmic shadows. :stuck_out_tongue:

I’m not quite ready to share the pathfinding source yet, I want to make absolutely sure it’s working as it should. :wink:

The shadows are actually very simple, all it’s doing is checking the map for a tile, if it’s there, it plops a shadow sprite under it. The confusing part is getting the time of day and rotating the shadow around with Graphics. But it’s actually not all that complicated at all, just takes a lot of tweaking to get it just right.

(EDIT: This code was designed specifically for a 8x8 tile map, you’ll have to change some values to work with a different size map, mainly the rendering forloops)

Fast-rendering, dynamic lighting, that is actually based off my pathfinding algorithm! Imagine that?




Looks good, very smooth!

Just because Rayvolution hasn’t mention, They’re stream is up now. Come and join. :stuck_out_tongue: http://www.twitch.tv/sg_rayvolution

I use the AngleCodeFont class and a custom font I made. :wink:




Oooch headache.
A day-night-cycle?
Looks interesting.