next »

[FuzzySlippers]

I'll be interested to watch your progress. I've been working on a dungeon crawler in Unity for a couple of months myself. I'm committed to sticking with Unity for this project as while the project is new I have years of Unity code base work I'd hate to abandon. However I'm definitely going to take a close look at UE4 after this one.

Despite the problems you encountered with blueprints I think UE4 has a lot more consistent behavior as many of Unity's systems are no where near as robust as they seem on the surface. With the particle system, for example, you can find a lot of places where it behaves bizarrely and you have little code access to its internals to run your own tests. I also have a lot more confidence in Epic's ability to quickly fix bugs and improve their product compared to Unity's often glacial pace.

From the surface UE4 does seem to be a slower workflow for a single developer so that seems like a pretty significant concern though. Unity also seems to be improving some of their long standing problems now that Epic is competing more fiercely with them. So with Epic moving so quickly and Unity beginning to respond it is difficult to know where either engine will be in a year. Good luck with your project!

[erebusman]

@bleezy ; I totally agree. It's a great game with close to 0 replayability.  Their map editor gave it some post life but when you look at games like Diablo that had some static plot but also procedural dungeons, loot, and monster generation .. man I played that so many times I can't count it.

@FuzzySlippers ; I have to agree with you on UE4 vs Unity ; Every day I teeter between wanting to choose UE4 for its better quality / higher power engine or Unity for a lot of the hand holding it does to make my life as a single developer easier.

UE4's tools are really very excellent.  I was surprised to hit a non-working blueprint so quickly honestly.

I have one other big concern on UE4 that I didn't bring up and that is the asset pipeline they recently changed to FBX 2014 format and I am pretty much stuck with using Blender for the midterm.   Blender uses FBX 2010?  I could have that wrong but in any case I know they weren't up to 2013, and they sure wont be up to 2014 any time soon. 

So I'm really concerned about having asset import problems particuarly on the animation side.

[eyeliner]

I like it you don't opt right out of the bat for random dungeons. One of the things I like is mapping a dungeon and then replay it by time-speeding or any other challenge I feel inclined (no items, specific gear, etc), which is impossible in procedural content.

Also, in level creating, you made exactly what I was doing with my game once. Making the level by code, using specific chunks at predeterminate coordinates. I found it makes a great way to save space, and adds the possibility of allowing for user content easily.

Good job all around!

[FuzzySlippers]

I found Blender's animation workflow pretty terrible so I'd be surprised if you stick with it in the long run anyway but maybe you'll grok it better than I did.

Procedural loot seems an easy choice as most people seem to like Diablo style loot. Procedural vs hand placed dungeons has been something I've been dithering on though. I have never encountered a procedural dungeon near as engaging as the best M&M or Wizardry dungeons but procedural can be exciting for the feeling of plunging into the unknown on every attempt. Currently I've got a system of placing together interlocking hand crafted sections randomly to try for a bit of variety but still feel less random but I haven't enough content in yet to test whether it feels right in actual gameplay.

[erebusman]

This week was very diverse week for productivity! I have updates on Interface GUI , Character Models, and a first pass on my Level Editor to share.

First up we have a wizard base model.  There are actually a couple of wizard like character that will appear (friendly and otherwise).  The very first plot based NPC is a wizard in fact so I wanted to get a base model started early on.

So at this point I could branch out and make different hoods (or no hood) different sleeves, and robe tassels or other features that would result in a fair amount of end variety. Also the texturing and faces could be potentially swapped out for more variety if it looks too similar.



 Next up we have the first pass at the player interface for the GUI.  The player bars traditionally have a player portrait and slots for  your left and right hand with status bars for health and mana.

Since I'm working towards the first prototype I went with the baseline elements for the first pass. I would like to add more interface elements eventually but some of that needs to come once more features are fleshed out.



 

Also I should mention I'm waiting on the Unity 4.6/5.0 update for the new UI before doing any serious UI work.  But I'm in fairly dire need for level editing features right now so I made a really early prototype for level editing this week also to make sure I was going to be able to do this inside of Unity.

The screenshot is actually a tiny bit misleading .. all you can do is place corner pieces right now .. the 4 other pieces you see in the bottom left were already in the scene!   Also none of the buttons on the right bar do anything yet either. I'll need to program in those features for placing down different prefabs based on which icon you selected this coming week.

Also I need to put in a grid system so everything snaps to a particular grid .. right now its just free form click anywhere style.   That sounds flexible but with grid-based movement that is planned the prefabs need to be exactly placed!



That's it for this week, see you next time!

[erebusman]

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.

I am very interested in having the physical based lighting model coming in Unity 5 but since I don't know how long that is going to take or even if I might be able to afford it or not I am trying to make things look as good as I can for now.

Firstly I used the torch that I made a couple of weeks ago and changed it from the old torch seen on the left with a standard diffuse + normal texture shader to a new emissive shader.  As you can see the area of the torch that would have the fire on appears to be red-hot as if its glowing! 

This effect of course makes the torch look much better (there are screenshots where it shows the pure black on the left and it looked bad).

Also I'll be using emissive shaders on other things (spells, glowing monster eyes etc) throughout the game so it was important to be able to get this working.
 


Finally I did some further tweaking to the lighting model I'm using which is to add HDR lighting to the camera.  What's interesting is then I added a tone mapping correction and played with all the options until I found that I was in fact able to get a much nicer tonal range if you compare the screenshot below you'll see that the new HDR lighting actually shows a better range of color in the near and far areas -- while still maintaining a rich dark (close to black) color where there is no lighting.

The image on the right however is much darker overall and the level just looks too darn dark even though you have a torch!

So these lighting changes really effect the atmosphere dramatically and I'm very happy with them!
 


Thanks for reading, see you next week!

[tieTYT]

Love those games, and I really want to see more of them. You nailed it when you refer that the genre has mostly been abandoned.

Hope to see this released.

I'm new here so I don't know if this is poor form to slightly detract by asking this but here goes...

I looked at screenshots of those games.  Although I agree those genres have mostly been abandoned, would it be correct to say Legend of Grimrock is a modern version?  Or, is that game somehow different?  I've never played any of the games mentioned in this post and only looked at their screenshots.

[erebusman]

Love those games, and I really want to see more of them. You nailed it when you refer that the genre has mostly been abandoned.

Hope to see this released.

I'm new here so I don't know if this is poor form to slightly detract by asking this but here goes...

I looked at screenshots of those games.  Although I agree those genres have mostly been abandoned, would it be correct to say Legend of Grimrock is a modern version?  Or, is that game somehow different?  I've never played any of the games mentioned in this post and only looked at their screenshots.

@tieTYT

I'd say yes Legend of Grimrock is a modern version ; most particularly they modernized the art.

What they did not modernize was the gameplay.. they stayed very core/basic with the game play.

I'm hoping to keep the core strategic grid based movement and dungeon crawl feel of the game play but modernize other elements.

Every time you play Legend of Grimrock you can find the same weapon, in the same place, on the same level every time.

That's called 'static' content.

The first time you play through its fun ; but if you want to play again .. well now its not as fun is it? Because you've seen everything there is to see already.

I will definitely have procedural loot in this game ; meaning you may find a weapon on that ledge but it could be a  Vampiric Dagger of Frostbite or an Ogre's Club of Stunning.

Another item I hope to include is procedural monsters ; I haven't fully fleshed out how I will implement this but a basic example might be that you are on a level that has Skeletons ... well the first skeleton might be a skeletal archer, the next one might be a skeletal warrior, and so forth.  Finally you come to a 'mini boss' room near the end of the level that is important to the plot -- again we get procedural monster but this one is an elite skeletal mage.

So these two examples are ways I hope to modernize the game; you can play it more than once and have different results.

Thanks for the question!

[eyeliner]

The image on the right however is much darker overall and the level just looks too darn dark even though you have a torch!

I like it like this.

So these lighting changes really effect the atmosphere dramatically and I'm very happy with them!
 


Thanks for reading, see you next week!

I prefer the right one. The lighting seems more accurate, because in the left image, you have way too much light coming from a non lit area.

You'd be surprised at how little light you get with a torch in the dark.

[erebusman]

Hello - just a brief update. 

My work had a major software release pending this week and we did overtime this weekend and I was not able to do my weekly update.  I did get some things done -- however it makes more sense to put it with next weeks update.

See you then!

[erebusman]

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).







So what's super cool about this is that the textures in the game can have a lot more variety to them than you might otherwise get in a game with very little additional design time needed.

Next update item is the level format logic was created this week.

This is a first pass and things will definitely change over time but in this screenshot we have a sample of  the level objects in both their physical and logic attached within the prefab object that is created at runtime:




In the screenshot you'll see the prefab is expanded and I've clicked on the "northWallLogic" object inside the prefab.  Farther to the right is the current boolean logic that I've decided to start with.

This is the initial prototype items that seemed to make sense to me; but I reserve the right to add or remove items as needed!

You won't actually need to worry about this when your doing a level -- you place a wall down and the logic will be attached to the wall.

Finally for work done in this update we have the new dialogue system!

Initially I planned on doing a very simple hard coded quest dialogue for the prototype -- it is a prototype after all however I was able to pick up the  "Dialogue System" for Unity asset on sale; so i figured I would go ahead and give that a try for the prototype.

After exploring its features a bit I'm actually pretty impressed and have myself wondering if this might actually be robust enough to use for the full game.

So here we have a quick screenshot showing off a dialogue that I mapped out using the Dialogue System:




As you can see in the shot the Dialogue System supports a graph system for mapping out the conversations.. it also actually supports another style of editing a conversation called "Outline" mode but I don't find that quite as intuitive myself.   I should also mention that this Dialogue System also supports a lot of 3rd party external dialogue systems -- but those require additional learning curves and expenses so I don't see myself using those at this point -- but it could be a nice reason to use it if you were already bought in to one of those external systems.

So the final screenshot is a placeholder NPC model where I was testing out the conversation that you see mapped above.



This is demoed in the video earlier in the post as well if you want to see it in action!

Thanks for reading, see you next time!

[erebusman]

A fairly minor update due to the 4th of July US holiday and my house hunting - I'll refer you to my blog if you care to read but it basically complains of being blocked due to Unity issues:

http://punchypuncherton.blogspot.com/2014/07/the-rise-of-dagon-week-of-july-5th-aka.html

[mft-dev]

Following. I really like the detail of your posts, thanks for tipping me off to Substance Designer - that program is exactly what I've been needing.

[erebusman]

Thanks mft, glad that was useful/informative about Substance designer!

[erebusman]

Hello,

I apologize I forgot to cross post the update from my blog on here last week  so this is a few days late!

If anyone is interested your always welcome to check the blog directly http://punchypuncherton.blogspot.com

So for this weeks update we have have some comments that refer to a g+ user; and on my Blogger blog that links in with the user name but here it wont make as much sense -- so again if needed or care to check the blog for those links.

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!

[erebusman]

Greetings folks, hope you had a great week!

This week I focused on trying to get combat in for just one enemy and one player.  Eventually of course I'll have to handle the 4 players and as many enemies that might be able to be in the immediate vicinity around you - but I like to take things one step at a time to avoid over-confusing myself.

I created a basic enum for player and monster states in the behavior classes for the player and in this case the melee skeleton we'll be testing and then made sure that they were able to pass back and forth some variables to let each other know its the other ones turn.

I also created a really simple messaging system to print out on the screen some basic info about the combat as for now I didn't want to get into programming out the buttons dimming when its on cool down , and then worrying about a global cooldown timer and such.

Right now its purely turn based. You go, monster goes, you go monster goes -- until someone is dead.

And here's a quick video to show it off:






Speaking of not wanting to work on the gui elements .. I really am doing my best to wait for Unity 3D 4.6 release until doing very much UI work. I did make some player bars (as you can see from the video) but this is all band-aid stuff until I get my hands on the new tools!

I do not want to go through writing a character creation screen, level up screen, inventory management, merchant buy/sell screen's etc and then have to refactor it all in 2 months (or less??) when the new UI system comes out.

That's pretty easy to leave for now as there is just such a mountain of work that needs to be done -- the UI only has to work the tiny bit that requires for me to move forward with the core gameplay right now. Also the level editor I want to write really needs to wait for the new UI also. I could certainly make some progress on it as its not as important as the player's UI ; but honestly I'm going to be using it  A LOT. I'd rather have nice tools to use rather than kludgey ones!

 Hopefully Unity will not drop the ball and make it take a year though -- obviously any kind of delay of that magnitude and I will have to "roll my own" or buy a solution from the asset store.

I've started to become pretty overall unsatisfied with most Unity asset store purchases that aren't actually 3D models though ..around 80% of the asset's I have are cumbersome to integrate and do not work the way I would like to. Usually after I get too far into integrating it I realize its not worth the work and take it back out and write my own stuff.

I think the only thing that's been a flat out win so far is the Sonic Ether Natural Bloom asset.  I don't plan on stopping to buy assets ; I have actually learned things by buying them -- like what not to do sometimes!  Also they've given me ideas about how I might like to approach something as it gave me insight how the other person did it.  So I don't think assets are useless or anything, but I do find myself not using them that often.

Finally if you've got a really keen eye you may notice I've tweaked the tone mapping on the camera again.

Previously I was using an 'adaptive' tone mapping script which is like in Half-Life (or other more modern games) where at first when you go in a bright area its "too bright" and then it would 'tone down' after x seconds.

I ended up feeling that was just too much for this style of RPG and now I swapped to a "photographic" tone mapping.  One side effect of that is the photographic one seems to have a better white/dark level in it so I'm a tiny bit happier with the lighting levels in general.  I reserve the right to tweak it a dozen more times .. especially if I can pick up Unity 5 and do the physically based shaders!

Thanks for checking in. See you next week!

[erebusman]

This week I initially had decided I would dedicate to learning rather than trying to focus on getting a feature in and allocating enough time to actually get some learning done and potentially failing at a both..

So I did some research and found I was in a particularly odd spot in that I wasn't sure what level of learning resources I really needed? I was specifically interested in learning more about the very specifics of Unity 3D development and it was hard for me to self-evaluate if I'm a 'beginner' or sliding into 'intermediate' area when it comes to Unity 3D specifically.

I do know I'm constantly confuzzled by the way Unity 3D does things, its component oriented approach doesn't always make sense to me.

Having to type things like :

"messageSystem = FindObjectOfType(typeof(MessageSystem)) as MessageSystem; "

Constantly throws me off.

I want to type:

"MessageSystem messageSystem  = new MessageSystem;"

But again dealing with Unity's component system throws me off. And I'm never quite sure that I'm doing things right or just using a shoe-horn approach to get the functionality I want rather than doing things properly in Unity 3D!

So I decided to start with a beginner book - there's a lot of value in learning the basics, and learning them well!

After some checking around I settled on Unity 4.x Game Development by Example Begginer's Guide

I've wanted to try some of Pakt publishing's title's and I was able to get the Kindle version on Amazon at a very nice price.

I did the first six chapters this week and here are my thoughts on the book so far:

Pros:
- The book is written in a very witty style that keeps it from being too try.
- The author seems to have a solid handle on what challenges beginners will have like taking on projects that are too large, and does a good job attempting to demonstrate why those are a bad idea; and gives good suggestions on how to create a manageable project.
- The code examples seem to work (hey its worth noting; in some books they don't!)
- It really does approach from the base line for the beginner.

Cons
- It claims to have Javascript and C# , which it sort of does - but if you want the C# examples you have to go to the end of the chapter.  Which makes the read very disjointed.  I'm not interested in Javascript for Unity 3D at all so this is a really irritating factor.
- The book really is very basic ; I think it really is for the true beginner. As someone who is approaching intermediate I'm beginning to feel that the book may not have a lot to offer me.

I would definitely recommend the book to a beginner interested in using Javascript in Unity 3D.  If you were interested in C# and have the patience to scroll back and forth for C# I would still say its a good book.

Finally I do in fact have a development update! After doing 6 chapters in the book I took a break and put in LERP movement for the player.  Previously the player used to 'snap' forward to the new position, but by using a LERP between the two positions the now move forward smoothly which both looks nicer in general and gives the perception of 'moving' a lot more than just snapping forward.

I made a quick video to show it off here: 



Thanks for reading, see you next week!

[erebusman]

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!

[tieTYT]

Battling that skeleton looks pretty cool.  I'm sure you're not trying to polish yet, but it would look a lot better if there were slash marks across the screen when you attack him and he attacks you. 

[erebusman]

Battling that skeleton looks pretty cool.  I'm sure you're not trying to polish yet, but it would look a lot better if there were slash marks across the screen when you attack him and he attacks you. 

Thanks for the reply and your feedback!

Yes I definitely plan on using some visual combat feedback! I am a little torn on ideas of what will look best but experimentation will surely prove out :-)