next »

[Joeb Rogers]

This was awesome to read through. Especially seeing all the custom tool work you've done to help you throughout production, as I'm particularly interested in getting into tools programming (when I can spare NOT working on the main game haha). The art looks fantastic too, best of luck!

[TheGrandHero]

This was awesome to read through. Especially seeing all the custom tool work you've done to help you throughout production, as I'm particularly interested in getting into tools programming (when I can spare NOT working on the main game haha). The art looks fantastic too, best of luck!

Several people now have been talking about the tools I made, so I guess I'll have to write about them in more detail. I was sort of avoiding the more technical aspects of creating the game because I was afraid people would find it boring, but if there's interest, I can delve a little deeper than I have been.

[Joeb Rogers]

Several people now have been talking about the tools I made, so I guess I'll have to write about them in more detail. I was sort of avoiding the more technical aspects of creating the game because I was afraid people would find it boring, but if there's interest, I can delve a little deeper than I have been.

Honestly, I think that would be really useful and interesting to read. A lot of indie developers imo come under one of two umbrellas: they either have a lot of development experience and understand the efficiency and aid that comes from utilising custom tools, and those who have yet to realise how much faster their workflow can become in comparison to slowly hardcoding everything.

It would be a great insight to many I think, to see in depth all the tools you've chosen to make and why you chose to make them (besides pure fun!).

[TheGrandHero]

A lot of indie developers imo come under one of two umbrellas: they either have a lot of development experience and understand the efficiency and aid that comes from utilising custom tools, and those who have yet to realise how much faster their workflow can become in comparison to slowly hardcoding everything.

I think I would say that there are three umbrellas. I'm paraphrasing what someone else once said, but:

• There are programmers that only know how to hardcode everything.
• There are programmers that know how to build tools.
• There are programmers that know when to build tools.

Knowing when to build a tool and when to just use a hard-coded solution is a skill that is probably overlooked a lot. Personally, I don't think I'm quite there yet. A few of the things I'm using tools for would probably be served just as well--if not better--with parsed text data files, whether at build time or at start-up.

[qMopey]

Well, what really matters is that you enjoy your style of development. That will carry the game along throughout the test of time. That said, I'm excited for more dev blog posts!!! 

[Joeb Rogers]

I think I would say that there are three umbrellas. I'm paraphrasing what someone else once said, but:

• There are programmers that only know how to hardcode everything.
• There are programmers that know how to build tools.
• There are programmers that know when to build tools.

Knowing when to build a tool and when to just use a hard-coded solution is a skill that is probably overlooked a lot. Personally, I don't think I'm quite there yet. A few of the things I'm using tools for would probably be served just as well--if not better--with parsed text data files, whether at build time or at start-up.

Yeah I can definitely agree with that! It's easy to get caught up breaking down all the things you could use a tool for in your game, until you're building like 30 unnecessary tools to minimally speed up your processes. That said, there are still plenty of use cases where a good tool can make a huge difference, not to mention it could be reused across multiple projects. A good example of this is the FM Synth you wrote!

[nathy after dark]

Yeah I can definitely agree with that! It's easy to get caught up breaking down all the things you could use a tool for in your game, until you're building like 30 unnecessary tools to minimally speed up your processes.

You reminded me of a talk! It really vocalized a lot of what I've learned from experience with fussing around too much with architecture, engines, extensibility, etc. getting in the way of dev. Here are the slides.

[TheGrandHero]

Dev Log #17
The World of Byo

I've talked a lot about Another Star 2's production and its gameplay mechanics, but so far I haven't said very much about its story. Since RPGs as a genre are so narrative-driven, I suppose that's a little strange. Today I'll finally introduce the game's setting. Small parts of what I'm going to share here I've touched on before elsewhere, but this is the first time I've really discussed the game's story in any detail. Hopefully it sounds like something fun you'll all want to experience and play through just as much as I want to create and share it.

Obvious disclaimer: story and details subject to change as the game's production carries on towards release.

The events of Another Star took place on the planet Mathma, a world full of warring clans that struggled against one another in ever-shifting alliances, eager to increase their own power and glory no matter the cost. The story of Another Star 2, however, takes place on a brand new world called Byo. Byo is a world of magic, swords, and fantasy, but also a world of technology and gunpowder, a planet populated with civilizations at all sorts of levels of development. Numerous species coexist on Byo, though humans are the most populous by far.

Like most habitable planets, Byo is a world teeming with monsters. Those traveling are advised to take the normal precautions, to have their sword or firearm at the ready, and to stick close to the roads if they don't want to run into too much trouble. But unlike Mathma, Byo is really quite peaceful. There is a stable balance of power between factions and, while armed struggle is not unknown, it has been generation since Byo has seen open warfare.

Here is Byo, the world you will explore and become a part of.

Byo may seem like a very Earth-like planet, but do not be fooled. It is no mere rock. Beneath its thin surface is a planet-sized mechanism of unknown purpose and provenance. Whatever advanced beings created this world are long gone, but a legion of synthetic custodians, widely assumed to be some manner of robots, now look after it deep below the surface. Whether these custodians were also created by the beings that created the planet itself, no one can say for sure. They rarely venture above ground, and even more rarely do they speak. Their only purpose, it seems, is to keep the planet's core running.

The planet has two moons, Exo and Origin. Exo is the smaller of the two, a mundane oblong sphere that it likely a captured asteroid. Origin is the more exceptional of the two, just as mysterious as Byo itself. Origin is covered in thick clouds and absolutely nothing is known of its surface, if indeed there is one. Probe and manned craft alike dissolve almost instantly upon contact with the moon's cloud cover. However, it seems that something must be active beneath the clouds. Occasionally, material drifts up from below, gathering in the moon's rings. This material includes organic compounds, suggesting the possibility of life. The rings periodically eject their contents, leaving bits to tumble down to Byo. What doesn't burn up in Byo's atmosphere always seems to land in the same place, piling up in a toxic heap overgrown with enormous fungus. Perhaps Origin's strange behavior is fundamentally tied to Byo's operation somehow?

You should find stuff like this all about the game's overworld.

Countless alien structures litter the landscape of Byo, exterior parts of the complex mechanisms below. They are a common sight, though their exact purpose can only be guessed at. What are they for? What do they do? Are they still functional?

Well, whatever this used to be, it's a shop now.

For the most part, the people of Byo just don't really care. All they know is that they're a free source of electricity. You can easily plug into the planet's power conduits where they come up to feed these structures, so it's common for people to build up around these structures. The planet's robot custodians still tend to these alien structures, maintaining them just enough to keep them from becoming completely overgrown. If they're bothered by others siphoning off the planet's power, they've yet to say or do anything about.

The people of Byo tend to build on top of those who came before—literally.

Byo's modern history stretches back many thousands of years, with many different space-faring civilizations arriving to find this strange world, colonizing it and tweaking it to suit their needs, but never fully claiming it for their own. Thus it's no surprise that it contains more recent ruins that clearly do not originate from the planet's original creators. Sometimes younger, fledgling peoples take up residence in the fallen cities of more advanced civilizations that arrived before them, while other times very advanced civilizations may find a home by modernizing a more primitive ruin.

But Byo's specific state as a lush planet of blue and green can be traced back to roughly ten thousand years ago. In that time, when few other civilizations had arrived, an extremely powerful human faction known as the Novar landed here and undertook its most extensive terraformation. The planet's alien shell was covered in oceans, grass, mountains, and forests. They built a great many vast cities, full of skyscrapers built of glass and steel that reached up to the heavens. But, for some unknown reason, they suddenly left Byo, leaving only a tiny fraction of their kind behind. These remnants would become the ancestors of the humans now living on Byo.

The world of Another Star 2 is certainly one of many mysteries. However, these mysteries are about to unravel very quickly, and at a most inopportune time. Despite its long history of peace, in truth Byo is very much a powder keg just waiting for the right spark to set it off. Tensions on the surface of the planet are starting to pile up very quickly. Rifts between factions are starting to widen, and old wounds that never quite healed are in danger of being reopened. Moreover, a power most foul is growing desperate, as a certain event elsewhere in the galaxy has led to unexpected consequences.

In the midst of this looming tragedy about to unfold, a young woman in search of adventure begins to take her first steps into the wide world...

[qMopey]

Did you draw those yourself? Are you an indie god?

[TheGrandHero]

Did you draw those yourself? Are you an indie god?

I did all the art myself, yes.

I'm pretty sure I'm not an indie god, though. I always assumed indie gods made more money than I do.

[qMopey]

Love your dev blog. Personally taking a lot of inspiration for the blog format, and I will steal reference your style for sure. Will read your story post soon!

[thunderlight10]

Are you going to port Another Star 1 and 2 to PS4, Xbox One and Switch in the future?

[TheGrandHero]

Shameless self-promotion: the original Another Star is currently 75% off on Steam during the Summer sale and you should totally buy it right now. Income from sales doesn't guarantee I'll finish Another Star 2, but it really does help cover hosting costs and keeps Vision Riders' bank account open.

Are you going to port Another Star 1 and 2 to PS4, Xbox One and Switch in the future?

Playing a game of mine on a real console would be a childhood dream of mine come true. Still kicking myself that I never managed to get anything out on XBox Live Indie Games.

The original Another Star would be the more difficult of the two. It's written in C# and does not use Unity, which makes porting to consoles somewhat difficult. A mobile port would be more likely. But I'm honestly not sure there's enough interest to warrant it, honestly. Not counting the IndieRoyal bundle it was in (for which I never got paid), it's still just short of 1,000 total sales over the course of about three years now. It's not the best looking game out there, either, so I don't think the Big Three are going to think it warrants their attention.

Another Star 2 is a different story. While it may be no artistic masterpiece, I think it's shaping up pretty well. So long as the number of people following its development continue to grow, it'd be much easier to get on with a console. Another Star 2 is also written in C++, so porting would primarily be an issue of dropping in new API calls and dealing with platform-specific quirks and optimizations.

That said, I can't make any promises, and I wouldn't hold my breath for it. Porting always has hidden gotchas and pitfalls that tend to be pretty time-consuming. I thought I was doing pretty well getting Another Star out to the full holy trinity of Windows/Linux/Mac, and it seems like I still run into some new and annoying porting problem every time I update that game. (Build once deploy everywhere my rear end.) There's also the significant cost of acquiring dev kits and such, which I just cannot shoulder right now financially.

In addition, there's the matter of porting the sequel but not the original, which may hamper sales. This is part of why I don't know if the final released game will even be called Another Star 2. I'm afraid people won't want to play the sequel if they haven't played the original, or that they'll look at the less interesting original and go "meh" and decide not to play the new game.

[cynicalsandel]

i forgot to post in this thread so i lost it in the forums. i'm doing so now. i don't have much to say. i think it's neat.

if only you called your first game "star", so you could've named this one "another star" to subtly acknowledge it's a sequel.

bad jokes aside, i am worried about the name "another star 2" too.

[Ayrik]

This is amazing. I love that you came up with your own console and are sticking to mainly the 8-bit era. My game is adhering 99% to NES specs so I really enjoy reading your blog and will definitely follow your progress!

[TheGrandHero]

if only you called your first game "star", so you could've named this one "another star" to subtly acknowledge it's a sequel.

"Heirs to Another Star" is one of the possible names I've considered for the game, since it accomplishes pretty much the same thing.

[xix]

TBH I think it's a lot harder to get people excited about sequels, so making it seem as though it's a standalone might be helpful.

[TheGrandHero]

Dev Log #18
The Path Forward

Lately, I've been working on a new tileset. This will be used for many of the ruins dotted across the world of Byo, built by all sorts of past civilizations that have come and gone.

My tilesets usually begin as mockups, like this one. I can display images in the engine to test them.

Ruins can be kind of tricky to get right with low resolution tile-based graphics, because if they look too nice and uniform then they just look like slightly run-down castles instead of crumbling ruins being slowly reclaimed by vegetation. I've been looking at Star Ocean: Blue Sphere a lot lately for inspiration on this. It's a Game Boy Color game that never left Japan, and it has some really nice looking ruins (well actually, it has some really nice looking everything). That game's graphics show what you can accomplish even on a grid with limited colors.

I added roots and broken floors to make it feel more run down. Variety helps keep it from looking too clean.

Some of my biggest progress in the past week has been finally hooking rooms up to the battle system. Encounters now trigger, and you can accept them as in the first game to begin a battle. After the battle, you get experience and loot, and are returned to the room to continue exploring. So far every battle is exactly the same because enemy parties haven't been properly implemented, and your HP isn't tracked between battles because the characters aren't actually in your party, but it's starting to feel like a real game at last. (I even find myself reflexively pressing the A button as soon as I hear the ambush alert sound, even though ambushes don't begin on their own yet.)

"BEE-DA-LEE-DA-LEEP!"

I began Another Star 2 about a year and a half ago. While I haven't been working on the game that whole time, a great chunk of that year and a half has been dedicated towards this one project. It can get a little frustrating when it takes so long for something to bear fruit. The first Another Star was playable within just hours, and could be played from beginning to end within a few months. (Completing it took much longer, though; about nine months all together.)

But with Another Star 2 I'm only now getting the map system and battle system to tie into each other. Granted, I spent a lot of time building a new engine for Another Star 2 in C++, while the majority of the first game's basic code was put together long before I began work on it. Still, this is taking a lot longer than it should. Even ignoring the time I spent before rebooting the engine, I've poured a lot of work into this with very little to show for it.

It's time to change all that.

Early on in Another Star's development, I put up a very early version of the game for download, jokingly calling it a "leaked" version. It was unpolished and had lots of bugs and typos, but it was complete up through about the third or fourth dungeon. I wasn't having very much luck with finding people who wanted to playtest the game for me at that point, so this was sort of my last-ditch effort to get feedback. I was hoping a few people would try it out, but to my surprise it really took off. (Granted, I assumed "now they're interested and will buy it when it's released" instead of continuing to post about the game and keep those people engaged, but that's another topic for another day.)

I'd like to do some similar things with this game. The first phase of that will be a preview build of the game. This won't be a full "leaked" release containing lots of unfinished dungeons. It will be more like a small demo in that, while incomplete, it will have some level of polish and be self-contained with an achievable end goal. I suppose this is akin to what many professional developers call a "vertical slice". The idea here is that the demo will be centered around a single small dungeon. It will give players a chance to try out the game, get interested, and give feedback. It also allows me to figure out how to streamline content creation so that I can churn out the assets for the full game. It will also help me decide what constitutes a "small" dungeon, how big a "full" dungeon should be, and how many the final game needs. This preview build won't be long. Maybe a half hour at most, and I think most of that will be just from getting used to a new game and trying things out.

Since I now have something to work towards, instead of aimlessly deciding what to work on next I can map out definite tasks that need to be completed. RPGs are really difficult to boil down to their essentials, because they need so many different components to work together before they are all that interesting. Thinking it over, I believe the following things need to be done in order to release this preview build. In no particular order:

• The preview build needs a small, non-linear dungeon to explore. I have a rough layout planned, and am already playing with room layouts to figure out how big they should be. Because the player character can run, and because the characters are larger than the first game, rooms may need to be rather big in order to avoid feeling cramped.
• The dungeon needs a couple of tilesets to build these rooms out of. (This part is mostly done; the outside tileset for the ruins is the only one I haven't done any work on yet.)
• There should be optional areas and secrets to find, encouraging the player to explore, and making the dungeon feel more like a real place instead of a simple obstacle course.
• There needs to be a variety of enemies. The enemies have to be drawn and animated, and they have to formed into enemy parties (called "formations" in the As2Tool editor). The game also needs to decide on which formation to use from several possibilities per room.
• There should be a challenging end boss for the dungeon. Of course, they have to be bigger and more impressive than normal enemies, because that's what makes them a boss!
• There needs to be a battle background or two for the ruins. Right now, the only backgrounds in the game are tests from early in the game's development, and they don't match the direction that the art style has been going. (Also, none of them are ruins.)
• Battles need to be further fleshed out. Right now, all either side can do is attack. The foundation of the enemy AI also needs to be implemented.
• There needs to be a full party to play with. That means three playable characters need to have a full set of animations for moving around, and for battle. Thus far, no playable characters have more than a handful of frames. Ridley, the game's main character, will be one of the party members in the preview build. I haven't decided yet who the other two will be. Ideally, they should bring a good balance to the team, because the player's customization options for them are going to be super-limited compared to the finished game.
• There needs to be a few different pieces of music, though they don't have to be 100% finished. Most needed are: the dungeon's theme, a battle theme, and a victory theme. These three all exist in varying states, but I don't think the dungeon theme or battle theme are ready even for the preview build.
• Items and equipment need to be implemented. It won't be much fun to explore if there isn't anything to find as a reward.
• The playable character's battle sprites need attachment points for their weapon sprites. The basic code for attaching sprites to each other has existed in the code for some time now, but there's currently no way to place these attachment points in As2Tool's sprite editor.
• The status menu needs to be up and running. Everything in the status menu needn't be functional, but the basic ability to check your party's current health and inventory are a must. The actual status page showing each character's detailed stats is likely to be a placeholder for now, though.
• I need to continue working on the scripting engine so that I can not only add interactive objects to a room, but also play out said interactions through dialog and cut scenes.
• Said cut scenes need to be written. There should be a few as the player progresses, letting the preview build's little side story play out. This will give players a chance to get a feel for the game's storytelling style.
• There needs to be some sort of title screen to greet the player when starting the game.
• There also needs to be a loading screen at startup. Right now, the game window remains invisible until its initial resources are in place, which takes a few seconds and may confuse players.
• There needs to be a game over screen, and a way for the player to carry on without having to start all over from the beginning.

Pictured: every single battle in the game right now. Every. Single. One.

In the interest of getting this preview build out the door, there are other tasks that are needed for the final game that, maybe, just maybe, aren't that important yet. Some of these include:

• Magic. It may not be implemented in the preview build. Items and magic both use scripting to function, so they're quite similar, but magic needs additional visual functions whereas most items can get by with a basic "use item" animation from the character and some text.
• Likewise, The characters almost certainly will not have their skills implemented, even if I implement magic in time for the preview build.
• PC games tend to have pretty large and complex option menus. A lot of this has to do with the wide variety of hardware you need to accommodate. I may put off programming this for now.
• Difficulty levels will absolutely be in the final game. However, you might not be able to select your difficulty level in this preview build because that would require having a working options menu.
• It would be nice to have a town in the demo so that you can buy supplies. Maybe the preview build even starts in the town and then you leave for the dungeon using an option in the town menu? However, while the town itself would be very easy to script, I'd have to set the game up to handle said script, so I'll likely put that off. You might get a merchant somewhere at the beginning of the dungeon instead.
• Another Star 2 has a new system planned for its leveling-up mechanic. It takes more work than just telling the player what stats got raised, though. For this preview build I may just give the character some more HP and call it a day. Your other stats are not quite as important in Another Star 2 as they were in Another Star; for a single dungeon, just improving your characters with stronger equipment found along the way should be enough to feel like you're making progress.
• The game's overworld is already functional as past dev logs have shown, but there's not really a reason to use it for this preview build. And while the mini-dungeon used here will almost certainly be in the game, I haven't even decided its position in the world anyway.
• You may or may not be able to save your game.

The goal here is to have this preview build out sooner rather than later. My aim is to have it up and running by the end of the month, but more likely it'll be well into August. A lot of this also depends on how much time I have to devote to the project. Depending on how real life plays out, Another Star 2 may have to set on the backburner for a bit. In any case, I'll continue to post on my progress and give insights into Another Star 2's mechanics and development as I do my best to press forward.

[Pixel Noise]

I think a small-scale, playable build (vertical slice, whatever) is a great idea, and I think anyone who's commented here would be eager to try it out! (and probably a lot of other folks, too)

[TheGrandHero]

Dev Log #19
Taking Inventory

It's been a week and a half now since my last dev log entry where I noted that I was working towards a little playable build of the game for public release. I wanted to finish it by the end of the month. I haven't made as much progress as I was hoping for, so it looks like I won't have anything ready quite so soon. I just need to learn how to make games faster, I suppose.

But at least progress is being made, even if it's not as quick as I was hoping. In the past week I've worked on getting the game's item system up and running. The scripting commands needed for items to be usable haven't been added yet, but almost everything else is done. This includes the inventory system, which is what I'm going to talk about today.

Here's the main inventory screen.

It's hard to imagine an RPG without some sort of inventory system. Not that it can't be done—it certainly can. But it's such a fundamental simulation of how we store and use our tools and possessions in real life that it's not just a cornerstone of RPGs, but of countless other genres as well. Items are usually very important in RPGs. You are an adventurer! Here is your sword! Here is your shield! Another Star 2, of course, is no exception.

Inventories in games tend to be broken down into two camps: infinite inventories that can hold everything, and limited inventories that only allow you to carry so many items (often based on weight, or count, or a combination thereof). Personally, I kind of like inventory management, so long as it's not too tedious, which is the main reason why Another Star had a limited inventory.

For a limited inventory to work well, the player needs to have access to information about the usefulness of items, and they need to be able to understand how much room they have. Both of these allow the player to make informed decisions about what items to keep and what items to toss or sell. Older games tended to fail at the former. Many came with fold-out charts in the box along with the manual. If you didn't have the chart, there was rarely an in-game way to find how powerful a given weapon or piece of armor is. Thankfully, improved display resolutions and better interface designs have pretty much nipped that problem in the bud.

Informing the player about the space left in their inventory still tends to be a problem, though. Bethesda games like Skyrim and Fallout are an example of this. Those games' inventories are limited based on weight, but when it's time to clear out your inventory it's often a struggle to figure out where all the weight is. Is it a few heavy items, or many light items that are the problem? This is an area where Another Star failed, I think. In Another Star you had 50 item slots. Players usually didn't realize this, though, because other than an untitled counter up in the corner of the inventory screen the game never really tells you up-front. Most players discover the item limit when they go to open a chest or buy something and the game suddenly tells them that they're already full.

There are a few ways I want to approach this differently in Another Star 2. First off, you'll notice that the inventory isn't an old-style list of text, it's icon-based. The graphics aren't just to be pretty. They add some valuable information that text alone has trouble conveying. There are visible slots for items to be in, so it's easy for the player to realize at a glance "oh, I only have this much room" without being explicitly told. Second, the inventory is going to be smaller at first. Maybe a dozen or so item slots at the beginning of the game. This means that the first time the player opens up the inventory, they'll see that there are less slots on screen than there is room for, meaning they don't have to scroll down before they realize the item slots don't go on forever. It also lets them "practice" managing a small inventory early in the game that's easy to track while they're still figuring out how different sorts of items are useful. Don't worry about the small starting inventory too much. Unlike the first Another Star, as this game goes on you'll be able to earn more inventory slots.

One more thing I'd like to do is to better encourage the player to use their items instead of hording them just for boss battles. The first Another Star had lots of battle-minded items like nets and bait that were useful in certain situations. However, other than the throwing stars and bows, even I usually just sell them when I go back and play the game. I want items you find to look and sound like they'd be fun to use when you come across them so that you'll want to try them out right away. I also want to make items like this more reliable. Why shouldn't the net always immobilize or slow down low-level non-intelligent enemies instead of only working half the time? If it's reliable instead of a gamble, people will want to make use of them because now they're a dependable tactic in battle. Plus, if it isn't as useful on bosses, players are likely to be less stingy with them.

This option sorts your entire inventory by type, name, or how long you've had each item.

The one thing I haven't quite figured out yet is "key" items. These were a problem in Another Star. They took up room in your inventory, but the game would never deny you one when you were out of inventory room. What sometimes happened is that a player would end up with 51 items or more in their inventory because they'd just gotten some key items. They'd go sell a single item when told to free up room to buy something, then get confused when they still couldn't buy the thing since their inventory was now at 50—still no room.

In my original notes for the game I planned to not have key items count towards the item total at all, but this might also be confusing, suddenly adding extra slots when you go over the limit just to have them disappear when you sell off items to make room. Most games tend to solve this by moving key items to their own special inventory, but I'm not sure this is a good idea for Another Star 2. In the first game, key items weren't just MacGuffins that have no purpose. They were often items that you could equip, such as the very useful "Father's Pendant" accessory acquired early in the game. If they're all in their own little "key item" inventory, the player is less likely to remember them or even realize they can be used. I may make some sort of "overflow" inventory where key items get banished to when you acquire one but have no room for it.

I suppose I should also mention to two icons at the end of the inventory screen. The first is just a simple sort option, as pointed out in the caption above. Another Star 1 also had this. Selecting it multiple times in a row has the game sort your inventory by a few different criteria. I assume most people will use this if their inventory starts to get too cluttered instead of doing it all manually by hand, especially as the inventory size grows.

The second icon is more interesting to me, though. In my original mock-up image of the inventory I added a recycling symbol to the trash bin to make it more obvious that when you "drop" an item, you aren't just throwing it away. As in the first game you get a little loot for it, although it's just a pittance so that it's still more worthwhile to hold on to it until you can sell it, if possible.

When I began working on the inventory this week, I went back to that mock-up in order to figure out where to put everything on the screen. When I did, I couldn't remember at first why I made it a recycle bin icon and not an actual trash icon. It reminded me so much of the "recycle bin" in modern operating systems that I decided to just roll with it.

Thanks for the gamedev pointers, Windows 95!

When you drop an item into the inventory's recycle bin, you get your bit of loot, but the item isn't actually disposed of yet. The most recent five items remain in the bin. If you change your mind, or pressed the button by mistake in a hurry, you can open up the recycle bin and select the item to get it back so long as you still have the loot from it, and have room in your inventory.

Now, it is possible in theory to abuse this mechanic to get five extra slots in your inventory. However, it's not as simple as you might think. Nothing in the recycle bin is safe; not once you leave the status menu and go back to exploring. If you die in battle, the entire contents of the bin is gone forever even if you choose to retry the battle. They'll also be gone if you ever reload a save. They aren't even guaranteed to be there while just walking around as maybe they'll start to randomly disappear from the bin after just a few seconds.

Here's the inventory in action.

Well, that pretty much sums up the inventory and my thoughts on it. What are your preferences when it comes to the way games handle items? What are some of your examples of both good and bad inventory designs in games you've played?

I think my next goal now is to get the character status and equipment screens up and running. Hopefully those go more quickly.