I'm Chris. I'm making games and I'm writing tools for different things. Such as games ;)
Today, more than 12 months after the last DevRambling about Firewalker, I've come to put it on ice.
On Ice is not cancelled.
Personally I've got a bitter taste of the past about it, thinking about how Prison Island fell apart like a card house in the wind.
I do know the situation is a little different today then it was many many moons ago when I had to cancel the Prison Island project but still. I really want to do this project one day.
At any rate, here's my reasoning.
Firewalker is, and that seems to be very typical for me, a project with a scope which is simply too large for the limited time I have for making games. There are six dungeons and a whole city with (surprise) six districts. The workload to produce all the required assets alone is daunting.
However, the most important factor is, I am at this time, simply not up for the job. I was refactoring code every other day because I kept learning new things. I broke one system after another, wiring them up again, leaving a mess of unused code and undocumented features and corner cases. My knowledge when I started the project was simply not sufficient to really pull it off.
However, there are some really (probably) good systems going on in the Firewalker codebase and I didn't want to let them catch dust. There are savegames, a Source engine like IO system, behaviour trees and a corresponding editor ... these kind of things.
So I pulled it all apart and created a library of code that is independent from any game it may be used in.
It can be found here: Github.com
This is my Firewalker-takeaway so far and it's okay.
During the past 2 years I have been working on smaller projects, learning new stuff and actually making games. Mostly in 72h gamejams. I've been using the code of that library in these jam games. I've been extending the library with my real-life requirements when making games and prototypes. I will delve into a couple of smaller projects with this codebase in my virtual backpack and gather new knowledge about making games.
I might even get to release something a little bigger than a 72h game at some point.
Eventually I will come back to Firewalker. It wil probably not be titled Firewalker anymore but it will be the top-down slashing beasts and solving dungeons thing I wanted it to be.
Hopefully, by then, I'll be able to actually pull off a project with such a scale.
So there's that.
PS: If you feel like reviewing / using / forking / contributing to that library, please do :)
It has been a few weeks now without a word of us so here I am again. A lot of stuff has happened outside the game that consumed most of the time spent, however, it was all part of starting work on milestone 2.
The most important bits: I have re-done the website. Along with it, I ordered a new server on which I set up all the infrastructure for developing the game once again. That was a very time consuming task but now we have a shiny new and clean box at our disposal. For those of you knowing me from the CanaryMod project: That is why the canarymod.net site is currently down. I'm awaiting a response from the new domain owner.
Anyway. Have a look: Playblack.net
Now to gather some proper in-game screenshots.
Development wise, we also started on milestone 2 tickets.
Since we're using Unity 5 now, I re-wired the savegame system dramatically so it would load prefabs via the AssetBundle API instead of the Resources API. That means we don't have to load all the things into memory all at once and as added bonus, loading of save-games is now asynchronous, which means it feels more fluid.
Additionally there has been work to account for "fixed time situations". That's, for instance, inside dungeons and houses, where the time should not pass but stand still. Of course this leaves a large gaping hole for a lot of feature creep but I'll do my best not to let it in all that much. But the thought of mechanics to manipulate time is tempting!
Also, the sound system got a bit of refreshment. It too loads its audio clips from asset bundles and can be spoken to via the event system we're using.
Next thing in line: Getting some proper in-game material going. Then it's time for a new indiedb page. I think before that there will not be enough stuff to show off.
That was it for today folks, thanks for reading
Howdy out there!
I had to forcefully take a break on development once more because the usual real-life happenings. It happens. The good news is, I'm still on schedule for the first Firewalker milestone - the technology release. It's actually not a release but the name sounds funky.
This milestone means that all the basic technology that I need (or think I need) in order to make the game is ready. By that I don't mean "all the AI" or "all the entities" but things like "the sound system", "important editor UI", "system to execute scripted sequences", "Entity Signals System (like I/O in Hammer Editor)" ... stuff like that. With these in place I can add more and more logic (or content), as I progress through the further making of Firewalker.
The tech-release will be ready the coming sunday (that's June the 14th) and once this is through I'll start on some PR related work. I'll create a new IndieDB page, perhaps something on facebook, fix up the website and, although only loosely related, I'll re-design the playblack site to something more modern looking. Of course the pages will be updated accordingly with information about what Firewalker actually is. I realise that my personal blog is way too abstract to give the reader a big picture.
Once that is done, I'll progress with the second milestone - which contains first bits of proper gameplay, at least one dungeon and a bunch of mobs. On that occasion I'll also tie up some loose ends in the code that are open from milestone one, if any, and clean up "the code so far".
This time I have no fancy pictures for you, I'm sorry :(
And that's it for today. Rather short but I hear that's a good thing sometimes!
I'm writing again because I have a little progress. First and foremost I went ahead and turned these dynamic shadows I showed off a while ago (http://www.moddb.com/members/damagefilter/videos/dynamic-2d-volumetric-lights#imagebox) into soft shadows.
That looks something like this:
Pretty pretty. It's even better when it's moving. I'll have a video for you soon.
The cool thing is, I can have the shadow casters really low-poly now and it wouldn't matter.
That means ... MORE dynamic lights! Can never have enough dynamic lights.
A word on the visual style on the screenshots so far:
This is not the final artwork. The finished or final versions will look darker with more detailed and less like they are straight from a kids game. I'll have some of this for you soon! We're currently developing the city layout and after that it's remaking and creating new sprites.
Now, what took me most of the time the past weeks was the new sequence editor.
It is based on the behaviour tree implementation I also use for the AI and so creating a sequence structure was not the hard part. I have it all there already, including serialisation and save game compatibility.
What took me so long was all the editor code. It went down to an extend where I was wondering if it was worth all the trouble I had.
Turned out it was worth it indeed. You may recognise that pseudo code thing - once again I borrowed from the old RPG Makers. With this sequence editor ready, we can push out story and gameplay progress very rapidly. But of course, it's not 100% functional yet. Some event types are still missing, like Sound triggers.
Generally though, variable operations, switches, messages - all the basics - are in and working.
And that feels good. Seems like I'll make it to my tech-release deadline in a timely manner!
And that's it for today, thanks for reading!
It has been a funky week full of hunting regressions while finishing the attribute spreading in the combat system... which is a fancy description for "Weapons can put things on fire now".
Which is essentially what is happening now.
Generally, weapons can do anything with the attacked entities now for demonstration purposes I chose the classic fireball and letting thigns go up in flames. This was all done to enhance combat mechanics and also to finish up the status display.
That's kind of an indicator about what kind of problems a particular entity may or may not have.
The initial idea was to add little icons above entity heads but then it seemed easier and much better to just introduce actual image effects.
The poison effect makes you go all green, Diablo-style ;)
But first, here's the fireball effect working:
So that was what I've been working on all week.
Thanks for reading and have a nce week!
Goood morning, folks!
The last week I was busy finding new ways of lighting up scenes in Firewalker.
That's not putting them on fire, that's setting up point and spotlights and better ambient light.
I did find a way that seems to be alright. It imposes one extra draw call all in all and so far it seems that it doesn't have any significant impact on the time required to render the scene.
So, it works by dropping a few things into an extra rendering layer (lights, mainly). They can be of any shape and colour. They can even be 2D volumetric light meshes (for dynamic cutout shadows).
That light layer is not rendered by the main camera but by a second camera that is rendering only this one layer.
To fake the ambient light I simply use the clear colour of that camera. At night it clears to some dark blue colour and at day it clears to something that looks like day.
The result is put into a render texture.
I call that a lightmap. Strictly speaking it's not a lightmap but the idea is the same.
The lightmap gets multiplied onto the the image that is rendered by the main camera.
Lights and daylight cycle. All dynamic.
That was the big thing this week.
I also wanted to implement a combat system but it turned out I already did that.
So that was one free point on my list.
Next thing on my schedule is a status indicator to show the status of the player and enemies.
That means, is something poinsoned or burning or frozen or numb and so on.
There shall be more colours then!
And that was it for this time, thanks for reading!
Why, hello there!
It has been a while, hasn't it?
I fell behind my originally planned schedule quite severely ... by 6 months ... *cough*.
That is why I was unable to write anything - there simply was nothing I could write about.
However, these six months didn't go by while I did nothing. I did something but perhaps not as much as I would have liked.
There were 2 major refactorings (because I love kicking my own ass and breaking the code over and over ...?) going on. Following is a very nerdy (more or less technical) rambling about code stuff.
I got around to finish the conversion from state machines to behaviour trees for my AI. One would think that is easy, however there is only one BT library out there for Unity that is worth using but I couldn't because it comes with integrated path finding and that path finding does not work on a 2D plane.
At least that is the impression I got while trying it out.
So I made my own ... more or less.
I ported the JBT library - or rather the relevant parts of it - to C# and wrote a node editor for Unity to integrate it. That very editor was a major pain in the neck to write though. The first version I made assumed that the Unity serialiser can serialise anything that falls within the rules (GameObject or annotated with Serializable etc etc). However, it has a maximum nesting level of 7.
Magic constants. Great!
That meant I could only have behaviours with a rather limited complexity.
I supposed that a proper boss battle AI would have more than just 7 nested behaviours to function properly, with all the sensor checks, decorators, composite nodes and an undefined amount of actions a boss can have.
So 7 ... not gonna happen.
For version 2 I used ProtoBufs, the same library in use for the save game system.
This way I can have reference tracking (awesome for having parent nodes as real references instead of copies, which would really break a lot of things) and an unlimited amount of nesting.
So ProtoBuf serialises my behaviour tree into a simple byte array and Unity serialises that byte array back and forth. Job was finally done.
I have implemented a simple wandering behaviour and attack-on-sight behaviour so far.
It works a charme.
The next big topic on my todo list was re-implementing the dialogue system.
It broke a while ago because it was too interconnected with all kinds of other parts like the input controller and inventory system. So I decided to decouple the whole thing and use my event bus to control it instead.
It can now be requested to do things by events, an "operator" does not need to know anything about the system doing the dialogues, it just makes requests. If there is no system in place, simply nothing will happen.
The dialogue manager itself dispatches events to notify all listeners that something happened. Specifically that a dialogue started or ended.
So that is done now too.
In other news
The moment it was released I switched to it and it's gooood!
I can now stop loading all the assets into memory at once and work with asset bundles. That means I should probably change the part of the save game system that loads prefabs to populate / re-create a scene. Not that it would make a big difference as all the assets are but a few kilobytes in size but it will probably lower minimum specs so you could run the game with a pile of wooden sticks.
And that was it for todays very text heavy blog entry. Next time there will be more pictures, promise!
It's friday and a good time to write another dev rambling!
This week was a bit dev-unfriendly. I had a lot of stuff to do at RL work and managed to do only little things for Firewalker. But better little things than no things at all.
First official act this week was to change the ration of pixels to world units.
That describes how many world units to fit into the size of a pixel.
By lessening this value, pixels will grow larger, which is what I wanted. Large pixely goodness.
It also blew up all the test level arrangements. Oh well.
Other than that I finished the inventory refactoring I was about to do. It's now nice and clean like it should be. Entities can have "Inventory bags" and they will be projected on an inventory GUI when required. Previously it was ... well not like that. More ... messy.
Additionally to that, there was finally nothing left that was blocking the loot drops implementation. So I went ahead and wrote mobs dropping loot. Generally speaking it's a kind of loot dispenser that would dispense items upon certain inputs such as entity death or if something calls its Drop method.
That meant that I also had to start implementing items displayed in the world. A player can pick them up by clicking on them. Hovering over an item with the mouse will show its name. Upon collecting them they will be auto-sorted into the player inventory.
Oh also, very important: My better half started on a new character spritesheet for the main player.
That new one looks pretty good and definitely a 1000x better than the old one. Although, movement animation is still iffy and needs adjustments. She's at it.
So this is what happened this week.
Here's a snippet of the road map so far (it's ever-changing but it represents a more or less accurate plan of things) - for your reading-pleasure (does not include artist stuff, only code).
- 0000019: [Feature] Sound Manager (damagefilter) - feedback.
- 0000006: [Feature] Dashing Movement (damagefilter) - assigned.
- 0000025: [Refactoring] Refactor AI State Machine into a Behaviour Tree (damagefilter) - assigned.
- 0000023: [Menu] ConVars Editor Window (damagefilter) - assigned.
- 0000022: [Feature] Quest System (Devenias) - assigned.
- 0000015: [Feature] Status Effect Display (damagefilter) - assigned.
- 0000010: [Feature] Loot Drops (damagefilter) - resolved.
- 0000012: [Feature] Inventory System & GUI (damagefilter) - resolved.
- 0000021: [Refactoring] Inventory Rendering (damagefilter) - resolved.
- 0000011: [Feature] Player elemental immunity (damagefilter) - resolved.
- 0000017: [Feature] Save State System (damagefilter) - resolved.
- 0000024: [Menu] Item Editor (damagefilter) - resolved.
- 0000013: [Feature] Items & Item Stacks System (damagefilter) - resolved.
- 0000020: [Feature] Monies! (damagefilter) - resolved.
- 0000016: [Feature] Game Logic System (damagefilter) - resolved.
- 0000009: [Refactoring] Move Player Movement into separate script (damagefilter) - resolved.
- 0000008: [Feature] ConVars & Global States (damagefilter) - resolved.
- 0000007: [Feature] Chat Display System (damagefilter) - resolved.
- 0000005: [General] Sprinting needs stamina (damagefilter) - resolved.
- 0000004: [Feature] Direct callbacks to state on state switch in FSM (damagefilter) - resolved.
- 0000003: [Feature] XML Dialog Flow System (damagefilter) - resolved.
- 0000002: [Feature] Day and Night Cycle and global clock (damagefilter) - resolved.
- 0000001: [Feature] Entity Attribute System (damagefilter) - resolved.
Next week I'm doing the status display and AI refactoring, which will likely take a lot of time as a behaviour tree is not exactly a trivial thing to implement.
Additionally, what is not in the roadmap yet, I need to re-implement the dialogue system. And maybe, while I'm at it, I can come up with something more fashionable.
That's it for this week,
thanks a lot for reading!
It's time for another Dev Ramble because a lot of stuff has been done since the last blog.
I have been working on various editors as well as game components and with the recent release of the Unity 4.6 beta, I was able to start throwing out NGUI from my project.
So that's cool.
So, what did happen?
First of all, there has been put more work into the city spritesheet. The grass was changed, new trees were added and the overall tone was adjusted to be slightly gloomier.
Here's a quick screen grab.
That player sprite there is also a subject to change (a lot). It's supposed to be a battle monk. Only, as you can see, the proportions relative to the environment are waaaay off. We're constantly iterating on it. There will probably also be a second set of larger houses soon.
Additionally to some art improvements, I was working on the save-game system, which is done by now. It's as simple as streaming all entities in a scene into a bunch of bytes and put them into a zip file. When loading scene data it will wipe the entire "default" scene clear and restore what was saved to that zip file. That is it - simply speaking. In reality it does a whole lot more than that.
I have also been working on implementing items in a fashionable way. That is to say, I am mimicking the behaviour of the RPG Maker. You get to define a set of items by names and values. That's what makes up an item. Like this:
Attributes as shown in the editor picture will assume random values (if values apply) between the minimum and maximum value definitions. It's also possible that an attribute is not attached to the item when spawned. So an item may have a super effective or useful attribute but it can only be occasionally found.
This makes for interesting item mechanics in my imagination. I hope it'll come out as good as I think it will, in the end.
Now that items are ready and a framework is layed out, I can start re-doing the whole inventory GUI.
Right now it works via NGUI (the free 2.7 version) but since Unity 4.6 comes with its own GUI system, I'll switch to that instead. This way I can use the same sprite data for inventory display and for displaying items in the world. No fuzzing about with different sprite atlases.
On a related note, the "Tech Foundation" release, which includes all the framework code to be functional, is due in december this year. But I'm through by 59% with all the scheduled tasks. Taking into account fluctuation in plans and requirements, I make it a 47% done.
Serious work started about 3 months ago so I'm about in-time with that planned release.
In december I will make a games page on indiedb too so, if you feel like it, you'll have something to track.
The next big thing I have planned is changing from a state machine to behaviour trees with my AI. It will allow me to make the enemies behave in all sorts of complex or simple ways depending on their defined tree of behaviours and decision making.
For now, that's about it. Thanks for reading!
Here's a gif that shows lamps reacting on time of day.
It looks a bit crude but for real, this looks really cool. Couldn't resist showing it off :P
Just a little fun thing, an example of entities reacting with the world time.
This entity in particular is a Func_Lamplight. Hehe.
Work on a quest system has been started so that will be a thing soon.
No blogs were found matching the criteria specified. We suggest you try the blog list with no filter applied, to browse all available. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.