Jump to content

  • Log In with Google      Sign In   
  • Create Account

SuperG

Member Since 06 Oct 2007
Offline Last Active Yesterday, 10:56 PM

Posts I've Made

In Topic: Is it worth learning a language if I only want to do game development?

27 December 2015 - 04:47 AM

To be honest game engines(at least the big mainstream ones) are getting much more point and click as the years go on, more time and effort is being put into trying to make engines that are easy to work with for non-technical people like artists, designers, etc. It saves a lot of time and money when big companies don't need to hire a dozen programmers just to make tiny changes to an engine to do something that the other devs need/want in a game, so the suite of tools you get is relatively impressive.There isn't much reason to learn coding just for the sake of learning it, you can pick up the very basics of a language in a day or two, but learning all the rules, complications, ways to make things happen on different platforms or working with libraries, those things take years to learn. In the case of just wanting a game you're basically avoiding the experience all those developers making the toolsets have accumulated over the years, just to have your own crack at it. That's fine if you want to be a programmer longterm, but not exactly efficient if you just want to develop a game. It'd be like learning to cut down trees and saw them just to make something out of planks you could pick up from the hardware store.I could also point out those engines just save insane amounts of time even as a programmer, I couldn't even begin to explain how much code and time it saves just using those engines. Even if you're experienced enough to know how to do those things, the fact is that they are already done for you. It isn't like we all have 'fun' writing what amounts to almost boilerplate code to set up things that have been set up thousands of times before, but in a slightly different environment.

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.

In Topic: How to finish a game

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.


In Topic: Replacing ECS with component based architecture, or traditional OOP, or somet...

26 December 2015 - 06:34 AM

My understanding from just reading a lot about it, is that OOD is more from a human perspective, also intended for junior programmers.

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>

ECS is hardware friendly architecture, and designer-friendly architecture

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. 

In Topic: Replacing ECS with component based architecture, or traditional OOP, or somet...

24 December 2015 - 10:28 AM

In the C++ (and Java, etc) community, "traditional C++ OOP code" usually doesn't follow the actual teachings of OOD at all... so it's not really OOP code :lol:
Most of the blogs where people try to set up this dichotomy between OOP and ECS as two radically different schools of thought, are written by people who only know that "traditional C++ OOP" (i.e. they don't really know OOP at all)... and their conclusions aren't necessarily correct. These people have been burnt by bad code that people incorrectly claimed was OOP, and have decided based on these claims that OOP is bad and wrong and doesn't utilize composition very well.
 
Real OOP puts emphasis on making larger, more complex objects, by composing them out of simpler components. So a good OOP design will actually be similar to one of these "ECS"/component designs.
If you want to learn C++ game programming, you don't need a big framework to get started. Just write the code that you need, solve the specific problems that you need, in plain C++.

Yes using often simple bad OO samples.
Me as a novice it hard with al that bad or out of contex advise.
So I read a lot of articles about it and there are some who have problems with ECS.

My understanding from just reading a lot about it, is that OOD is more from a human perspective, also intended for junior programmers. Also novices like me. As it easier to reason about.
For simple games it apperently does not matter much, both solution even not so good ones might do.
But ECS has also a hardcore part and that the data oriented ECS kind.
Which make sense to. It is from the perspective of the hardware. This means that it is
Human perspective vs hardware architecture knowledge. To me it means as a software engeneer to get the most out of software you need to know hardware to best use DOD ECS. And the problem with this it start late to out shine at huge complexity level then OOD and parrallel computing within these Systems.

To me if your make a light game in java or C# or any other high level language OOD and basic OO agegration or OO- component based OO ECS will often do to .

But if you game has high performance demands and has huge numbers of entity or componnents and run on many "in- order" cores, CPU like xbox360 or Cell PS3.
Then Hardware matters and to engineer your software how the hardware likes it .
Using C++ and. This also means that very experienced programmers who know software but don't know the hardware in dept. Could use it wrong. Or don't get the most of potentional out of it.

Also for very experienced OOD dev I get the impression they have this urge to force there OOD solution on DOD ECS on the first sight of a problem to solve, braking the benefits and blame ECS.


I get the impression that DOD fits ECS well. But often OOD does the job to. And these methodes can co exist in the same code base. But be carfull to mix it within it core.
I have no ECS experience and am a novice C++ programmer .
But I fall a bit to the more pure DOD ECS solution.
DOD ECS of Richard Fabian
T- machine.
They also give a link to relational databases.
My interpretation of that is. Sure the acount or autorisation for MMO could use MySQL. Not suitable for game engine.
But from gameengine it can be a specilized implementation of relational game data base engine using data on harddrive and buffered in memory. As the components in array. Using custom memory manager.

So get the impression that OO is miss used and gave bad experienc, but also DOD and ECS are miss used.
But for novice like me DOD ECS to advanced solution like nuke on a fly. Well they say start small and use what get the job done.

In Topic: Realistic space battles - fun or not?

24 December 2015 - 12:44 AM

This focus on A.I. destroys any game.

Why? Me thinks AI make sense, also it is expensive by mass and spacecraft design to put humans in it. There still would be manned space craft the big ones but with lot AI support. Also if you using AI also the option of remote controle get possible. Fighters for defence and non FTL strike range could be piloted from carrier. As Mass driver weapons in space are more effective and also extreem long kill range add firing unit and foo if closing in to each other. Life expectations and combat endurance is very short for smaller space craft . But also medium. Drones make sense as warfare is more how fast you can produce or replace units. Numbers and war production.

I do not believe this 300 years ago people believe stuff. Even slower than light travel is almost impossible. Chemical engines run out of fuel in minutes. Ion engines have almost no thrust, light is even weaker. You can make up for that with lots of power (tritium fusion reactors are much more realistic compared to your ideas). Such a spaceship would accelerate like a fighter air plane. For days. With thousands of tons of weight. May we go from step to step and firstly reduce flight to mars to 1 day and then tackle FTL travel .

My guess is space warfare is fiction, it is unreal. Orbital satelite warfare as missile shield wel that possible . Near future it does not get excited much more. Unless some major bunch of technical breaktrough as making it also economical possible, putting some thing in space is expensive . Technological means does not mean it wil happen. Orbital warfare means orbit will become a orbital mine field by debri. Because it already is a bit due to ground to satelite missile test .
So realistic to me means a more science to fiction balanse. Because pure current day tech criple you so much it make no sense to go out there wage war.

Have you read the papers about laser communication between satellites? Or how hard is it to hit the retro-reflector on the moon. This is all pretty close in  space-terms , but on the front of technology. Laser communication outside the earth orbit is pure science fiction ..
.. and lasers as a weapon on that distance more so .

You know it important at what audience you aim your game my bet is what game killer for nasa prof A could be not for nasa prof B. Because some can have different expectation of what the future might be. Keep in mind most of the target audience don't have high tech education so realisme is more about believability then the pure form. And take some or the most conveniënt fiction tech brake trough. Laser has compared to railguns a very far effective range against smaller and faster moving targets.
Gunpowder 7.62. Combat 300 meter travel time to target, nato bullit 1/3 1/4 second in space with no drag a bit shorter. Laser no drag you get 1/4 light second of combat range.
Sniping nato 7.62 800m in space you keep you muzle effectivity so it moa distance to target size and agility 5 seconds that realy far.
5 seconds for a heavy laser canon attack a non agile vessel 100m large 20 m wide on 5 light seconds.

Of course already von Neuman knew, A.I. is the way to go. We do not need no humans (players or in space).

I would keep this but will have humans in space but at a cost.
Also keep in mind a 1km vessel doesnot mean the crew can move in that 1 km only crew compartments. And those compartment can be very limited. Like 5 to 15% of the vessel. The constructor is free to make it luxory for civilian or as spartan for military Vessel .
Altho Nimitz naval carrier are a few 100 m long with a crew of 5 K.
In space it could be 1 km and a 250 crew but wide mix of 25.000 Drones .

Well i take the soft scifi games and movies and series as reference and make some features for game more realistic as it fit the game is fun balance . For intterstallar trading there just need to be FTL.

What make no sense to me is take real scale space and go for fighter planes in space Combat with a speed limit which is very low for space. Because its online game. Cripple it more to make it more depth and slow pace with turn handicap.

Most milsim game are still game then a true mil trainer. Space sim might need much more compromises .

PARTNERS