• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

nekitusan

Members
  • Content count

    41
  • Joined

  • Last visited

Community Reputation

206 Neutral

About nekitusan

  • Rank
    Member

Personal Information

  1. good, good, research first :) yes, its true, I am working on the engine, but mainly for own use, at least at first. I am aware that the age of many game engines is over, Unity and UE are here to stay and evolve. Their codebase is huge, the amount of features is also staggering and their communities massive. I am just doing this for fun and keeping my coding skills up to date. Asking about the current issues and problems gives me a bit of insight into how to shape my engine and tools, though I also know the problems in Unity and UE because my job is to work with those engines daily, but I'm an engine programmer, I'm not a game developer or level designer/artist, so this feedback comes in handy. Right now I am developing the editor's GUI, its basically the same as Unity's, its in OpenGL, but fully skinnable by user (test dummy app http://gamedev.ro/data/iotd/38634becd396ad66b55303cd9909f97c373.png  and  http://gamedev.ro/data/iotd/53770fcc4ecc06769a14829c51ea4577e1e.png) The engine is also in development, as engines are in development for ever :), more details I can give if asked. So that's pretty much it, I thank everyone for any idea or feedback on those engines.   PS: I have asked this question on Unity and Unreal forums, if you're interested for other people's replies.
  2.   I wonder what made you think the question was asked on that note ( "fighting toe-to-toe" ) ? :)
  3. What's your biggest problems/missing features with Unity or Unreal Engine ? From engine to editor, UX, code, etc. Let it all out.
  4. well, thanks all for the great posts, while I have decided to continue coding on the engine for fun (and anger when sometimes things won't  work properly), now I'm thinking to semi-close the project, after almost 16 years of engine-related dev saga :). I will work on the engine when I'll start to miss C++, maybe in the weekends, not almost daily as I did so far (and nothing good came out of it :D ). Part of this decision is that yesterday I was coding on the shaders, fiddling around with Blinn-Phong, Schlick's fresnel aprox., cubemaps and other mambo-jambo, and while trying to put together some PBR wannabe, reading some blogs, I've realized once again how of a math n00b I am, but if I would wanted to learn all that stuff, I wouldn't liked it... so, that was the cherry on top of the cake... too much hassle, even for a hobby, while I could make games as a hobby and even get a buck for that :). The engine code repository can be found here: https://bitbucket.org/7thfactor/tachyon  Its not a complete engine, its more of a sandbox playground. I would like to give back something to the community, as it gave me all these years, there might be some nice pieces of code and ideas inside, not all is super clean or finished, bits and pieces of my thinking mixed with hundreds of ideas from the Collective. I guess its time to actually make some games, and Unity 4.6 and 5 seem pretty good for this, after I've worked as a job in Unity for almost 2 years and seeing its goods and bads. Now allow me to squeeze in a corner and cry...   "So Long, and Thanks for All the Fish, So sad that it should come to this..." Thanks all again for the insights!  
  5. Must disagree with that. If anything, there are more low level techniques being shared than ever, IMO.   Anyway, if tool dev is your thing, I guess you'll have to come up with something that hasn't been done yet, or at least something you could do better. Without knowing your experience, it sure would be nice to have a good dynamic music creation tool available, for instance. Point being, there are tons of niches that haven't been filled yet...   yes, I am also following those blogs and some more, but its not enough :), at least in the "old" days there was more down-to-the-metal information in forms of tutorials than now, imho. Sure, we have the whitepapers and slides from the big companies and various hobbyists or employees from the big or little companies, but I find them scarce or my google skills are underdeveloped :). Either way, I still believe there are more Unity programmers being "produced" than hardcore ones, and that happens because of this engine monopoly.
  6. I've worked at Crytek as CryEngine's Sandbox Editor developer and architect for editor's future. Left the company to pursue the personal dream of developing an engine and other things. After UE4 and Unity5 announcement I was feeling overpowered to continue on my work, not to mention the limited time and funds available . Started a blog a while ago http://7thfactor.com some quite old screenshots http://7thfactor.com/showroom/nytro/history and a previous blog http://7thfactor.com/nytro/blog.
  7. As a game engine developer myself, I was wondering about the need of custom game engines, the state of commercial engine offers and also about game engine engineer job offers scarcity. We can all observe how the game engine market has changed since Unity started to occupy a major part of it and also after UE4 was released to the public, that started the "war" for the user, for affordable game engine technology. I'm seeing the current distinct parts of the game engine market or area of game software technology: hobby custom game engines, very few probably aimed at 3D anymore, a several 2D oriented ones usually written for specific indie games; custom proprietary game engines, used in-house by some game studios such as DICE's FrostBite,  Kojima's FoxEngine, SquareEnix's Luminous, and others; hobbyist game engines from the last generation, or the pre-unity, pre-UE4, with ok features but not really AAA grade, and we have here (in no particular order ) Leadwerks, NeoAxis, Torque, C4, Shiva3D, Esenthel, Gamestart, Gamecore, etc., some better than others. Some might get upgraded in the future, but not a certainty; top hobbyist game engines, here we have the well known players Unity3D and UnrealEngine4, plus some more obscure or not so much used ones like Unigine, CryEngine, and others I don't remember; open source game engines, there are some notable ones like Panda3D, Delta3D, Polycode, OGRE(rendering), Blender GameEngine, and others; So, one of my questions is, is it worth still to make a custom game engine for yourself or even to think about making it open source or commercial ? Open source might be a nice thing and an experience for learning new stuff, but since the big commercial players are doing a relatively good job, commercial might not be a doable idea, unless you have a big or veteran team of experienced programmers. Another topic is the scarcity of engine tech development, I can only see few jobs related to that of few companies, due to the aforementioned monopolization of the commercial engine market. Jobs of that kind one might find at No. 2 and No. 4, sometimes No.1. And yet another topic is the relative lack of low level and techniques/new tech tutorials or articles, as they're not so many as they were years ago. This is also a byproduct of the game engine/tech developers, due to this new segregation of the market. This is more of a rant, an open discussion for how the market for game engine technology and man power and competences has changed in the last lets say 10 years, since I dont see anyone bringing this into discussion, people being more busy on how to cash in the AppStore and how to create the next big 2D game X clone or Minecraft clone. A dilution of the engineering competence is happening I think, since its not so needed anymore, the big game engine guys have the manpower and money to overshadow most of the emerging game engines that might try to pop out (Bitsquid, Offset, RealityEngine, etc), which are usually bought by big companies. Things have changed, how does an (oldish ) game engine developer copes with this change? Basically, should I continue on my game engine or use just the tech above and make games... I hope some of you had/have this problem and can talk about it.   Feel free to rant on the subjects above, I would love to hear your thoughts.   Bonus content: I see all the cool rendering features being added to top tier engines like PBR, deferred in many flavors, custom GUI for editors, publishing to a gazillion platforms, asset stores, tons of middleware added, etc.. and I feel a "little" bit overwhelmed and I wonder if I should stay a tech-oriented developer or go to the actual game developer side, where you actually make games and not tech. But I like to build engines and editors, yet for what purpose since the tools are already given up for free by the other companies. Yes, its a personal crisis :).
  8. When you are composing the image based on your various gbuffer components, you have one single shader, that shader would have those subshaders for various materials. Of course you have multiple shaders to prepare your gbuffer or other render targets for lights and such, but for the final composition procedure you have a single shader. I was suggesting taking that shader with 2-3 lighting solutions and material id to something auto generated from a node based graph, usually nowadays you have several lighting options using that material id, which are hardcoded in the shader code, what I am saying is one could generate the code from a graph, to have totally custom lighting solutions based on a user created graph (with simple ops, mul, add, div, uv rotator, etc.). This is done easily when you have forward rendering since you can set a shader per object and render it with that custom generated shader, but in deferred you can only use one single shader to compose that scene from the gbuffer, so, you need to squeeze all of the many custom shaders code into one hardware shader to be used on the screen quad used to compose the scene. Anyway, after some more thinking I got to a conclusion, its interesting to use this approach, which is almost like a RenderMan solution, full control over your shader code from a graph, in deferred, but one might be slowed down when choosing the right shader path based on material id, since you need to do that branching based on the current pixel mat id. I'll get on with it and if I remember this topic, will post some screens and post mortem :), thanks for the brainstorming.
  9. Ok, you have to understand that I need to have just one single ubershader because I am doing deferred over a quad, I dont need many shaders, you cant have more than one shader when you are doing deferred, only multiple entry point functions called by the actual main shader function, for each material id encountered, you can have similar setup for various lighting formulas, call the lighting function based on your current material id found at that pixel (texel in our case, since we're drawing a screen quad). In a node based "shader" code generation system you can have a plethora of "shaders" with various operations inside them, and call the right function for a specific material id, but there is only one hardware shader which has all this code in it, what are you talking about its not deferred stuff, or from what I understand you're talking about a more fixed setup where the code is the same but only material params are different from pixel to pixel, well, I'm not talking about that approach, I want to have total freedom on writing the pixel shader for each material id, and since we're just using one hardware shader to lit/process that screen quad, I am trying to find a way to have "soft" shader code called by material id, many generated shader functions inside the big ubershader, anyway I've figured it out now, it seems Unreal4 is doing as I was saying (from a whitepaper I was reading now), and they have the limitation on branching to the right shading function when the number of generated (by a material graph) shading functions is high and also when the bound texture count is high (for when they do layered materials), fyi read this http://www.unrealengine.com/files/downloads/2013SiggraphPresentationsNotes.pdf , its interesting.
  10. I was saying about the graph that generates an ubershader from its nodes at authoring time of course, based on shader code snippets or blocks. What I was saying, is, when you for example have 100 shader graphs and each is exposing several blocks connected in various ways with various constant values and data, you need to generate an ubershader, be it as one source file or more that gets included, but at 100 combinations, there will be 100 functions that are automatical y generated to call the block's shader code. So the end code will be big and to choose for each pixel based on the material id you need to do a switch of 100 cases so you can choose the right entrypoint to execute for that pixel. Example: float3 phong(....) {....} float fresnel()..... float4 mtl001_main_ps() { float3 c = phon(...)...... fresnel()..... return color;} float4 mtl002_main_ps() { float3 c = phon(...)...... fresnel()....some other operations.... return color;} ...... and lets say 98 more shader graph auto generated functions float4 main_ps() { int mtl_id = getMaterialId(IN.texcoord); switch (mtl_id) { case 1: return mtl001_main_ps(IN); case 2: return mtl002_main_ps(IN); ....... and the next 98 shader func calls.... so, how one can handle a lot of shader funcs without having that huge switch in the shader.
  11. yes you just said what I've said. I was wondering about what happens when you have hundreds of custom shaders functions compiled in that ubershader and called using branching in the main shader func. Are there any ways to split this into some sort of multipass deferred rendering approach? and what are your thoughts about unreal4 node based mtl system, I'm curious about implementation details.
  12. I am wondering how a shader/material system based on blocks would work in a deferred renderer. Since in deferred rendering we can use just a shader to render the screen quad, I see it as an ubershader automatically generated from all the custom shaders the user creates and based on the current pixel material id you choose the right shader function to take over the lighting. Thing is, if you have lets say 100 custom shaders created in the node based shader editor, having a switch in the main shader function to choose the right entrypoint might be a little too much. I have seen unreal4 does some node based materials, so what do you guys think about this topic?
  13. SeanMiddleditch, I was thinking of that, thread/bundle, and you're right, wouldn't help, even worse, since its serial reading from hdd, so I will have one thread for the resource manager, thanks for reassuring it :). I have also a job/task scheduler which will be used by the resource manager, but I think I will use polling since its more safe/clear for me at least, instead of callbacks (which I also support). I dont use STL :) for various reasons, more or less logical.
  14. alright guys, thanks, Hodgman good point with the queue filled from any thread with "onloaded" messages to be consumed by the main thread.
  15. I have some conceptual problems for a resource manager to be thread safe (can be called from any thread). The manager has a list of worker threads (one per bundle, a bundle is a zip file). Traditionally, in a single-threaded manager we do something like this:   // sync load of a texture, loads and returns after texture is fully loaded Texture* pTex = resourceManager()->load("maka.png"); // we got the texture, use it int w = pTex->width(); int h = pTex->height(); // do something with w and h But in an async manager how we do that? Currently I'm using an observer list with callbacks for when a resource is completely loaded, the Observer is called and you can use the pointer to the resource. In this manager, resources are used as IDs, you do not have direct access to the pointer because you do not know in what state is at some point, it may be removed or modified from another thread. ResourceId myTextureId = 3493; // or we can use: resourceId("maka.png") to get the id struct MyResObserver : public IResourceObserver { void onResourceLoaded(Resource* pRes) { Texture* pTex = dynamic_cast<Texture*>(pRes); if (pTex && pTex->id() == myTextureId) { int w = pTex->width(); int h = pTex->height(); // use w and h } } } myObserver; ///.................... void someClass::someInit() { // we add our observer into the manager's list resourceManager()->addObserver(&myObserver); // async loading, returns right away, the resource will be loaded later on resourceManager()->load(myTextureId); // or we could do: resourceManager()->load(someTextureId, &myObserver); } Any other ideas would be welcomed, thanks.