Synced data, libraries, coding, and data storage
Moderator: Moderators
Synced data, libraries, coding, and data storage
A lot of people have complained about springs internals, some have even gone as far as starting a brand new engine to start from scratch (Command Engine/OSRTS).
So it isn't a very good idea to worsen this issue by treating the whole engine like a playground.
Libraries and includes are being added that affect the entire engine and external projects, increasing the number of dependencies required to compile things and increasing the compile time too.
Some of these such as lua are a necessary addition, but others are not.
What's more this lack of proper organisation is a potential danger, and could lead to code that is prone to causing desyncs and crashes, or is just horrendous spaghetti code that's hard to follow.
So to start with I suggest the very very basic principle that fnordia first put across when the engine was open sourced for anyone working on the engine.
1) Do not mix synced and unsynced data.
By synced data I mean classes such as:
Unitdef
WeaponDef
Moveinfo
Featuredef
Including handling of:
Lua Gadgets
AIs
pathfinding
los and radar
etc, these define things that should be the same on all client and are critical to the game state.
By UnSynced data I mean:
Widgets
OpenGL data/routines
sfx
GUI states
networking
2) Only add #include directives where they're needed
If I am doing AI I should not have to compile a dependency that has absolutely nothing to do with AI. Why does my los code need to know what a weapondef is? Why does my tdf parser need to know the maximum number of players a game can have? Why does my networking class need to know howto load dds textures into ram?
This can increase compile time and its bad organisation. So much so its now affecting projects outside of spring. As an AI developer every few weeks I find that my project ends up including more and more headers, not because I have added more dependencies but because people have been careless and added their #include statements anywhere without due care to attention.
1) Do not mix synced and unsynced data.
2) Only add #include directives where they're needed
This just shouldn't be happening. This is an RTS engine not a calculator app. A lot of this isn't even spring organisation, its simple common sense good coding practices.
So it isn't a very good idea to worsen this issue by treating the whole engine like a playground.
Libraries and includes are being added that affect the entire engine and external projects, increasing the number of dependencies required to compile things and increasing the compile time too.
Some of these such as lua are a necessary addition, but others are not.
What's more this lack of proper organisation is a potential danger, and could lead to code that is prone to causing desyncs and crashes, or is just horrendous spaghetti code that's hard to follow.
So to start with I suggest the very very basic principle that fnordia first put across when the engine was open sourced for anyone working on the engine.
1) Do not mix synced and unsynced data.
By synced data I mean classes such as:
Unitdef
WeaponDef
Moveinfo
Featuredef
Including handling of:
Lua Gadgets
AIs
pathfinding
los and radar
etc, these define things that should be the same on all client and are critical to the game state.
By UnSynced data I mean:
Widgets
OpenGL data/routines
sfx
GUI states
networking
2) Only add #include directives where they're needed
If I am doing AI I should not have to compile a dependency that has absolutely nothing to do with AI. Why does my los code need to know what a weapondef is? Why does my tdf parser need to know the maximum number of players a game can have? Why does my networking class need to know howto load dds textures into ram?
This can increase compile time and its bad organisation. So much so its now affecting projects outside of spring. As an AI developer every few weeks I find that my project ends up including more and more headers, not because I have added more dependencies but because people have been careless and added their #include statements anywhere without due care to attention.
1) Do not mix synced and unsynced data.
2) Only add #include directives where they're needed
This just shouldn't be happening. This is an RTS engine not a calculator app. A lot of this isn't even spring organisation, its simple common sense good coding practices.
Last edited by AF on 03 Nov 2007, 23:40, edited 1 time in total.
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
+2
BUT:
networking - Is unsynced now and I can't think of a reason to change that.
AIs - Is synced now but I think it would work better (=safer, easier) when its would be unsynced (and working like a regular player)
BUT:
networking - Is unsynced now and I can't think of a reason to change that.
AIs - Is synced now but I think it would work better (=safer, easier) when its would be unsynced (and working like a regular player)
The problem are not only the header files. Lots of code is all spread around in the engine. Nearly every class i mess around with has some code inside which (in my opinion) doesn't belongs there, sometimes the same code is even doubled in different classes.2) Only add #include directives where they're needed
Re: Synced data, libraries, coding, and data storage
It is or was somewhere in the bowels of buildbot.no-ip.info iirc, unless that was an older one.
Re: Synced data, libraries, coding, and data storage
Would code reviews, "cage cleaning", writings of unit-tests, code documentation and other efforts aimed at increasing the quality and maintainability of the code be accepted or even appreciated in this project?
Such work won't directly create any new functionality/features what so ever, but makes it easier to create/add such things in the future.
I can also imagine that such efforts to some extent addresses the problems AF are mentioning.
(And also, they are a brilliant opportunity to familiarize oneself with the code...)
Such work won't directly create any new functionality/features what so ever, but makes it easier to create/add such things in the future.
I can also imagine that such efforts to some extent addresses the problems AF are mentioning.
(And also, they are a brilliant opportunity to familiarize oneself with the code...)
Re: Synced data, libraries, coding, and data storage
I would definitely appreciate it
(It's what I was doing over 50% of the time when I was more actively coding...)
(It's what I was doing over 50% of the time when I was more actively coding...)
Re: Synced data, libraries, coding, and data storage
I would appreciate it too. and zes zou are right i think, its a good thing to familiariye with the code.
Re: Synced data, libraries, coding, and data storage
These issues aren't that prevalent recently.
Unstickied.
Unstickied.
Re: Synced data, libraries, coding, and data storage
What's not prevalent exactly? Debugging sync errors?
Re: Synced data, libraries, coding, and data storage
I think now mixing synced and unsynced data is okay as long as it's done properly.
Re: Synced data, libraries, coding, and data storage
The coding practices stated in the OP are just common sense for anyone developing in the engine. It's not really worth to keep this a sticky, as it doesn't convey any important information, nor is it a common thread worth posting in like the Random WIP ones.Jools wrote:What's not prevalent exactly? Debugging sync errors?