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.
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.
Is this thing on?
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)
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.
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.
Thanks for reading, 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:
That's about it, 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.
have you checked out our shiney Minecraft Server already?
It's cool, it's pure and it runs on our mighty root server.
You will usually find the PlayBlack guys there, running around and buildung stuff, because that is what we can do best :P
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!