Streus

Streus makes games. Current Project: "Sketchtroid"

[streuscode]

Now a dungeon can have any number of subdungeons (which can, in turn, have subdungeons).  Basically, a tree of graphs.  What do you mean that’s disgusting?

There are still a few edge cases I need to clean up where generating a subdungeon fails due to insufficient space (i.e. it gets pinned inside its parent dungeon or between two different dungeons).

Once I get those under wraps, I can move on to the really fun part!

[streuscode]

Took a break from my other side project for Sketchtroid to work on something else: dungeon generation for the infinite gamemode.

Above are three 100 “room” levels generated using my current algorithm (colored lines are traversable paths, the green square is the start, and the red one is the end).  The generation itself if purposefully lengthened so that the algorithm can be seen in action.  I’m not going to talk about what’s going on under the hood quite yet; there’re still some major modifications that need to be made.

Until then, here are some 2000 room levels I generated.

[streuscode]

I’m gonna go ahead and ignore the fact that I haven’t posted here in awhile.

Wait.  Shit.

Above we’ve got the new-and-improved custom CLI I made specifically for Sketchtroid.  The old version used Unity’s fancy UI system, which in nice, but over-complicated the GUI for this specific application.  So I migrated everything over to the IMGUI system Unity also provides, which made the whole console much more lightweight.  The Console has also been slowly accruing commands and features as I find I need them (e.g. I just added a channel system that allows me to split up logging information n’ the like).

And here’s a super early version of status effect indicators.

And the ability select menu.

Oh, and there’s these things too, they’re great.  They’re the foundation I’ll be building all my switches, pressure plates, doors, moving walls, and lots of other fun stuff on.  Ye got yer AND gates n’ yer OR gates, which can be inverted into NAND and NOR respectively.  Then ye gotchya delay nodes n’ yer clocks n’ sources (always on) n’ toggles n’ leafs (which can be inverted to make a NOR).  Oh, and don’tchya ferget yer XOR n’ XNOR gates, those are essential.

The next month and a half or so is looking to be pretty open for me to work on Sketchtroid, so expect more from me.

[streuscode]

So I’ve been taking a break from Sketchtroid to play with shaders a little.

Pretty cool so far.

Tumblr's annoying so here's the first gif on Imgur.

[streuscode]

Still chipping away at things here and there.  I ran into a few issues with what I was planning to do next that have forced me to rethink how I want to approach it in the future.  While I’ve been mulling over that I started to work on the HUD, specifically these fancy little abilities status things.  The color of the cooldown bar is determined by the currently equipped damage type.

Hm... this post is feelin’ a little short.  Take some of this art off my hands.

Aight, that’s enough.  Till next time!

[streuscode]

Not a whole lot of functionality to show off today; instead, I’ve got a load of art assets I drew up.  Drew down?  Drew.  I drew them.  Yea.

Now, these are organized into sets here, but, really, none of these parts necessarily belong with one another.  Each part (cone, engine, wings) corresponds to an ability the player has equipped (with the core set, the default, corresponding to an absence of abilities).  All the abilities can be swapped out for another at any time.  Often, different situations will require that the player do so in order to progress.

Some of this art is definitely going to be redone at some point; the tier 2 cone and the tier 3 wings really irk me.  But I’m kinda sprinting to a demo-able state, so I’ve just noted them as things I’d like to revisit once I hit that point.

As a side note, if you’d like to keep up to date on my progress, check out the github for this project.  I keep it more or less up-to-date.

Till next time!

[streuscode]

Today we’ve got a New Game menu, with all the relevant options for the primary game mode in and functional, as well as a little flair for the player in the form of a little icon that displays their current damage type.

Both of these are technically in-progress.  The New Game menu has a section for a planned “Infinite” game mode, which will be a kind of rogue-lite, make-it-as-far-as-you-can thing.  And the flair will eventually include all the visual parts of the player.  The wings, cone (front), and engine (back) will change depending on the abilities the player has equipped.

Which means lots more art tomorrow.  Which isn’t a bad thing.  After all...

...I’m not short on code.

Till next time!

[streuscode]

Still chipping away at stuff for Sketchtroid.  Here’re some gifs of the beginnings of a savepoint and the Load Game menu (with some art for the difficulties thrown in for free).

There might be a lot more of these smaller posts in the pipeline over the next couple of days; keep an eye out!

Till next time!

EDIT:

Apparently Tumblr hates all my gifs, so there’re now on Imgur for your viewing pleasure. 1 2

[streuscode]

Tumblr doesn't like this gif, so you get to visit Imgur to see it

So I’ve been working on and off for the past couple months on Sketchtroid, a top-down arcade-y metroidvania, and I’ve finally gotten to the point where I feel like I’ve got semi-interesting things to show off.

The obvious thing demonstrated by the Imgur gif is scene transitioning, which, yea took a bit to get working properly, but it’s more of a representative of all the stuff that is happening behind the scenes.

And this is that super-fancy, behind-the-scenes stuff.  See, I wanted some data persistence in Sketchtroid.  Having enemies respawn every time a scene is reloaded gets old really fast, so I made a system that tracks relevent data and saves/loads it as needed.  Doing so took quite a bit more work than I initially thought, but I’m really proud of what I ended up with.

I can’t promise regular updates on this project, but I’ll try to post whenever I cook up something for it that I think is cool.

Until then!

[streuscode]

I fell off the map for a bit again; I ended up being much more busy than I could have expected, and, as a result, Vagus took a back seat.

While I wasn’t working on Vagus directly, I was keeping it in the back of my mind.  I tried to solve some of the glaring problems I was running into, but the only viable solution I found required that I start again from scratch.  As much as I like the idea behind Vagus, I really didn’t feel like restarting the whole thing.  I’ll most likely return to it eventually, but for now I’ve decided to move on.

So for the past month and a half or so, I’ve been planning out the project that I started just last week: Sketchtroid (It’s a placeholder name).  Sketchtroid is a top-down arcade-y metroidvania with a ‘sketchy’ artstyle (basically, I plan in hand-drawing everything with a tablet).  I won’t go too far into design at the mo.  Each mechanic and design decision I’ve made will be covered as I implement it.  For a general roadmap of the project, check out the repository on GitHub.

As of now, I’m working on the code relevant to the core combat of the game: Entities, Abilities, Statuses, Bullets, etc.  I plan on discussing each part of the system, as well as the system as a whole, as I build it.  Some parts, like Statuses, Abilities, and a small class called a Stat, are already done, so expect posts on those in the coming days.  The entire combat system should be done within the week (should be).

After I have the combat core done, posts should get considerably more interesting as I move out of pure code.

I’ll be back tomorrow to talk about the Stat class!

[streuscode]

Development has been slow lately.  A mix of work on different things, and the volume of the work that needs to be done on this project, has slowed the progress I’ve been making drastically.  Last week I didn’t really have much of substance to show so I forewent posting.  This could become a pattern.  However, I may have other gamedev-related things to post to fill in the gaps, so I’m sure it’ll be fine.

Anyway, what’s this?  Well, this is quite a few things; can’t you be more specific?  First of all, there’s the HUD, which is only briefly featured in the above gif.  It displays info regarding the current round, the score, as well as the player’s heath, shields, and abilities.  All good stuff.  The “Pause” menu (it doesn’t actually pause the game, though it may include functionality to request a pause later on) allows for things that one might expect of a pause menu, but it has the added bonus of a “strategic view”.  Right now, the strategic view isn’t much more than what the gif shows, a top-down view of the field that can be panned around.  When finished, however, the strategic view will show detailed information regarding the capturable nodes, including their names, and the team to which they belong.  Also, at the end of each round, players will be able to enter the strategic view to re-position their nodes.

I also put in these little pop-up dialog boxes.

So yea, I still have a lot to do to square away the strategic view, but once I have it done, most of the technically demanding features of Vagus’s primary game mode will be done.

Hopefully I’ll have some cool stuff to show off next week.  Until then!

[streuscode]

Teeeeechnically it’s Saturday here as I’m writing up this post, so I’m a little off schedule, but eh, close enough.

This week I got something working that’s worth showing off: the Class Edit menu (featuring some placeholder art from Game-icons.net).  In Vagus, Player customization is centered around sets of passives that change stats, add active abilities, and offer unique behaviors.  For clarity (and to help me brainstorm), passives are sorted into sets of four called classes.  The above gif features the Surveyor class, which is centered around passively placed markers to which the player can teleport.  I have a few other classes laid out, like the Defender, Imperialist, and Daredevil.   Each class is built to work well as a full set, but the idea is to have a a large-ish pool of passives that players can mix and match to suit their preferred playstyle.  It should be noted, though, that every 4th passive of a class is locked if the 1st passive of the same set is not equipped (4th passives tend to be the strongest).

Right now, though, these passives don’t do anything in-game.  All I’ve got so far is the UI pictured above and saving/loading functionality.  I started on syncing players’ passive data over the network, but that’s not quite done yet.

Once I’ve got that squared away, I’ll probably move on to the actual game, seeing as I now have all the data I need to set up each player.  With all the UI and backend stuff I’ve been working on, I’m looking forward to doing some actual gameplay programming.

Though I might end up working on a HUD too...

Anyway, till next time!

[streuscode]

I return from my almost two month long hiatus to reveal Vagus (or The Vagus Project)!  Truth be told, there isn’t much to show off yet, even though I’ve been easing into the project over the past few weeks.  Despite that, Vagus has a much more complex design in comparison to my last project Tytans II, so I have plenty to yap about in this preliminary post.

Tytans II has taken an indefinite back-burner position.  I learned a lot about Unity and C# though it, which was my original intention when I started the project.  Given that it served its purpose, I don’t really regret moving on before polishing it into a final product.

Now that I’ve addressed that, let’s talk about Vagus, a competitive multiplayer game that takes inspiration from a Japanese card game.

Vagus really started out as a kind of spaceship arena-shooter with an emphasis on high inertia.  The special part of the idea was the high inertia; really, the whole idea kinda revolved around it.  My first idea for a map included a singularity in the center that players would use to swing themselves around the arena.  High emphasis on deliberate movement.

The more I played with the idea, though, the more annoying the idea sounded.  Players wouldn’t be able to react quickly.  New players would most likely just orbit the center opposite of each other and take pot shots.  Close fly-bys would be fleeting, or would result in a DPS race as the two players just kinda unload on each other.

So I swapped out high-inertia movement for a proper game rule set, one that I knew facilitated quick, but strategic game play.  I’m fortunate to have learned about Karuta during my hiatus.  That said, Karuta can’t really be played on a computer.  The physical aspects of playing are to important to the game.  Also, the rules call for a 15 minute memorization period, which wouldn’t fly in a video game.  Oh, and players need to able to speak Japanese; and, to play competitively, players must memorize 100 separate poems.

I could go on.

Nevertheless, I stuck with the idea of integrating Karuta into my existing game idea.  The above is a gaudy representation of the result.

Players still control spaceships, but the map and the objectives are very different.  Each player has territory on the map.  In each territory are 12 (could be changed) nodes.  Each node has some identifying marker that can be seen by both players.  In each round, a marker name is slowly revealed to both players.  The first player to capture the node with the matching name removes the node from the field.  If the node was on the capturer’s side, nothing additional happens.  If the node was on the opposite side, the node is removed and replaced with a node from the capturer’s side.  The first player to remove all nodes from their side wins.

Karuta has some rules for selecting incorrect cards that I may or may not use.  Really it depends on the pool of node identifiers I end up using and how node capturing ends up working.  There wiil certainly be a penalty for capturing an incorrect node, though.

On top of this, players can actively fight each other.  Death doesn’t really mean much other than losing positioning and being unable to act for some time.

I’m working on “classes”, which consist of sets of four interchangeable passives that affect playstyle.  Stuff like moving faster in friendly territory, placing markers that can be teleported to, or just being a menace that focuses on keeping the other player out of the game.

There’s still a lot to work on.  As of now, I have parts of the Main Menu UI finished along with some the backend for multiplayer/the lobby.  Unity’s default multiplayer functionality has really helped me get this project off the ground (though I’m still figuring out the API).  Right now, I’m focusing on getting player setup in the lobby at a starting point, and then I’m going to start thinking about gameplay options before I dive into making a prototype of the actual game.

Oh, before I go, Monday probably won’t be update day anymore.  Expect either Thursday or Friday to take its place.

Aaaaand I think that’s it.  Thanks for reading, if you made it this far!

[streuscode]

Oi, you there!  Yea, you!  Lemme talk at you for abit.

As you can see above, I added the Arc ability.  Now, you may be thinking “Why, Streus, that’s just a lazy teleport!”, and you’d be right.  Well, it can’t teleport over walls, so it’s not completely lazy.  It also damages enemies caught between the start and end points; so that’s nifty.  Arc isn’t completely done yet, though.  I’d like to add some VFX between the start and endpoints, and I need to tweak the collision detection a little, but it’s all good.

On the UI front, I spent a whole 10 minutes updating the UI for ability charges so that it wasn’t just a number overlaid on the ability icon

And I gave the health bar a simple little low health animation.

And the energy heat bar got a little gradient that I may or may not keep.

Hold up.  Heat?

Yup.  Most of this past week was focused on redesigning the energy/mana pool system into something that fit Tytans II better.  Heat is what I came up with.  Instead of passively building energy to spend on abilities, players will start with an empty pool of heat that will build as they use abilities.  Heat will decay passively, but players can also discharge heat by using their basic attack.  Exceeding the heat limit incurs...some kind of penalty.  I’m still mulling over what exactly the penalty should be, but I’m pretty sure I’ll be going with some kind of damage infliction.  Could be straight damage equal to the exceeded amount (heat - heatMax); could be a damage over time status effect with the same value; could be a movement penalty.  The possibilities are endless.  Mostly endless.  Pretty endless.  More endless than not.

Other things will probably demand my attention this coming week, so next week’s post shouldn’t be anything too substantial.

Until then!

[streuscode]

Happiest of Mondays, everyone!  Good holidays?  Good.  Let’s get into it.

Like I said last Monday, I took this week off, but I still spent a little time thinking about what I’d like to get into this week.  Part of that was just implementing Charge, Trap, and Arc (which I started on today; Charge can be seen above), and part was redesigning some clunkier parts of Tytans II.

This post ended up actually being pretty lengthy, so if you want details...

Lots of bits of the original Tytans found its way into my current project because I wanted a quick and easy base to start off with, seeing as this is my first solo project in Unity (and the longest running so far).  As I’ve said many times, there’s so much wrong with the design of Tytans, and it’s taken this replotting of the path I took in developing it for me to pick out all of the mistakes I made.

And as I’ve been playtesting Tytans II, I’ve come to conclusion that the movement style it inherited from its predecessor is pretty wank.  For those that don’t scour and catalog every sentence I throw up on here, the movement style for Tytans and Tytans II is a simple WASD configuration with the player locked to face the mouse position.  W moves the player to the mouse, A strafes left, etc.  I thought this style would allow for lots of dynamic circling, strafing, dodging.  In the end, it encourages a very static playstyle.  One where the player keeps whatever they’re shooting at more or less above them on the screen so that their axes of movement don’t flip (A goes right, D left, etc).  If the camera rotation was locked to the player’s rotation, it might work...

Instead of going further off the rails in an attempt to salvage a mechanic that more or less just made me feel uncomfortable when playing, I opted for a classic 8-directional WASD setup (as can be seen above).  It’s familiar, and it’s flexible enough.

The other change I’ve been considering, but not yet implemented, has to do with energy.  Tytans II‘s energy system is the classic mana-type deal.  Player has limited resource pool.  Player spends resource to use abilities.  If player doesn’t have enough resource for ability, player cannot use ability.  There’s nothing wrong with having a “mana” pool or resource bars, so long as they fit the pace of the gameplay.  As I see it, the kind of mana-pool system Tytans II has at the mo is better suited for a slower paced game.  I’m not going to go any further explanation-wise, because I feel like I could write up a whole post on game pace and resource pools.  Suffice to say, the current energy system is getting a rehaul this week.

I’ll talk about it, and the changes I will have made, next week.

Until then!

[streuscode]

I don’t feel like writing this post, but I’m doing it anyway!  Uh, I mean...  Happy Monday, everybody!

Prometheus got even more work this week.  I fixed up my distribution algorithm (it was quite buggy) and I settled on attack patterns (two displayed above) for him.  He and his minions are pretty much complete; however, I can’ t help but feel like they’re lacking something.  I’ll probably revisit him after I’ve done one or two more bosses, but for now I’m giving him the back burner treatment because I’m just so goddamn tired of working on the same fight.

I’m just going to add in his ability drops and call it a day 2-3 weeks.  At least I’m happy with the icons for his dropped abilities.

Charge, Arc, and Trap, respectively.

I’ll try to get some work done on those abilities and get started on Helios this week, but I really can’t promise much.

Till next time, amigos!

[streuscode]

Happy Monday, everybody!

This is going to be a long post, in which I’ll cover difficulty, re-balancing, AI, algorithms, geometry, and I’ll say the word “tacos” once.

Ready?  Let’s dive in!

So, what you see above is a taste of how I plan to tackle the three levels of difficulty in Tytans II.  In Tytans, I handled difficulty very naively.  I basically just treated each difficulty as a multiplier for boss health and damage.  The result was slow, unforgiving gameplay on the higher difficulties.  For Tytans II I settled on something very different.  The difficulties still are, in essence, multipliers; however, they affect very different values.  In the case of Themis, this means increasing the number of “Sword of Truth”s she shoots at a time, and decreasing the interval between her first and second volleys.  I plan on adopting similar, but not identical schemes for difficulty for the other bosses.

As a side note, both last and this week I’ve been tweaking the classes a bit.  I nerfed the Defender’s shield ability a bit, and gave the Obliterator a new primary fire.

This sums up what the bulk of my dev time in the past week was focused on.  Mother.  Fuckin’.  Minion formations.  Now almost nothing else in Prometheus’s fight is finished, so ignore everything that isn’t the minons’ movement.

When I started thinking about this fight, I thought I was going to have to build some complex AI to make the fight interesting (read: not a clusterfuck of minions doing whatever).  As I thought more about what I wanted the fight to be like, though, I realized something fundamental about my approach to Tytans II.  Pattern and rhythm.  Playing Tytans II isn’t about fighting some super intelligent opponent that can easily outsmart you; rather, it’s focused on small sets of predictable behaviors working in tandem to present a challenge.

And so I thought, why not just make Prometheus a kind of conductor, guiding a group of musicians through a piece of music?  So I set to work on making a class that could create a pattern of n minions given a shape defined by an array of vertices.  Specifically, I focused on distributing n objects over a series of line segments.

Aaaand here’s the code to do that (obviously there’s a lot more code than this, but this is the important bit) (and yes, I’m sure there’s a way to make this way more efficient).  Distributing n objects over a single line is easy; the real challenge of this algorithm was accounting for reaching the end of a line and continuing on to the next one.  (If there’s enough interest, I may create a separate post explaining the whole idea.)

I initially planned on including a filled polygon case, as well as cases for ellipses (and therefore, circles), but I’ve spent enough time on Prometheus as is, and I need to finish him up and move on to Helios.  Maybe he’ll be done by next week.  Maybe.

Anyway, thanks for reading through this post!  It didn’t end up a long as I thought it would.  Must less space to build suspense for the tacos gag.  Ah well.

Until next week!