Level Editor update, questions about early access, Kickstarter failed

As you may have heard (probably not because no one reads this anyways) my Kickstarter failed!

I had a particular roadmap planned out to reach video production gameplay goals for the Kickstarter campaign but now that the campaign has failed I have had to re-evaluate what features I need and in what particular order.

Had I been able to fund my project I would have proceeding in particular direction and had considerably more resources available to me.

Now that those resources are off the table the question at hand is given this is a single player RPG can I go to early access?

I feel that going to early access with part of my single player campaign is a fairly bad move - players will grind through that rather quickly and then be crying out for more content that is going to take a considerable amount of time for me to produce by myself.

Doing that would hypothetically result in an initial good release but would be followed by a lot of negative feedback/reviews from customers who might not be happy with my pace of updates.

User created content can far outstrip my personal ability to produce content ; but without a level editor there will be no user created content!  Given this I felt the best way to proceed forward would be to pivot my focus towards the level editor.

The first step of doing this was to tackle a task I had been putting off which is to "refactor" the level editor into a much more manageable architecture.

I had designed it on a 'as I need' basis and literally thrown functionality in anywhere I could to get things moving for the Kickstarter.

But now I need the Editor code to be solid and easy to work with in the sense of extending it and adding new features, but also in the sense of troubleshooting/debugging any issues that come up.

So I spent approximately the first 30 days after the Kickstarter refactoring all the core level editing functionality to point at the Level Loader class.

The Level Loader of course .. was meant to load saved levels in to the game.  But as you can imagine as you are editing - you are literally loading a level ... on the fly!

Previously I had "on the fly" editing being done in an Editor class, and final "in game" loading only in the Level Loader.

There was also another type of loading which was "inspector based loading" where you get into the individual details of any one grid square and change those details.  This represented a 3rd place code lived to load elements of a level.

So after refactoring all this - all loading is done in the LevelLoader now!

Having achieved this I then added several new features which I demonstrate in this video:

- ability to have an in-game preview window
- ability to toggle to a full screen gameplay mode
- ability to drag & drop monsters in to the game
- ability to toggle a skylight for ease of editing or previewing actual dungeon lighting conditions
- new create level dialogue with configurable elements
- a new player arrow icon - with a emissive texture to make it easy to see regardless of lighting conditions

Other work I did that is not shown:

- refactored the save/store/loading of levels into the local users directory structure ; this ensures users can save their levels to disk where they have permission ; it also gives a default place where I can look for levels to load that the user has created
- added ability to set custom save level names
- added loading dialogue that presents a drop down list of all levels available to load
- fixed quite a few bugs
- refactored the GUI to be more streamlined/minimalistic (more work to do here in the future)

So my next set of goals is to add even more functionality to the level editor; some of these additions should happen pretty quickly because they are just similar to functionality that I've already demonstrated here.  Other items of course are more unique and will require specific work to implement.

Thanks for reading, see you next time!

Second Level Set shaping up & various progress news

So my first post of the year comes rather late ; but I have lots of great things that have been going on!

Firstly I have been integrating a new dungeon set into the game!  I purchased this level set and I was very surprised to find something of this quality level that suited my game so well!

Here we have an example of the new level set with the Servant of Dagon meeting his end by the Cemetery Gates spell:

As you see it looks just brilliant! The materials are well done and high resolution and as you see the lighting and shadows from the spell really show off nicely against the rich texture set.

Furthermore I've been spending quite a bit of time polishing the lighting in many different respects. 

One thing I've been working on is getting the right mix of dark and light in the dungeon.  This shot shows off something close to what I want when the player has no light :

As you see the dark is truly rich and foreboding ; the player has very little ability to see outside of the given light sources and would create a good level of suspense forcing the player to stick to the lit areas in fear of what lies in the dark!

What you can't see in these stills is the work I've been doing on the lights to make them softly glow and pulse to simulate an actual fire. Each light source has 2-3 point lights that are colored and animated different giving different yellow/orange highlights and pulse/flicker at different rates as well as cast shadows that move.

All together its looking really good !  There is some difficulty of maintaining perfect lighting when swapping level sets though ; supposedly PBR materials are supposed to help solve this problem but at this time I still find it tough with my 2 level sets to get a lighting level that makes them both look absolutely perfect..

Its a tough decision that I'm putting off right now but I could hypothetically create some "per level" kind of lighting variables that get updated when you load between level sets.  This would allow me to really nail the lighting levels of course but I'm being stubborn and working with the materials and the light settings themselves right now to try and achieve that rather than resorting to this shortcut.

While there are still many other items to show off  I'm going to swap gears and discuss what's really been keeping my head down for the last month or so and that is I've been working very hard on composing my Kickstarter.

I've run into enough surprises and challenges while working on it I'm considering writing a few blog entries on those challenges.

Some areas of interest that I think might be interesting is Taxes (yeah ugly topic but very important!), Rewards & Fulfillment (slightly more exciting but risky and complex), and the Fine Art of Estimating Your Project Goal.

The actual project goal has been incredibly enlightening to me - I really always thought it was just a matter of filling in blanks on a spreadsheet but I've now done 5 different sets of spreadsheet calculations based off of different assumptions and come up with different numbers.  Each set of assumptions could be totally legitimate or completely wrong!

Anyways.. I'm unclear on who reads the posts or what interest level there would be on these kickstarter articles ; I know a lot of people see the word Kickstarter and close the page right away so please leave a note or drop me a line if your interested in such material!

QuestFlow : A Unity 3D Quest & Dialogue Editor, free?

If you've been following me at all you know I'm working on a classic dungeon crawl RPG called The Rise of Dagon and as such I have need of a quest and dialogue system in my game.

Today I would like to not bore you with the details of how I typed so diligently on my game, but rather offer up a discussion about the QuestFlow system I'm writing and that I am looking to at releasing it for free.

As such I wanted to discuss what my needs were that bring me to this decision and then discuss with you (if you are interested) in having / using this system? And if you are interested what I might need to do to make it better for you in the short, mid and long term?

If you ever get a chance to work in professional software development that uses the Agile methodologies you'll come across this thing called a "user story".  A  user story describes what the end user  expectations are about the software you are about to deliver.

When I sat down to write (or purchase) a quest system for The Rise of Dagon I realized I needed to create a user story of what my expectations were going to be otherwise I might spend some time doing the wrong things and my time is limited and valuable so .. yeah lets not waste it!

The user story I came up with was:

"I need to be able to implement a quest system that allows both myself and my game playing customer the ability to create a full quest campaign with NPCs, Quests, Dialogue's, Locations, and Rewards. 

Ideally this system needs to be able to be integrated to the actual game.

Bonus points for the ability to re-use it in my next game!"

And so I went looking for a system that I could purchase that would do this for me on the Unity Asset store, and I also went Googling for solutions as well.

What I came up with was a lot of systems that almost worked; but ultimately one big clinchers came up again and again:  my game playing customers would not be allowed to use it without them also paying!

And this is critical for me because end user modification is huge ; if your game takes off and your gamers are able to create their own content ; they will create far more content themselves than you will ever humanly be able to do!

No system that required my gamers to go buy a hundred dollar software like Articy Draft for example was going to "add value" to my game.

Rather requiring a 3rd party purchase would just put the first 3 nails in the coffin  of modding for my game as far as I'm concerned!

While I did find some assets on the Unity asset store that could have let me make my game - I could not have freely distributed them to my customers; or I would have had to do extensive work to integrate the 3rd party utility to interface through my games UI.

I came to a point where I was considering the approach of using a 3rd party dialogue system called Dialogue System by Pixel Crushers but after prototyping a quest with it and then spending 2-3 days reading documentation I came away with a feeling that they were trying too hard to please too many people with endless 3rd party support options. Ultimately the system feels bloated and integrating it in to my game would probably require creating some sort of bridge between Unity and the LUA back end scripting that they use.

If I was willing to do all that (and I was) I should also be willing to spend a few days considering a homebrew system that was written purely in Unity and C# and that wouldn't require any dancing around with endless 3rd party systems.

So this week I wrote the initial implementation of Quest Flow and realized it was going so well that this really does seem like the way to go after all.

Additionally because I have the requirement that my gamers be able to use it freely; I may need to post it on the Unity Asset store as a package (or a git repo, or an importable package included with the game etc).

Given that .. we come to my post today .. if I'm going to be posting it for free then I should probably consider opening it up even further - to you!

So if I were to do such a thing, I realize that I myself would have questions like : what license, what features, does it do this thing I want it to do?

And given that I'm trying to develop games to SELL to MAKE MONEY .. it has to be a license that won't get in my way of doing that, nor should it do so if you want to use my quest system or distribute it to your customers!

So I wanted to open a discussion about the following topics:

• What license would be most attractive for this? Currently I'm leaning towards Apache 2.0
• What features would you like to see in such software - considering at least initially it is intended to be a complete solution within Unity in C#.
• Should I in fact make this a fully open source project and post up a git repo for it and invite people to collaborate?

Obviously I'm okay with any other discussion as well but these are the ones top of my mind at the moment.

Where it is at right now:

• I have written base classes for NPCs, Locations, Quests, and Conversations
• I have written Unity Editor windows for all of the above

What do I plan on doing next?

After writing the Unity Editor windows I realize that this system really needs to work together better and I'm tempted either take a more detailed combined editor window approach that integrates all of the items together OR alternatively utilize the new Unity GUI to create a full featured Quest editor.

The advantage of using the Unity GUI to doing it is that anyone adopting the system could simply use this for themselves and their gamers by implementing it in a scene.

This second approach feels most right to me because of the end goal of user modification; but maybe I'm not thinking everything through here?

Thoughts?

Teleporters and Treasure!

This was a really nice week for productivity for me : I was able to get in teleporters and lootable treasure containers in to the Rise of Dagon.

While the lootable treasure containers did take a bit of code work because of the slightly complex nature of handling 4 different characters inventory including being able to drag & drop on portraits, in to hands, into the inventory, and into the equipment area where your traditional 'paper doll' for all your armor and such that has very specific slot requirements - yes despite that mouthful - it was only about 3-4 hours of work to get it in as I was able to copy patterns I had in for the rest of the inventory.

Also I was able to optimize/refactor a little bit of inventory code to be better while I was in there so it was a double win!

The teleporter was  pretty easy --  it literally took more time to make the particle effects than the code!  Its really nice when features that you worry about ahead of time end up being much less painful to implement than you had feared!  (either that or I'm slowly getting better at this but I don't realize it?)

I still need to integrate teleporters in to the level editor but I should be able to get that done by the end of the weekend!

That's it for this update - see you next time!

What should I name this spell?

What should I name this spell?

I thought I would reach out and ask for some audience participation / help on naming this spell I'm working on today!

Spell Effect Description:

This spell is an "in progress" work from the Dark Affinity school of spells (black/dark/evil style magic).

The spell idea is to have a group of skeletal hands rise from under the target and attack it.

The red cloud is just for atmosphere and ambience .. the Skeletal Warrior pictured standing in the cloud in this case just happens to be the monster I caught in it for this screenshot - he is not actually part of the spell effect!

My initial name idea was "Army of Darkness" as a tribute/easter egg to the film of the same name but I'm worried that I might run in to trademark or copyright issues if I do that?

So .. now taking ideas for a cool spell name!

Terms & Conditions:

By submitting a spell name you hereby grant me rights to use it royalty free in my game.

Bonus

No promises.. but I hope to take your name/handle down (if you want) and include it in a portions of the credits, I'm already planning on doing a kickstarter and having some of the stretch goals include user design contributions so this is something I want to do anyways!

Good luck and thanks for the ideas!

edit: Updated image -- particles are more 'bloody' red less 'pink' lol.

How I implemented my first spell in to my Unity based RPG

Today I'm going to do something I haven't done before: attempt to share my complete implementation of a feature (my Spell system) in my Rise of Dagon RPG (made in Unity 3D) including some source code!

I know of course I'm no bloody genius and my code hasn't any unique ideas in it - in fact if your a particularly great coder you can probably spot some things I've done poorly.  (hey if so drop me a note - I'd love to make improvements!)

But also I hope that a few people might find it interesting - maybe you haven't gotten in to the new Unity UI, maybe you are just starting out on an RPG and seeing how someone else went about it will help you think your way through yours?

Maybe my game's code is a train wreck - and this will be a great laugh for you?  Perhaps a great example of what not to do?

As I'm attempting to share the complete implementation - this is going to be long! So hey if your the TLDR type; pan through the screenshots and bail now!

Otherwise .. here we go!

Deeper dungeons! Oh my!

This shot points out the three levels, the wall texture makes them blend together a bit.

I've been working on the dungeon editor this past week for Rise of Dagon  ,and while the level format has always supported dungeons of multiple level depth its only been recently that I've added that support properly in to the editor as well as the player movement behaviors so you could actually go from one level to the other.

That's quite a nasty drop off to the left, don't look down!

At this time all you can do is fall down to a lower level, I have not yet implemented stairs or ladders (not sure I will actually do ladders..) but I have a prototype stair in progress and hope to have that in fairly soon.

Next up I have been continuously working on my character portraits in Mudbox and Photoshop. I've found that creating a bust sculpt of a character in Mudbox, then using the Mudbox painting tools to give the character some skin tones and color the hair in works very nicely.  Then I take a screenshot and do some post effects, add in a backdrop, and a little retouching in Photoshop.  This has been working out for me pretty well and I've put a lot of practice in to that process; and it looks like it starting to pay off to me!

Here is the 3 main steps that produce a portrait.

I'm certainly not going to win any fantasy artist awards but I am getting to the point where I'm starting to actually like the way the output looks!

Thanks for reading, see you next time!

Notch invests in The Rise of Dagon development...

So before we get any further, the topic here is a spoof.  Notch has not invested in The Rise of Dagon and I have no expectation that he is even aware I exist.

But I saw a tweet from Notch here and it really stirred up a huge amount of unexpected thoughts in me that I wanted to share today.

Notch (in real life known as Markus Persson) is one of the founders of Minecraft , and sold his share in the company recently to Microsoft for a hefty $2.5 billion dollars.

After recovering from shock at both the raw number and the fact that he sold and exited the company he helped create - naturally many hopeful indie developers probably have  had a fleeting thought that Notch could be a really powerful Angel Investor / Philanthropist in the indie community and seed some incredible indie projects around the world with much needed funding - potentially causing a game production revolution single handedly.

There are all sorts of projects on Kickstarter that want small amounts like $20,000, $50,000 and so on. Notch could pick one project a month under $100,000 and be funding projects for the next 10,000+ months if he reserved 1 Billion for his philanthropist efforts right?

Sounds great, lets get to work!

But then I stopped and really thought about it.  I mean really think about it.

What if he did invest in my project .. does he get a say in my development now?

Maybe I would be willing to to have him as an executive producer for the cash influx? But what would you have to trade for an investor?

Are you really just expecting an investor to throw you a bucket of cash and say "I truly don't care what you do with my money, buy a truck of bacon for all I care?".

But I thought I was an indie? All of a sudden I'm really willing to surrender some portion of my vision - this thing I've been telling everyone else (never mind myself) that I believe in so much!! SO freaking much!

But no apparently all it takes is Markus Persson walking up with $55,000.00 and all of a sudden I'm throwing shit out the window like I don't give a damn about my game just to make him happy?

I thought this is the entire reason I'm an indie so I can do it my way?

I'm not going AAA for a reason.

I'm not looking for a publisher for a reason!

I'm not looking to sell out to make a quick buck for a reason!

Because if I was I wouldn't be slaving over this blog for a year to build a community, and grinding architecture out late at night after I get off work from my day job and after I put my kid to bed would I?

I mean its  hard, its damn hard. But am I being honest with myself if I take this kind of money??

If your going to sell out - then don't ask Notch to be your enabler. Just sell out. Go get some AAA or hell .. these days in the mobile market I'd call most of these mobile studios single A studios - go get paid. Stop bellyaching.

And then there's this other thing that hit me - that made me write this.

Get this .. if Notch did invest in my project (or yours) then all of a sudden everyone would know (because of course you would proudly tell everyone someone so awesome as Notch invested in you right??)

So now .. everyone is looking at your project all of a sudden.  Everyone is wondering to themselves "What is so cool about this project that I missed - it's got to be there, Notch saw it!"

And everything will change; just because he invested.  Even if it was some small amount like $5000.00 dollars.

$5000.00 won't make a dent in my project; but the press attention, the community exposure, the freaking twitter storm?  You can't buy that kind of exposure!

So now - the world has changed ; you are on the map now man! All because Markus threw you a 5k drop in the bucket.

But every time someone sees your tweet - its in the back of their head and they are going to pay you one more notch of attention (no pun intended :-).

And when your game finally ships - you know all the news sites are going to mention that this is the game that Notch invested in right?

And lets say (for fantasy or arguments sake - take your pic) that your game ships and is a financial success.

When you sit back afterwards and the a euphoria has worn off  are you going to pat yourself on the back and tell yourself how right you were all along?  How your game's vision was just so awesome that it was destined to succeed no matter what? How great of a designer you are?

Or maybe, just maybe might you start to wonder - what would have happened if Notch never did invest?

Would anyone have ever noticed you?

This is your chance of getting noticed in the mobile market place today

Would anyone care about your project?

And to me that's heavy shit. I've dreamed of making this RPG for a long time.  But if I had to attribute all of its success to someone else's fame and investment rather than my effort, my design, my dream - to me that would be a bitter pill to swallow and I sure as hell wouldn't be patting myself on the back.

So in the end that little dream many of us have of someone swooping in and solving all of our financial woes when it comes to production doesn't feel as sweet to me as it sounds.

Finally  I admit even with doubts I am expressing here;  I can not dismiss the possibility of investors or crowd funding or other sources of income to supplement my development are interesting and would need to be carefully considered for their reward vs their impact on the project.

I (like many of you) wish I could have a self sustaining business and do this for the rest of my life - as I've been doing on the side for 20 full years.

But Notch buying my success with his personal gravitas is no recipe for sustainability. It doesn't make my studio in to a gold minting machine.

What happens when he doesn't invest in my next game?  Then, all of a sudden, I'm getting 1/4 of the sales and attention? Does my studio go out of business?

As indie's we have to find our way to sustainability, usually on our own.

And so I close with some thoughts and advice:

Do not dwell in despair over another person's success, even if it seems outrageous.

Do not overwhelm your daily sense of wonder and joy in creating games in jealousy over Markus's billions.

Do live in the moment, find joy in creativity, hope for wonderful things, and put a little bit of your heart in your game every day.

When you finally finish I hope you find a sense of satisfaction and a job well done, perhaps a few moments of truly uplifting euphoria - the kind that money can't buy.

Walk the path you've chosen without hope or despair, just simply enjoy the journey, sometimes that's all you get.

Mudbox Painting Tutorial on Servant of Dagon model

Hello,

To follow up on the set of tutorials I've been doing the past week I am doing a diffuse painting tutorial using Mudbox 3D today using my Servant of Dagon model.

I go over some basic painting tools, how to approach using reference, and paint a new texture from start to finish in an exploratory fashion

Modelling process tutorial - Servant of Dagon

Hello!

I had a special update today, a fellow indie developer messaged me with questions about my creative process on the Servant of Dagon model I shared this past weekend.

So in interest of sharing with the community I took the time to document the process and I did some screen grabs and annotated them with comments to create a sort of "process tutorial" on the model.

A process tutorial is basically means it shows how I went about creating the model as logical steps; rather than being a "how do I operate the mechanics of modelling program X" approach.

I know that when I was learning a lot of this I had to do it by myself and its really hard to find a tutor or mentor on these topics so I hope these grabs shed some light on the creative process.

Please feel free to ask questions I'll try to follow up with comments, additional grabs or write ups as needed.

I've put a few pro-tips on a lot of these shots, if you have some insights or pro tips of your own you'd like to share please leave a comment below!

Step 1: Create a low poly base model, typically using box modelling techniques. If available recycle old models you have as a starting point!

Step 2: In my example I have recycled a chest from a human model that I created in the past, here I am stitching that chest together with the newly modeled tail and head piece I created for the Servant of Dagon.

Step 3:  Use the mirroring technique so that you only have to create 'half' of a model.  This saves immense amount of time. If you need non-symmetrical parts add those after you have mirrored your model over.

Step 4: Here I show the marking of UV seams as a step towards doing the UV mapping.  Try to make the seams in places that will be out of the players line of sight, or in areas they are less likely to view often.

Step 5 :  Create the actual UV maps.  UV map creation can be very time consuming and complex (especially as a beginner) make sure to watch SEVERAL application specific tutorials until you are reasonably sure you have found what appears to be the easiest method applicable to your application.  In my case LSCM unwrapping automatically unwraps the model in a very satisfactory way at the press of a single menu option.

Step 6: Further adjust UV maps as needed.  Even if your application does a brilliant job you may want to either adjust the map for maximum coverage on the canvas (blank space is a waste of canvas that could be adding detail to your model!) or arrange as I did in this example so that I have room for some accessories I plan to add to the model in the near future.

Step 7: Import in to a sculpting app (Zbrush, Mudbox, Blender etc) and sculpt large details first at low subdivision levels

Step 8: Sculpt the more fine details at higher subdivision levels. Focus your time in high visibility areas like the face or areas the player will see most often.

Step 9: Paint the model.  Ideally these days you would be painting in an advanced 3D painter program like Mudbox, Substance Painter or others ; but if needed export the UV map and paint in Photoshop or GIMP.

Step 10: Get him in game!  Obviously the end goal is to get our new model in game!

Let me know how you liked this tutorial and if the process approach was good/bad for you!

3 Year Indie Retrospective

A swipe side-by-side comparison between a year 1 game and a year 3 of mine.

Roughly four years ago in mid 2011 ago I was working in a call center working as a tech support agent and due to some office politics (a manager got mad at one of my co-workers) and a bit of bad judgement on my part (we were both using foul language in a private chat to each other ) I was called in to an office and given my “final written notice” that if I did even one more thing wrong I would be fired immediately.  This happened in the great Wall Street induced depression of 2008 and jobs were scarce to come by (still are)!

I was terrified.

Rise of Dagon: Procedural Loot System coming together

A couple of days after last week's update where I mentioned I have been working on my inventory system for 6 weeks it struck me that was a little disingenuous because I have in fact been working on the inventory for that time but I've also been working on my procedural loot system at the same time!

So I have not tracked the specific time I spent on either one; they integrate to tightly its often been at the same time but effectively you could say I've been working on each of them for about 3 weeks.

This week I was able to really take the procedural loot to the next level by adding in the loot Prefix and Suffix type to weapons and armor!

So I have a cool screenshot of some randomly generated items  to share to show off how that is coming along

So what's not immediately apparent in these weapons is all the components that go in to making the items..

Each item has a "MagicProperty" component which can provide a "prefix" power, and a "suffix" power.

So depending on what Prefix or Suffix your item has it has a name that goes along with it. 

So a "Leeching" prefixed item is actually a vampiric property that helps heal you when you damage an enemy with it.

A Suffix of "Darkness" would give extra bonus to your Darkness Affinity - and as discussed previously any bonus to your Affinity Powers will have multiple ramifications. Stacking desired affinity powers for character builds will be a major source of building a powerful character.

Some properties provide stat bonuses, others will provide a spell like effect on attack and so forth.

The properties can also be blank of course meaning they convey no bonus in that case but that's not as quite fun to show off!

So the title of the weapon or equipment item reflects the Prefix/Suffix of the MagicProperty and this is the only way the player currently knows that the item contains some additional powers to those that are listed on the inspector itself.

So below that of course is the normalized Attribute (stats) that an item might have bonuses to your Strength, Dexterity or other attributes.

I created a system where the item can have from 1-5 of these bonuses but currently since I'm designing for the low level end of the game only 1-3 can actually show up.

Furthermore I hope to fine tune it so that if you kill an elite or boss monster you will be much more likely to get an item with better range and value of Attribute bonuses on it as a reward.

So that's it for this week - the procedural loot system is in very solid shape right now it just needs polish and some iterations to make more variety and interesting combinations come out so that the loot will seem interesting and varied.

Thanks for reading,see you next week!

Rise of Dagon: Dec 27 2014

This week I mainly focused on a process to create inventory armor icons for the players. I was able to previously purchase some weapon icons but I have as of yet not been able to get a good resource for the armor sets.

So I was able to work out a process that got a little faster as I went along which is really important if I'm going to create a bunch of icons by myself it can't take a really long time or the game will take too long!

So the chest armor took the longest being about two evenings to get it where I liked it.  The pants took a day. And then I was able to get the boots and gloves done in one day.

What I hope to do now that I've been through those pieces is to use the low poly version to sculpt additional armor variants very quickly speeding up the process even further.

I realize these are not incredible sculpt's that would look great in Thief game or something but they come out as armor icons very nicely.

Otherwise as time permitted I focused on some troubleshooting I had been putting off.  Previously I had to manually hit a 'load level' button once the main scene loaded ; given some of the changes I made this week now the level initializes on its own when you either start a new game or hit continue.

- Got automatic level loading in; previously you had to click a 'load level' in to the game once the game started
- You can now swap between different character inventories without having to go out of the inventory and back in
- added GUI "X" icon to close out inventory
- added supporting code for X icon to close out inventory

I also made some improvements to the inventory code to support swapping in between characters.

This next week I will probably work further on some armor icons and inventory code.

Thanks for reading, hope you had a nice holiday and a happy new year!

LD31 - Menus / Title

So my #LD31 is coming together with polish this afternoon.

I have gotten in a sound track and a couple of basic sounds.

I have also been working on all the menus - most of those are done except for the game over win/lose condition screens have to be polished with text / info.

So the title of my game is DEATH POLICE 3000 which is a satire based on the current social issues in the USA ... shooting of unarmed civilians by our police force most frequently black males but also homeless and mentally ill men are targeted as well, and combined with the old movie Death Race 2000 where sport was made of killing people.

Obviously in a limited time span of 48 hours I can't really go in to depth here so the satire is pretty blunt.

Rise of Dagon : Nov 29th 2014

As promised after a week break I have returned with an update.

I was hoping to have been moved the previous week but unfortunately the place I was going to was not ready yet. So that is still at some point in the future for me.

One of the big things that happened was the Unity 5 beta 14 release.  I updated to this release and it made a gigantic difference on the look of the levels to the point where everything looked like it was made out of super-shiny metal!

So I had to refactor a lot of the shader settings and found that they had swapped the default Unity 5 material from 'specular' model to 'metallic' model.

I believe they also massively ramped up the specular levels of everything in general. So you'll find that the screenshots look different due to tweaks I made; however I can't say this is the final look & feel because I expect things to change again as the beta isn't over yet!

Unity 5 Beta aside I've been focusing on some polishing to the core game loop.

The core game loop is in .. in case I hadn't said that before!

So the core game loop being in is great but it was missing a little bit of polish that made some of those things not so easy to see to the player.  For instance if a player had died, the only way for you to know that previously was the red health bar looked 'empty'  , which it could also look pretty darn empty if you had only 1 health left for example.

So I now have a skull replace the player portrait when they are dead to let you actually know that particular character is dead.

Also there are now damage blood splashes on the character portraits, with the amount of damage you have received

Over the next week I plan to add more polishing bits as I mentioned above that provide feedback about what is going on to the player and improve the game play in general.

So now I'm going to be tightening the core game play loop and try to get game play to that really tight and fun spot that it needs to be at.  This is a really exciting point to be at for the project, but there's still lots of work to do that is not part of the core game loop.

So for the past two weeks we have the changelist:

• first pass character portraits added to GUI
• animated damage splash on character portraits
• animated damage number indicator on character portraits
• monsters now face player when attacking at all angles
• migrated from legacy animation to mechanim system
• added monster attack animations
• added monster death animations
• added monster miss animations
• end game condition for party death added
• skull portrait for dead character condition added
• end game condition for party victory added
• first pass end game menu added

Thanks for reading, see you next week.

The Rise of Dagon: Week of August 9th 2014

As mentioned in last week's update I had been doing some cleanup from designing the logic for levels so that I could finally tie together a level's logic with its physical attributes.

The first thing I decided to go with was to tie the players movement to the physical aspect of the level. What you did not realize previously (because I never showed it) was that if you attempted to move through a wall -- well you would move through the wall!

I was always careful in my video's to not move through walls -- simply because it would be odd for the viewer to understand what exactly was going on if I had done that!

Tying the logic to the physical structure was actually a two part task:

1. When actually constructing the level from prefabs make sure to mark the appropriate data so the player can actually use it.
2. Create code for when the player attempts to move to check the square that is the destination to see if it can be moved to and allow/disallow as appropriate.

To do this I decided to pick up a bit of code I had used before to create a dungeon room out of prefabs.  For each type of prefab I made a method that not only lays down the appropriate type of floor, ceiling, and walls but it also tells the "logicChunksArray" if it is passable by the player, and if each wall is playerapassable or not for instance.

So as I did that in steps I have a little in-progress screenshot here showing that I had the outer walls, but no corners, or center squares yet:

 This went fairly well but it was a little bit messy and I now have a method for each type of  grid you can have like so:

When you look at all of these combined they call out to be refactored as there is a lot of similar code going on but right now I was just happy to get it working!

Eventually what really needs to happen instead of having methods like this to construct very particular types of a square grid is I need to have an actual level format that just constructs exactly what needs to be in each square but for now this was a fairly quick and dirty implementation that takes me another step towards reaching functionality goals that I have.

This coming week I intend to continue working on logic related tasks -- I haven't actually decided what specific sub-task I'm going to tackle yet honestly I just finished up this work last night that I'm showing off today and need to pick through what looks like the most attainable bit of work I can take on for the coming week.

See you next week!

The Rise of Dagon: Weekly update August 2, 2014

Greetings!

This week's update is progress on the level format, level logic and the inevitable collision of the two.

As previously mentioned I've made preliminary efforts at laying down levels in code which worked out quite well.

I also mentioned working on level logic ; the bit that ties the things you can see, to what you are allowed to do.

Those items are coming very close to meeting in the middle now however I found that I actually had quite a bit of a mess as I had been slapping things together in a way that was taken from the 'just get things working' angle and now that it was time to stitch them together it was just obviously a bit too messy to work with.

I don't believe in over-optimizing at the beginning but I also know a mess when I see it! So I spent a good bit of time this week condensing the code from about 10 classes in to 3-4 classes and eliminating several class members from the primary logical class as they ended up being redundant as I saw how things were cleaning up.

Here's a quick screenshot of a mostly optimized  bit of logic inserted in to an array:

I was in fact still working on it, I had some public variables that ended up private later and the getter/setter properties are all that you can see for most of them now when you inspect it.

So starting Friday I have been doing testing where I use my current level code to insert a bit of the logic, and then I have a gameobject that I click on that prints out in a debug statement if the logic matches what it should be.  

The tests have gone well so this coming week I will begin integrating the level construction  with the level logic!

This task is complex enough I expect it to take more than a week, and I am very much wondering if its time to write a first pass file format for this or not? I would prefer to wait longer because I'm sure the format is going to change as I explore more .. but at some point I'm just going to need it! In any case I'm attempting to delay that decision until it becomes clear that its needed to proceed.

Thanks for reading, see you next week!

The Rise of Dagon: Week of 7/12/14

This week was a nice recovery from the previous week where I was blocked for almost the full week with a Unity 3D / Monodevelop bug where breakpoints did not work.

Thankfully +Carl Pinder had the winning reply which solved the problem:

"This is going to sound like a superstitious practice, but it does work. 1) Add some garbage text to your file, e.g. "asdasdasd". 2) Save the file and switch to Unity. 3) Unity will promptly error the compilation of your code. 4) Undo the garbage text and save. 4) Switch to Unity and breakpoints will magically work again."

So here's a big 'thank you' to +Carl Pinder !  It's great when a community can help get you through things like this.

So afterwards I was able to take another step forward linking the prefab logic with the game logic layer and we have here a screenshot demonstrating the properties of the wall being passable or not in the debug output:

Also I'm going to provide a zoom in detail image; another feature I started on is a baseline character and class system to go along with the UI elements I have previously shown.

At this time I'm hard coding a Warrior, Mage, Rogue, and Healer. 

(While I'm sure we'll have some variant of these classes in the final game the names may change.)

So if you check the detail you can see that I've instantiated each of the 4 GUI HUD bars to one of the 4 classes and printed at text object above it to show which class it is for now.

Eventually I'll make it so mana bar's dont show for non-magic using classes as well as other tweaks so that your HUD bar for each character has some custom elements that are needed for the repsective class. For instance I'm really interested in improving the way that caster classes interface in these kind of games!

Finally after having gotten the above two things done I spent some time refactoring some of the Level Logic to make it better organized and maybe a little bit more performant (especially for the way Unity / C# work).

Unfortunately I ran in to a snag, I was trying to add some items to  List which is part of the collections available in C# but it didn't appear to be working. Furthermore as I attempted to type "List" the intellisense (or whatever the autocompletion feature is called in Monodevelop) kicked in and tried to tell me I should use an IList or a ArrayList.   

The snag ended up being that I trusted Monodevelop that this was actually right ; that those were the collections that were available in Unity 3D and that I couldn't actually use a List!

So I continued trying to implement my feature; not having it work and having other minor issues I left it overnight and the next day was relating my experience to one of my co-workers who immediately perked up and said "OH YEAH!" That happened to me too!

Then he related "You just have to add 'using System.Collections.Generic' to do that!".

Then we both proceeded to be very dissatisfied as learners of Unity 3D how Monodevelop doesn't do the same thing that Visual Studio or Eclipse IDE's can do!

Now of course I know better; but as someone who is learning having a Intellisense style feature that helps you bring in the proper imports and check your syntax (properly) is really useful to lowering your learning curve.  Obviously it cost me one evening of grief to get over that -- but even knowing it is there I'm sure I will have a little bit more learning curve ahead of me now that I know Monodevelop does not have my back here!

That's it for this week. Thanks for reading!

The Rise of Dagon: Week of 6/28 Update

This update encompasses the weeks of 6/28 and 6/21 due to the previous week I skipped my update because my day job required overtime work.  We shipped a major version release and I had to work extra to help ship the release -- including the full weekend!

I did get a few small things done during that previous week but felt it would be better to combine that smaller amount of work in with this weeks update for a nicer full update.

So the first thing I did was work on Substance related textures for the level design aspect of the game.

I was able figure out run-time controls for the Substance textures! This is a super cool feature where  in the level editor you can change the appearance of the level's textures depending on the parameters I expose in the substance designer.

Things like the color, the specular level, the tiling of the x/y of the texture, or even more interesting effects like the 'dirt' level of the texture.

In this short video I am demoing a toggle button of the dirt level of the texture; toggling between a 'clean' texture and a 'dirty' texture as one potential parameter as well as the new dialogue system (discussed further below).

The Rise of Dagon : Week of June 14 Update

This week was mostly about work on the level file format for the game.

I've had it in the back of my mind since starting the game how I might like to have the level format look like.

However once the actual form of the prefabs started taking place plans had to change just a bit ; I knew this would happen of course so its the reason I did a fair bit of exploratory work on the prefabs before attempting to begin work in earnest on the level format.

First thing was to sketch out in my handy (physical) notepad several ideas.

What was interesting is that putting it down on paper made it much more concrete about which items were going to be important for the level format.

This picture was the first sketch which looks a little interesting but wasn't what I went with:

In the end I was able to create a first pass level format and lay out some level details in much more particular than the larger prefabs I had been working with previously.  This is actually quite a good thing as it will permit the level format to have much more varied content.  

My previous efforts would have had all the corner pieces always exactly the same (just rotated).  Now I can have a corner that has a shelf on one wall or a  cracked wall on one side and a normal wall on the other side. The extra level of detail will help keep the levels from feeling too static!

Next up I did a fair bit of work throughout the week on the lighting and some shader work to go along with it.