• Content count

  • Joined

  • Last visited

Community Reputation

1300 Excellent

About SuperG

  • Rank

Personal Information

  • Interests
  1. I have the same problem. I notice this. If follow John Carmack , yes his step from C to C++ is very old one. His newer adventures also years old back is with Haskel. So that Funcional programming with pure Functional languages. in these day there is still C but C++ is C++ C++98 C++11 C++14 and C++17 so the long livaty of C++ is it legacy support and it still evolving. D is the language is the one wich drops legacy i Notice hard defending of OOP. But I also Discovered the combination Functional Reactive programming. Because CPU get many more cores so side effect less , lockless programming and much easy way of archieve that with paradigm that support it from it core. Without being guru to tackle that major problem of concurrent and parallel programming. In paradigm wich seams to come from the single core time. John Carmack interrest in Functional programming has to mean something. What is the relation of functional with DOD
  2. There are much more reasons for ECS then performance. In that case Hardware is important and the most obvious thing about current hardware is many core CPU so Multithreading in efficient way. AMD is comming out with friendlier priced 8cores with SMT. So 8cores could become the new 4 thread limit. So utilising future CPU and wat mainstream wil become is supporting beyond 10 threads? Those other reasons depend largly on what type of game you gonna make and if ECS is solution that support specific features best. ECS in the DOD way offers this. If you game have high numbers of entitys. If you have lot of different types of entities. If you can assemble types in runtime. If you want to procedural generate types with different mix of components. If you want to change entitys runtime. A bad case for ECS is 1 on 1 counter sniper game with complex balistics. A good case is game like Arma where few units spam bullits with 2K to 10K Rounds per minute from gatling gun. Mounted on armored units air units attack heli in large scale warfare. A even better fit would be space game where there are no fix classes but design units in game with procedural but can also load design in or designing ships is part of core game. ECS for game like Pong or tetris clone. Then ECS might be huge overkill solution. My idea of space game is like as with cars naval ship. In Century of carse there are a lot of types spread over years in the few hundres so procedural need. Naval most ships have a specific design and there are only few build of the sane type and bigger the more uniek they are. Also lot of diversity. I expect the counter part of T- ford to bugaty Venyon in space. But also naval counter pars of century of torpedoboats and nimitz class carriers. Many types of bombere fighters frigates of centuries of space Warfare. Often you don't rely on ECS but my case i might need it badly.
  3. UML diagrams for video games

    The way I understand it. UML is a standard. And it explains it self rather very well. The L wich stand for " Language" It purpouse it to communicate Modeling. If both participant know UML then they communicate the model to each other. If only one ore none knows UML but uses there own way of expressing model. Sketches. Then they need to explane what it means to the Other. Me thinks in specific branches like game development and small teams The use of it is often not needed. But in large corporation with huge teams and lot of junior programmers its good thing to speak the same language and know the same modeling language. In software where there is lot of change and no clear target as in games. But in large scale bussness software where there is legacy stuf from decades no drastical changes. But if new employer come in they can read the UML and see the bigger picture or that part of the package or module. Two fictional examples. Mostly in UML example they come from bussness side. Like bank where your department team design the ATM software for specific new ATM model. In this case the use cases are clear also as it done before for older ATM models . In your team are two new employers. If corporation uses UML and the new team members knows UML . Communicating the job can be started right on. Indie dev team of 5 experimenting with new idea going for prototyping a few ideas How do you usecase gameplay and fun. Where most are self tought programmers and there dev experience are of one man to less then 7 teams . No UML. Sketches wil do. My experience as first impression of somebody else software base. A DX11 example bundle and framework. Then I compile that frame work of other dev from internet as DX11 example bundle . You see long list of project which depend on other projects in that list where some project are end app tech sample demos using the framework project. Mixed in that long list. With in each project there is huge list of .H and Cpp files where there is no insight of dependancies. In my own very little pet project it not a problem one project and a short list of files. My own project are so small I don't need UML. I am alone so for Communicating with myself. Make sense after 6 month I have no clue what I did. If my project got bigger. It would be nice.
  4. Multithreaded renderengine is not the same as a multithreaden game engine. To me it means the render system or component and render backend is that multithreaded or not. DX11 supports multithreaded with defered contex , but the result of that , it doesn't yield much Gains. With Mantle and DX12 and Vulkan is it possible to use eficently multithreading for rendering and ACE Asynchonoc compute engine For rendering compute and kopy Engines That means if your game load and GPU settings are CPU bound. Like a huge amount of drawcalls. And with these new efficient low overhead API it factor 10 x or so more drawcalls are possible compared to the old API. So to me it seams do you want to render multithreaded and go wild with drawcalls then you need DX12 or Vulkan. Where the game engine often already is multithreaded and there is also the same isue you can do it easy way with low or limited gains , or better advanced ways where you can gain a lot. Multithreading game engine is is something differrent then multithreaded rendering. The last is specific the new API and the whole engine is complex topic to not only multithread tread save but also do it efficently so to scale well on more cores. But also beyond 4 cores. But the render component is part of the larger full engine so there architecture need to fit very well so they are strongly related. So I would read into DX12 multithreading. Don't know yet if my DX12 book dives deep into that matter.
  5. X- series I have a lot of fun with . But not Rebirth which is very different . The problem with Egosoft is small budged complex game production . A production that don't fit within budged . Bad decision to try go for consoles . Where unfinished rushedout games are blocked . So there 1.0 releases are Alfa sold as Release games . Where 2,x are Beta . Depending on mod community to fix thing to finish gameplay mechanics and making it feature conpleet . Because at that time there wasn't anything big in the genre . They where the only one I thank them for supporting the genre . Now the genre got mild revival . They did some thing right compared to current big ones . And that staying away from MMO . Biggest problem is A cumbersome GUI that not fully implented and a hog to handle the farious gameplay the game offer . Yes they did have carriers but with no GUI and gameplay workt out for it . There where mod to ease the pain. So because my interrest in game development I get strong impression that these complex games depend highly on strong AI and GUI development . As one person can not manage a whole nation doing work of milions and babysit milions .
  6.    As Norman Barrows stated. It depends on the game. The example there don't need it. Entity is just a ID is used in the Data Oriented Design. The value of that and its features used in pure form might be noticed in much bigger game. The way it noticed is if you got a lot of something. If entity need to change component on run time. Move components in memory. Make new entity by combining components even in run time. I think it would be noticable the benefit if your making a game. With the scope of. A Space tactical stratigic game , where game is about * In game design ship types . By player content driven game. Not just data driven but beyonpd that. * in game tweak components stats . Bigger ship can have bigger guns. * build fleets . * And watch the AI fight it out or act like armada Admiral player vs player etc. * if you got carriers with dozen types of Fighters etc. It makes Entity in numbers very large. * drone frigates it can make entities insane. Launched 300 or so in a X series game. * Missile frigates. Missile barage like Egosoft Xseries Then a more pure form of ECS the DOD way make sense. There are a lot of games from small to big there is not a lot of something and no need to mutate objects. So it make no sense to go with ID for Entity. But there are game concept where it have great value.
  7. Correctness as in contex as thread save. Avoiding deadlocks or share data that depend on order it prosces from few treads. If it save it correct as no deadlock crash or corrupted data, but not parrallel as if you trow a tradfic light on place where many lanes garther. My guess is to use parralism to the max the software solution needs to be designed with parralism in mind not only thread save. Making computation as non dependant and avoid shared data. Avoiding deadlock by design and critical section stuf.
  8. OOP and DOD

    Yes it is confusing for beginning programmer like me. But this is how I see it. By my observations and readed articles about it. OOP is way to handle growing complexity as software base grows larger. It a way to split software enginering over many Programmer. Tackle large scale software engenering. I think. It is learned in software enginering education so it where beginners start to come in touch with it. As I did not have that education OOP is as vague to me as DOD. But I am into C++. As for games they say start smal like a phong clone or space invader. Then with a language where easy'er to start in and full supporting OOP. Make little game that runs everywhere even in browser. Like java. Or C#. They say DOD is about optimisation but its more. It is also about hardware knowledge and build a solution that fits hardware at best for a very performance and tech pushing software problem. That last is crusial part that makes DOD relevant or not. As the best example of this case is. Where you have high need to push the hardware. And the hardware is very sensitive for OOP misbehavior. And you problem there is lot of thing to compute. So first you need to know if you need DOD. 1 ) A platform exclusive means you can focus on optimise and learn the platform and it architecture in deep detail. 2 ) A platform that much more sensitive to OOP waist of bad memory acces pattern where compare to common used CPU 3 ) a software solution that need to get the most out of it. 1 ) A console Exclusive! 2 ) A in order cpu with lack of big caches but predicable cache latency, a excotic beast the Cell CPU of the PS3 is. 3. ) a PS3 triple A game exclusive. But not exclusive there are exception, like for crossplatform titles to get PS3 up to level of other platform might need to invest in PS3 port team with same need to delf deep in it architecture. Studio with dedicated game engine team. Can do this to. That why some of the pro DoD article come from developrs who worked on PS3 exclusives or advance port, like a very hardware demanding cross platform title to utilise PS3 to it fullest. Like DicE Thus DOD is about high performance computing and hardware knowledge to take full advantage of it. It where advanced software enginering, meets hardware architecture knowledge. As a next step beyond a advances and experience software engineer. Who need to be expert in architecture to. This means that for console release exclusive, this expertise of platform is starting to grows with each production.The next big title 2 of the same dev they get more knowledge get even more out of it. So sequel 2 on the same platform looks much better. This keeps growing to where the 4 th big title get even more out of the platform because of the growing platform architecture knowledge and game show this leap in understanding of the platform. And then nextgen comes. These DOD guru need to learn a new platform and it architecture again. Where small titles running on whatever platform it undoable for smal team to figure out multi platform Or don't have the resources or the game is not that demanding. As for PC you have this wild configurations posiblities. From game related articles DOD seams to fit ECS very good. The reason that DOD ECS examples can perform worse then OOP because it tested in small tech demo example where there often is no deep knowledge of the platform tested on. Often these programmers have high OOP skill but DOD is new . Where platform often can handle small scale OOP bad behavior because CPU it designed to handle most common software by having large caches, out of order cores and advanced branch prediction units. And the DOD solution uses probaly the wrong data structure. Or the array size is to small or the mix OOP with DOD where OOP works as anti DOD Patern. Also those who sucesfuly utilised DOD on PS3 CELL. Also uses thos SPE units all 7 minus reserverd ones. So comparing DOD singlethreaded solution to a OOP single threaded solution is not the real practical gain. As hardware architecture for DOD is crusial so is multicore CPU use for them. Also a unused iGPU on APU is wasted architecture compute power usable with C++ AMP OpenCL or DirectX compute . Most DOD examples are ECS based and uses often a OOP mix. So first you need to have a game idea that is so demanding that you need those 8 cores . Know the hardware as deep as posible. Which bit limited on PC platform. But C++ is also for managing memory. So to me Java for DOD is step back. It best to delf first deeply in the theory, then follow programmers that just start using DOD and draw hard conclusions, often fallback on OOP very fast. Thus DOD mixing it with OOP. And DOD turn out bad. So have bad experience with it. A good start is Richard Fabian online DOD book. As it hint to DoD solution for OOP solutions, that important if you know the OOP way but Running into a wall with DOD. My guess is its big advance topic and that online book explains it deeplier then any one does to my knowledge. So what do the expert here think about that online DOD book.
  9. Unlimted speed & memory No need for optimisation, auto or compiler wil do. The highest level of language wil do. So you can talk to the computer in human native languages . And feed it with full mathematic writing. Using the full formulas for every finegrain computation. With very fine delta time of 1 millie sec for physics computing . For each NPC AI & AL can be implemented in most full & complex way. Even rendering optical sensing for AI and run analistic computation on that for every AI NPC. So to 3D sound. Game worlds and all it objects and entity are photorealistic and full interactive. With full material atributed in volumetric way. Like also material based destructable.
  10. Some say early optimisation is a bad thing. But it could be mostly true but not that black and white, more be a 20 to 80 rule that there is lot grey area. Some post upward it mentiond that ECS is multithreaded friendly . Multithreaded is a optimisation for scaling and higher scope games that got and wil be more important as utilising modern cores. While quad is mainstream now we going beyond 8 plus hyperthteading. It isn't about thread save only, but also effecient parralel computing. ESC using more pure Data oriented design support that much better. As efficent parrallel computing relies on software architecture and method paradigm used. While OOP and ECS and DOD are mixable. But some benefits of DOD could be destroyed by mix it with OOP. It could be that some ECS architectures perform bad because of that. For small games where scaling and heavy multithreading is not needed its no isue . That my observation by reading a lot on ECS. And are interrested to in ECS scaling and use for big scope games.
  11. Game Engine Architecture: what's after that?

    The advice is valid and I have the same isue. But if the goal is to build a engine for your games. The advice is to make a game and engine wil show up after iterations and refactoring to reusable architecture with split of framework to engine and the game specific part. That make sense! But instead of Game to show of your engine. I think that needed for large engine team who there engine is the licencable product need a game that show of the game engine. You get a full game which feel like tech demo but is full game. IDsoft first games of each IDtech engine. That make sense! But we are beginners. Not big engine building studio or team. It doesn't have to be a full game. But a short basic barebone short core feature showing tech demo. Like short minimal feature playable game. That means your first version of your first playable tech demo. You need only the most needed features to get this first minimalistic game running and full playable. That means it will very light on content. Using simplistic asset done by engine programmer. No need for content production pipeline. Because that get hard needed when you go for full game and need lot of assets and levels etc. Choose if simple MPlay like splitscreen. Or NPC not both at ones. Add one feature per iteration. Or shooting NPC which are light on AI. Like astriods for space shooter. Zero AI needed. Go for pure procedural first so the need for artist is low . That the plan I go for. Also often these example source code do work. But if not debugging and get working is big learning experience. Also what I did is rip a depricated math lib out and put the current in. Go from 32 bit build to make it 64bit build. And I drop the 32 bit. I got both books. But they are bridge to far. But shows what is the end road and it a lot of features big and small. So long road to go. Like they both mention memory management. Like my old dev PC is a memory limited platform. Not for the first 100 iterations for a demo. It got 8GB with old quadcore from AMD. It not the sinclair ZX81 where you bound by extreem low amout of memory. And for the first low number of simplistic dummy asset a big enough memory waisting memory pool wil work. For now. And Reusing objects. How ever at some point where you get to make a full game the asset needs wil grow and memory footprint grow and then more advance memory management is needed. Also where you come at point to release a demo, having memory management keeping using to much might make your target audience smaller. But then again its tech demo. I would priortise features from the minimal game demo and add and refactor for the next feature that make the most sense like depend on existing implementiation of features. A good example are astriods. No AI as they are not NPC and no Mplay needed. To make it chalanging there can be a lot and moving fast. At some point there comes a enemy space craft but not before static mines. Then defence satelites. For FPS shooter Classical zombie. No need for advance AI. But before that to avoid animation, some low tech robot like man size big vacuum cleaner but with a weapon. After the 250 next feature itteration the demo have nice feature pack so does the engine . In my case I go first for the most abstract and feature poor minimalistic abstract space shooter tech demo, that could grow to big genre merger and stil be in demo low asset state. And sticking with procedural content.
  12. Unity Structuring a Simple 2D Engine

    Simple game might have a very limited number of features. So a very basic game engine with at least those few features will do. 
  13. Yes, the first experience for me with that was the first Crysis game in Editor mode. The way I played it. With little mutexes. The reason is to make those large art teams as productive as Posible. With script coder artist and game designer a total conversion means a new game. I got this FPS weapon balanse idea. But I also want to learn C++. So I have 3 pet projects one is a game, to do it myself or at least try to. But for FPS where my focus is more on weapon balanse and realism or simulation. I think Crytech engine wil do where you can choose out of 3 script languages c++ C# Lua. Even a balace mod wil do. Triple A studio have huge art teams that the way they are in the big league as you need huge capital to have large workforce. So a very data driven engine is key to productivity of those work forces. Of course with a smal team you have a small art team you can still make GFX rich games but not that rich in assets or high fidelity. But not all games need that. A Mass Effect high profile title vs the first Counterstrike. Total conversion mod of other game. A other way to get quantity with small team in assets is go Procedural generation. These solution complement each other.
  14. How to finish a game

    What a coincedence, I have 3 little project in the pipe. Hobby projects. One is little text math related app. Then a DX11 based guitar related math app and a little 3D space game. Have a idea for a FPS game. But I also decided that 4th is way to much even a third to. For the game, to keep the larger scope a bit, instead to go for full game, a demo wil do or technical demo. As long as it is fully playable and show the core features.
  15. Not really. The whole "human perspective" thing is a trap, which leads to the dark side of that "traditional OO bullshit". Every OO course starts with "in the real world we have students and teachers, so let's make a Student class and a Teacher class! Also in the real world students and teachers are both people, so let's make our classes inherit from a Person base class!". No. Bad. Stop.A class exists to hide the implementation of an abstraction. It takes a particular representation of some data, enforces invariants on that data to allow axioms to be formed (to allow the program function to be easily reasoned about), and presents a different (abstracted) interface to manipulate or view the data. The stereotypical classroom example above completely misses all of this. When deciding to create a class, you need to know more than just what data you have (e.g. personal details of students and teachers) -- you need to know why you're storing it, which is to say you need to know how it needs to be transformed and/or viewed. Once you know how it is transformed, viewed, and stored, then you can build the abstraction that links those 3 facets, and you can discover the invariants that need to be enforced. You can't just make a Student/Teacher/Person in isolation, you need the context of what problem you're trying to solve. If you don't know what the abstraction is, or what the transformation is, you can't just go and make a class. This means it's not any closer to a "human perspective" than the procedural paradigm.OO is meant to make programming easier (than pre-OO procedural programming), but that does not make it a tool for junior programmers. When you achieve the senior rank in any discipline, you don't throw out all the tools that you've mastered and start doing everything by hand just for the hell of it. You use the tools that you now have a mastery of! Well your reply actually is more fine detailed explaination of "it, is that OOD is more from a human perspective". Because more is not the same as equal. I don't imply that you take real world 1 on 1 to software. And then we are spot on! If it where that easy everybody would be a OOD guru. Or no need for. It more in large line of things, it more like RL then what I compare it to. That data oriented way of ECSHow the hardware see it, cPU core ALU who like to be feed data from neat cache line aligned array of POD from slow memory, where most or better al the data is used to get as much cache hits then misses. But also there are a lot of pitfalls etc wich a DOD guru could explain better .It is about the details. There is whole online book about it.But rough line to get a idea for introduction is. " from perspective the hardware likes it."Where it is more thinking about data first.And with that it make sense that people do understand RL even if not be programmer at all. But thinking about data structures you need, from a novice point is much more daunting.Also I do not expect junior programmer understand hardware architecture at high level even where most senior programmers don't. So yes OOD is much beginner friendly as is easier to comprehend.I notice that novice programmers have problem understand DOD and mix with ECS because they don't have the technical background. For most programmers is PC a Blackbox. If you start programming then comparing to real world is way to explain thing to novices. But wenn starting programming and find a solution from data structure centered perspective is like a bridge to far.As novice programmer it not easy, but I have a technical background altho limited and old. Z80 6800xMore then 20 years old. When memory was as slow as CPU was. As part of my electronics education at that time TTL logic and IC. That give me some preference now for the DOD way. It still is black box but bit more grey opaque to me. To me ECSEntity : Key a ID Component : component pod in arraySystem : component manager using the array So discribing OOD vs DOD in one or two sentences means no room for fine details. There are plenty big books for explaining the pittfalls and anti patterns and more.<blockquote class='ipsBlockquote' data-author="Servant of the Lord" data-cid="5267914" data-time="1451062113">Servant of the Lord, on 25 Dec 2015 - 5:48 PM, said:<p> That's not necessarily true. It was initially conceived to be designer and/or gameplay programmer friendly, but not necessarily performant.Early ECS engines focused on keeping gameplay programming manageable in massive games, by allowing unknown components to communicate via message passing -- e.g. a fireball spell could announce "heat damage", and then any number of components could respond to that message. A fire shield might filter the message out, or a heat-susceptible cloak might add extra damage on top.Other ECS engines focused on making gameplay behaviors data-driven (not data-oriented), which is another way of saying "programmed via config files", which allowed game designers (not programmers) to construct new entities and built a lot of the gameplay.It's fairly recently that data-oriented design has been applied to ECS in an attempt to create hardware-friendly versions of this (loose) pattern -- many of these new versions though are very different from older ECS engines... It is such a broad term these days that it's almost impossible to say that ECS is anything :lol:Your right about that.The older engines like used in Thief, Dungeon Siege, etc... weren't called ECS though; they were called (if I remember correctly) Component-Based-Design. Years later, when the architecture solidified somewhat more, people started calling it ECS. In my mind, ECS is a more specific architectural pattern that's semi-solidified, more cache-friendly, and is a type of the broader category of Component Based Design.At least, that's how people should use the terms.