Slick Forums

~The Treasure of Absalom~
By Plissken and Ebola Zaire
Images, Videos, and Links

• New Slick2D engine WIP - The engine after about 2 months of work on it. I've had quite a bit time to devote learning Slick and making this during the summer, and hopefully development will continue on normally into the next university semester. Be sure to turn on annotations for descriptions of features.
  
• Official Absalom YouTube Channel - Feel free to subscribe and you'll be automatically notified whenever we post a new development video!
  
• The City - Designed by Plissken. This is actually the entire thing- we didn't feel the need for a sprawling metropolis, especially considering that it will play backseat to the main adventuring area. Nevertheless, Plissken showed off some incredible design here, as you can see, along with some sweet tile art by Linkus.
  
• The Desert - Designed by Ebola Zaire. The desert will only be the size of one BS overworld; this quest was originally to be for the one map quest contest and we've stuck to the original plan of roughly 64 overworld screens and 64 dungeon screens. This is actually what I'd call a "bad teaser" since it doesn't show a typical collection of screens; as Adrem ventures further inland, the blue here will disappear completely.
  
• The "Dungeon" - Designed by Plissken. The dungeon area will be just as big as the overworld and feature dozens of entrances. These screens also demonstrate the way that Adrem will collect his loot.
  
• Screen Design w/ Commentary - Ebola Zaire goes through the process of designing a screen at 4x speed with some author commentary to go along with it. (MADE IN OLD ENGINE, BUT WILL STILL BE IN GAME.)
  
• Screen Design w/ Commentary 2 - Plissken designs a dungeon screen and explains some of the process. (MADE IN OLD ENGINE, BUT WILL STILL BE IN GAME.)

General Information

Background: In April of 2009 (when this was originally posted) on a site dedicated to the Game Making program Zelda Classic, I PM'ed fellow PureZC member Ebola Zaire about a collaboration project for a One Map Quest Contest that was being held at that time. We joined up and came up with an idea that introduced a new type of gameplay to the zelda-esque genre. This isn't a long game with multiple dungeons that follows a typical zelda formula. It originally was a game making program called Zelda Classic which set out to emulate Zelda 1 behavior. Zelda Classic started over 10 years ago and is very much dated and hard to work with. I eventually got fed up with lack of control over the features and the buggy scripting language so I have now set out to build it myself from scratch using Slick2D.

The thought behind this project was simple: we make a quest in a desert, and we make it look good. Things didn't stay that way for very long; between a scripter and designer, the project became something else completely.

Although (originally, not any more ) made in Zelda Classic, this is not a Zelda game; this is an original world of completely new characters. You are the adventurous treasure hunter Adrem, who sets out from his native port to search out gold, glory, and the legendary Treasure of Absalom. Along the way, of course, he'll also have his mettle tested against vicious monsters, ancient curses, and treacherous traps that threaten to end his journey prematurely.

But nothing ventured, nothing gained.

And who, of course, knows this better than a true capitalist? For the only way to further yourself in this world is to buy low and sell high. Enemies will not drop money; you'll find no chests full of easily convertible cash. Adrem will instead often find himself knee-deep through the ruins beneath the surface without a penny to show for it. Instead, he will find tangible treasures; relics of the past that have been left protected even after their owners' deaths. If something is protected, it must have value; this value is how Adrem will make his money. He buys low. He sells high.

Of course, what this means practically is that your dad was right; there's no money tree out there. If the only way to get money is to sell a finite number of items, the total amount of money in the game is equally finite. We have given each treasure a sell value that you can redeem at a shop in town; however, we've also created some items to fit together as a set. You can sell them as individual pieces, but they will be much more valuable if you sell them as one. This isn't always the best choice though, since it means that you won't have as much money immediately available to you. Sometimes, it is the best choice; if you sell all the items immediately at their lowest value, you won't be able to buy everything that this game has to offer.

Just money in and of itself is a terrible goal; luckily, there are plenty of opportunities for Adrem to forgo his greed and give up the money he's amassed to expand and upgrade his arsenal. Finding a grappling hook in the depths of a dark dungeon seems unlikely; luckily, the shop in your port town just got one in stock. Of course, you'll have to save long and hard to afford such an item; perhaps buying the lantern will allow you to reach more treasure that will help in the process, but it will set your saving efforts back a large step. Once again, there is no correct path here; this is your journey, and the choice is up to you. However, although no choice is wrong, Adrem may find that some choices make the path forward considerably more difficult.

If that was too much theoretical talk for you, you can always read the tl;dr version:

• You won't find money on enemies or in chests
• You'll instead find treasure deep in the depths of the ruins
• Treasure can be sold via a shop, but you never know how much treasure is worth until you turn around and go back
• Some treasure is worth more if it's in a set with other items
• Most items, even equipment items, have to be bought
  

Everything Else
Some stuff are just placeholders until we can find something better. Such as all the character tiles are 16x16 which is much too small, and looks goofy next to most of the other graphics. Once I can find a dedicated spriter who can stick with us then the graphical side of things will be smoothed out.

Ebola and I are always eager to hear your opinions and suggestions; posting in this topic is the number one thing you can do to support this quest, so comment freely.

Neat. Always been a fan of Zelda.

Those npc sprites look a lot like the ones from the GameBoy Color.

They're custom made for a certain tileset in Zelda Classic. Again they'll be replaced once I can get another spriter to join the team. (Old one is awesome, but was never actually specifically on the team, just did work from time to time)

EDIT: Oops, yeah the NPCs are from the gameboy games, I misread and thought you said Link tiles.

really nice! Some code experience with slick you want to share with us? For example, handle animation stuff, backgrounds, and so on?

Suggestion: npc could not move behind something? In first video the npc-girl disappear for some time

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Very nice

Like the dialogue and lighthouse systems. I'm eager for more!

The maps are all made in tiled, and the animations have properties setup to denote when I should be animating a tile instead of just rendering the TiledMap still image. Then I find those tiles, add the amount of consecutive images based on another property in the first frame to an animation with the duration based on another property. Then I render that animation in the spot the original image was rendered at on the TiledMap. I did something similar to pull out what part of the TiledMap needed to be transparent.

And yeah, NPCs do need to have their walkability space changed, since they have the ability to "disappear" behind houses (still logically makes sense, but it'd be better if you could always know where they are without debug mode turned on). They can also trap the player sometimes, so I need to code their own little set of polygons that denotes a border for their walking range.

Anyway, thank you guys for your responses! At the moment I'm working on item functionality, multiple areas, enemies, and the always dreaded movement and collision fixes. I'll be sure to post a demo when I feel it has reached that point.

About movement and collision fixes:

Love the way it was done in Zelda Link to the Past or Terranigma (that wasn't released in the US, tho one of the BEST RPGs). You can just keep running against a wall and it will basically push either right or left, that was pretty neat.

That was with diagonal movement though right? Like if you walk towards a wall while going up and to the left, then you hit the wall (going vertical on the screen), and without changing any input the player would start heading up?

I'm not doing diagonal movement (except where the game forces it, like the stairs) but I did my best to make the movement work as fluid as possible. Say you're holding up, then you hit a wall (still holding up), without letting go of up you press left, you'd start going left, then if you let go of left as you're still holding up, you'd go up. I accomplished this by putting all input on a stack, then just using the top most element as the movement source, and when a button is let go of, get rid of the element in the stack that corresponds with that button.

Yeah Zelda was with diagonal movement. I read somewhere, they used 16x16 tiles, but the actual collision was done on a 8x8 collision layer, so they could set the collisions more precisely. Anyway, worked perfectly for them, and all that on the old SNES with the limited RAM

Yeah I am also using 16x16 grid system with the collision being done via 8x8 polygons so I can get more precise. I started with diagonal movement, but honestly I just find diagonal movement goofy for some reason, much prefer the tradition 4 directional system.

It looks awesome. I'm wondering how you managed to keep the camera centered on your character while still being bounded by the edge of the screen. I've been fooling around and making my own game engine, but I haven't been able to figure that out. I've got the camera centered on the player, and I've got bounding boxes around the screen, I just can't figure it out unless the player is moving straight at it..

edit: also, after watching the video again, I see lots of different collision boxes. From watching one of the other videos I see you're making the city image separately. Does that mean you're placing all of the collision boxes programatically? If so, instead of having ten 16x16 boxes on top of each other, couldn't you just tell it to plug in one 16x160 instead of those 10? When I did that and smashed together all the individual collision boxes I got a dramatic fps increase.

Of course, that's probably just because my collision detection is inefficient and might not be a problem for you, but if you are placing those collision boxes programatically, it's something to think about.

In terms of the collision. In Tiled I'm assigning every solid 8x8 block a property to let my code know that they are to be collision blocks. Then at the creation of the map, I look through all the properties and setup a list of polygons that denote where those collision blocks are. At the moment, it checks if the player is colliding with any polygon in the list (like, checks all of them every cycle) and there are no FPS problems but this is a small map. What I'm planning on doing is being able to only analyze the collision blocks that are within an immediate range of 2 blocks around all sides of the player. That way, each cycle will only check 20 or so collisions max (instead of every possible collision you could experience on the map at each cycle.)

The camera was actually pretty simple. I basically said that if the player is moving to the right && and he is at the middle of the screen && the map is not all the way to the right then move the map to the left at the speed the player would normally be moving to the right. Same thing for each corresponding direction. If those conditions aren't met (basically, he's near an edge) then just move the player normally and leave the map stationary.

Ah, I didn't know the editor you were using could assign properties to tiles like that. I thought it was only producing a large image. So then what exactly does Tiled export? Can it export simply a large image, or is it some kind of xml (or something else)?

Yeah, it creates an xml file which Slick already has a interpreter written for.

If I may ask a question, do you place the NPCs in Tiled as well? And the dialogue? As a property/reference to a file?

Also, the lightning is extremely nice. Love the lighthouse. Any insights on how that's achieved? I've played around with lightning in Slick, but that wasn't really that easy to achieve.

Last one: Do you use a UI lib or is everything self-made?