Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1094 Excellent


About Shaarigan

  • Rank

Personal Information

  • Role
    Artificial Intelligence
  • Interests


  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Shaarigan

    Procedural Animation

    My first naive approach of something like this (as our project is exactly something like this at the moment let a program generate and animate NPC models for our game) is to have a set of certain rules that describe to the program how a character (or spider in your case) moves it's legs. Explained in more detail, you have to ask youself the question what makes a spider be a spider. A computer be design is stupid and a program dosen't know about spiders and humans, their differences and traits. This is part where the program needs to start "learning" about the rules that define the traits of humans, spiders, frogs and whatever it should handle. First if you have defined rules, you can start training your program to make/animate those characters and let it learn by try and error. It will produce different kinds of animation loops and you have to decide if they look realistic or if that combination of rules and parameters match. A good point to start may be genetic algorithms in the first step so that your program is able to generate lists of rulesets that match the attended training schema. Then you could start by adding more maschine learning technics. I'm for example experimenting with SOMs (self organizing maps) to keep associations between informations in a kind of artificial memory connected
  2. I didn't wrote that this works, I wrote that this works with WM_OVERLAPPED set What I think you could do is calling the window without the border flags (WS_OVERLAPPEDWINDOW, WS_THICKFRAME) and then set the border flags to see how huge the difference is in height between those two window rects. This way, you know the title height because this can change between windows versions. I utilized this via void Surface::Style(Surface::SurfaceStyle style) { uint32 flags = GetWindowLongA((HWND) handle, GWL_STYLE); if(style == Surface::Windowed && HasFlag(flags, WS_POPUP)) { flags ^= WS_POPUP; flags |= (WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME); } else if(style == Surface::Borderless && HasFlag(flags, WS_OVERLAPPEDWINDOW)) { flags ^= WS_OVERLAPPEDWINDOW; flags |= WS_POPUP; } else if(style == Surface::Borderless && (HasFlag(flags, (WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME)))) { flags ^= (WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME); flags |= WS_POPUP; } SetWindowLongA((HWND) handle, GWL_STYLE, flags); }
  3. You might miss a point, the system in ECS We have had in one of our games the 'object handles interaction' approach but it was that the object needed to do a lot of checks for interaction. I refactored this to a system based approach. The door just has some logic that knows what should be done if an interaction succeeds, this makes it easier to implement more interaction objects from the general interaction component. Second, the door has a requirement component that implements checks for certain circumstances that have to be match. Now we have a system that I'll call game-master system that does all the interaction based on certain rules. The subject wants to interact with certain object so tells the system the own component (player/NPC, inventory) and the components it want to interact with. The system now performs the data processing work, looks for a requirement component and passes the player component and iventory component to it to do some checks. If successfull, the interaction components 'Do' function is called that will proceed with the interaction; swing the door or open the inventory menu of the chest for example. This way you can add new components for requirements and interaction more easily
  4. Shaarigan

    Allocator design issues

    Why did you want to composite allocators together? The use of composition is to have different atomic tasks that you want to attach to your master-component to add functionality depending on your current needs. An allocator for example can just do one thing; allocating and managing memory. I don't see any use of composition here because each allocator should exactly tackle one kind of allocation. A heap allocator should process heap memory, stack allocator should go for stack memory and a block allocator should work on certain block of memory, stored anywhere else. Doing allocation profiling and memory performance checks is part of the profiler API you will/should use and shouldn't be something to compose together to an allocator. Either you use it statically/dynamically or you opt it out using the preprocessor. Another part you should really got headaches from is the fact of multithreaded memory allocation. Do you want to make all allocators multithreading compatible and have always to attach a second composition that handles locked memory access? I used the article in this blog to build my memory management system. It is multithreading safe by using atomics to count the number of objects/total byte count and also produces profiler entiries that don't just tell me how much memory is consumed but also what pointer addresses have been allocated so I can join my game engine's memory from the profiler process and investigate the memory cell on demand. Getting memory leaks is nearly impossible with how it is implemented because any allocator will assert on failure, for example if there are objects left in allocation when the allocator gets disposed. I additionally wrote a static allocator working on a small fixed size memory block on startup, to allocate any other allocators in instead of the new approach the article describes
  5. We are still looking for at least one experienced co-programmer that will work on the system with me together
  6. I use windows with WS_OVERLAPPED set but don't use AdjustWindowRect, instead void Surface::Size(uint32 width, uint32 height) { RECT rect; Drough::memset(&rect, 0, sizeof(rect)); GetWindowRect((HWND) handle, &rect); SetWindowPos((HWND) handle, 0, rect.left, rect.top, width, height, SWP_NOMOVE | SWP_NOOWNERZORDER | SWP_NOZORDER); } does well for me
  7. The main question is what else runs in a different thread of your game? It dosent make sense to split a sepratate thread for timers if you have 10 other threads running whatever logic in the background. Animation is usually done using the time delta from last frame to current frame. I don't know any kind of engine that uses a separate timer class for anymations. Time delta is calculated by getting the time on the start of last frame and the time of the start of current frame, this way you know how much time expired between your two frames and can mult that factor to anything, any animation, any movement and whatever you also have. In my engine, I use a pooling for tasks that may run in any thread my scheduler gives it so I start a timer in one thread and check for it in another one for example on update loop or when reaching a code part that utilizes the timer. This is the reason why timers and timing functions write in there docs to wayt "at least a minimum ammount of time before executing callback". This is because you won't have exact timing even if you run a timer thread because threads may schedule from the OS and if you have a large list of timers, it becomes an O(n) operation until your callback returns. I use high precision timers, so my "Timer-Class" is just an uint64 value with the CPU tick count. To get the time elapsed I then throw that into a measure function that calculates the difference between my 'timer' and current CPU ticks, thats it. Timers are in my experience barely used except for gameplay features, anything else that is frequently updated, like ingame-time for example, is usually bound to the time delta of the frame
  8. Shaarigan

    Finding and Choosing Libraries for C++

    There are two very good resources for anything you seek in the C++ world https://github.com/fffaraz/awesome-cpp https://github.com/danistefanovic/build-your-own-x
  9. Shaarigan

    Game Tools programming

    This is a difficult question because doing tools is a wide range of different topics. A tool is just usually a console supporter program that solves a task, what task this is is up to you. Usually a tool is based on a console program that takes a few arguments to control the work of it, maybe with a graphical interface, mostly there isn't. You can write tools in any language you know/ are convinient to work with, the trend tends to more C# based tools and this is what I do too. However, there might be needs to also have tools written in another language like C++, if the engine core code that provides access to certain feature (for example ECDSA signing) is written too in that language and you have no chance to create an interopt layer between that language and C#. In C/C++ based core code this is for example possible using CLR/CLI or the DLLImportAttribute. In my case, I have a core dll that contains some usefull C# classes I've written for my tools. Foremost the AutoConfig class is very usefull because it matches the arguments passed when starting the given tool into a static or instance class so you won't need self splitting/parsing and processing your arguments instead map them to specific C# fields and properties. To the tool itself, this depends on the task you want to solve. If you ask for a more specific topic of something like for example "I want to make a tool that mixes two sounds together" then there will be more specific resources we can suggest but otherwise thats all for now
  10. Our team has grown to an acceptable state for now containing contributors from the 2D Art Design Tools Development topics but we still need some contributors in the 3D Art Game/ Server Programming Engine Programming topics.
  11. Shaarigan

    Architecture Advice - ECS without events?

    I have had some prototype in the past made with Unity that targets exact these scenario We have had a NoiseTracker component added to our guards that was bound to an event system. This event system has had a noice channel that fires each frame when the player does an action that may lead to noise, its strength and position. The NoiseTracker registered to this specific event channel and then decided depending on it's character component's data (Position,AttentionLevel ..) if it should ship the event call to it's character. This was C# and now comes C++; To implement a generic event handling system into my engine I took a look at what an event system needs to do and come to the conclusion that it is simply a static sync or async processed list of data that is dropped to certain audience. So what my event system does is exactly that, recording some kind of data that depends to the channel it is put to in a list and at some point, iterate through that list to execute all registered function delegates by passing each single data entry. To have the possibility to support several channels and also channels of the same data, I made a template for it that is of signature template<int ChannelId, returnType (Parameter, Parameter ...)> struct Dispatcher This way, we can not only define the signature of the function call that is an allowed recipient but also the structure of the data that can be passed to it. The ChannelId parameter lets one specify also different channels of the same data as described above. I've used it in a long-term test with different things but mostly Input handling with very good results
  12. Shaarigan

    Managing a growing project

    What I've learned from the years I write code now is that it dosen't always depend on comments because comments don't make a good code base. Thinking about what should be achieved with the code base before writing the first line is much more important because I ended up refactoring a projects logical structure in the past more times I refactored code from changing content. This is why I splitted large projects into a more modular structure where I have a core code base that is modular extended by functionality of logical different topics. In C++, this is quite simple by splitting the project into standalone projects and linking them together as static library while you havent this kind of convinience in C#, you can split everything up into several libraries to include into your final application. My development tools for the game engine written in C# stay all in the same directory but have there own subdirectory. Anything is build into the root directory (Tools). I then have a core library that contains certain subset of C# code that any other of my tools shares partially. This way I have the same code base for all my tools. Using my dev tools leaded to having a shell application that is dynamically loading my tools into one single program during runtime. It is capable to do all the build setup, remote attach to my game engine and even manages the code base by managing the modular parts in packages. I took this from NPM here but a little more simplified enabling my development process to dynamically drag in/out code packages/ modules of my current project depending on the requirements I currently have in this project. If you are working in Unity, you are something bound to the engine (I took Unity in here because you tagged just C#) so its project structure and building pipeline. But managing your modular code in several subdirectories should work here too and you are also able to declare code as your core or main module. Second, using namespaces. I know that this is a topic to discuss about because half the people tend to not use them while the other half overcomplicates namespaces. Namespaces are a great feature to logically split up your code into functional sections. This means that IO classes should live in there own namespace, encryption classes should live in there own namespace and so on. Third and least, keep it simple and be as lazy as possible.Simple class names, simple but meaningfull function and variable names make life easier. Using consts for constant values makes it easier to change them in certain code base and most of the time you just need static functions (from my experience) so making a class for everything is pointless. With being lazy I mean that a lazy coder wont copy/paste the same code, do repetitive stuff by hand (just like filling out a table of key codes) using some kind of quick n dirty tool to do the work and writes as less comments as possible except for those that are meaningfull too These are some of my experiences I made, someone will have other experiences made and at the end you have to choose what fits best to you
  13. Ok so I just complete two points that come to topic over and over again. Sure, you can create dynamic terrain in Unity as it supports dynamic mesh updates during runtime. I used it in a prototype to procedurally create grass meshes on the shape of terrain at where the player stayed. If he moved, the grass mesh needs to fit to the shapes of the terrain as well so I updated the mesh frequently. Doing terrain is the same, you have a mesh that consists of points with different heights. This is your base terrain, you know have to do some texture management that is also possible during runtime to place whatever texture is used at that given point in your terrain. You then need to optimize your data by linking larger equal parts together to reduce the mesh size in memory Second level is dynamic LOD. To do terrain LOD, you usually will split your terrain into a quad tree to determine the cells and cell deepness to display. Some old fashioned tutorials written in C did do this dynamically on camera position change, some other more modern games calculated just the lod chunks once and displayed one for another without recalculation. Last but not least, it depends on the requirements you have how efficient it is to generate your terrain as it may never change after deployment. Holding meshes in memory means consuming rare VRAM and not-so-rare RAM. Assuming a common setup you have 8 GB RAM and 1 - 2 GB VRAM to consume while hard drives reach 1 TB sin a tandard setup for today. This means you have more time in generating your terrain cells than you have while simply loading them from hard drive. This may make a difference depending on the kind of movement; A walking simulator will have less chunk reloads as a fligth or driving simulator
  14. The problem here is that you expect anything to work instantly on Windows, Linux, mac and whatever platform. This is just provided by the "generic game creation tools" like Unity or Unreal and you have to spend additional working to get it running on other platforms. Means something like Mono-Based needs to be build for .Net to work under Windows, needs to be build for Mono on Linux and as XCode project on Mac utilizing the Mono Runtime. We suffer this every day building our software for Windows and Mac, two different platforms means two different build pipelines and possibly API changes. This isn't something you would like to take attention to when "just prototyping a game" unless you have certain audience that creates the need to do so. You wont have the convinient one-click deploy you have in Unity or Unreal. This isnt really unnormal to development with unity. I last wrote a car simulation in Unity and most code was self written relying minimal on Vector3 and doing some transform in an update loop, anything else was too plain old C# code.I wont say "I don't use Unity's functions much so I don't use Unity much" because anything you do, launching the game, loading textures, materials, meshes propably and render the stuff is handled by Unity. Even the C# code is running on an internal Mono Runtime that is embedded into the Unity player. Unity handles your your Update loops, render pipeline and a lot more in the background so maybe you will read a little more technical about what Unity or a game engine really does. But if you want something lower level, you should concider if it is worth either to seek a lot deeper in the net and maybe end on something that may be more buggy as Unity is (haha, good joke XD ) or you'll have to spend a lot in achieving your must-have bullets with more lower level systems: I looked at but have never worked with Urho 3D, it is cross platform Angel Code supporting community driven game engine with an Angel Code extensible editor OpenTK a pure C# wrapper arround OpenGL, OpenCL and OpenAL implemented cross platform so you could setup your building with it on different platforms. Taking Assimp# in addition and you have anything on hands to setup your game in C# from scratch I've written my game engine/framework from scratch using just only OS dependent API code so I know how much work it us to setup an environment before be able to code a game with it. It isn't something you would spend just a few weeks on rather than a couple of years (measured in hobby time)
  15. Shaarigan

    A quick question about code

    What I would do is to decouple anything from that class and remove the update function so you can add an event to your enemy. If the enemy dies you will decrement a coutner and if that counter reaches zero, you will fire an additional event to respawn a new bunch of enemies. This can make your code cleaner and performing better. What is triggered in the OnSpawnEnemies-Event is then up to you (or the writer) to choose the right pattern (maybe add the pattern function as event listener). As I worked for years on different games and game environments now, I got the opinion that working with events instead of fixed update loop manager classes seems to be more efficient in code structure and when debugging the code. Also (except for Unity), you are able to parallelize anything more efficiently; but thats just me, you may think in an opposing way But what I learned ofer all the years is that if you can, think about it until you come to a solution that you think fits for this case, otherwise you will end refactoring your code any and any again
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!