Month: February 2016

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