• Content count

  • Joined

  • Last visited

Community Reputation

339 Neutral

About ShadowKGames

  • Rank
  1. Fallen Spirit RPG

    Fallen Spirit - RPG Hi Everyone,   Around six months ago, we set out making an RPG along the lines of the Witcher and Dragon age in Unity. This WIP, is part of the the Spirit Universe franchise. Your actions / interactions and the path you follow can make a huge impact on the world around you. Fallen spirit ("RPG") set in the Vex district of the Spirit Universe, a diverse world of culture and technology is at war and you're in the middle.   [attachment=20182:1-1.jpg] [attachment=20183:screenshot1.jpg] [attachment=20184:screenshot3.jpg] [attachment=20185:screenshot4jpg.jpg] [attachment=20186:screenshot7.jpg] [attachment=20187:screenshot13.jpg]  
  2. Fallen Spirit

    Fallen Spirit RPG
  3. Fallen Spirit concept art

    From the album Fallen Spirit

    © ShadowKind Games

  4. Graphics Feedback

      In the picture now at the top there is nothing more I can do, also the feedback I've generally got is that the textures are very bumpy. We use normal maps / displacement maps and a lot of the time some sort of parallax or tessellation shaders.. So if I hear back from a lot of people that things still look flat, then I'll have to start investigating the engines renderer.. We use Unity.
  5. Graphics Feedback

    Well I took a lot of the advice on board, in all fairness we are years away from a final product. But it's great to have feedback at this early stage   Here is where we are at now, a lot of systems have been changed / improved etc.   Edit: Deleted old photo moved to top..  
  6. Need Help Choosing My Path!

    I'd like to factor in choice here (or the lack of).. If you use CryEngine (With or without Mono) or Unity or Unreal 4 (let's face it, that's the future). You are going to use C#, C++ and C (Maybe Lua if you really feel like it), one for logic another for core functions and another for things like shaders. If you build your own stuff, chances are examples will be in C++ and again for stuff like GLSL C...   So if you want to get into games development, I recon the path is already pretty much pre-determined, plus there not all that different from each other.. Once you get around C# then move to C++ sure theres a fair few differences but you'll be able to find your way around and follow tutorials more easily.
  7. Unity Some advice on Unity

    A stack trace is not a type of error. A stack trace is additional information about what functions the program was executing when an error occurred. You should contact them, describe the problem, and ask if a 64-bit editor is even possible for them. Providing a 64-bit version is not always possible, and even when it is it can take a LOT of effort. If it's not possible or feasible for them, you'll have to deal with it yourself by fitting your assets within the 2 or 3 GB of RAM that's available to a single 32-bit process.     I fully understand this, I'm building an engine with a 64-bit editor. It still doesn't take away from the fact Unity loads resources directly into RAM which is a limitation that's causing headaches.. I'll try the patch and see where to go from there:   I'm going to start (or try) porting the lighting and shadow mapping system into Unity) The only thing left is to create some sort of terrain system which will probably take a fair while but it's better than starting from scratch.   Maybe voxel based? Not sure yet, it's been a while since I've attempted a lot of this stuff.
  8. Unity Some advice on Unity

      That is beautiful, thanks I'll give it a try.
  9. Graphics Feedback

    Hello. I believe that you would have the same result if you were using Unreal or CryEngine, so this is something that you should deal with artistically rather than technically. The foliage in your picture seems to grow out of the cobblestone ground. It would look better if you could blend the two elements together with either texturing (by overlaying a decal mesh with a semitransparent texture over the ground), or simply by using vertex colouring - a cheap feature that sometimes we tend to forget about. Eric Chadwick of Polycount has dealt with a similar problem using vertex colouring:     Texturing is just on oversight because the terrain is so large, I can fix that very easily. The issue is with the tree system, how grass foliage in wind zones is displayed..   That fuzzy look, that amplified with a lot of weird artifacts when you move around. I've seen a voxel system for Unity which eradicates this issue but it cost's $3000.00..   I have a lot of issues with flickering lighting and shadowmaps and pixels showing through the trees as blocks.. Thanks for the link, I'll check it out.
  10. Graphics Feedback

    Thanks for the feedback everyone, the guy's just a stand in for now there will be a character creation system.   As for the lighting and foliage, the lighting / shadowmaps and terrain system in Unity isn't fantastic to say the least. I've been wondering exactly what to do about it.. I'm sure I'll figure something out.   Thanks again.
  11. Unity Some advice on Unity

      Cheers, it pops up with a stacktrace error every now and again sorry for the confusion. The ironic or should I say moronic this is it works absolutely fine once you have built the solution!   So do I scale back the quality of the game so the Editor will work correctly? I find this kind of un-acceptable. Something Unity need to address.
  12. Unity Some advice on Unity

    A stack overflow error? It sounds like you have a particular script or arrangement of scripts/references which is causing very deep (perhaps infinite) recursion. Fix that and you should be fine. 64-bit will not help with stack overflows. I am not aware of any problems with Unity handling massive numbers of GameObjects in a single scene. I only do 2D in Unity, so I can't help with any of the 3D rendering questions, unfortunately.     There's no scripts in the game so far, just a big level. It literally says at the side of it, system out of memory!.   2D games would never have this issue as the size is small, if you have a collection of around 20,000 meshes in the asset / resources section then start applying only a small portion to the scene it then falls flat on it's face.   It starts to grind to a halt even after you just import a set amount of objects.   ERROR: Out of memory Stacktrace:    
  13. Unity Some advice on Unity

    GameDev Guru's, I posted this on the Unity forums and I know we have some epic talented people on this forum so I want a second opinion:   I'm torn as we paid for Unity Pro, what to do about all of this:   I want to share the list of issues with Unity Pro I'm / were having and see if we can get some feedback before either making a real go at sorting out the issues. Or ditching Unity Pro and moving on: Firstly: We are having to switch off a bunch of resources (asset's) in a half built scene, because if we don't a stack error occurs and the editor runs out of memory / crashes Unity. Obviously a 64-bit editor would fix this, but it's becoming painful. I've experimented with dicing up the scene with Async loading, not to much avail. Moving on: We have partially replicated a scene from CryEngine, draw calls stay below 2000 in CE and we usually get around 50 - 60 FPS on a Radeon 6850 which is our lowest target market, with DX11 switched on in Unity we are usually getting around 6 - 7K with deferred rendering after occlusion culling (With weird issues like models occasionally disappearing). It seems the best solution, would be to create our own culling solution using better algorithms which some should be hardware based. When I investigated, it seems because Unity doesn't support new versions of GL so it may be impossible to do.. I'll see what is possible with DX11. (Even though ideally we want to release for Mac).. The profiler in Unity points towards the scenery rendering being the main issue, bill boarding seems to be of little use especially with an over the shoulder camera you notice the billboards changing dramatically. It looks horrible to be honest.. Which brings me on the next issue: Trees: Up close textures look like old 16-bit console representation's of how trees should look, we have tried shaders to improve the look to little avail. These shaders we wrote in Unreal Engine and look great, I'll post some examples. Beyond that, wind zones don't seem to represent how wind actually works.. It would be ideal to split the windzones if possible? To make grass etc. appear as if it's moving more fluently.. The only solution I can think of is to build a completely new terrain system. Which follows on to: Shadows: There's a lot of issues with flickering, especially from trees and grass causing a lot of artifacts.. So the only solution I can think of is to change how shadow mapping works, which I'm unsure of and I'm not to clued up on the viability. Which then leads me to lighting: The likes of god rays appearing through trees appear as a block of pixels instead of representing how light would actually work, this somewhat can be less noticeable by switching to a linear color space. But that's only a small portion, there seems to be an issue with pointlights near geometry. As a user moves the lights will flicker quickly, solution is to replace the lighting system.. Then we have issues with Far plan Z-Buffer precision on busy geometry, I've only ever noticed this in Unity as CE and Unreal doesn't have this problem. Distant objects flicker incessantly.. Not sure how I'd get past this in Unity.! All in all, it seems a lot of work to sort all of this out.. In some instances, it's something we can't sort out. So, any feedback is welcome.. Even if it's move on from Unity!
  14. GameEngine from start to finish(DevLog)

    Part 2: OpenGL and Math   I'll start off by covering some basic questions:   Do I need to be a Math Genius?   No! You have a massive calculator in front of you called a PC, if the prerequisite was a PHD in maths before you could make a game then many people wouldn't get very far. But you do need to have a basic understanding of how the math is put together, the reasons why we do it and how it relates to rendering. Being straight up honest, the formulas made by math Guru's is freely available to copy and paste on the web. But we don't want to do that do we? No! Except perhaps the strange formula that is used for quaternion rotation.   End users and abstraction   One thing you need to decide is who are you doing this for? A commercial released engine for finance, or do you want to use it for a team / personal use? Why I mention this  here is you will have to automate a lot of the framework for end users who do not care or desire to know what you do about how an engine works. Abstraction can be the a world of pain unto itself and cause more headaches than building the engine itself. All the math will be publicly available, the renderer will be manipulated with a couple of clicks.   Sure automating tools to become very simple to use can also benefit yourself, but you may find the time to create is not worth the effort. But this tutorial / set of whining, will be based around a commercial engine. Use the concepts and choose your positions wisely..   OK!!   So I've covered the Q&A, now I think it's time to start learning about how the engine is built!   Coordinates   The shear basics are, we have a screen filled with pixels that are RGB (Red, Green and Blue) or (Cyan, Magenta, Yellow and black). The higher the resolution, the more pixels are displayed on the screen. We have CRT's which use a timing system, but as technology has moved on I'll not mention anything about them. LCD screens represent pixels as dots / squares, usually manufactured on a 2D grid.   Just as pixels are displayed in a grid, we also are going to compute based on an invisible grid with locations called Vectors. We can have 2 vectors (X,Y) one to represent horizontal axis and another to represent the vertical axis. Whilst we do use 2D Vectors in a 3D game, we will mainly be focusing on a 3 dimensional vectors represented as (X,Y,Z) and a 4D representation (X,Y,Z,W) for rotations. What? 4D? It's a simple way to think about it and as it's not necessary to explain every detail so I'll move on from this one and return later :).   The claw GRRR!   Easiest way to think about coordinates in 3D space is to stick your hand up in the air and do a three finger claw, your middle finger pointing straight out, your index finger pointing up and finally your thumb pointing the side. Or make an L shape with your Index / thumb and have your middle finger pointing directly away from you. We always start from (0,0,0), theres nothing stopping you from starting somewhere else.. But there's an issue I'll discuss later in the tutorials with how floating point precision far away from the default location of (0,0,0) can cause issues. By the way (0,0,0) = (0(X), (0(Y), (0(Z)) so in other words X,Y and Z are all set to zero in parenthesis. So what's the point of all this?   It's how we do anything in games, drawing lines, spheres and even calculated positions of complex meshes. Then we transform them from one location to another based on coordinates. So now we have a basic understanding of vectors, let's move on to our next lovely set of maths.   Vertices and indices   In essence we play a massive game of dot to dot and GL will join the lines up and every line is classed as a vertex, I don't want to go into optimisation to early. But indices brings up a valid point, what if we have two conjoining triangles with overlapping lines? What will OpenGL do if we only displayed everything as Vertices? Well it would draw every Vertex, so we have two triangles and six lines (Vertices). This isn't ideal as I will show you later, drawing is one of the most resource hungry portions in regards to rendering. Welcome to indices, in which simply we just don't duplicate vertices and append as an indices. So we don't draw line, 1,2,3,4,5 and 6 and duplicate the intersection of line 3 (to the adjoining triangle) we just draw, 1,2,3 and 2,3,4.   Enter the Matrix   What we could do is, set all these positions manually. We could transform from one location to another in 3D space by setting every position in code line by line, but that would be silly and utter waste of time.   So what we use is a Matrix / matrices and take advantage of our giant calculator to perform transforms for us.. Cool huh? The biggest question is what are we trying to achieve with these matrices?   Well basically we need to define where we are in relation to anything else, I'm sat in the lower left corner of my room. On top of a chair, in a certain part of the world. So we have three important matrices to consider:   World, view and projection   World    Where is the object / model / mesh located in the world? That's about it for world view:   View   Where exactly is the model so the camera can see it?    Projection   This is what type of camera we are going to use, for our project there will be two. One as a main 3D projection and a secondary as a 2D orthographic projection for the user interface.   Finishing off   I hope you enjoyed this, next time we are going to look at how we apply these features and delve a little deeper into applying the math and how OpenGL responds.   I'm going to reveal what sort of game we're going to make as well :)!   An RPG WOOO! Wait Wait.. What about my FPS? What about my X game!??   It doesn't matter, once you have learn't all of this you will realise very quickly.. There's honestly not that much difference in it!! You might change where the camera is, or modify the physics slightly for your grenade launcher.   Why an RPG then?   Because, it is the biggest pain in the ass I could find and the toolset will be extensive and transformable to most other games!. Hence when someone pops onto a forum with no experience and says HEY! I want to make an MMORPG and we just have a giggle about it. If they knew what they were getting into, they'd run to the hills!
  15. GameEngine from start to finish(DevLog)

    I think it's worth linking to the article at this point for anyone unfamiliar with it: write games, not engines.  A lot of people simply read the title and maybe skim a little of the text and assume the article is telling you not to create an engine at all, but that's not actually the point it makes; rather, it suggests an approach to engine creation where you start by writing one or more games and refactoring out the useful functionality to form the basis of your engine -- and it's a very good approach for ensuring your engine meets the requirements of a real game without wasting your time on features that might not be needed.   Obviously not an approach for everyone, but valuable advice to read and consider.  Looking forward to seeing how your efforts progress!    (...and yes, if you really feel like you prefer to keep this as a forum topic rather than journal entries that's fine, although I'll move you from For Beginners to Game Programming. )     Sounds great, thanks for the citation. That actually wasn't the one I originally read, the article linked shows you should make a game and have an engine built around it which is right on the money and my intentions..   Also thanks for the move and appreciate the input, from everyone.. I really do, I don't pretend to know everything and I love it when a community comes together to get a solution put together.   I'll just add, any information / point of view or opinion is not a reflection of the company I work at. This is my own personal take on things..