Wednesday 2 October 2013

Devlog 2013-10-02

Devlog 2013-10-02

Here is a run down of the activities achieved this week on SurviveRL:


Network & Multiplayer
A rewrite of the experimental code is in progress. I had managed to get the
client to login to the server, and the server issue its ticks to the client, wherein
the client would receive those.

Tests done showed that the implementation works as I had hoped, so all that is left
now, is to continue to code on this new implementation.


What's planned this week
I'm hoping to continue with the network coding. My freetime is very limited though at
the moment, where i'm averaging around 5 hours a week max on this. It's only short term
though, and I should be able to increase on this in 2 weeks.


Something to read
Blog posts shouldn't always be boring, so i'll write a few lines on the subject of
roguelikes, namely on the use tilesets and tile renderer clients for roguelikes. Berlin
states that a roguelike should represent its world as ASCII characters on a grid, which
is where I am with SurviveRL. But, some of the major RLs and Android RLs (plus those on
Steam) use a graphical frontend.

I sent a request to Desura about a month ago, to submit SurviveRL to the service, just based
on the ascii client. I was merely curious to see if the submission process would take
the game, based purely on its criteria for upcoming game features. Naturally, this game
was declined in submission. The reason? well, in summary that the game doesn't seem to be
something that people would want to buy.

How do we define a buy decision then? Roguelikes are a respectable game genre, with fantastic
replayablity, but decidely low graphic display content. If I were to move SurviveRL away
from a Berlin definition of a roguelike (ascii display) and make a tile based graphic client,
and submit, would it change the game? No. The game would be displayed in a different way.

I read a recent reddit post asking for a list of current roguelikes on Steam. Interestingly
enough, *ALL* of them were using graphical clients, not ASCII. How much should we RL devs
stick to the Berlin definition? Can we still class our games as roguelikes if we use tile clients?

I will battle along in the engine code for now, and get the roguelike to an enjoyable play state.
After that, it's a question of numbers: to reach a larger client base, it probably needs some
eye candy, and then, can I still call the game a roguelike?

3 comments:

  1. Do not despair at the Berlin definition---it is meant as a general, descriptive outline and not an ironclad set of core attributes. Had I been around at the time and it been somehow anthropomorphized, I would've punched it in the face for doing more to cast aspersions on hopeful Roguelike devs than to bolster them by far. At best, it muddles reality in the form on confusing and conflating aspects that were indicative of the times and especially the technological considerations having an external impact on the genre with the core, natural state of being---and it gives no credence to the spirit of the thing. Tile graphics are certainly still Roguelike-capable, as is ANY discernible graphical style.

    ASCII, as is, historically has terrible baggage in the game dev world outright for atrocious scaling issues, poor U/I choices/animation/framerate concerns, ease of color misuse, and general Font Hell---the blame lies squarely on those that chose to just fall back to terminal configuring/stick poking in the formative years as opposed to wading into the field of battle with Bitmap, Vector, Polygons, etc.

    Have confidence in your project, let it and yourself not be yoked by inequitable forces of antiquity, and try your level best to improve and perhaps break new ground on all aspects of SurviveRL instead of operating solely within a narrow sandbox encased within a walled garden.

    ReplyDelete
    Replies
    1. I'm sure though that a day will come within 12 months, where people look at this game and question its credibility in holding true to a roguelike. But yes, maybe its time that the Berlin definition be thrown out so that roguelikes can move forward on other aspects without this horrendous restriction.

      Thanks for the comment also :)

      Delete
    2. The first step is getting ahead of any questioning of any sort one way or another---to simply have the quality of craftsmanship on all the various fronts on lucid display speak for itself. You have the advantage of knowing ahead of time much of what theoretic critics and detractors may rightly or wrongly take issue with whereas they quite likely don't even exist yet as persons aware of the game---a good position to work from. Afterwards, many questions won't even matter beyond trivial concerns---people care far less about minutiae when the Gestalt of the thing on the whole is polished to an obvious degree at even a cursory glance.

      The Spirit of a Roguelike is paramount far beyond taxonomy, much the same as many other genres that don't necessarily need to ritualistically contend with such a spectre of doubt due to the odd track history has played out thus far. As the dev, you know internally whether what you're chasing after is a Roguelike, A Sim, a Puzzle, etc---from there it is just best foot forward on all fronts and releasing as often as is feasible to keep momentum and visibility going.

      Delete