SuperGMember Since 06 Oct 2007
Offline Last Active Oct 19 2016 11:55 PM
- Group Members
- Active Posts 77
- Profile Views 5,426
- Submitted Links 0
- Member Title Member
- Age 46 years old
- Birthday May 23, 1970
SuperG hasn't added any contacts yet.
Posted by SuperG on 16 October 2016 - 07:07 AM
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.
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.
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.
Posted by SuperG on 13 May 2016 - 11:28 PM
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.
Posted by SuperG on 27 April 2016 - 06:20 AM
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.
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.
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.
Posted by SuperG on 24 March 2016 - 12:30 AM
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.
Posted by SuperG on 19 March 2016 - 12:09 AM
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.
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
A stargate SG1 episode. Where they remotely controle fighters planet side.
Avatar where even Character Get remote controled.
Farscape where pilot brain connect to ship systems.
Movie where you float in chamber having full spherical monitor view outside the ship and by Wii like gestures like bunch give fire commands and direction it must go. For the turrets with the best arc for that direction. You become the spacecraft.
Andromeda where fighter can be manned but also unmanned used.
So yes make sense a remote pilot could lead a sqaud of drone Fighters.
For interception for long range bogey these drones could stand High G force launch to get up to high speed for faster interception. Then manned fighter could .
Most weapon tech depend on huge engery out put.
So a drone with gunpowder gaitling gun and missile rack. When depleted of it few misiles it get much more agile and become fast dogfighter.
Bigger ships with there fusion reactor have railguns and laser
For railguns the muzle velocity and mass is in relation to the energy it needs.
Short low power railguns could be still much better then gunpowder. But longrail gun wher a gun with the same projectile get a long range canon class railgun.
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
For me this a easy choice as I so not into MMO.
Competive short online sessions I do. But this type of game doesn't need to fall under that.
Co- op maybe. As in crew on the same spacecraft.
But I would more go from making the soft scifi more hardcore.
Then stick to real science and keep that as pure as posible.
But if I keep real space up to scale. Then distances got extreem. Then I need this FTL fiction. FTL may or my not be posible. But if it would be a huge brake trough. I expect that these engines are huge and the powerplant extreem to.
So what I drop is roaming space in a Fighter, with FTL drive the size of ipad? With Cargo bay? And only single seat cockpit?. That a no go for me.
Also Spacecraft is no plane no submarine no naval thing there is something in common with all but also very extreem differences. So it make sense to not start in a fighter that the more airplanes in space combat. But in a spacecraft. You have to travel and trade so it has a lowest and older tech FTL drive. Which is big engine plus power plant. You have cargo bay and living space no cockpit but more small bridge. Which means not agile. So if heaving weapons they are for defence and probaly be mounted on turret. No dogfighting .
My guess pirates in deep space make no sense but do make the game more interresting. So I keep them. If they want to take your ship or cargo the need to match your speed. In that case a docked heavy fighter make sense as gun turrets do come with cost of space mass ammo and power needs.
In this case dogfighting situation do come along. In military combat it isn't about matching speed but take out keeping your main high velocity vector. You see you bogey on sensors screen filling. But not looking out your cockpit.
Another fiction I keep is shield tech. Because combat could be often one hit one kill. How ever there efficiency depend on there tech level mass and have high power need. The heavy fighter or better gunship have the smaller once.
Spacecraft construct. Want some realism there to. fTL works in some specific way so these engines could be part of ship design.
Fusionion drive as main cruise engine. Best power mass and fuel mass ratio.
Fusion plasma thrusters for planet side take of. Best power mass ratio. Less fuel mass ratio.
So with each ship type you need a balanse between these engine.
Less fusion power thrusters no planetside landing capability.
Also in setting where there are centuries of space colonisation mining and exploration and warfare. There are centuries of space ship types with wide tech settings.
For me space craft design would need to be procedural following techlevel.
The problem with design good looking concept space craft. The often conflict with physicaly realistic simulation model of thruster placing and structure strength.
So for planet side landing vessel you wouls see something build around large fusion ion drives.
Or at least see some big fusion plasma thrusters.
I space craft like in the movie Promethiouse make sense.
There is also choice to make on mass. Big FTL or lighter FTL vs landing capability.
Posted by SuperG on 02 December 2015 - 12:01 PM
If you last defence line track even the smaller projectile or the very fast. Half the response time is good thing. Also it is more stealthy to go passive.
Heat is also a problem. Optical sensors would be full range above and beyound the visual band.
Also stealth is limited obscuring background stars and a modern advanced space ship computer could proces the sensor data to detect the more stealthy . Where high fidelity small arc zoom in sensor inspect the annomalis in 360 spere arc detection.
As such space craft 1 AU away are screen filling.
Kenetic weapons are effective because speed is quadratic factor.
Laser puls canon is means to snipe with a almost 1/3 delays at 100.000KM range.
A space craft build around the canon make sens.
Space craft could be realy big lightweight. With a lot of reduncty to be able to take lots of kenetic hits.
Large spread out sensor array.
It is posible to tweak the fun and game pace with how much and wich fictional tech your wil using in the game.
Missiles are on it own in effective but in swarm over run point defence turrets.
Space shot kun to take out as much sensors. Blind vessel. The a swarm missile get more effective.
It also seams that it might not get a fighter dogfighting gameplay.
I am thinking a lot about this. But there are a whole lot of choices to make.
And practical warfare is a arms race where both parties adapt to what works and what not.
In reality there should also besides the units that worked very well also the dead ends . If tactic change what did not work could become effective.
For this thing the FTL drive. For me that fiction tech should be rather big engine needing a very extreem high energy use. So notting less then a fusion plant or extremer. Especially for the faster FTL.
A agile fighter or drone won't have FTL. Or there smaller very weak once for the upper limit sub FTL.
Like a corvette
Posted by SuperG on 25 October 2015 - 04:14 AM
Which faded away out of my head.
For modern game programming. ASM is a to low level solution C/ C++ is as low as I want to go.
If I go for ASM then it wil be for practical use of those modern CPU extentions.
Math libs using SSE2 as its very common in mainstream CPU.
But AVX AVX256 and the upcoming 512 is not. First for fun. With practical option for it.
It will be very new to me to.
Posted by SuperG on 01 April 2015 - 11:44 PM
If you have many fleets some might be reserve to re- enforce or replace battle reduced fleet.
Ship damage comes in light and heavy. Light can be repaired by ship crew medium need repair assistance heavy damage a repar frigate. Or equipment dock. While severe damage means shipyard or repair dock.
That means depending on mission impotance. Some mission have a high priority and are crusal for the war. Then ships go all the way. While less urgend missions depending on damage, ships return to shipyard. Or fall back to the support group.
So as commander you can set the urgency of mission and treshold when to go to defensive stance to where return for repairs.
Repair are costly but lot less then build a new ship.
Posted by SuperG on 24 May 2014 - 11:11 AM
Well I think there would be a better way, or better a most less wrong way. Or better you need to decide in allotted time what to do and what could be done in time. Which often is a compromise. When is there the time to do it right. it's done when it done.
Example of more health. Any thing could influence the gameplay. Health to more leeway to take huge risk. Faster pace more rushing. Other way
like If enemies are less accurate, you just keep more distance but in close range it doesn't matter. Games could be linear and corridor based with lots to close encounters.
More health means. Much more time to react. Making wrong responsive decision don't weight that heavy. Having much more chance to get through a ambush. Wenn not you move slower and more observing to spot first the opfor dose you.
What this means if you go for action rich epic story regular game are hanging back. Might not be the game flow you intended.
I do think there is a right way but it's to costly to develop.
You also need to know very much about the gamer. Ask that when showing the difficulty screen. |then the game adopts to player in way he prefer.
If you are into deep story you want a good story flow game experience. So don't replay a part to much better not at all.
If you are a action gamer you want to have fun it's less about survival but more ammo rich environment. high number but effective weapons.
Then those very hardcore player who want to be challenged.
these kind of gamer exist in all skill levels but need different adoption.
Also mostly the game flow difficulty is very variable. While mid and end part should be going up they could be walk in the park, but there are point replayed dozen times.
A very costly to implement way could be. Taunting and reputation. If you are good the AI adapts to more care full approach. Calling reinforcements before they going in.
while if your barely move forward. The opposing force get more risky and let it know by letting you know your time has come and going after you without backup.
I more a games who want to shoot and just follow the story line. Having some core gameplay action. Without end bosses QTE or cut scenes.
Normally I choose Easy or normal. But some games Hard is easy.