Jump to content
SuperG hasn't added any contacts yet.
Posted by SuperG on 01 March 2017 - 01:03 AM
Posted by SuperG on 16 October 2016 - 07:07 AM
Posted by SuperG on 14 June 2016 - 05:40 AM
>> It's how often you combine these things into game objects like ships, or cars, and make new ones with tweaks etc. [/size]
that's what i call defining a new "entity type". IE a new kind of "game object". some games must do this often and have many people who must be able to do it with various skill sets, and some games do not. like most things it depends on the work to be done, and the size and skills of the team.[/size]
IE if you were going to bang out pong, pacman, galaga, space invaders, or missile command, etc. by yourself on weekend just for fun, you wouldn't bother with ECS.[/size]
As Norman Barrows stated. It depends on the game. The example there don't need it.
Personally, I like the Unity approach. You get most of the benefits of components without the unnecessary trouble that complete decoupling causes. None of the games I've worked on that shipped - or the ones that were cancelled! - used the "entity is just an ID" mantra because it buys you little but costs you a lot in terms of code clarity and predictability. Some of the people above will disagree, obviously.
Posted by SuperG on 13 May 2016 - 11:28 PM
Posted by SuperG on 27 April 2016 - 06:20 AM
Posted by SuperG on 24 March 2016 - 12:30 AM
Posted by SuperG on 19 March 2016 - 12:09 AM
Posted by SuperG on 26 December 2015 - 07:44 PM
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.
Posted by SuperG on 26 December 2015 - 06:34 AM
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>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!
My understanding from just reading a lot about it, is that OOD is more from a human perspective, also intended for junior programmers.
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.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
ECS is hardware friendly architecture, and designer-friendly architecture
Posted by SuperG on 04 December 2015 - 12:53 AM
Posted by SuperG on 03 December 2015 - 12:57 PM
I don't want to debate real physics but less than 300 years ago people thought that if you went faster than 40 mph you'd die from inertial forces.
FTL may or my not be posible. But if it would be a huge brake trough.
People less than 100 years ago said it was impossible for a human to break the sound barrier because the shock wave would kill you.
With our current understanding of physics it's impossible to travel faster than light but this doesn't mean it's impossible that we'll ever travel interstellar distances in practical timescales.
After all if a cave man saw you driving a car what would he think? It's science fiction to him, not science fact.
We can't speculate about future science and say "this is believable because it seems like what we have now", that makes no sense because the real world has proved future technology is a thing we struggle to predict and can't ever imagine.
Back when star trek came out they thought that in the 23rd century a computer would still be the size of a large room.
How wrong they were...
Sure, but that doesn't mean that these " relative easy" barrier's are broken. That anything can be broken! It could even be that the most advanced godlike alien somewhere in the universe are bound and isolated by limit of C
I'm surprised no one mentioned drones yet.
When I think of a "realistic" scifi space combat, I tend to think of a more "Drone carrier" ship launching drones out of a railgun at insane speeds, which then seek out targets and communicate that info/attack.
Or maybe fusion powered lasers that disentegrate anything in their FOV?
Autonomious drone which also could be used remote. The Pilots are on the drone carrier.
Also with advance tech and miximg tech a fighter drone missile mine got a bit merge.
In space a cruise missile could have FTL so a big engine thus big and expensive missile.
With high velocities there often is no need for warhead. But some mass
Posted by SuperG on 03 December 2015 - 12:54 AM
Posted by SuperG on 02 December 2015 - 12:01 PM
Posted by SuperG on 25 October 2015 - 04:14 AM
Posted by SuperG on 01 April 2015 - 11:44 PM
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.