The finished game is a little bit of an OS in itself -- it has its own GUI system, user profile system, network protocols, built in internet browser, scripting subsystem maybe even with a custom made language etc. This is wrong.
Julius {l Wrote}:I am a bit torn on this idea. First of all your racing game example would obviously not work
smcameron {l Wrote}:Games are not tools, they are to a large extent art.
smcameron {l Wrote}:Free games especially tend to be hobby projects
smcameron {l Wrote}:Debuggability
smcameron {l Wrote}:Because free game dev tends to be a solo activity
fluffrabbit {l Wrote}:You think developers aren't smart enough to make sound decisions about libraries? I would describe a lot of Unity users that way, and those people might use Godot and even Torque, but when you get to something like Ogre I blame the game developer for making stupid decisions because s/he should know better by that point.
drummyfish {l Wrote}:Imagine an ultimate FPS game composed of many small components our community has created and that allows any player to create a completely unique flavor of it. There can be different distributions of the game for different purposes -- casual players, hardcore players, speedrunners, slow computers, fast computers, children, adults, ... -- just as there are distributions of Linux. You think the opponent AI sucks? Just switch the AI module. The game is too slow? Just switch a module. Whenever a new gaming platform comes out, there will almost immediately be a port of this game to it -- on smart watches, handhelds, VR, ... Just recompile the components, and possibly leave out those that the platform can't use (because of performance etc.).
drummyfish {l Wrote}:But generally this is a big problem and it's what I am talking about -- libre games die in the same way proprietary games die because even if freely available, they are existentially dependent and de facto owned by a single person who knows how the code works and how to compile it. When that person loses interest or e.g. the whole game depends on a package that has died and can't easily be replaced, the game dies as a whole, along with all the wheels that were newly invented. It's an immense waste of effort.
drummyfish {l Wrote}:I am not trying to force anyone to do this, I would simply like to find maybe a few followers of my idea here.
So here is another important idea I'd like to communicate here: Make game components as general as possible and don't try to assume any specific use or platform.
smcameron {l Wrote}:Games are not tools, they are to a large extent art.
Of course games are art, but they are still technology and game development is still engineering.
This philosophy could be applied to almost any game.
A big project could simply be a merger of many small hobbyist projects in this case.
smcameron {l Wrote}:Because free game dev tends to be a solo activity
Well but this is exactly what I think is wrong
if one of the ten or more optional audio libraries has no maintainer then new projects will use another one and old projects are either left with the maintenance burden more or less individually or more likely they will patch around an old version as "good enough" and over time it becomes a huge technical debt.
freemedia2018 {l Wrote}:smcameron {l Wrote}:Games are not tools, they are to a large extent art.
Exactly.
fluffrabbit {l Wrote}:if one of the ten or more optional audio libraries has no maintainer then new projects will use another one and old projects are either left with the maintenance burden more or less individually or more likely they will patch around an old version as "good enough" and over time it becomes a huge technical debt.
That doesn't sound so bad if the game developers can maintain the libraries once they become abandonware.
fluffrabbit {l Wrote}:So many textwalls.
Some people are detail oriented
The Unix approach is no less debuggable -- I'd maybe argue it is more debuggable, because the components are more separated, you clearly see the communication between the components and any component can be completely isolated and tested with unit tests or in other ways.
Users browsing this forum: No registered users and 1 guest