Jump to content

  • Log In with Google      Sign In   
  • Create Account

ShadowKGames

Member Since 22 Oct 2013
Offline Last Active May 18 2014 06:31 PM

#5125491 Some advice on Unity

Posted by ShadowKGames on 21 January 2014 - 03:40 PM

 

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!


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.

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.


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.




#5125324 Some advice on Unity

Posted by ShadowKGames on 21 January 2014 - 07:02 AM

Understood - that's definitely out of memory and not a stack overflow. You confused me when you said it was a stack error.

Splitting up the level will help, but only if you limit what you load to what you can fit in memory. If you have to load the entire level at once, splitting it up won't help. Splitting up the level WILL let you distribute the blocking loads over more frames though if you want to do that.

You will probably also eventually need to reduce the size of your assets (shrink or lower texture quality/compression type, reduce triangles, etc).

In some cases you might be inadvertently copying textures or materials if you are modifying them at runtime (it doesn't sound like that yet since you don't have any scripts yet).

 

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.




#5125241 Some advice on Unity

Posted by ShadowKGames on 20 January 2014 - 11:17 PM

 

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.

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.

 

  1. ERROR: Out of memory
  2. Stacktrace:  
  3.  



#5125236 Some advice on Unity

Posted by ShadowKGames on 20 January 2014 - 10:52 PM

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!




#5124597 GameEngine from start to finish(DevLog)

Posted by ShadowKGames on 17 January 2014 - 10:15 PM

 


Wrapping this portion up, I saw an article saying build games not engines. Which rings very true, but there is more to it and not everything is black and white.

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! smile.png

 

(...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. smile.png)

 

 

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




#5124527 GameEngine from start to finish(DevLog)

Posted by ShadowKGames on 17 January 2014 - 04:39 PM

Part 1 (Build engines not games)

 

I'll explain the title later smile.png:

 

As said, I'll cover the shear basics and questions asked.. When I originally started the hardest thing was to find what I needed to get going.. So I'll simplify the startup procedure and answer questions I've seen asked many times.

 

What is a game engine?

 

The question is very open to interpretation, diluted further with modern commercial and freeware (Open source) game engines.  Simply put, I see a game engine as a solution to build and develop games quickly. The toolset size is dependant on what a developer is intending to do, you wouldn't focus on orthographic (2D) projection for a 3D game (let's move past the UI for now), but a multi-platform commercial engine like Unity would. There's several features in this tutorial that many engines wouldn't use of need, so they don't have them.. But they are still an engine, then we have open source products like Ogre3D and Horde3D which are rendering engines. Rendering is a term for displaying graphics, whether using Microsoft's implementation direct3D or the multi-platform OpenGL.

 

Why would I build my own engine?

 

A lot of what I say is subjective and it's for you to make your own mind up, but I will say don't attempt to build an engine if the following applies:

 

  • A current engine serves all purposes required
  • You haven't used a game engine before and at the very least, you're unfamiliar with putting a basic game together.
  • You haven't discovered the limitations of a specific engine.

Building an engine can aid in multiple areas:

 

  • Closed source engines are difficult to modify if impossible
  • Deep understanding of not only how games work, but how tools fit together
  • Feature set's can always be improved and added
  • Financial return

Anyone deciding to build an engine has to weigh up is it worth it, this is NOT A COMMITMENT TO MAKE LIGHTLY and in most cases isn't worth the effort.

 

What's the difference between a game and an engine?

 

Not as much as one would expect, a game requires a renderer / physics / input / audio / UI and a way to be executed on a system / load resources / save games.

 

Many a time code is re-used from a game to build an engine around it, if you're going to do it from scratch then you might as well build what is in essence a level editor which allows you to quickly craft scenes and event's.. That's where the engine comes in, because once completed everything is done in the background.

 

What is the toolset we need?

 

Ok a list of tools:

 

SDL 2.0 (http://www.libsdl.org/)

Glew (http://glew.sourceforge.net/)

QT Creator (Because it's cross platform and supports widget's, (VIsual studio can also use QT widgets) (http://qt-project.org/wiki/Category:Tools::QtCreator)

UI (http://cegui.org.uk/) I'm open to other suggestions for vector or widget based solutions

Nvidia Physx 3.1 SDK (https://developer.nvidia.com/physx-sdk-v31)

 

Build engines not games

 

Wrapping this portion up, I saw an article saying build games not engines. Which rings very true, but there is more to it and not everything is black and white. As said, the best path is to find an engine that works for you. Failing that, you will spend a large portion of time building an engine for your game and time will be consumed building toolsets instead of writing an actual game itself. In a nutshell, this word TIME is the greatest challenge here.. A large high fidelity game may take 2 - 3 years to complete, add an additional 2 years for an engine, then ask yourself. Do you have the time?

 

In part 2, I'll be discussing openGL and Math:




#5124290 GameEngine from start to finish(DevLog)

Posted by ShadowKGames on 16 January 2014 - 10:12 PM

Engine DevLog

 

What I thought might be a cool idea is to create a dev log all about making a game engine from start to finish, I'm not talking just a simple triangle in OpenGL.. I'm talking about everything, from building the API around the renderer to particles / phsyx / post processing and even advanced features, I one day want to implement like a cut down V-ray rendering mechanism.

 

I'll include everything, all the trials and tribulations. The points of utter frustration, the days where I worked so long I can't even remember my name the next day.. I'll approach it from a beginners perspective.

 

Why not just use a tutorial?

 

Well, I'm not going to release all the code because it'll one day be a commercial engine. Even though it's me on my own doing it out of work, also what tutorials generally don't give you is the headache of debugging. They don't include common issues and things you may come across, neither do they go into the actual experience of doing all of this.

 

What's my experience?

 

I've been a hobbyist / professional developer / engineer for 14 years, spanning across multiple different sectors including games / telecommunications / retail etc. 

 

Am I a beginner?

 

Ummm, yes and no.. I've done many projects large and small, I've built engine frameworks (or rip-offs for learning) and worked on games as a developer and artist. But I will be starting from scratch to create a modular engine with as little interclass dependency as possible. So additions and features don't need a re-write, the whole cause of a previous failure. This is a new one for me too, so it'll be very interesting.

 

Can I do this?

 

Yes, if you put the time in.. It's hard work and in many years I have never seen a genius programmer neither have I ever seen someone build an engine with no experience of game creation before. I have seen slackers and hard workers with a thirst for knowledge..

 

The code and target

 

The point in this is to create a modern OpenGL framework, I'll introduce you to the framework / concepts and tools. What I want from my code is:

 

> Little in the way of bugs

> Easy for others to understand

> Maintainable easy framework which can suitably modified

> Doesn't crash

 

I'm not proud and I'm a human, I don't care if someone thinks my code is crap or not.. I do care about my end users.

 

Where to start:

 

Might be a nice introduction, go play a game.. Your favorite game (yes you heard me), instead of focusing on how fun it is.. Start thinking about how it's put together.. I'm talking make notes on what happens when you press a key and you move forward, what happens when a GUI menu item is clicked etc. etc.

 

There's a name for what happens, you move forward (Transformation), you rotate (Quaternion transform), you press a key (Event).. Think about the logic..

 

If I get hit, then I loose life.. Hmm you say an if statement.. 

 

Also a primer on how this all came to be might be a good idea:

 

http://openglbook.com/the-book/preface-what-is-opengl/

 

What language do I choose?

 

Well being honest, the language is kind of irrelevant in the whole scheme of things. But I will be choosing C++, I'll be straight up and say I don't really like C++.. A lot of the quirks infernally annoy me, on basic render tests there has been near 0 impact on performance on a modern PC between C++ and C# with garbage collection.

 

So why?

 

Because most of the source examples I have reverse engineered are in C++, even from the Nvidia developers framework, also you might as well get used to it as GLSL shaders are in C anyway.. it's easy to find a deferred rendering example in C++.. But using an OpenTK wrapper and using C# examples are scarce and it can become painful. Also for better or worse, it's what I'm used to.

 

Will I use libraries?

 

Of course I will, you'd be mad to create an input and sound library.. Even if you're in a team of 20, any shortcut, ANYTHING that can make your life easier use it.. Building an engine is hard enough and takes years, let's not add to the pain. Everything else is all us, the renderer, shader and toolset will be done by us.

 

What do I get out of this?

 

I'm starting from scratch and it's a give and take scenario, some Guru's on here might help me in certain area's.

 

I hope this is a good introduction and I'm looking forward to updating as I go along.




#5122853 C# Game Engines

Posted by ShadowKGames on 11 January 2014 - 10:42 AM

I'll try and get a windows release out there first and make a Mac Build later, It's not at the top of the priority list.

 

I really appreciate you taking the time to answer.




#5122496 Have you made a game engine

Posted by ShadowKGames on 09 January 2014 - 09:07 PM

@ Lichtso Deferred lighting isn't that difficult (Don't get me wrong it's not that easy either).

 

http://ogldev.atspace.co.uk/www/tutorial35/tutorial35.html << Tutorial and source here.

 

Now POM isn't much of a killer, but you have brought up something very close to me... Trying to future proof an engine by getting that DAMN ray-tracing algorithm in so it doesn't cause the hardware (Even 2X R290x's) to come to a complete grinding halt.

 

DSSDO instead of SSAO, there tons of examples out there and a massive CryTek presentation on how it fits together. Great for a small mental hernia, but very much possible to implement, there is source code out there for it I'm sure you can reverse engineer it.

 

@ Nathan

 

Sorry, but if you don't know how to sort out Vectors yet building an engine is the worst possible thing you can do.. If you try to sort out matrices definitions for vectors, cross products, normalizing and Quaternion's without successful implementation you're going to suffer. I highly suggest you start with something like Unity, find out how a game is put together before you try and make an engine. Learn how to firstly manipulate the utter basics, follow the Unity Tutorial videos:

 

http://unity3d.com/learn/tutorials/modules/beginner/scripting

 

You still have to use and manipulate them, but all the hard math is abstracted from you. Vectors are the most simple portion of this whole thing.!

 

Why exactly do you feel the need to build your own engine? I have a reason, Unity doesn't do what I need it to..! To build a framework on top of it would take nearly as much time as just building an engine. CrySDK was too buggy and I didn't have a access to source to fix it and UDK I just didn't fancy smile.png.. (Unreal 4 looks like my cup of tea though).

 

I've been doing this a long time and I sure as hell don't really want to build an engine, it is last resort.. If all fails, then I'll build one and it's not because I want to. 

 

The other side:

 

My engine I originally started on was in development for so long it's now defunct anyway and buggy as hell, so I started up a new basic implementation with OpenGL 4..! It's taken me two weeks just to get a basic engine with renderer together, for some people it takes months to get to the stage of having rotation, input, .OBJ loaders, a simple renderer put together as shown below:

 

Tip: For anyone attempting this, prototype it in a higher level language first.. There's no shame in doing so and use things like LWJGL, game engine design is ridiculously hard.

Attached Thumbnails

  • SETest3.png



#5121048 Graphics Feedback

Posted by ShadowKGames on 03 January 2014 - 08:07 PM

So over the next two years, me and my team are developing a story driven RPG. It's a franchise based development along the lines of The Witcher and Dragon Age. 

 

We are in early development, whilst we can't afford to be at the forefront of cutting edge tech. If at all possible, I'd like to ask if the following image is on the right track for a medium sized development and any feedback would be more than welcome. Also we are still looking for mac based alpha / level testers if anyone would be interested. You will be compensated with a free copy of the game..

 

 

Attached Thumbnails

  • screenshot4X.jpg



#5119753 Have you made a game engine

Posted by ShadowKGames on 28 December 2013 - 08:11 PM

 

@ Nathan, this is a closed engine which was started in 2011.. Originally made for creating large open world RPG games, but I disbanded it for a small while to focus on actually making games. After our next title is out we will have time to finish it off, licensing has yet to be finalised.


How many is 'our/we'

 

 

Originally it was just me, now a team of five full time engineers and 10 part time. I'll be straight up with you Nathan, trying to make a game engine of any considerable worth was the worst Idea I have ever had. Reason I disbanded it honestly is because I got stuck and to this day a fair few years on, still don't know how to fix it.. I started coding when I was 13, worked in API development (Not games) for 12 years and have a fair amount of experience in many languages not just C++... Now I have a team of much better coders and the engine still remains a thorn in my side.. I'm glad I started using Unreal and Unity, focus on making games.. Not throwing years of your life away on a pipe dream, if it actually see the light of day it'll be out of pure Iron clad stubborn will, nothing else.

 

Best of luck on your adventures.




#5119668 Is using an existing library, actually cheating?

Posted by ShadowKGames on 28 December 2013 - 10:22 AM

 


There is so much to learn about using engines and adding to them, that alone can take many years to master. Never mind trying to build your own engine.! There just isn't enough time, I own a company with a team of 5 very experienced devs and we still don't have enough time and we certainly aren't trying to re-invent the wheel.

 

The team of which I belong has put many many many hours over the last several years mostly with existing libraries and industry standard workflow pipeline.  Guess what?  After years we are finally seeing the light at the end of the tunnel and a release of a game in the conceivable future!   ... and we are a very skilled TEAM working our... uh... tails off, so a similar situation to yours in many ways.

 

 

Very much so, I don't think people realise what's involved until you're at least a fair way in .. (Obviously dependant on what you're trying to achieve), if it's a high fidelity modern 3D game then there's more than enough challenge for three years and a team of 5 just making it. Never mind anything else, sure we are trying to improve our feature set to stay competitive. But that's about it!.. We have a half built engine which we are releasing in 2015, for no more reason than continued revenue after we have finished our game.. 

 

I wish you the best of luck with your game and a happy new year.




#5119582 Have you made a game engine

Posted by ShadowKGames on 27 December 2013 - 04:47 PM

Yes, we are finishing off our second title and we will be leaving our current engine and moving on to using our own.. Mainly general purpose, we have RPG and FPS prototypes working in it but a fair few kinks that need to be sorted out. We will be licensing it out after that:

 

Features that are in ShadowEngine V0.1, due for the Aug 2015 release:

 

64-Bit Editor

Nvidia Physx 3

Language support: C++ and C#

Direct X and open GL support

Custom shaders will be allowed

Data clustered streaming with compression algorithm

Track animation with cutscene system

Deferred lighting and HDR support

Post effects suite: DOF, BOKEH, Bloom, Motion Blur, Colour correction, DSSDO, SSAO, Edge detection, AA

Real time GI (Voxel based, spherical harmonic indirect lighting)

Internal runtime compiler

Terrain creation suite

 

Supported platforms, PC and Mac..




#5119574 Is using an existing library, actually cheating?

Posted by ShadowKGames on 27 December 2013 - 04:13 PM

Do you want to develop a game or an engine? At some point you will have to use a third party library like Direct X, so is it cheating? No, you relatively have no choice if you care about compatibility. Learning how to develop with third party engines is difficult enough and remember you are just one person, there's huge teams developing engines and one person can not get it to the same level of competition and as a learning example is relatively pointless until you know the basics of how a decent game goes together, if you want a challenge take a crack with Unity..

 

To get it up to a decent graphical standard, chuck the default shaders in the bin and start from scratch with shader lab. Work on adding some advanced features like sorting out the Post AA in DR, things like SMAA shaders. Dump all the post effects and try implementing DSSDO, pristine mostion blur, add other lacking things like a Voxel based realtime GI.. Build your game, sort out all the challenges in AI, controllers, physics, shadows and performance.. Create your own LOD / Culling system is also a good idea.. Come back in a fair few years when you're done. (That's if you have experience and the knowledge to know how to put it all together)..

 

There is so much to learn about using engines and adding to them, that alone can take many years to master. Never mind trying to build your own engine.! There just isn't enough time, I own a company with a team of 5 very experienced devs and we still don't have enough time and we certainly aren't trying to re-invent the wheel.




#5104687 How should i learn to make games in c++

Posted by ShadowKGames on 26 October 2013 - 07:50 PM

The easiest way for me personally was this way, first I learnt C# years back because it was simple (well kind of) to understand. Played with it at a high level, found out how basics like Raycasting, Physics (gravity, quaternion, Vertices etc.) worked.. Then I moved onto shaders, such examples are shaderlab, looking at how scripts interacted with shaders. How FXAA / MLAA / MSAA / Bumped Specular / BDIFF Bloom etc. worked.  I then moved onto C++, which ironically enough isn't a million miles away from C#.

 

 

 

,  






PARTNERS