[portej05]

Hiya folks.

This is an article I wrote for internal a few weeks ago, but didn't get a lot of feedback except for 'we disagree'.
I'm posting it here not to initiate a flamewar, but to see what the wider community think. It is posted verbatim (I believe - I removed one line break towards the end during posting it here).

Please be considerate in your responses.

NB: FreeDA was an external project, but is no more. Please ignore references to it.

I've recently been doing a lot of thinking about FSO/SCP. A _LOT_.
In the past year I've been a newbie to FSO, I've been a coder on FSO and I've been part of a lot of discussions on the engine.
Since I'm currently evaluating my position with the team, there is little damage that can come from posting what I honestly think about the engine, the philosophy and the team.
I want to see this engine in 5 years in a lot better shape than it is at the moment, but that isn't going to happen without some radical changes in the way we do things.

1) The Engine.
Where to start. It is simply a mess.
There is little to no documentation on the internals of the engine. All documentation that people are normally forwarded to (the wiki/karajormas FAQ/etc) is intended to be used by modders rather than developers on the engine. When a new feature is coded for the engine or a bug needs to be fixed, the coder involved needs to study up on a lot of the engine in order to understand why something is broken or how to implement somthing (just investigating the popup bug recently took me through graphics, multi, the state system, and a heck of a lot more). The learning curve to getting started with FSO coding is huge, and understanding this gives an idea of why WMC code introduced as many bugs as it did. There is no way one person can understand the immense amount of intricate code in FSO.

Too much of the behaviour of the engine is hardcoded in the engine, resulting in massive code bloat, buggy features, difficult to customise features (just look at the current HUD rantings from WCS). There is little use of scripting and some mods refuse to use scripting altogether (WCS). Scripting is incredibly powerful, and if it had been implemented correctly would allow mods to easily specify the behaviour they want, instead of introducing yet another set of flags and more hardcoded behaviour. Scripts would be able to be shared around and modified as needed, rather than significant amounts of code dedicated to what scripting should be doing.

There is little in the way of meta-data about the engine. This can be seen in the lack of tools available for developing mods for the engine. PCS2, FRED and notepad are the most commonly cited tools (and there are the occasional VP packaging tools that are mentioned). Also, tools such as fonttool no longer compile or work correctly under windows. In fact, the general tool environment for FSO is disastrous. Whilst an experienced modder who has been working with the engine since retail finds things easy enough, the entry curve for a new modder is massive. In addition to this, the table format is almost impossible to parse without prior knowledge of the table formats, leading to a situation where there are no useful tools for modders to use for creating and verifying tables. FUBAR earlier stated that he just uses notepad. Again, this is fine for an experienced modder, but for a less experienced modder it can be a frustrating couple of hours of wasted time. In addition, firing up the engine to check a table takes a fair amount of time. The only direction currently being pursued (FreeDA is a totally separate project, and may not even be actively continued on depending on the outcome of a number of discussions in progress) is to _PORT_ FRED to wxWidgets. The issue here is that there is no addressing of fundamental limitations of FRED (its transaction system, or the undo system which modders would REALLY like) and I believe this will make it a waste of resources. In addition, FRED is renowned for being incredibly buggy and dangerous to mods (not to mention having to edit files afterwards with notepad). It is also incredibly tied to the engine source, resulting in a heck of a lot of code which could be eliminated, resulting in a simpler engine (removing all code with Fred_running referenced, basically + a heck of a lot more that only FRED uses). PCS2 has been described as 'cryptic and buggy' as well, and a lot of modders seem to be confused as to what you can do with it and even what it is actually for.

In terms of what can occur with correct meta data, code generation can become automatic, and thus significantly more reliable and bug-free with the use of the right tools. We are in a vicious cycle of tools being extremely difficult to develop because the engine doesn't support them easily.

The version commenting system is a disaster waiting to happen. The behaviour of a mod could significantly change based on the build, and this may allow cheating. Mods should be properly versioned. This would even aid with verifying tables for multi and would make stats collection simpler (allocate stats to a particular version and then you can combine as you want to). It would also aid with the management of the engine and the requirements of mods - "you need engine X.X.X to run mod ABC". In addition to mod versioning, there is no asset versioning or management system to aid with developing or updating a mod system.

Code quality is generally low. Folks working on the engine have an intermediate knowledge of C, and a rudimentary knowledge of C++. This can be seen from many commits and many bug fixes fixing fundamental mis-understandings of C++. In addition, most of the coding team do not understand linking or compiling in the kind of depth required to implement high performance code. There is also a lack of understanding of algorithms such as memory allocation resulting in inappropriate selection or implementation of algorithms. For a project 8 years old not to have a coding guidance document is incredibly short sighted, and definitely a turn off for experienced coders. In addition, a lack of a documentation system, and the multitude of bugs caused by a lack of understanding of code is also turning away coders (I know at least two currently who looked at the code behind FSO and refuse to touch it).

There is far too much in the way of hard coded _DATA_ in the engine. Sure you can over-ride it, and as I understand it, a lot of mods do. But WHY is it in the engine in the first place, and not placed somewhere like the mediavps or a 'retail' mod. I have heard no good technical argument. The retail data is holding us back. Maybe folks are happy or OK with that. But without providing decent tools to update things, we're holding ourselves back. We can't work with 10 year old data in the same form as it was 10 years ago forever.

There is no formal testing framework for engine functions. This would eliminate a lot of questions about managing backwards compatibility, and is a major component of ALL modern, well developed software. FSO is significantly lacking in this area.

Linking has received it's own lengthy treatment, so I will refrain from mentioning it again here.

The launch system itself deserves another special mention. It currently provides only flag data to the launcher. The launcher needs to know a lot about what FSO is expecting and where to provide it. Developers are far too concerned with backwards supporting engines all the way to retail than designing a better system for future engine work. In addition, the deprecation of HKLM has already occurred, and whilst people want to rid the launcher of it, the statement that any new launcher must work with retail is hindering this.

We do a lot of things the way we do because 'the users are too stupid to work it out'. Maybe that's because we do things in an unusual way a lot of the time. There is NO installer for FSO and no tool for ensuring that the FSO game directories are set up correctly. The structure of the VCProjects also says a lot about how lazy we are with dependency management. The correct way to manage project dependencies is NOT by just lumping them in SVN to make things easier for coders.

2) The Philosophy
The philosophy of FSO isn't going to stand the engine or the team in good stead.

The backwards compatibility of FSO at all costs is going to cost the team dearly in development potential over the next few years. There is currently NO sign of a deprecation framework within the engine to deal with legacy data whilst moving to a new framework which is significantly more flexible. There is no desire to move to a new framework because 'what we have is fine'. This is incredibly short sighted. It also causes some significantly bad code (I'm thinking parsing here). Nobody is spending time looking at what people might want to do 5 years into the future.

You all know my opinions on the recently posted 'SCP Policies and Objectives' thread, so I will refrain from repeating them here.

The current issues with WCS/SCP relationships are indicative of a larger problem. We don't currently have any major forward planning. We rely a lot on coders doing the 'right' thing to move us in the 'right' direction. An example of this is the incredibly demanding nature of KeldorKatarn. Whilst solutions have generally been pointed out, and the difficulties of solving the problems they want us to solve have been pointed, we're still being accused of being slow and not interested. We're also being accused of holding up the development of their game. If their game was being developed against a roadmapped set of features we would not be having these difficulties. Requests could be handled in a fashion that would allow the engine to be updated when they were available, rather than requiring a mod to be released with a custom engine.

You all know what I think of TBP. We should not be having to develop Zathras at all. TBP should be dying a natural death with support for 3.6.9 being dropped. This is a consumption of valuable resources that could be better used elsewhere because of one dropkick who cracked.

It's almost as if we're continuing development in the same fashion that :V: would have after releasing FSO. Spend as little money or development capital to keep the engine giving a few new features each release.

3) The Team
There is no formal team structure. There is no clear project manager. There is no clear single point of contact between mod teams and the engine team. We have engine team member immersed deeply within mods who are developing features for their mods whilst other features would be worth more time (or at least better fixed). This isn't generally a problem, however we can see from the multitude of patches flying forth from WCS that it is consuming a lot of time to be always checking code from a mod.

I've mentioned above that we have an average of intermediate C coding ability. We do not have significant architecture or software engineering experience evident within the team. The engine is continually being hacked without regard for either. We do not (anymore) have anyone regularly profiling the entire engine to see what is going on. We are spending a lot of time looking at changes that we don't understand.

The current idea of project management for FSO is to let everybody work on whatever interests them, and the patches are watched over by folks, however they aren't necessarily checked for correctness by anyone. There is no management of what the engine needs.

The very idea of freezing the entire code base and working on engine structure is not popular, people are more interested in feature work than core structural work. This will again cost the engine within the next 5 years.

In the time I've worked on FSO, I generally don't see technical responses to my comments or suggestions. They generally fall into the categories of 'this will upset someone' or 'this isn't the way we do it', rather than 'solution X will require more processing time or will cost us significantly in tool development'. I also don't see any desire to develop tools under the auspices of the SCP. PCS2 was developed externally, FreeDA (doubtful at present) is developed externally. fonttools is dying. VP packaging tools are all external tools.

I've probably missed a lot of what I think about FSO above. I realised today that I spend more time *****ing about FSO than I do enjoying working on FSO. The team needs to change it's direction big time in order to still be viable in 5 years time. I'm not entirely sure that it's possible with the current team or the current project philosophies to fix any of the above problems I've outlined.

I'm interested to hear what you think about the above. I'm guessing most responses will contest points or explain that we don't have the manpower to fix any of the issues. My response to that is b***s**t. Full feature freeze whilst the entire engine undergoes an overhaul and a full documentation drive. But I'm also guessing that that will never happen, and the required meta data generation systems and code restructuring will never occur. Tool development has practically frozen for a long time, with only minor additions to FRED (which is still very buggy).

EDIT: fixed quoting // G5K

[karajorma]

I'm pretty sure you got a whole ton of feedback on the SCP channel about this post.

[General Battuta]

It's my understanding that portej05's contributions are one of the reasons that 3.6.12 is considerably faster and more stable than 3.6.10. If that's the case I would (and do) give his opinion serious consideration.

[portej05]

@karajorma: On some other topics, yes, on this one, not as much.

@Battuta: I believe taylor came up with an even faster particle system, and that has replaced mine.

[Thaeris]

Given my understanding of how FSO works (which is not tremendous), I fully agree with portej's sentiments.

[Kopachris]

Given my understanding of how FSO works (which is not tremendous), I fully agree with portej's sentiments.

Ditto.

[karajorma]

@karajorma: On some other topics, yes, on this one, not as much.

Given that I spent over an hour pointing out the flaws in that post including how it would lead to several TCs and mods having to abandon the engine, I really don't know what you were expecting in feedback.

[chief1983]

Faster yes, but more stable is currently still being debated.

[Spoon]

Given that I zero understanding of coding and the workings of the engine itself I can't really put together a useful comment
I just hope you guys can work something out before drama rips it all apart.

[T-Man]

My opinion of this is to ignore it. I do not wish to be exploited in the power plays of others.

That is all.

[General Battuta]

My opinion of this is to ignore it. I do not wish to be exploited in the power plays of others.

That is all.

ITT we didn't read the article!

[taylor]

This is obvious flame-bait, otherwise the responses to the original posting that portej05 quoted would also have been included.  Too much of the "article" is also either completely irrelevant, been thoroughly addressed in the past, or is flat out wrong.  Unless any other dev wants to comment regarding this article, again, I say that this thread just be closed and lets move on to more relevant things.

[chief1983]

Here's the rest of the thread then, for completeness.

I don't feel the majority of the post was ever addressed.  As you can see, the thread was actually fairly short and only involved several members.  It also doesn't really seem to cover what was 'wrong'.

The version commenting system is a disaster waiting to happen. The behaviour of a mod could significantly change based on the build, and this may allow cheating. Mods should be properly versioned. This would even aid with verifying tables for multi and would make stats collection simpler (allocate stats to a particular version and then you can combine as you want to). It would also aid with the management of the engine and the requirements of mods - "you need engine X.X.X to run mod ABC". In addition to mod versioning, there is no asset versioning or management system to aid with developing or updating a mod system.

Certainly true

Code quality is generally low. Folks working on the engine have an intermediate knowledge of C, and a rudimentary knowledge of C++. This can be seen from many commits and many bug fixes fixing fundamental mis-understandings of C++. In addition, most of the coding team do not understand linking or compiling in the kind of depth required to implement high performance code. There is also a lack of understanding of algorithms such as memory allocation resulting in inappropriate selection or implementation of algorithms. For a project 8 years old not to have a coding guidance document is incredibly short sighted, and definitely a turn off for experienced coders. In addition, a lack of a documentation system, and the multitude of bugs caused by a lack of understanding of code is also turning away coders (I know at least two currently who looked at the code behind FSO and refuse to touch it).

Then could you please explain how it should be done? If people don't understand what they are doing wrong and no one tells them about it then nothing is going to change.

There is far too much in the way of hard coded _DATA_ in the engine. Sure you can over-ride it, and as I understand it, a lot of mods do. But WHY is it in the engine in the first place, and not placed somewhere like the mediavps or a 'retail' mod. I have heard no good technical argument. The retail data is holding us back. Maybe folks are happy or OK with that. But without providing decent tools to update things, we're holding ourselves back. We can't work with 10 year old data in the same form as it was 10 years ago forever.

Retail data could conceivably be cut from the code and used to form a 'retail' mod. If removing it would allow better organization or handling of the code i certainly wouldn't have any problems with that.

We don't currently have any major forward planning. We rely a lot on coders doing the 'right' thing to move us in the 'right' direction. An example of this is the incredibly demanding nature of KeldorKatarn. Whilst solutions have generally been pointed out, and the difficulties of solving the problems they want us to solve have been pointed, we're still being accused of being slow and not interested. We're also being accused of holding up the development of their game. If their game was being developed against a roadmapped set of features we would not be having these difficulties. Requests could be handled in a fashion that would allow the engine to be updated when they were available, rather than requiring a mod to be released with a custom engine.

You all know what I think of TBP. We should not be having to develop Zathras at all. TBP should be dying a natural death with support for 3.6.9 being dropped. This is a consumption of valuable resources that could be better used elsewhere because of one dropkick who cracked.

It's almost as if we're continuing development in the same fashion that :V: would have after releasing FSO. Spend as little money or development capital to keep the engine giving a few new features each release.

That is also true. Problem is that none seems to be willing to direct the progress. Or if they are willing then they are not skilled enough to do so.

In the time I've worked on FSO, I generally don't see technical responses to my comments or suggestions. They generally fall into the categories of 'this will upset someone' or 'this isn't the way we do it', rather than 'solution X will require more processing time or will cost us significantly in tool development'. I also don't see any desire to develop tools under the auspices of the SCP. PCS2 was developed externally, FreeDA (doubtful at present) is developed externally. fonttools is dying. VP packaging tools are all external tools.


I've probably missed a lot of what I think about FSO above. I realised today that I spend more time *****ing about FSO than I do enjoying working on FSO. The team needs to change it's direction big time in order to still be viable in 5 years time. I'm not entirely sure that it's possible with the current team or the current project philosophies to fix any of the above problems I've outlined.

I'm interested to hear what you think about the above. I'm guessing most responses will contest points or explain that we don't have the manpower to fix any of the issues. My response to that is b***s**t. Full feature freeze whilst the entire engine undergoes an overhaul and a full documentation drive. But I'm also guessing that that will never happen, and the required meta data generation systems and code restructuring will never occur. Tool development has practically frozen for a long time, with only minor additions to FRED (which is still very buggy).

If a freeze is required then the code base needs to be frozen. I have no arguments against that. But some one needs to give pretty clear instructions on what and how to change. For example (I am not really c educated grant you that) i have seen some of the code issues you mention. However i am out of my depth when it comes to figuring out viable solutions to the issues.

There is far too much in the way of hard coded _DATA_ in the engine. Sure you can over-ride it, and as I understand it, a lot of mods do. But WHY is it in the engine in the first place, and not placed somewhere like the mediavps or a 'retail' mod. I have heard no good technical argument. The retail data is holding us back. Maybe folks are happy or OK with that. But without providing decent tools to update things, we're holding ourselves back. We can't work with 10 year old data in the same form as it was 10 years ago forever.

Retail data could conceivably be cut from the code and used to form a 'retail' mod. If removing it would allow better organization or handling of the code i certainly wouldn't have any problems with that.

Yeah but I'm sure there are some who would.  Really, being able to drop the engine in with the retail install has always been one of the requirements, that's why it's still that way.  Changing that may be something some are opposed to, but if it still gave you the ability to play the retail experience with nothing but the retail game data and the current engine, I'd be ok too.

The problem with dropping retail data support is this. When you suddenly uncover a bug you'll find it pretty hard to know what caused it the new SCP code or the new SCP data.

A good example of this is the large number of AI bugs QD pointed out a little while back. As things stand we can play a mission on retail and then play a mission on FSO and compare. Once you've changed the data you've got a problem. Is the issue with the data or with the code?

I'd much rather see something like what was done with def_files. Keep the data somewhere that it works with retail but where it doesn't get in the way of other stuff.

I've asked for my internal access to be revoked as I no longer have any interest in FSO or the FSO ecosystem.

I don't think that we want to change the retail data, just get more of it out of the engine itself.  Apparently this involves things like the hardcoded filenames for GUI elements, etc.

Yeah but there is no way to get that out of the engine without either doing something like def_files or requiring new data for retail.

Now I have no problem with the former.

[T-Man]

ITT we didn't read the article!

I will confess i did not fully; i only skimmed over it. However, the attitude and intention of it (or at least the intention i perceived) was clear in what i did read; an attempt to spark some kind of backlash and try and blackmail the modding team into doing what portej05 wishes. I apologise if you feel differently but that is how i felt reading it and i do not wish to be involved in such things.

Ultimately, the point is mute anyway, as, to quote portej05 himself from chief1983's article:

I've asked for my internal access to be revoked as I no longer have any interest in FSO or the FSO ecosystem.

portej05 stated a wish to part ways with FSO and stated he has no interest in it anymore. If such is the case, why is he suddenly back putting up information? If he asked to return and discuss the situation with the modding team, then it would be different, but he has stated no interest in returning, and even if he did state such, i would admittedly find it hard to believe him at this point as i would suspect him doing so only because i mention it (that is down to me being judgemental i admit, but that i cannot help). I see this as an attempt to get back at the team and to try and force them into doing things his way through peer-pressure of the community, simply because they disagreed with him. His entire argument, from my perspective, is thus meaningless; he stated he chose to walk away, so now he must walk away.

Perhaps problems do exist in FSO; that i cannot deny as i do not know the situation. However, the way he has (in my eyes) attempted to go about it these changes is malicious, and has thus destroyed any credability in it.

[Goober5000]

T-Man is very perceptive.

EDIT: If any dev wishes to comment further, he can PM me and I'll reopen the thread.  However, as the subject of the thread has been addressed extensively in the forum, in IRC, and elsewhere, there is very little to be gained by rehashing things here.

[chief1983]

ITT we didn't read the article!

I will confess i did not fully; i only skimmed over it. However, the attitude and intention of it (or at least the intention i perceived) was clear in what i did read; an attempt to spark some kind of backlash and try and blackmail the modding team into doing what portej05 wishes. I apologise if you feel differently but that is how i felt reading it and i do not wish to be involved in such things.

Ultimately, the point is mute anyway, as, to quote portej05 himself from chief1983's article:

I've asked for my internal access to be revoked as I no longer have any interest in FSO or the FSO ecosystem.

portej05 stated a wish to part ways with FSO and stated he has no interest in it anymore. If such is the case, why is he suddenly back putting up information? If he asked to return and discuss the situation with the modding team, then it would be different, but he has stated no interest in returning, and even if he did state such, i would admittedly find it hard to believe him at this point as i would suspect him doing so only because i mention it (that is down to me being judgemental i admit, but that i cannot help). I see this as an attempt to get back and to try and flame the modding team into doing things his way, simply because they disagreed with him. His entire argument, from my perspective, is thus meaningless; he stated he chose to walk away, so now he must walk away.

Perhaps problems do exist in FSO; that i cannot deny as i do not know the situation. However, the way he has (in my eyes) attempted to go about it is malicious, and has thus destroyed any credability in it.

portej05 has left a couple times now but it's hard for him to cut off fully and watch the project from afar because it's still a project he cares about.  So I can understand where he's coming from.  I also don't believe he's trying to start a flamewar, or 'blackmail', but merely get some of the issues he's discussed privately, but to no end, out to a broader public.  It's in our best interest to show that the issues have been addressed, cannot be addressed, or address them, not name or make false accusations.  If we can't, then it would appear we've lied.  Some times it's just difficult to walk away, and regardless we haven't actually covered what issues are or aren't valid yet (save for the few in my quotes from internal), and we're nearing page 2 of this thread.

I'm posting this realizing that the thread was already locked because I don't want it to go to waste.  Goober's comment about wishing for further discussion still applies, I'll leave it be.  I'm just trying to smooth some things out.

[Sandwich]

Given my understanding of how FSO works (which is not tremendous), I fully agree with portej's sentiments.

Took the words right out of my mouth. I've never been a coder in anything beyond some PHP, but every time I've encountered a program of some sort that stores its data in external, human-readable files, such as .ini or .xml files, it makes it that much easier to start tweaking things to work the way I want them to.

Pardon me while I wax poetic for a bit.

Taking a step back, we can see how :V:'s decisions in the past have had a tremendous effect on the present. Think about it. Freespace 2 is 11 years old. Why do we even exist? Back in the days before the source code was released, things were lively primarily due to 2 tools: FRED and PCS. With them, we could write our own stories, and paint our own pictures. If we had not been able to modify things, to create new content, everything would have stagnated after the 2nd or 3rd playthrough, and :V: would never have bothered releasing the source code to a non-existent community.

To keep things alive, we need to have those abilities for storytelling and art creation. FSO could be enhanced to become the bestest game engine ever made for the next 100 years, and without the tools to do anything with it, it wouldn't be used. I realize that some of the SCP coders probably are coding for the fun of it... they simply enjoy coding, they enjoy the rush of success they get when a feature they created from scratch starts to work properly. But keep in mind that there are hordes of FREDders, modelers, texturers, writers, and modders who need the right tools to be able to do things with what the coders create. Think of it as a Buggati Veyron in the midst of craggy, snow-covered mountains. It's a marvel of engineering and design, framed in majestic vistas, but without a road to drive on, it's pretty much useless.

I used to dabble a lot in FRED and modelling. I stopped when I saw that the tools weren't keeping up with the engine.

[/poetic_waxage]

Think over what portej05 said about a feature freeze for the sake of a complete overhaul and documentation. Even with the mantra of retail compatibility, it can't be impossible. Netbooks prove that - things had gotten so fast, that instead of making them faster and better, people went for just sufficient performance using the admirable efficiency of today's technology. So it seems to me that the engine could be completely overhauled, with retail compatibility replaced by meta-data support, and we'd still be left with processing power on today's rigs to run an "external" abstraction engine for retail-compatible data.

[karajorma]

While there are some good ideas in that post, a feature freeze basically means no development of FSO beyond the overhaul. i.e no new features until the engine has been overhauled. We're basically talking about the 5-6 active SCP coders deciding to build a completely new engine. With the current staff I doubt that could happen in under 2 years and to be honest I'd say 5 years is a more realistic figure.

This is basically Ferrium all over again. Except this time he's insisting on doing it by stopping development of FSO rather than running both and letting the best engine win.

If we tried it we'd kill the community in the process. Most of the TCs and mods would either fork the code, move to different engines or slowly run out of steam after getting bored of waiting for features and fixes they desperately need.

I flat out told Portej05 this was my objection to his plan when he suggested this last time, yet here is the argument again with no attempt to address my arguments against it.

If you want to see a more sensible plan, read the post here which so far none of the SCP have disagreed with. And to be honest Chief, I disagree with you and I think T-man called it.

[Sandwich]

Understood, kara - you're infinitely more acquainted with the SCP than I. I hadn't realized that there were so few active coders.

Your idea sounds great as well; to be honest, my main concern is that the SCP move away from the haphazard development of features it's had ever since the beginning, towards something more organized and documented. We really need to make HLP and the SCP a more welcoming place for newcomers to get involved in, and any steps in that direction are welcome.