KRL

Posted on by Kitch

Not as much progress this week as I’d like, but progress nonetheless.  Last week, I pretty much put major feature development on hold as I wait for the upcoming 7DRL to pass, and that turned out to be a really good idea given the week I’ve had.

Early-week was spent preparing a presentation on KRL that I gave at our local Tulsa Game Development group.  I’m not entirely sure how well it went, but I felt alright about it.  The thing about presenting on a niche genre is you can pretty much spout any nonsense that comes to mind, and they’ll believe you 😀

The blank stares when I referenced some of the major and minor roguelikes…. even 868-HACK.   868-HACK!  Who hasn’t played that?

Seriously though, it’s a really great group, and a lot larger than I expected for the area.  I encourage anyone out there to look into their local scene… you never know who you’ll meet.  (Like maybe someone that actually worked on games you grew up playing!)

Then, I had the pleasure of a nice, good old fashioned hard drive crash.  Yeah.   I got completely back up and running after a day or two, as I’m really good about backing stuff up.  However, it was still time spent doing something other than working on the project.  I think it actually turned out to be a good thing, as it allowed me to start the development environment over from scratch and really optimize source control and backups.

In the time I’ve not been preparing talks, or reinstalling software…  I did take the component based design idea to work with me, and have the concept implemented in a project we are working on.  So far, it’s been really solid, and that encourages me… a lot.  I’ve been doing a lot of back-end refactoring of the KRL code base, in order to prepare for the transition.  I don’t think it will take more than a week of work once the trigger is pulled, and make most the things component based.

A lot of thought has gone into my 7DRL ideas this week.  I believe I have cinched it down to be highly focused on the combat mechanics.  You know how fighting games have their “moves”?  Something like that… but a bit more roguelike.  I don’t want to spoil too much…  but I’m really jazzed about this idea.  It definitely goes on the “if not this 7DRL, it still needs to be made” pile.

As far as new KRL features, really the only thing added was a framework for talking with web services.  This allows for things like analytics, leader boards, etc.  It’s a rather easy thing to implement with today’s modern shenanigans and goings on, but I always put it on the back burner.  I realize a lot of this is going to be very application specific, so I just implemented the basics for sending and recieving web based calls.

Untitled-2

Next Sunday update may be a little different, as I’ll be in the thick of the 7DRL!  I plan on updating daily during the week… but only if the time spent on the update will not cut into the development of the game!  During Ludum Dare, I try to post a short update at least every 12 hours… I find it gives me a break and can actually add a bit of focus.  Those usually consist of a short blurb of text, and a screenshot.  I’ve never done this over 7 days, so we’ll see what format, if any, even works.  I’ve totally accepted the idea that this may just be a series of my typical “old man yelling at clouds” posts  😛

Love

Ross

 

 

 

KRL Backend Refactoring

Posted on by Kitch

Early this week I watched a video from the US IRDC with Brian Bucklew talking about component based design.

The component based module is not something that is all together new to me…  I’ve been exposed to it via a few projects in the past.. but I’ll be honest.. I just didn’t get it then.  I’m from the older school of thinking, where they taught you that object oriented programming was the solution to all the worlds problems.  With what I’ve been struggling with over the last few months, Brian’s talk spoke to me directly and really put it all into perspective.  His problems were mine… so his solution must be worth a look at.  

After some brief experimentation, the light bulb turned on and I decided to completely rewrite my back-end.  This may have not been the best idea, seeing that the 7DRL is fast approaching, and the engine has some fairly major holes (like inventory and combat systems). But, you know… you get to the point where you see the path you want to go, and you just can’t force yourself to work on anything else that would steer you away.  Yes, I could work on an inventory system that would work with the current code base, but that time would be wasted, as I’m not sure how it would interact with the new component based system…

So, that’s where the time has been spent this week.   This wasn’t my first attempt at a roguelike engine, so I knew the problems ahead.  I had already designed the base classes in such a way that they would minimize the impact of the problems I would face, without actually solving them.  This has actually helped me a lot in the transition, though there are still a lot of holes.

Long story short… as of now.. it’s not working.    It will.. eventually… but right now, it’s not in a state where I am comfortable that it will be complete by the time 7DRL comes about.  I’ve got KRL in a state where I can switch between the two backends… and will continue on the older, more tried and true approach for now.  At least until after the 7DRL.

Speaking of the 7DRL… yeah… that’s a thing…  I’ve got a lot of ideas, and not too sure what direction I want to go with it.

Since this is my first, I probably want to take it nice and slow.  Do a standard, sort of familiar roguelike idea.  Generate a dungeon… explore it… gather treasure.. kill goblins…  yes.   This will work.  Nice, simple, straight forward and easy.

Then, there’s the more experimental side….

I have an idea for an evacuation sort of roguelike.  An urban environment, where your goal is to escape the city, bringing along what and who you can, while being pursued by some sort of threat (aliens, virus, zombies.. etc)

I have an idea for an exploration based roguelike, where you are a probe on an alien planet and none of the items/terrain/creatures are known to you.  The goal is to discover as much as you can and send that data back to earth..

Then I have an idea for a roguelike where you lead a group of @’s, and teach them things.  Over time, you develop a culture that may or may not jive with the other groups in the game.

I don’t know.  The hardest part of this challenge is that you have too much time to think.  Ludum Dare is easy.  48 hours… unknown theme… do  it!  For this one, the waiting and possibilities are the hardest part.

Anyhow… off to figure this one out.  Hopefully, by the next update, I will have a concrete idea nailed down, and then, that will leave me a week to plan.

But then.. there’s this back-end programming that needs to happen…

 

Love,

Ross

Introducing KRL

Posted on by Kitch

So, yeah.  Since June of last year I’ve been working on a little roguelike project on the side.  Since development on rium has slowed down a bit over the last few months (for reasons not likely to become clear at the moment), I’ve really shifted most if not all of my development time into this project.  I’m really enjoying it, and already have a long list of games in mind to make once this thing is baked a bit.

Wait… wha.. an engine?

Yes.  I’m aware there are a number of roguelike engines out there.  Yes, I know there are several game engines out there, with roguelike plugins.  Reinventing the wheel, resolving solved problems, wasting time developing math when you could be developing games…  Yes, I know…  I know the usual advice, and I I’m very aware as to why I don’t totally agree with it, but that’s a subject for another post.  One I may get into one day… but not today.

So, the Basics

Rendering

KRL is written in C# with an extremely flexible rendering backend.  Currently, I’m rendering using OpenGL via OpenTK, with alternative rendering to XNA (FNA/Monogame).  I chose C#, as it’s a language I’m becoming more and more familiar with (and enjoy).  The backend rendering code is well isolated and extremely basic, rendering tiles from a tile atlas… so switching between rendering engines is a rather simple process.  This was a high priority for the engine, and one of the first things I did.cp437_standard_8x8

KRL is solely graphic tile based… there is no terminal mode.  I’m ok with that.  Tiles are loaded from image files, whichare mapped via xml files (currently).  Tiles can be re-loaded dynamically, allowing for switching between tile sizes, console sizes and tilesets at runtime.  Experience (mine and others) has taught me that preferred screen and tile sizes are very subjective, so I have planned accordingly.  This should also make custom tilesets rather trivial.  Simply change the tile texture, and the glyph mapping XML.

One or more glyphs can be assigned to any created game object in one of several different modes.  For each frame, you can define a glyph, background and foreground color.  This allows for static glyphs (like dirt), animated glyphs (like water),  connected glyphs (like walls) or state based glyphs ( like doors).  The rendering side of the code takes care of the rest, dynamically assigning the correct glyph for the frame and state.

User Interfacemenus

KRL currently supports both mouse and keyboard input, though I’ll admit it heavily favors keyboard input at the time.  As a lefty, a heavy focus was put on key mapping.  Similar to the rendering, the basic mouse and keyboard capture are isolated, to keep them portable as possible.  Game Controller support is currently not supported, but it is an interesting prospect I want to look into when I find a roguelike game idea that could possibly work with that control scheme :)

For the main interface that the programmer will interact with, I went with a panel system.  The UI is divided into seperate panels (KRLMapPanel, KRLStatusPanel, KRLLogPanel,etc) each of which can be controlled by their own separate input handlers, as well as be re-sized dynamically, either by relative or absolute dimensions.

Maps
krlLighting

Maps are divided into spaces, allowing terrain tiles, structure tiles, item tiles and mob tiles to be stacked into the same space.  Each individual space also tracks it’s visible, discovered and lit status, which is handled by the renderer.  Maps are structured and store in both a grid based fashion (as in a 2D array), as well as a grid based fashion (as in a grid).  This, while minimally expensive in memory, can allow for some pathfinding and FOV algorithm optimization.

KRLGifFOV supports multiple passes for lighting, as well as visibility.  This I would image in pretty basic stuff, but the approach was to make it as simple as possible.  Set an entity as a light source, and set its range, and the map takes care of lighting itself.  Set a mob’s visual range, and it tracks it’s own FOV each turn.

Currently, maps support a static, XxX grid, or an pseudo infitite chunk based approach…

Mobs and Structures and Terrain and Items. Oh My.

Base classes exist for all these elements, which handle animation, collision, and lighting.  Creating a new “one of these” TM is as simple as populating the type and the glyphs,  or deriving off the base class, if you require overriding the FrameUpdate or TakeTurn procedures.  All of these can be defined programmatically,  as well as from files (unless you are overriding behaviors.. of course)

Scripting is something I really want to implement, but for now it’s taken a back seat.  I’ve implemented Lua, Python and C# into a C# based engine in the past, but it opens up a big ol can of debug checking worms I’m really not wanting to get into at the moment.  I have designed the whole engine with this possibility in mind, so when and if it does come, it shouldn’t be that big a thang.

And the fun little parts…

I love procedural generation.  I have to admit I may have a problem with it.  I’ve produced a number of procedural algorithms to produce dungeons, caves, cities and other things.  I’ve designed my procedural algorithms to support a automatic, as well as a stepped mode.  This, step by step mode has added a pretty handy way to debug and tweak procedural generation algorithms.  I highly recommend it.  It also allows for some pretty fun animations.
krlGenSMroomanimation

Along with animations, I’ve also added in an effect system, which can be easily setup as a color and a time.

Future Plans

The big plan is to debut this engine with the upcoming 7DRL challenge.  If all goes well, I plan to opensource, or at least make available the engine for use to others.  I’ll be honest, it isn’t a ‘secret’ or ‘money’ thing… it’s simple laziness.  I don’t want to support an engine for me and you :P, I have enough fun keeping it working for me.  Future plans are subject to change however…so as it matures, we’ll see how usable and maintainable it becomes.

As the weeks go by, I hope to update this section with updates to the engine, or a little more in depth into specific areas myself or others find interesting.  Stay tuned!

ggg

 

Love,

Ross

He’s Gone Rogue (like)

Posted on by Kitch

Back when I started this in 2011, I committed to writing a development log that I would update every week.  It didn’t last long, against the convienient  140 chars and a screenshot that twitter provided.  However, I’ve begun to miss the value that it provided…  even if  no one read it, it helped keep me focused.  Yes, I could spend this week playing dwarf fortress or CK2… but then, what would the update look like?

I’ve decided to start it up again, and will try to stick to the Sunday schedule as best I can for as long as I can make myself do it .

So, first off, I guess I should start up with a little catch up…

The last few years I’vUntitled-8e become more involved in the local game development scene.  I’ve showed my games at some local conventions like SUPER! BitCon  and was on a game development panel at ComicCon.  I’ve also attended meetups in OKC and Tulsa, where I’ve met a ton of other local developers that are doing awesome things.  Looking forward to showing again at SUPER BitCon! this year, as well as attending the XPO event this autumn in Tulsa.

I’ve made some  updates to in a window.  It runs a lot better now, I’ve fixed a lot of bugs and added a few levels.  Untitled-5

Work continues on rium.I feel it’s really close.  I’ve just been trying to work out the game balance.  I’m hoping to use the SUPER BitCon! showing to really fine tune the balance issues.

Also planning to start greenlight campaigns for both in a window, and rium around that time, with release dates planned this autumn.  Greenlight at one, release at the other.  More on that to come soon.

Recently, my thoughts have been stuck on roguelike development.  Anyone who knows anything about me would have seen this one coming a mile away.  As a gamer that’s been gaming for upwards of 30 years, I find myself in a constant quest for depth.  I’ve dabbled in some of the classics over the years, and more recently got into Cataclysm DDA and Cogmind.  They just seem to hit me in the right spot… I’ve always believed that the greatest games are experienced not on the screen, but in the mind.  Present a representation of a scenario, and let it play out in the players mind, as opposed to telling them to sit down, shut up, and look at this shiny cinematic that’s going to explain it for you.   Then, give the player same ways to go about facing the situation they are currently in, than they had in the last situation, as opposed to “press X to win”.

rl

This isn’t my first attempt at roguelikery.  I’ve prototyped several games in the past, to varying degrees of success.  This time I’m starting bottum up… working an engine from scratch.  It’s going well, and more importantly, it’s been a lot of fun without a lot of stress.  I’m enjoying it immensely.  That’s what the whole gig is about, right?  If you’re not enjoying it, you’re doing it wrong.   I’m working on a follow up post to kick off the development log for the KRLEngine.

And, of course, see you next week!

 

Love,

Ross

 

 

Rium Shot #1

Good to be back

Posted on by Kitch

It’s been a while. Can’t believe it’s been over a year since I was at E3 with In a Window. Since that time, I’ve been relatively quiet. Still working, but pretty quiet. Just not a whole lot to get excited about, really. No project I’ve worked on recently has really just caught my interest in such a way that the good projects usually do.

MonkeyBall

A game about monkeys fighting over bananas

Sub Game

A submarine game

space game

A procedural spaceship game

screen2

A Combat game where players can copy themselves as a defensive stategy

screen3

Countless takes on the Hex Grid

screen5

Ascii Helicopter Game.  Plus many… many more.

I keep going back to this, though.

Rium Shot #1

Voxterium

Voxterium was received so well, however, Revision was not.  Why?  Well, that’s really easy.  I took out too much from the first, and added too much to the second.  The criticisms I received on Revision were very hard to hear.  Not because they were mean, or because they were “insulting my baby.”  It was because I completely agreed with (most) of them, and  were related to decisions I made that I wasn’t comfortable with.

The campaign mode

Looking through my history of notes, I was always negative about the campaign mode.  I felt that the campaign mode was not a good fit for this game, it felt forced.  I didn’t listen to myself.  I put it in the game because :

  • It was an attempt to add some pacing.  Start out easy, and slowly introduce new powerups, blocks and enemy weapons.  You’re supposed to do that, right?   Not necessarily.  This ended  up doing that, but at waaaay too slow a pace and contributed to a lot of the “long, boring slog” comments.
  • Games have game modes.  Games have campaign modes.  What I didn’t realize is that a lot of people choose one game mode, and that’s it.  If they choose the campaign mode first, and it is a “long, boring slog”, the assumption is that all other game modes are exactly the same way.   If you have 10 game modes, and one of these is a campaign mode, they will choose campaign mode.

 

Long story short, I created a game mode significantly weaker than the others, and virtually forced all my players to choose it.

Difficulty

Of all the game modes, all of them are completely neu

tered save two.   Even those two are cut down from the original betas.  I balanced the game completely wrong.

Achievements

Not necessarily a bad thing, but they really don’t add anything to the game and were kind of an afterthought.  Again, the game has achievements because games have achievements.  The time I spent on these, could have been invested in other areas.

Audio

The music for this game is great.  Zeph’s tracks fit well and I believe added so much to the game.  Much of even the majority negative feedback I did give praise to the music.  However the rest of the audio could have used some work.  Some of it was “grating” and a lot of it could benefit from some of the audio knowledge I’ve gained over the last 2 years.

One thing really bothers me, however, and I want to address it.  More than one set of submission feedback referred to the game as a “rhythm” game, and one kindly suggested a number of rhythm games I should play to get a better handle of the genre.  I don’t know what to say.  This is not a rhythm game.  Not even close.  All I can do with this feedback is take it as a compliment to the “marriage” of the gameplay and the soundtrack.

Moving Forward

When I played Terry Cavanagh’s Hexagon for the Pirate cart, and then  played Super Hexagon when it came out,  I immediately noticed a similar story…  I’m not comparing my game to his, as his is absolutely brilliant, but it is the same story of refining an original idea.  But where Terry Cavanagh made the right decisions, I made the wrong one’s.   He listened to the game, while I spent my time listening to other games and trying to make mine more like others.  This is not how you do it.

I learned a lot from that experience. and I feel I need to spend some time giving Voxterium the remake it deserves.  There’s a good game in there, and I completely let that idea down.

So my new game I am working on, is my old game that I was working on.  Up to this point, I have concentrated on stripping stuff out of the game, and refining the survival modes, as well as a few graphical updates.  Stay tuned for more updates, as I hope to be posting some more info and updates soon.