This thread has gone through the wringer, starting as a months-late introduction to a platformer roguelike, branching to accommodate a spin-off of that, and eventually becoming all about the spin-off.

So, here's

It looks like--

Yep, that's the point.

When does it--

Soon.

What platforms is it--

Windows, Mac, and Linux.

But can I--

Yes, the CRT simulation is totally optional, just like it was in Super Win the Game. In fact, it's disabled by default in this one.

You can read lots more about the development of Gunmetal Arcadia Zero and its sequel, the roguelike Gunmetal Arcadia at the official site.

Not yet sure whether I'll create a new thread for the roguelike Gunmetal Arcadia and let this one live on as the Zero thread or whether I'll just reset the percentage back to whatever makes sense and keep on using this one. We'll see.

Original, outdated post follows:

OH HAI. I started working on this one last October and forgot to make a TIGS thread until today. Whoops!

What the butts is Gunmetal Arcadia?

Gunmetal Arcadia is an action platformer featuring permadeath and upgrade choices in a procedurally generated world of entwined magic and technology.

I'm reusing much of the technology I developed for Super Win the Game and making improvements wherever I'm able to facilitate a richer, more expressive experience.

The core game mechanics in Gunmetal Arcadia will mirror those of classic action-adventure games like Zelda II, The Battle of Olympus, Faxanadu, Castlevania, and others. Run, jump, hack and slash, collect loot, buy upgrades, kill baddies, talk to NPCs, save the world, bleep bloop blah.

The world of Gunmetal Arcadia is divided between those who favor technology, engineering, and military might, and those who favor magic, natural resources, and elemental energy. The tense balance between these factions is the backdrop to a larger conflict: Arcadia is being invaded by an alien menace, and it's up to you to defend the land and take the fight to your invaders. As you progress, you'll upgrade your character with new weapons and abilities that will skew either towards the technological or the magical. Depending on how you outfit your hero, NPCs may react to you differently, and your actions may have lasting effects on the world.

I'm about three or four months into development, and I'm in the middle of building a lot of the moment-to-moment gameplay stuff working or prototyped. I'm putting off most of the high-level roguelike systems until later in the dev cycle. I've worked on a few projects that involved random level generation in the past, and I've found that if I start thinking about that stuff too early, it tends to muddy up everything else. This time I'm starting with the fundamental mechanics and building out. (My thinking is, until I can make one bespoke level fun, how can I expect to be able to make thousands of randomly generated levels fun?) Most of the content in the current build is placeholder (the player character is basically a trace-over of Link from Zelda II); my plan is to move on to real content production once I've wrapped up the implementation of core systems.

Screenshots

Thumbnails. Click to big!

Highlights from past blog entries

I've been keeping a weekly devlog at gunmetalarcadia.com since the project's inception, and I'll be linking or pasting those here in the future as well. Here are some of my favorites from the last few months:

The CRT effect is incredible. I've never seen anyone reproducing the effect of the inner bezel of the TV reflecting the image before - very nice idea and very convincing! The game itself looks great too

My level editor also serves as an entity construction tool. In Super Win, entity construction was done entirely by hand in XML markup; in Gunmetal, some aspects have been wrapped within a visual editor for ease. In both cases, however, the editor outputs definition files for each entity. These definition files consist of XML-like nested key-value pairs, written in a binary format for faster loading. As these files are generic in format, I use them for multiple purposes in my engine. When used to define an entity, each of the top-level tags define a component either in full or in part.

At runtime, the game invokes the entity factory to produce an entity based on a provided definition file. The factory examines each tag, producing components as needed, attaching them to the output entity, and giving them a chance to use the input definition data to set up their own properties. At this point, the factory also queries the serializer to see whether it contains any additional data with which to define this entity’s components. If we’re just starting a new game and constructing an entity for the first time, it will not. We’ll come back to that in a bit.

The factory returns the fully constructed entity to the game, where it lives for a while and does whatever it’s supposed to do. (Essentially everything that can be seen or interacted with in the game is an entity, from the player character to enemies to loot drops to doors to signposts to particle effects and so on.) At some point, the entity will be destroyed. This may be because it’s something like a particle effect that has exceeded its lifetime, or because it’s an enemy who has been killed or a loot drop that has been collected, or maybe the player has walked into another room and this entity is being removed from gameplay. As part of entity destruction, each component has a chance to export data about its current state to a component delta structure. This data is passed to the serializer and stored until the next time the factory attempts to construct this entity, at which point the original definition data is supplemented with these deltas in order to restore the entity’s components to the state they were previously in.

In order to distinguish between similar entities which may share the same definition data, entities are assigned a GUID. These is done automatically when entities are placed in the level editor, and (new to Gunmetal) this can also be done at runtime for things that are dynamically spawned, such as loot drops. The serializer looks for the presence of GUID information when managing component deltas. If the entity has no GUID information, it is assumed to be a temporary entity like a particle effect that does not need to be serialized.

Not only does the serializer keep track of information about entities and components that have been created at runtime during the current session, it also handles disk access for saving and loading component deltas. This allows the previous state of entities to be restored on a future session. This was how saved games were handled in Super Win, and will likely be how they’ll be handled in Gunmetal as well.

I've published a playable test build today. It's a super short demo, I'm mostly just looking for feedback on game feel, how the character moves and stuff like that. If you have a couple minutes to give it a try, I'd appreciate any feedback!

Miscellaneous thoughts follow:Character felt slightly slippery - I think I would prefer it if he(?) stopped a bit quicker when I let go of the controls.

I just realised the other thing which makes it feel slippery to me is that you make the character crouch on landing, but don't cancel the X velocity. To me, if he's landing heavily enough to go to his knees there's no way he'll keep walking/running at the same time.

Attacking the slime felt quite good and solid. The breakable wall less so (mainly just lack of effects, I think)

Gravity felt a bit too high after the apex of the jump. It felt fine for walking off edges, but a bit too rapid for the end of the jump. Maybe smooth the transition from jump gravity to fall

I really like the CRT simulation!

Going left/right when at the top of a ladder made the character climb up a tile higher than needed (when climbing the ladders which stick up a tile above the neighboring floor)

Using the same key to read signs and attack seemed odd unless you're not going to have enemies in the same rooms as signs. If you're using up to enter doors, why not use that for reading signs too? (Since they're also on the back wall)

Hope that helps, and good luck! I really enjoyed "You've got to win the game" and "Super win the game", so I'm looking forward to this!

ok tried it. i only have 2 gripes: 1. the bombs are too bouncy and thus too hard control, especially considering they can damage you. 2. the death animation for the slime is a little unsatisfying. i feel like instead of just blinking for an arbitrary amount of time and time disappearing it should explode or deflate or something like that imo.

The similarity to Zelda II will definitely tweak a lot of people's nostalgia buttons; mine, certainly. That's still one of my favorite games of all time.

Since you talk about choosing between magic/technology, I'm assuming you are planning to implement other sorts of attacks, ranged, etc, other than the sword? Or will everything be close range/melee based?

I liked the controls, they feel just as the old days, down to that little push back when you hit something.Though as Silbereisen pointed out, the bombs may be a bit too bouncy, usually I used them to break walls and it would bounce off these walls anyway, so I ended up just placing them.

Also the bombs explosion graphics may be a little small for its area of effect on the breakable blocks.Otherwise, I'm excited to see more of the game!

Whoops, it's been a few weeks since I updated this thread. I'm taking a short break from working on Gunmetal Arcadia to add some new content to Super Win the Game, but I've continued making weekly blog updates.

I've been busy wrapping up some new content on Super Win the Game over the last couple of months, but I'm back to working on Gunmetal Arcadia now, and I'm starting up a series of video logs to accompany the weekly devlog I've been keeping. I've written about this new development in the most recent blog and talked about it in the pilot episode.

I’ve been thinking more consciously about how to develop a consistent aesthetic for this game that feels authentic to NES games. I feel like I might’ve talked about this a bit in the past, but examining Faxanadu has been hugely revelatory in understanding how to play to the strengths and weaknesses of the NES color palette. Take a look at this scene from early in the game:

Notice how each element is monochromatic: the walls are green, the background is orange, the enemies are blue, and the player character is a sort of pinkish hue. The NES color palette is notoriously lacking in dark or desaturated colors, but the bright, bold colors it offers don’t necessarily have to appear cartoony. Delineating each element by hue allows the scene to remain legible even when elements overlap in brightness. The background ranges from bright pumpkin orange to dark brown to almost total blackness, but it all reads as a background element because it’s united by a common hue, and although its luma is roughly equivalent to that of the walls, there’s no confusion as to which elements are solid and which can be walked past.

It’s also worth noting that the walls have a brighter, more distinct highlight than the background elements, so even in grayscale, even with very similar luma, there’s enough of a difference to distinguish between the two. This highlight is also a slightly different hue than the rest of the tile (pale yellow versus the forest green that comprises the majority), but it still reads as monochrome.

In the interest of complete transparency, here’s what my schedule looks like right now. I’m doing contract work three days a week. It usually takes me a full day to record and edit “Let’s Make Gunmetal Arcadia” episodes and produce the weekend’s in-dev builds, so that’s a fourth day gone. Ignoring the handful of hours it takes to write these devlogs, that only leaves one work day for actual development. Of course, there are evenings and weekends, and I make up the difference working more of those than is probably healthy. It feels like I’m spending literally nearly every waking hour working on this game. So why is progress so slow?