Before starting a new year here's a review of what went right, of what went wrong and our future plan on Blackreef Pirates.

What went right

2. Having a fixed schedule and focus
I'm a "professional procrastinator". To me was really hard to find the focus needed to blog every week (with video) but having this fixed schedule really did wonders: it pushed me to find something to show off every time and in turn this focused me more on the real game, instead of working on secondary features.

3. Working from home
After a decade of office work is great to work from home. I always had weird work hours (I work best at night) and I finally can choose when to start my work day. Also, having no real budget, working from home is great to reduce many expenses.

4. Remote collaboration
I started the year working as a "one man band" but in August I started a collaboration with a talented 3d modeler. I was very worried about the lack of a common place to work together, but in the end that wasn't really necessary. We can meet each other now and then (it's only 1 hour far by car) but we work remotely everytime: all we need is a combination of skype, dropbox and a shared online whiteboard. We work on different part of the game so it's easy to integrate everything without conflicts.

5. Good and clean project standards
Isn't hard to create things in a complicated and convoluted way and while this isn't really an issue for many developers we're trying instead to keep things simple and easy: you won't find textures, scripts, 3d models or materials scattered all over the project directory. Each texture is stored in the same uncompressed format and double sized (the minimum is 4096x4096) in order to be ready to release a HD version when the future HW permits.

If everything goes in the right direction, this codebase could be the starting point of our future games, so I'm happy to get this right from the start.

6. Win, Mac and iOS with only one project
We're doing all the ports at the same time and we developed some tools to help us reduce or adapt the game resources to fit different screen sizes, OS and control scheme. This is good because we will ready to release on all platforms at once and you won't find poor third party adaptations with changes in the gameplay because one of the platform have a "touch" interface instead of the classic mouse&keyboard or gamepad.

What went wrong

1. Lack of content
I really underestimate the time needed to produce good content. Even if many part of the gameplay are ready or near to be completed we're still missing big parts of story, graphic and audio content.

I have to admit, it's all my fault: I have a strong technical background and usually I can do pretty accurate schedules about the coding part but what I learned is that in the end the tech is the easy part, the hard part is creating content and putting everything together. Also, the real graphic work started 7 months late: I was slow to understand I wasn't able to do all the 3D work. Luckily, Marco joined the team in August and since then the game graphics improved heavily :)

2. Using Unity
Yes, this was also in the "What went right" section: our game needed something extra (the GUI system, pathfind) and something different (character ambient shading). Happily I was able to "bend" Unity and extend the editor in the wanted direction. The downside is that I spent too much time on these customizations and I lost 8 weeks of development I could have used differently.

3. Stress
Working 10 hours everyday (even on weekend) is hard: I'm now completely out of shape and I gained something like 8kg in one year: this have to be fixed ASAP! With stress also came some serious mood swings ranging from depression to happyness (even in the same day), too many times I thought the best thing to do was to quit and go back my previous life. Luckily my wife was capable to keep my mental sanity to an acceptable level, thanks again Micaela!

4. Early playable alpha
My promise was to have a new playable alpha out every month but since September I didn't find the time to prepare a new one. Sure, it helped me to iron out some bugs early but probably was too soon to have it publicly playable: the core gameplay wasn't clearly defined and a lot of people didn't fully understand what "alpha version" really means, that's why I removed it today.

I still plan to let you try the alpha in the near future though, in a way or another.

So, was it worth it?

Yes, absolutely! Everything happened this year, good and bad, has been an invaluable learning experience. I have now a better understanding of my weaknesses and what really means being a game dev.

My original plan was to complete the game in only one year, alone. I was wrong about the time needed and the ability to do it alone but in the end I think it's completely acceptable.

The future

First, we're going to enjoy some days off to prevent us from mental and physical exhaustion :D

Then, the development of Blackreef Pirates will continue and according to what we learned we're only halfway to completion. We could stop the development as announced and publish the current game as it is, but we think that if we keep working a little we're going to have a really great game.

In the coming months we are going to keep you posted weekly about the development of the game and about the launch of the dedicated website www.blackreefpirates.com that is going to be a better place to host our little but growing community and collect all the news and media.

Changes from last week

• New swords: real steel, no more wood!
• Parry (miss) and evade animations: more dynamic melee combat
• Initial support for hit, miss, evade based on character stats
• Particle systems: used for sword "sparkles" together with the parry animation
• New target selection style (red circle on floor): less cluttered screen

Enemy AI

Parley!?

Sight is pretty easy and straightforward to implement (remember Week 15?) and the only thing I added this week is different "Field of view" when patrolling and when in combat.

This "line-of-sight" technique works fine, but...it was too easy to sneak behind an enemy unnoticed, so I added a hearing sense.

Each footstep or combat sound now emits a "sound stimulus" directed (with a maximum range) to every NPC in the game. This is useful to alert nearby NPC about a fight or something suspicios.

These "sounds stimuli" are also using the pathfind system to reach the NPCs: this way when you make some noise inside a room the NPC can hear it coming (apparently) from the door.

All this things makes me eager to add a "sneak" ability to the player...but I must resist 'cause there's no time for it now :(

The first arena

The game that will be playable in late february is going to be focused entirely on combat and party/inventory management. This is a huge part and need to be perfectly balanced and tested before adding all the rest (story, exploration, quests, etc...).

In short: we're giving you a smaller but tasty cake istead of a bigger but half baked one. And yes, we will add the frosting later!

There will be many combat arenas and various challenges to complete. We almost completed the first arena: is pretty small and is perfect for a 1vs1 or 2vs2 introductory fights.

Ok...ok, enough talk, here's the weekly video showing some new gameplay bugs features.

Am I going to survive this? Oh, here's my bottle of rum!

Hey everybody, we're back with some new video goodness! This time you can see some great progress on the action bar and the combat system.

Action bar and "warmup" time

Wait...what? You will probably know the meaning of a action "cooldown" time often used in RPG...well, we're heading to a opposite approach: the warmup time. In short, you can use any action you want (if the character have enough stamina) but you need to wait a little before is really executed.

Oh, don't worry, this wait is very short, from 1 (generic attack) to 3 seconds (for bigger and powerful attacks).

New combat animations

Here's a short video with all the cool things...I'm going back to my rum

Combat actions

The biggest change is the introduction of the stamina bar: there will be no "cooldown" time for attack actions. Every action use a bit of stamina, so you can use powerful attacks until the character's stamina run out, then you have to wait for the stamina bar to recharge before to be able to use more powerful attacks.

Savegames

Did I mentioned all the savegames will be backed up automatically on the cloud? Yes, you will be able to use the same character profile on the ipad, web or the stand alone desktop version.

Weapon types and combat animations

• sword
• mace
• axe
• gun

Instead of using always the same animation for all weapon types I choose to create several animations related to each type. We have now 5 new animations for sword attacks (4 generic and 1 special attack).

Character stats

Updates from user feedback

• Double click on enemy will trigger the default attack action
• The animations are now faster

New weapons

But...here's a quick preview of the Inventory panel for Blackreef Pirates!

New inventory panel (click to zoom)

We still have some time to spend on it, what would you like to see improved or changed? (yes, many icons are still placeholder and buttons need to be moved...)

In other news, Marco has started working on a set of new weapons so we can test them on the inventory screen :D

In this weekly video I'm going to show you the new animations for walking, running and running with drawn sword.

Also, there are some improvements in the specularity for characters and weapons shaders.

Here's a little video of the new assets...

Blob shadows

Indoor scenes and camera

The camera used for little indoor scenes like this will be completely automatic, similar to the one used in point&click adventure games. And no minimap for indoor scenes! You're not getting lost in here, right?!

Here is our traditional weekly video, enjoy!

So, here's our personal tribute to the Skyrim world: epic helmet with horns!

Micro FAQ

• Are we completely nuts? Yes!
• Is the helmet a joke? Absolutely!
• Can we have a "Arrrr" shout in Blackreef Pirates? We're thinking about it ;-)

Even if the helmet looks great in game we cannot use it because...well...isn't very piratey. But we can borrow something else from Skyrim: the camera with a lateral offset. What? Just look the video :)

The second (real) update is a target indicator in the minimap. This was a very requested feature and I hope will help you in not getting lost anymore. It will point you to next quest objective.

Marco is working hard to finish the core part of the city and then spend some time placing ornaments and little details.

Here's some pretty shots of the city:

Camera improvements

One of the main complaints about the game is camera movement. It's one of the first features I worked on and still need some love. Everyone wants something different, so I wrote another camera style. It's similar to the one present in Dragon Age: Origins so many RPG lovers will feel like home :)

Here's some improvements inspired by your comments and critics:

• Free look: you can now look up&down with the camera
• Camera type #1: Move your character with W,S and rotate the camera with A,D keys.
• Camera type #2: Move your character with W,A,S,D and camera will follow and auto-rotate.

Of course you will be able to choose which camera type you prefer in the game options.

Other minor changes:

• Move all characters using physics (fixed the character going through walls bug)
• Mouse wheel to change camera distance
• GUI updates and trying a different fonts

Whaat? Where is the game?!

Don't worry, the game is progressing well, Marco is creating a whole new section of the city and I'm working on some new gameplay feature related to Indoor scenes. Also, the story start to have some interesting twists, but I still can't talk about the details ;-)

Gamma correction

In a perfect world every monitor have always the right contrast and colors. In a perfect world gamma correction makes no sense. But we live in a world where every monitor is slightly or completely different from the "standard" because of user settings or cheap hardware.

We want to create a game that looks great everywhere, so we need a way to compensate all these monitor differences in lighting. One of the solutions is to provide the user with a slider to correct the gamma and then correct the image with a post-process filter.

Here a simple test with 3 different gamma settings:

Gamma correction test (click to zoom)

New website

www.blackreefpirates.com

Currently is just a placeholder page with some links but soon we plan to add all the game related media and a community forum to it.

Kongregate

Recently they also the publishing of Unity3d games in their portal...It's a great opportunity for small developers like us to grab a little exposure, so we published our little "Training arena" alpha on it.

The results? The alpha got 1000 (and more) plays in just a few days. I'm sure we can do more with the next alpha but, in the meanwhile, please support us!

Hint: Give us a 5 star rating to gain more visibility!

That's all for this update, see you next week with a new "Art asset overview" video.

I must admit...the iPad 2 version of the game runs incredibly great :D

Not only the game is running correctly and without graphical glitches but is also rock solid at 60 FPS with 2X antialias!

Yes, 60 FPS!

So, I spent this week configuring everything to work on this little "magical" device and working on an custom UI more suited for a touch screen.

Remember the Week 20? I talked about an experiment with a touch interface using two virtual analog pads. Right now I removed the VPad on the right and instead you can simple swipe horizontally on the screen to rotate the camera, it's much more suited for this kind of devices.

The other big change in the UI is the placement of the action buttons on the right. Sure, it can look a bit weird but once you try it will be clear that not having to move your hands is the best solution.

New UI layout for touchscreens

Lastly, thank you everybody for all the feedback about the latest Alpha. Here's some fixes already available in the webplayer:

• Camera stuck after dialogues
• More acceleration of the player
• Right mouse button is grabbed instantly without having to move it
• Action bar shows the active action (yes, still need some work..)
• many minor fixes and optimizations...

The changes are too many but the biggest are:

• improvements in character animations
• dialogues with NPC
• level scripting and cutscenes
• checkpoints
• mission objectives UI
• weapon grab

Warning: this demo is incomplete. I mean, it's a good testbed for many features that will be included in the final game but contains a lot of placeholder animations (the "grab weapon from table" is clearly one of them) and gameplay glitches. However I plan to continue working on it and release updates when ready, without waiting another one full month for another release.

As always, you can play it directly in your browser or if you prefer there's a downloadable version too:

Play in your browser

Download windows

Download mac

But...here's some good news for you: we have found a name for our little game! Yes!

Blackreef Pirates!

Here's some fresh screens from the training arena (aka Alpha 6)

I also started working on this gameplay features (more on these later):

• Dialogues
• Cutscenes
• Mission objectives UI
• Checkpoints (a-la GTA)
• Training dummy and shooting target
• Friendly NPC
• Skydome

Our plans were to show you a new playable alpha but I'm taking another extra week to cleanup the code and iron out some problems people is having with the webplayer (I'm thinking about creating a stand alone build next time).

Changes

• Party PC AI
• 9-Quad widget: for buttons and progress bars
• Training dummy AI: (yes, stay still and keep doing nothing until you're in pieces. Very intelligent :D

How about the art side? In the upcoming Alpha 6 we're leaving the "prototype look" and we are going to use this arena as a place to test all the new combat features. The arena is still a work in progress and without too many details, see you next week for the final version! :)

Wireframe (click to zoom)

Still here? If you liked this post and you're not subscribed yet...here's our YouTube channel, RSS feed and Twitter

The pirate village

Yes, we're building the village :)

Remember the first pirate island prototype video? Well, Marco started to replace some of the placeholders models and created the first section of the pirate village. We have now more variety of wood textures and some windows too. Did I mention I love the addition of a small combat arena? This arena will be very useful in the start of the game to teach players the basics of combat.

Secondary weapon

Here's a video showing you the first part of the village and the gun shooting. Enjoy :)

About IndieDB
"The aim of Indie DB is to connect independent developers of games with players, from the day they start developing their game to the day they release it. On Indie DB we give developers control of the site, allowing them to share details and behind the scenes insight about the games they are creating, in the form of news, images, videos and downloads."

Some people worried about the lack of gameplay updates...well, a new playable alpha is coming, stay tuned :)

All objects in the scene share the same texture atlas (a big 2048x2048 texture on iPad and 4096x4096 on desktop), have a very low polycount and are organized in a way to be reusable and as foundation of larger and more complex props.

If you like to have more information about UV management, texturing, modeling or other tips please leave a comment and follow our devblog!

Together with the game theme I also announce the start of a collaboration with Marco Lisci, a very talented environment artist and level designer. Marco is already hard working on the first level of the game, a little pirate town and a the nearby port.

Work in progress!

I'm very excited to show you his first work, everything is just a placeholder to test the level size and spaces...and I love it!

Here's a video with a fly-through of the first level prototype, isn't great?

• New models: chest, hands, belt, legs, boots and a beard!
• Swords!
• Attachment "bone" for swords and draw animation
• Running with sword animation
• Custom shader for weapons (with fake specular)

Why "modular"? Well, I can't create every character from scratch because it's hard, error prone and not very practical. Instead I'm planning to create a small number of body types and then assemble the final model using many small pieces to achieve different looking characters.

Different skin colors thanks to Vertex Colors

Here's the first bodytype. It's a slim male based on Adam character and it's almost ready to be the base for every other bodytype. I'm planning to create at least 3 male and 3 female bodytypes and each one will have 3 different heads and clothes. This should be enough to achieve a little character variation in the final game :)

Each character will use interchangeable parts like:

• head
• hands
• torso
• arms
• legs
• feet
• hair
• hats

All the character assembly is made at run-time. This allows me to "randomize" the look of minor characters you encounter in the game.

The problem with using so many parts in Unity is that every part is a different Skinned Mesh requiring a separate draw call (this is bad for performance and for your health!).

Here's a little tip: you can actually combine all the meshes that uses the same material into a single mesh. The CombineSkinnedMeshes script in UnifyCommunity wiki is a great starting point.

Base character

Combined mesh

As you can see, adding parts doesn't increase the draw calls counter: Victory! :D

Facial animation

In the game you will often encounter and talk to people. Even if I'm not aiming to have a full and realistic facial animation a-la "LA Noire" I want to add a little of "life" to characters giving them facial "bones". Yes, facial bones is the only way to have a little animation inside Unity. There are better tecnique out there, like "morph targets", but at the moment I think it's good enough.

Each bodytype shares a common skeleton and animations, this is a great time-saver but also very tricky to get working with different models. Here's a little video showing a single bodytype with some variations (different head, skin color and hair) using the same animations.

If you liked these first characters and enjoyed the video please subscribe to the youtube channel and let other know about it :)

I also started to work on the game theme and background story...I can't show anything to you at the moment but trust me: is going to be awesome B-)

Changes from last week

• Sword trail for melee attacks
• Improved character shader (now with more specular goodness)
• Reworked vignetting and pause fx

What are you waiting for? Try the Alpha #5 "Shotguns" in your browser!

I still have six months to complete my evil plan of world domination and finish the game :)

All these months I've been working on this project almost everyday full-time but there are still many things to do. Here's what I'll work on in the next months (in random order):

• Dialogues with NPC
• Friendly NPC
• Combat AI for NPC
• Load/Save games
• World map
• Better party AI
• Buy/sell stuff in stores
• Quest tracking
• Cutscenes
• Automatic pizza maker

Half journey numbers

So far the entire project has:

• Lines of code: 16613 (120 scripts)
• Textures: 66
• Audio files: 23
• Materials: 38
• Blender models: 8
• Scenes: 12
• Total assets size: 238M

Changes from last week:

• Standard door prefab
• Vertical door prefab
• Camera vertical angle correction based on terrain slope
• Footstep sounds now emitted at feet position
• bug fix in Pathfind

Some people asked how my tipical work week looks like...well, I think my job here is not very different from many "computer jobs" with the exception of working from home and be able to choose your own work hours. The real problem often is how hard is to stop working when doing something you love..I must admit, sometimes I work too much.

The best thing I learned since I started is how challenging and rewarding game development is if you try to cover every aspect: one day I'm the programmer, another day I'm the audio guy, the modeler, the animator, etc... There's plenty of things to learn and create everyday, and if you're like me this is heaven.

I prefer to work on many short milestones of one or two week maximum and I try to achieve something (even in random order) every day. Many people can argue that is not a very organized way of doing things but...hey, it's working! :)

The video this week is a summary of 5 days of development. I took a small video everyday and you can see how a new feature is done and how much time little things like adding sound effect can absorb.

Enough talk, enjoy the video :D

Changes from last week

• Bullet trails
• Muzzle flash
• Shotgun fire sound
• Shotgun reload sound
• Shotgun fire animation
• Idle animation for ranged attack

I found a way to have 9 different combat actions usable for the iPad version: action categories! This solution require 2 taps instead of one but seems to be the only practical way to deal with many buttons when you're grabbing your iPad like a gamepad.

The first tap is used to select the category and the second is to select the action, not many games uses a similar technique...I hope you like it :)

Changes from last week

• iOS: Removed right virtual analog pad
• iOS: actions organised by category
• iOS: switch leader button
• Menu buttons only visible when game is paused

The combat system is starting to be usable and I added a new "action system". Each player now have actions subdivided this way:

• melee attack (3 actions)
• ranged attack (3 actions)
• use magic (3 actions)
• Open container
• Use object
• Talk to NPC

In the alpha you can see many of the action in the lower part of the screen, but at the moment they all trigger to the same combat action. This (and icons) will be improved in the next alpha.

Changes from last week

• added body fall sound
• target selection via click/tap on NPC
• added 9 buttons for actions

Warning: this demo contains traces of programmer’s art!

What are you waiting for? Try the Alpha #4 "July" in your browser!

Foley-like audio system

What seemed like a really easy work turned into a nightmare when I discovered that sounds are not paused automagically when you set the timestep to zero inside Unity3D. After some searches I found that I had to manually stop each playing sound and then restore them using AudioSource.Play with an offset. All this audio work reminds me the good old days working on Hydrogen drum machine...maybe one day I'll start a drum machine project with unity... :)

This new sound effect system is now used for the walking sounds, weapon "swoosh", weapon "hit" and NPC pain.

NPC pain...and death

The NPC character is still not reacting to ease the testing and after a few hits it will die and fall down. I know all this could sound funny but it's a HUGE step towards a real combat system.

Other minor changes:

• Weapon is now attached at run-time
• Death animation for Adam
• Dead bodies are destructed after 5 seconds
• Virtual analog pads are hidden in desktop build
• New map to test the combat system
• Player is hidden if camera is too close

Enjoy this week video and remember to subscribe to the youtube channel!

• It's designed for programmers
• Has an internal atlas creation utility
• It's fat free

The atlas utility is built as a simple EditorWindow and uses the Texture2D.PackTextures method to create the atlas.

Yes, it's ugly..but it works :)

Using a texture atlas had a big impact on my workflow, now I cannot use directly a texture but instead I can only add the texture in the atlas and then use the image id (the position inside the atlas) to refer to that texture. Yes, it's one more step to do but the results are great: 1 draw call for the widgets and 1 for all the text. And it's faster than ever :D

The final atlas texture

Ok..ok, enough talk about the tech..how about the game?

Now there's a new system to replace the old "mouse over" action. It's an automatic target selection that highlights all the interactive object around and then shows some information about the object in the front of the player.

Interactive objects around the player

The target selection works also on NPC and it shows the HP bar and the combat level.

NPC information during combat

Full changelog

• Automatic target selection (for interactive objects and NPCs)
• New graphics for Party status panel (now the leader is highlighted)
• New small bitmap font (20px)
• Support for multiple atlases in SubGUI
• Basic character AI LOD (reduced AI cicles when far from player)

That's all for this week, see you next Monday..I'm cooking a new Alpha for you!

Desktop users doesn't have to worry...the game will also be released on PC/Mac platform.

Last week I mentioned the problem I had to move away from a mouse&keyboard centered controls towards a common PC, gamepad and touch control scheme.

The first victim of this transition is the "mouse over" (used to see object information). The next week I'm going to replace the object highlight with some sort of GUI overlay.

iOS controls

My implementation of virtual analog stick isn't very different to the majority of games present on iOS but I took some time to fine tuning the behaviour of this little component.

Now repeat with me: fixed position virtual sticks are bad. Everyone has different hand sizes and there's no way to know the best position. In my implementation the stick will move under your thumb when you touch the screen, so there's little room for unwanted movement tipical of fixed position sticks.

The left stick is used to move the player and the right stick is used to rotate the camera. Since camera rotation is horizontal I made the right stick horizontal only.

If you prefer to not use the virtual sticks I added the ability to move the camera with a horizontal swipe and move the player directly clicking...ehm...tapping on the floor (with pathfind, of course).

Desktop controls

Nothing new here. Game controls are still keyboard and mouse or alternatively you can use a XBox 360 controller, it works great and I managed to even have the rumble working in unity3d :)

Full changelog

• New animation: Melee hit received
• Damage and attack speed now based on equipped items.
• Graphical damage points visualization
• Click on floor to move in that position
• iOS: Action button
• iOS: virtual pad implementation
• iOS: horizontal swipe to rotate camera
• Desktop: rumble support for Xbox 360 controller

Enjoy this week video...yes, Adam got angry :)

I did some experiments with different control schemes like touchscreen and xbox controller. It's really hard to keep everything coherent: every type of control have its advantages and limitations that influence the gameplay too (I need to think a way to replace the "mouse over" action).

However, here's the changes:

• Default attack action with LMB click on enemy
• Pathfind used to reach NPC (in combat mode) and Containers when there's not a clear line-of-sight
• NPC uses pathfind to find again its patrol path (after a combat)
• First melee attack animation (sword attack)
• Combat idle animation
• Placeholder walk animation
• Fake bumpmap shader (little detail even without dynamic lights)
• Experiments with "bird view" camera style (removing ceiling and disabling camera collision)
• Experiments with 3D HP bar
• Desaturated and blueish color tint in postprocess shader
• Bug fix: weird neck bone rotation during pause
• Bug fix: NPC can see through walls

What are you waiting for? Try the Alpha #3 "Pathfind" in your browser!

Since now the PC/NPC follow behaviour, used for following the party leader or an enemy, was based on a simple line-of-sight technique. Even if this technique works pretty good in a open world environment with few obstacles it has too many flaws for an indoor use with lots of walls and obstructions. To overcome these limitations I implemented a pathfind solution on the top of the existing behaviour.

How this all works?

As always, I'm trying to pre-calculate everything in the editor to keep CPU load at minimum during play. I choose to create a Navigation Graph and compute all the connections between Navigation Points, distance and edge cost inside the unity editor using raycasts to determine visibility between them.

Creation of the Navigation graph inside unity

Once the navigation graph is ready I use this data to create a path at run-time using a classic A* algorithm. Placing all the navigation point manually can be an hard task but since the points are very few the pathfind algorithm will generate a solution very fast.

Right now the pathfind is only used when the party leader is not visible with a cheaper line-of-sight check.

Works pretty well..so, let's play hide and seek! :D

Patrol path

The patrol behaviour is still too rigid and robot-like, I'll try to smooth the path in the future and add some variation (multiple paths?). Also, I desperately need to finish the walk animation...the NPC guard can't run all day :D

What!? Aren't you subscribed to the youtube channel!? Go click the "subscribe" button now..yes that's an order ;)

This week I created a new "training room" and started coding the basic AI for the enemy NPC. Right now the NPC still cannot attack, but can "see" the player and seek him using a line-of-sight technique similar to what already used for the party members follow behaviour. Also, I'm testing a very cheap collision avoidance technique using 2 "feelers" to sense a near obstacle (even a dynamic one).

Adam, run!

Changes

• Adam has a face!
• Different soundtrack for Combat mode
• Yellow/Red circles under PC/NPC (to reduce friend/enemy ambiguity)
• Show information on mouse over NPC
• NPC turn head towards the combat target
• NPC line of sight (raycast, blocked by walls)
• NPC "feelers"
• NPC shown as a red dot in the minimap

Enjoy this weekly video changelog and remember to subscribe to the youtube channel!

This week changes

• Right mouse drag is now used to rotate camera
• Container details view: consumable items can be used, weapon and armor can be equipped.
• Basic character stats and comparison with the selected item
• All data now is real and read from a static XML file.
• Adapted various UI to fit in 1024x768 screens

Alpha #2 is online!

I took one week break from game development and spent the time to unpack boxes and relax with family and friends. The weather in Sardinia can't be better and inspires me to get out more often and enjoy the wilderness of nature away from the cities.

Sardinia, Italy

Starting to work again after a break is hard for me...I can barely remember what I was doing, so I tried to work only on "fun things". Being a programmer by trade "fun things" mean a lot of code :D

Experiment #1: GUI

My goal is to create a framework that uses very few draw calls to draw the widgets and handles a lot of text.

Left: final result. Right: 3D scene view

How it works?

The core uses the same path already taken from many UI framework for unity: an orthographic camera, some meshes generated at runtime, texture atlases and lots of UV work.

At the moment I'm generating 2 meshes: the first is used for all the widgets (label, buttons, etc...) and the second is used only for text.

The bitmap font renderer was the hardest part but luckily there's lot of examples about how to implement such a thing. I'm using the AngelCode Bitmap font generator to create the glyph atlas. This part is pretty finished, I only need to implement the kerning and multiple font support. :)

It's fast :D

Here's the code used for a simple window with a label and a button...isn't pretty?

class MyUI : SubWidget
{
	SubButton btn1;
	
	public MyUI() : base( "MyUI" )
	{
		setBGColor( new Color( 0.37f, 0.63f, 0.75f ) ); // blue background
		
		// create a red label
		SubLabel lbl1 = new SubLabel( "test label" );
		lbl1.setRect( 10, 100, 300, 200 );
		lbl1.setBGColor( new Color( 0.5f, 0.0f, 0.0f ) );
		lbl1.text = "I'm a label!";
		
		// create a green button
		btn1 = new SubButton( "btn1" );
		btn1.setSize( 300, 50 );
		btn1.setBGColor( new Color( 0.2f, 0.35f, 0.11f ) );
		btn1.lmb_clicked_cb = onBtnClicked;
		
		// create a fixed layout
		SubFixedLayout layout = new SubFixedLayout( this );
		layout.addWidget( lbl1 );
		layout.addWidget( btn1 );
	}

	/// Called when the widget container is resized 
	public override void onParentRectChanged ()
	{
		// keep this widget "fullscreen" leaving a margin of 100px
		setSize( Screen.width - 100, Screen.height - 100 );
		alignCenter();

		// align the button horizontally
		btn1.alignHCenter();
	}

	public void onBtnClicked( SubButton btn )
	{
		Debug.Log( "Someone clicked the button!!!" );
	}
}

Experiment #2: Static mesh combine

The modular test level

The test level I'm using is composed of 796 pieces. Such a high number of pieces is causing me some problems:

• lightmap (too much wasted space between pieces and lot of artifacts)
• too many draw calls

Activating "static batching" and using occlusion culling helps greatly in reducing the overall draw calls count but the overhead it's still too high for my old 2007 MacMini (my low end target).

To reduce the number of polygons I hacked the CombineChildren.cs script shipped with unity to be used in editor mode and not at runtime. This way the combined meshes are visible in the editor and I can create lightmaps for them.

Big combined meshes

The script is used to create several meshes: mesh are combined when using the same material and if they are in the same "sector". I found that subdiving the entire 256x256 meters map in 64 sectors is enough to keep the advantages of mesh combination without killing the occlusion culling algorithm due to too much large meshes.

After running the script, the level was reduced from 796 to only 21 big meshes (thanks to the fact I'm reusing a lot of materials).

As final step in the script I'm recreating the secondary UV for the newly created meshes. The created Lightmaps are now wasting less space between UV islands and the UV topology is cleaner too, resulting in less visible seams between meshes.

Left: Lightmap of a modular map. Right: Lightmap of a combined modular map

That's all for this week update, the next thursday it's Alpha 2 time!

Yes, my mood is affected by the bad weather, but also by Immediate Mode GUI. What? You never heard of IM GUI?

On Immediate Mode GUI

While developing a desktop application there are many conventions and guidelines. GUI toolkits designed for the desktop enforce and make easy for the developer to stay inside these guidelines.

But...there's no common human interface guideline for games! Also, there's no common GUI toolkit: every game engine has it's own toolkit with its own quirks and often you cannot switch easily to another toolkit.

The game engine I'm using, Unity, is no exception. Unity's approach is to use "Immediate Mode GUI" and I think it's perfect when you're prototyping a game or doing something really basic. The drawback is that creating complex UI or a custom widget become a pain.

Another big problem I had with immediate mode gui is the insane number of draw calls reducing framerate and overall performance.

Probably it's just me but I prefer an "old-style" GUI toolkit, the one with a hierarchy of widgets and with UI state inside the widgets. I mean, I want the button widget to store its pressed/unpressed state inside itself and not having a "btn1PressedState" variable around my game code. If I ever need that state back I'll just ask the button for it.

I need a different GUI toolkit. The NIH syndrome strikes again and I'm already working on a new toolkit.

ok...ok...enough rant for today...

This week changes

Continuing from the last week development I'm still working on the Item Container UI. I made some nice progress and the same window is going to be used also for the party inventory with little modifications. I hope you like the new layout changes too, I'm trying to keep everything minimal and easy to read.

Changes

• Item list filter: All, Weapons, Armor, Consumables
• Item list pagination
• Item basic attributes separated from extra attributes
• Placeholder for item image
• Panel to show the party currently equipped items and the comparison with the selected item (still WIP)
• Started the party inventory code and basic character stats

Enjoy the weekly video changelog and remember to subscribe to youtube channel!

The next milestone (alpha 2) will focus on item management and inventory. It's one of the most important part of a RPG game and in my opinion a bad user interface can ruin the entire game experience. I'll try to make a simple and clear interface first and then ruin everything adding graphics and useless features ;-)

Here's the fist step, the "item container" thing. Inside the game an item container is an object you can interact with carrying one or more item inside. This can be a simple storage box like I used in the video or something like a dead enemy body you can search for loot.

Left: normal object. Right: highlighted object

Every object you can interact in the game is now using the same graphical feedback with a nice highlight effect. For the unity people interested in how the shader works here's the graph made with Strumpy's Shader Editor. It's a normal-mapped shader with the addition of a "_selection" input controlling the amount of highlight.

Who knew a single pizza is worth +70 HP?

Left click to open the container and...here's the Found items panel! On the left you can see the found items (sorted by category: weapons first, armor and then consumables) and clicking on one you can see the complete description and all the item attributes.

That's all for this week, enjoy the video!

Is this a game?

No lies. There's no game yet but, while still working on it, I'm giving you the chance to try a little slice of gameplay. In this first alpha build you can walk around inside 2 maps (Blue and Red map, try to locate the portals to move between them!) to test the movements and the party basic behaviour (follow the leader, hold positions).

The promise

I'm going to create a new and publicly playable "Alpha version" every month. Unpolished and with lots of rough edges but hey...it's the price to pay for the preview :)

Alpha version?

Alpha version means that everything is still in progress and not all the features are implemented or final, so your comments and suggestions can really help to shape a better game.

First playable alpha, in your browser!

This week changes

• Main menu and in-game instructions
• Shader "level of detail" for better support on low performance video cards
• Added some placeholder background tracks and a brand-new music system
• A new little maze in the Red Level to test the follow behaviour of party members

What is this pause for? Well, the game I'm developing is not an action game and even if some action will be present you'll might need to pause, think, give orders to your party members and only then continue to play (especially in big and complex combat scenes). If you're used to play "Dragon Age" or "Star Wars: Knights Of The Old Republic" you surely know the importance of pause in the gameplay.

Right now during pause you can only rotate the camera and switch party leader but as soon as I implement combat I'm going to add more actions (like attack, use item, etc..).

Visually there's nothing fancy, I'm just using a simple "vignetting" fx to show that the game is paused.

Pause!

How this works? Unity has a useful property to set the speed of the physics engine. Just set "Time.timescale = 0" to completely pause the physics engine. Now every movement is stopped...but I still needed to move the camera so this forced me to juggle some code around the fact that during pause the FixedUpdate callback isn't called anymore.

Some extra features...

Beware! The camera is shooting rays!

Instead of using a single raycast to detect if a collider is between the camera and the character, now I'm using 3 rays and the character will be in "occluded" state only when all rays are shorter than the minimum. Still not perfect, sure, but take a look at the video below for a comparison between the old and the new technique.

...right now there's still much to do and everything is not polished yet but...I was thinking about making a public alpha for you to test and comment..are you interested?

Yes, I got flu.

Let's talk about moving between maps. The game world is subdivided in many small maps (up to 256x256 meters per map) because it's the only way to have detailed locations and performance.

How things works? We have "Spawn points" and "Portals".

A spawn point is nothing special, it's only a placeholder GameObject. Its position and Y-axis rotation will be used to place the player once loaded the new level.

Spawn point

A portal is a trigger gameobject created with a simple box collider and two attributes:

• Next map
• Next spawn point name

A portal! GLaDOS not included.

Easy uh?

How to keep game state?

Loading a new level it's the easy part...but every GameObject will be destroyed when the scene is unloaded. So, how to keep data and game state alive between level changes?

This simple script will keep a gameobject from being destroyed on scene change:

void Start()
{
	DontDestroyOnLoad( this );
}

I started creating an empty GameObject named "_GAME" that uses that script. Then I put every GameObject I want to keep alive between scene change as a child to "_GAME". This way I can store values and GameObjects and be sure they will be still here when loading a new scene.

The only drawback is that I was forced to move a lot of code and rethink the connections between gameobjects but being a programmer that was the fun part, or not? :)

Extra - Information panel

Also, I started working on interactive objects and the related information panel. This panel will be very useful to show information about objects and other characters.

Information panel

...and as always...enjoy this week video and remember to subscribe!

• Everyone is at GDC but me.
• iPad 2 was announced
• I ate too many "Frittelle di riso"
• I saw the sun in Hannover, yes..and the sky was clear too (a miracle!)
• Adam got two new friends

...more seriously...yes, Adam got two new friends and now they are forming a party. Inside the game the player will be in control of the party leader and will give command to the other party members but without directly controlling their movement.

I've added a simple "Party status bar" on the leftmost part of the screen showing a summary of the characters attributes (like "next attack time" and HP). Clicking on the character face in party status bar will set this character as leader. Alternatively pressing TAB key cicles the leader between the party characters.

Green, White, Red! How stylish are they?

There are two main party behaviour:

• Follow the leader: every character in the party will follow the leader
• Hold position: every character will stay in position while the leader is free to move

Characters are always forming a triangle with the leader on top and I'm using a simple follow behaviour based on line of sight: sometimes a character will get stuck in level geometry and lost the leader...but don't worry, a pathfind solution is already planned :)

Enjoy the video, see you next time and remember to subscribe to the youtube channel!!

• blob shadow for characters
• updated character shader to work on older SM2 cards
• procedural head turn
• project updated to unity 3.2

I'm using my 2007 Mac Mini as a low end target and by the time I'll complete the game I think everyone will be using a better computer. It has a powerful video card...the almighty Intel GMA 950! Wow, that videocard is so powerful that even my toaster render pixel faster. Simple shaders are supported (shader model 2) but any fullscreen image effect will hit hard on the framerate. Shadows are not even an option and even with only 2 lights it cannot reach more than 10 FPS.

So, with all these limitations there are very few choices to make. Here's the recipe:

• No dynamic shadows
• Everything will be baked or preprocessed offline
• No dynamic lights (almost)

Plain (left) vs Lightmapped scene (right)

Beast is doing a great job with lightmaps and since the characters are always near to the ground I'm sampling the lightmap texture on the floor to get the "ambient" color. It's far to be realistic or accurate but it's very lightweight and characters blends nice with the static environment.

Diffuse specular (left) vs Custom shader (right)

Diffuse specular (left) vs Custom shader (right)

The character shader is still very basic. I'm trying to achieve a "stylized lighting" using:

• One real-time directional light from top (adds a bit of specularity)
• Half-Lambert shading
• RimLight (make the character outline visible even in the dark)
• Fresnel term to make normalmaps details visible even without lights

...yes, Adam also got friends. Let's talk about party management the next time...

You know...I started writing a new blog post, adding some images, something else here, something there...and still was not happy of the result. I was using Wordpress and despite being a great blog software I didn't really understand all its unnecessary complexity. Every time I wrote some html code, hit save button and...all my formatting is lost forever :(

"How hard it could be? It's just a blog, not rocket science!" ...and one minute later I was starting to code this new website from scratch.

This time I choosed to try Google App Engine instead of using the usual LAMP stack. Why App engine? Well...it just works. Wolfire's blog have a very good post about it, go read it.

Everything looks good and I'm really happy with the results. In the future I'm planning to add more, like the game webplayer for the playable demo and all the related user management here... only then my need to reinvent the wheel will be satisfied ^_^

Hope you like the new graphics and layout, I'm trying to keep the website simple and clean, if you find errors or broken links please report them.

The work started last week on the minimap is finished and I spent some extra time to experiment and hack things inside Unity3d.

Here's some freshly added features:

• Minimap: semi-transparent background for the non-walkable part of the map
• Minimap: "North" icon
• Minimap: Player trail (this features should help people not very used to look through a rotating map)
• Minimap: smooth circular mask
• Footstep detection and sound
• Dynamic reverb effect based on room size or wall proximity
• Initial post-process shader
• Ambient lighting test for characters

As you can see in the video, everything static is lightmapped and only one dynamic light is used for the characters and moving elements. My goal is to allow people to play at 60FPS even on old hardware. Some of the things that are more heavy on the graphic card are shadows and dynamic lighting. Yes, shadows a dynamic lights looks cool but why not experiment with some old school technique?

So, during the creation of the walkmap now I'm also creating a texture I like to call "ambient map".

The so called "ambient map" only capture indirect lighting from the lightmaps and will be used to add some indirect lighting to all the moving objects close to the ground, including characters.

If you are interested, please subscribe and see you the next thursday for more information about it.

This week I've been working like crazy on many things and the progress really inspires me to continue this development journey. One of the thing I've been working on is a minimap component! I always get lost (even in real life) and I think is one of the most important part of the user experience in games.

When I'm playing a game I don't want to get lost and too many times I keep wandering because I had no clear map or just because I forgot where to head next.

Here's my key point to a map system:

• Easy to read: a simple and schematic map is the best, leave all the detail in the 3d view and put only important ones in the minimap.
• Enemy/friends position: the minimap shows the position of the people around you allowing an easier strategic planning during battles.

Since the level will be mostly static I choosed to preprocess the level data inside the unity editor and bake the walkmap data inside a texture.

I'm creating the walkmap (the walkable part of the map) scanning the level with a simple flood fill algorithm. Just decide a starting point and use raycast to find the ground level. Use the ray hit position and angle to decide if that position is walkable or not. You can also use the API Physics.CheckSphere for extra checks.

Ok, now I have a texture, how do I show that in the game? At first I used a simple GUI.DrawTexture to draw the walkmap to the screen but I needed more..something like zoom, scroll, rotation around character position and a circular shape. The only way I found to do that is to use a custom shader, a mask texture for the circular cutout, a script to handle some voodoo UV translation and GUI.matrix manipulation...and a headache...

Next step is to add character positions and point of interest markers. Nothing too fancy here, just some GUI.DrawTexture calls and some trigonometry.

Future enhancements in "Minimap, part 2":

• semi-transparent background for the non-walkable part of the map
• border glow inside the script (I'm tired to do that all the time inside an image editor)
• "North" icon
• Target point and direction arrow to reach that point

That's all for this week, if you liked this post be sure to subscribe, see you next thursday!

You should already know about Adam, in this video he is running inside a test scene in order to test the freshly written camera script. Thank you Adam!

I choosed to not allow the player to rotate the camera "up&down" (X axis rotation) but only "horizontally" (Y axis rotation). Some people will dislike this behavior for sure but I'm going to sacrifice some features in order to create a nice camera: too many times I got frustrated by the poor third camera movement used in games. Yeah, I know..it's not easy. My choice is to remove some direct control from the user and let the game decide, anticipating what the player will want to see. For example the camera right now is lowering the height and distance from the player when hitting walls too often. Another example of a future implementation is to correct the point of view when the player is moving thru stairs.

Current controls are:

• WASD: move the player
• right mouse button drag: rotate the camera around the player
• mouse scrool wheel: change the player-camera distance

As always..it's still not perfect and I will continue working on it. Have you any suggestion or reference to create the best camera setup ever? ;)

Adam was modeled, rigged and animated inside Blender and then seamlessy imported into Unity3d.

I made some test animations like "idle", "walk", "run" and then I used the unity3d ability to "sync" between different animations. Of course this will work only if the animations are similar (like starting a run/walk cycle always with the same foot). Once the animations are "synced" you could use the usual Animation.blend or Animation.crossfade methods to mix them using the character speed as parameter.

The result is still not perfect and there's some feet sliding but it's enough to keep the project going and for a prototype made with programmer's art.

Yes, you may have noticed I'm using a third person camera setup in the last image, see you on Thursday for more information about it.

I want to be able to move many characters using low amount of CPU cycles and still have in depth control about things like where to walk and where not (in the future a walkmap texture will be auto-generated from the level). Unfortunately the default Unity3D character controller is not very customizable in this case and so I choosed to write a custom one.

My solution is to use a simple script controlling a setup like this:

• a capsule collider component, for handling collisions with the other characters and the world
• rigidbody component
• a raycast to "sense" the ground height

The script sense the ground height every time the FixedUpdate callback is called and adjust the Y position of the character accordingly. This way I can move freely the character being sure it's always touching the floor (for simplicity's sake all the gameplay will be 2D, completely ignoring the vertical axis).

The movement part is really simple: I'm using a 2D vector (the green line in the video) to tell the character the desired direction to go and final position is computed taking in account character specific parameters like maximum speed and acceleration.

Yes, there are still some problems when falling from an high place (see the final part of the video) and some minor ones...but it's a start :D

Even if the camera is still fixed at the moment, all the movement is relative to the camera orientation making possible to implement fixed setups like the one shown in the video (useful inside a small room) and a full-featured third person camera in a near future.

That all for now, see you next time with "my first game character" post.

Gameplay

Very few things are already defined as final but I’m going to start adding features I like from other games and then rework them until they fit with the rest of the game.

The game will have a third-person style camera focused on the main character and you’ll be in a control of a party (up to 5 people) with non-customizable characters. They will have their own appearance and abilities…so no, you cannot call your character "RadioactiveBanana" and be a kick-ass mage/dwarf/whatever…no, simply let the story decide this for you, you’ll be playing a “role” in this game, right?

Exploration

While the world will not be very vast there will be many places to explore and visit. Many world areas will be available in your map but others will still need exploring and mapping.

Combat

You will be able to fight agains groups of enemies and, if you prefer, try to evade from them. There will not be “random combat” scenes (remember the old Final Fantasy games? I hate that random battle part….).

Pause is the key to combat: you can play without interruptions or you can choose to “stop the time” and think more about the battle and strategy. No more twitchy actions in RPG games please!

Dialogues

Where are all the good dialogues gone? I still remember (there were fantastic) some dialogue lines used in the old good time of adventure games. Do you? Well, the direction will be to create few people to talk with but with many topics and lines.

Craft

Still not sure about this but it will be cool to create from scratch and enhance regular items with new additions…there’s still time to decide this feature…

Quest/missions

A simple and automatic window to keep track of your in-game laundry list will be available. It’s too bad when you stop playing for a week forgetting what to do and wandering without goals..

Game engine and editor

I used to be proud of my little 3d game engine I created over the years but I must admit that even if it was good I was always working on the engine code rather than creating games.

This time I’m going to use a game engine called Unity. It’s a great application, a well organized game engine and editor with a very clean workflow. Many people complains about the renderer but, although isn’t state of art, I think is good enough to create a good game. I’m going to use it for prototyping and building all the systems needed to define the gameplay and also as a level editor (with many custom editor scripts).

Platforms

Using Unity I have a lot of possibilities about the platform to choose. However for this first game I’m going to target only the Windows and Mac OS since they are easier to develop with and test. In the future I could think about downsizing the game art and try to release to smaller and portable devices like iPhone/iPad and Android smartphones.

Controls

How can we control the game? I’m thinking about implementing two main modes:

• Keyboard and mouse
• XBox 360 gamepad

They are quite different and will require a careful planning (especially on the graphical user interface side) but they are what I will expect from a standard game.

Yes, I know. These are a lot of things to do for a “small game” uh? It’s not going to be an easy journey, see you on Thursday with the next update: "basic character movements".

First things first: why I’m doing all this?

Well, to be honest I always had a sweet spot for videogames since my childhood. In the following years I always dreamed about making a “real” game, so I studied and worked hard as a computer programmer to be able to make it. I started doing some experiments and learning a bit about every aspect of game development and eventually I quit my day job. Yes, really. This may sound crazy to someone but I think it’s the right time to start this new adventure and announce my “evil world domination plan”.

Here’s the crazy deal:

• 1 year of time: the game MUST be playable and mostly art complete by the end of this year
• solo project: I’ll be doing all this by myself (with some external help of course)
• I’ll post a project status update every week from now
• nothing too big: I’m going to create a small but fun game

That’s my evil plan, see you next Thursday!