I'm Chris. I'm making games and I'm writing tools for different things. Such as games ;) Also, this is my personal private account thingy. I'm only officially speaking for things related to PlayBlack. Nothing else. So you know.

Blog RSS Feed Report abuse DevRamblings 6 - Improving Combat Mechanics

0 comments by damagefilter on Mar 30th, 2015

Hello there!

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.
Flame-up!

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!

Cheers,
df

Report abuse DevRamblings 5 - It's about lights

0 comments by damagefilter on Mar 22nd, 2015

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.
Simple fake 2D 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.
Et voila.
Lights and daylight cycle. All dynamic.
Simple fake 2D light
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!

Cheers,
df

Report abuse Firewalker DevRamblings 4

0 comments by damagefilter on Mar 16th, 2015

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.

State Machines to Behaviour Trees

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 new dialogues

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


Unity 5!

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!

Cheers,
df

Report abuse Firewalker DevRamblings 3

0 comments by damagefilter on Sep 5th, 2014

Hello!
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.

Derpy Pixels
That's what happened ... but at least the pixels are all there. Nice and large.

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.

Items in World
Furthermore I re-implemented the player stats GUI.
Thanks to the new Unity GUI that went very smooth and did not make much problems.

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!

Cheers,
df

Report abuse Firewalker DevRamblings 2

1 comment by damagefilter on Aug 29th, 2014

Hello there!

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.
The Town 01

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:
The Item Ed
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!

Report abuse Couldn't resist the urge

0 comments by damagefilter on Aug 18th, 2014

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
Func_Lamplight

Just a little fun thing, an example of entities reacting with the world time.
This entity in particular is a Func_Lamplight. Hehe.

Also relevant:
Work on a quest system has been started so that will be a thing soon.

Report abuse Firewalker DevRamblings

0 comments by damagefilter on Aug 15th, 2014

Hello.
Is this thing on?
Great.
So here I am again. Today, I would like to introduce you to my "Project-30" which is not my 30st project but a thing where the deadline is the day I turn 30.
Which is about 3.5 years from now on.
I'm working on this mostly on my own. I had enough of large teams as you might imagine.
So that is realistic, no?
I did not make a game page for it yet for there is really not so much to show off so far as I've been busy working on the "core systems" to get the game running.
I want to talk about this progress but not today.
Today I'll simply want to introduce you to the game and where I'm heading with it.
Here's a picture of the earliest prototype (which I posted here)

Firewalker Stuff

Today, Firewalker looks significantly different. For once I dropped the 3D aspect and went with 2D 16-bit optics. It's also not a sidescroller anymore but top-down. There is not much representative material yet but here's an old part of a screengrab from my testpark map.

Firewalker v3 Devshot
This decision came mostly from me wanting to do something retro-looking, yet a bit modern. I also knew that I have a serious lack of resources when it comes to 3D. I'm not exactly a bad-ass 3D artist.

So what is Firewalker all about?

It is a mixture of diablo-esque hack & slay gameplay and Zelda-style RPG puzzle solving, dungeons and questing. There will be a lot of bloody pixels and dark humour while the story evolves to its bitter bitter end.

That's where I want to take it but that is not everything.

My personal favourite feature is the day and night cycle. It's a very organic thing.
For instance, certain enemies will only spawn at night. Certain shops may also only be open the hour after midnight. Also traveling around the world in the dark is much more dangerous.
I think there's a lot of dynamic gameplay to gain from this.

So that is that.
During further development I'll provide builds up until a certain stage for everybody to try out if they so want.

That's that.
Thanks for reading, folks.
So long!

Report abuse Devblog 2.0

0 comments by damagefilter on Apr 21st, 2011

Hello Folks!
It's me again to inform you that I'm moving my "blog" to playblackstudios.net
Not that I don't like it here on ModDB anymore.
It's more the fact that we made a bradn new website and we ought to use it over there ;)

Check out the latest blog:
[LINK]

That's about it, folks! ;)

Report abuse Website Update and Minecraft

0 comments by damagefilter on Apr 11th, 2011

Hello Folks!
The second update to our website has been deployed.
Check the changelist/bugfixes/etc here

Next will be soe technical updates to harden the security on our site.

Anyway.
have you checked out our shiney Minecraft Server already?
It's cool, it's pure and it runs on our mighty root server.

46.4.78.198:25565

You will usually find the PlayBlack guys there, running around and buildung stuff, because that is what we can do best :P
FYI:
You do not have build rights as a visitor, ask for them or type /motd in the chat ;)

That's it for today folks!
Thx for reading!

Report abuse Whatever happened over all this time

0 comments by damagefilter on Apr 6th, 2011

I thought I blogged a bit more by now but either all my blogs are gone or I just didn't do it for no good reason.
Funny how my brain sometimes has punctures ;)

Anyway.
We were working quite a bit these days, besides playing Minecraft way too much, ofc.
Most of the work was dedicated to the new playblackstudios.net website,
the secureing of our new root server and the problems it causes.
You know, like FTP Services not working properly, E-Mails beeing bounced back or
not coming to the server at all because the firewall wouldn't allow it ....
stuff like that.

But now, our emails are working properly again and you can contact us as usual.
If you like to, that is.

Lets talk a bit about the website.
Many people asked me about what that PlayBlack thing is going to be, how and why.
We already have enough platforms to advertise our mods.
Well, that's totally true.
But PlayBlack isn't going to be a platform to advertise your mod or game.
It is going to be a development framework for the whole team.
We will offer services like bugtrackers, SVN Repositories, forums and many more.
For free.
On one server, under one domain.
With one account per user. (That's the plan, I'm looking into bridging login methods in a secure way)

However, if you want to know more, look here and read the news.
It's all in alpha, if you like to call it that way, but under heavy development.
And for now I'll just use it as information site until everything runs fine and we can start
testing it with other mod teams etc.