Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: masteripper on January 19, 2014, 10:14:02 am
-
Hello to everybody
I have a probably stupid question...why in all the years of development didn't the programming philosophy didn't changed from functional to object oriented programming...classes,objects etc
I am doing bussiness programs but i always wanted to do games programming and i am wοndering...
-
Bits of the code have been changed to OO. Changing all of the code though pretty much means rewriting the entire thing from scratch.
-
Well.
Two things:
1. Most of the newer stuff uses an explicitly object-oriented design. Like the HUD gauge code for example.
2. FS2's core design is strongly object-oriented, It just does not use OO language features.
-
Because it was originally written in pure C, which had no OO features.
Just thought that point should be highlighted.
-
So it has a resembling OO design but it does not follow them....can anyone enlight if is common in game programming...
By the way is there some enhanced technical documentations....something like flowcharts....
-
The paradigm is commonly seen when legacy code has been maintained well past its anticipated lifespan without having the available resources to fully rewrite it, in and out of the game coding world.
-
Hello to everybody
I have a probably stupid question...why in all the years of development didn't the programming philosophy didn't changed from functional to object oriented programming...classes,objects etc
I am doing bussiness programs but i always wanted to do games programming and i am wοndering...
FSO has never been functional, or anything close to it. I think you're confusing functional programming with something else.
-
By the way is there some enhanced technical documentations....something like flowcharts....
You can try using doxygen and have it generate inheritance charts for you. There are some other programs out there that can perhaps do a logical flow chart for you, but be advised it will take some time for such programs to run through the entire codebase.
Word of caution: if you are interested in making a game engine yourself from scratch, go with something very simple first such as a 2D game. A full-fledged 3D game may be enticing at first, but remember there is a lot of things you have to consider in order to get good results.
-
Hello to everybody
I have a probably stupid question...why in all the years of development didn't the programming philosophy didn't changed from functional to object oriented programming...classes,objects etc
I am doing bussiness programs but i always wanted to do games programming and i am wοndering...
FSO has never been functional, or anything close to it. I think you're confusing functional programming with something else.
Sorry my wrong i think the correct term is Procedural Programming
-
I believe that in the real world, the idea of doing something as huge as converting a large established codebase to conform to a different paradigm (such as object-orientedness) is something you only do if 1) you can throw a lot of money and people at it, 2) you think it's way easier than it is or 3) there is some kind of a really pressing reason to do so.
-
I believe that in the real world, the idea of doing something as huge as converting a large established codebase to conform to a different paradigm (such as object-orientedness) is something you only do if 1) you can throw a lot of money and people at it, 2) you think it's way easier than it is or 3) there is some kind of a really pressing reason to do so.
I believe that it would "raise" the friendliness for many wannabe coders and provide a much cleaner picture of what is going on...and maybe provide a starting point for tranforming this to a game engine for space sims .that this is just my humble opinion....(thanks Volition for this great gift)
By the way if it is tranferred to another platform (e.g C# is there a problem ?)
-
There's just a problem with that: we are not being paid for this work. Which means that we're limited to work we can do in our spare time, which of course is work that is fun, not some boring refactoring work.
And that's before we take into account that the code is readable enough that a skilled coder can implement New features and fix bugs after just a few days of study.
Secondly, FSO already is one of the best engines for space Sims out there, it certainly is versatile enough to accommodate a wide range of stories.
We so not want this engine to be an all-purpose engine, there are a lot of those already. We're concentrating on making a really good engine for mission-based space Sims, and that's it.
-
:nono:
I'm going to guess that you are not a coder, or fairly new to it, possibly early Uni experience at best. Correct me if I'm wrong please. But you're suggesting to a team of coders to rewrite an engine in a whole new language with a different design pattern, when it should be fairly obvious based on the historical progress of FSO that it is highly infeasible. That shows a great lack of understanding for the effort involved, hence my assumption. I'll attempt to analogize, it's like asking a recreational league softball team to just "play better and win the World Series". At that suggestion it's very likely that some people will even take offense. Googling for how to do things like you are suggesting to large legacy projects will probably bring up more than one profanity-strewn article about the difficulties involved. I'd definitely check some of those out if you're curious about the work level required.
-
:nono:
I'm going to guess that you are not a coder, or fairly new to it, possibly early Uni experience at best. Correct me if I'm wrong please. But you're suggesting to a team of coders to rewrite an engine in a whole new language with a different design pattern, when it should be fairly obvious based on the historical progress of FSO that it is highly infeasible. That shows a great lack of understanding for the effort involved, hence my assumption. I'll attempt to analogize, it's like asking a recreational league softball team to just "play better and win the World Series". At that suggestion it's very likely that some people will even take offense. Googling for how to do things like you are suggesting to large legacy projects will probably bring up more than one profanity-strewn article about the difficulties involved. I'd definitely check some of those out if you're curious about the work level required.
There's just a problem with that: we are not being paid for this work. Which means that we're limited to work we can do in our spare time, which of course is work that is fun, not some boring refactoring work.
And that's before we take into account that the code is readable enough that a skilled coder can implement New features and fix bugs after just a few days of study.
Secondly, FSO already is one of the best engines for space Sims out there, it certainly is versatile enough to accommodate a wide range of stories.
We so not want this engine to be an all-purpose engine, there are a lot of those already. We're concentrating on making a really good engine for mission-based space Sims, and that's it.
I am extremely sorry if i offended you to any way ....and i want to stress this in any possible way...
I have the utmost respect for you and all the HARD WORK you have put ...sacrificing valuable time from your life to put in an UNPAID project
There is no argument that you are heroes for every new coder that builds skills and experience from your Hard Work and also you are giving to a LOT of people a good choice of FUN....
I am just asking this questions in case something was started .... probably some time ago.... and is burried somewhere along the forum...
I have some experience with OO languages (C# , Java) and i am wondering if this is a good idea to transfer a GREAT code to another platform(C#) as a "pet" project.
Unfortunately i am rather old to start learning C++ and i am afraid it isn't going to be any practical use for me so i'd rather stick to managed code.
Again i am just ...just.. asking.....questions...and of course i am not asking from anyone to transfer it...i know the stupidity of this...after all if it works why bother fixing it...:)
Thanks for the answers...
-
Porting FSO to C# is pointless. We would have to refactor everything, we would have a bunch of cross-platform compatibility headaches, and we would likely lose quite a bit of performance on the way.
So we're not going to do that.
-
I have some experience with OO languages (C# , Java) and i am wondering if this is a good idea to transfer a GREAT code to another platform(C#) as a "pet" project.
Unfortunately i am rather old to start learning C++ and i am afraid it isn't going to be any practical use for me so i'd rather stick to managed code.
Again i am just ...just.. asking.....questions...and of course i am not asking from anyone to transfer it...i know the stupidity of this...after all if it works why bother fixing it...:)
Thanks for the answers...
As The_E has mentioned, porting the FSO codebase to a pure C#, Java, or others, would take a great deal amount of time and effort from its participants. As it were, I myself can only do maybe 400 lines of code a day; if only my paying job would allow me the needed downtime.
C++ isn't drastically different from C#, it's very likely that you'll be able to understand the majority of a C++ program, particularly those bits where classes and structs are involved. I would recommend that you'd just take a look at a few portions of the code first before resigning to not being able to learn the C++ language.
-
I have some experience with OO languages (C# , Java) and i am wondering if this is a good idea to transfer a GREAT code to another platform(C#) as a "pet" project.
Unfortunately i am rather old to start learning C++ and i am afraid it isn't going to be any practical use for me so i'd rather stick to managed code.
Again i am just ...just.. asking.....questions...and of course i am not asking from anyone to transfer it...i know the stupidity of this...after all if it works why bother fixing it...:)
Thanks for the answers...
As The_E has mentioned, porting the FSO codebase to a pure C#, Java, or others, would take a great deal amount of time and effort from its participants. As it were, I myself can only do maybe 400 lines of code a day; if only my paying job would allow me the needed downtime.
C++ isn't drastically different from C#, it's very likely that you'll be able to understand the majority of a C++ program, particularly those bits where classes and structs are involved. I would recommend that you'd just take a look at a few portions of the code first before resigning to not being able to learn the C++ language.
Porting FSO to C# is pointless. We would have to refactor everything, we would have a bunch of cross-platform compatibility headaches, and we would likely lose quite a bit of performance on the way.
So we're not going to do that.
Of course i wouldn't suggest to refactor it ....i am just asking if there was ever a thought in doing so and if you think from your experience if it is possible...
-
Because it was originally written in pure C, which had no OO features.
Just thought that point should be highlighted.
I remember reading about it but i must say i have forgot it...
-
Porting FSO to C# is pointless. We would have to refactor everything, we would have a bunch of cross-platform compatibility headaches, and we would likely lose quite a bit of performance on the way.
So we're not going to do that.
Of course i wouldn't suggest to refactor it ....i am just asking if there was ever a thought in doing so and if you think from your experience if it is possible...
Possible? Yes.
A good idea? Hell no. Noone has ever brought this up in a serious way. The closest to that was an aborted project called Ferrium years ago, which was intended as a blind rewrite of the engine, but as I said, that project was aborted and never went anywhere.
I would estimate that, if all currently active SCP coders were to drop what they're doing for their own personal projects and concentrated on just rewriting the engine from scratch, we would be done in a year or two. By which time noone would care any more, because the modders we are making this engine for would have quit in frustration.
-
Possible? Yes.
A good idea? Hell no. Noone has ever brought this up in a serious way. The closest to that was an aborted project called Ferrium years ago, which was intended as a blind rewrite of the engine, but as I said, that project was aborted and never went anywhere.
I would estimate that, if all currently active SCP coders were to drop what they're doing for their own personal projects and concentrated on just rewriting the engine from scratch, we would be done in a year or two. By which time noone would care any more, because the modders we are making this engine for would have quit in frustration.
I never thought about the "politics" of such a move.....thats a very interesting point....i
-
See, that's the thing here: We're very much carrying a large amount of technical debt owing to the fact that a lot of coders have worked on this engine for years, and while it was rather robust when we got it (and is rather robust at the moment), there's still a bunch of stuff we have to support, some of which being decidedly fragile.
It got so bad at some point that we had to dedicate 4 releases almost entirely to fixing bugs and correcting regressions (3.6.12, 3.6.14, 3.6.16, 3.6.18), with little in the way of big new features introduced. It's very much a matter of "If it ain't broke, don't fix it", and so we see proposals to reengineer huge parts of the engine with a large amount of skepticism.
And during all that, we have to keep an ear out for what the people using this engine to create content want from it, to figure out how we can help them create awesome games. Shutting down development for a year is not something we want to do again, because if we do, it means pissing off what in a normal software development environment would be our customers.
-
See, that's the thing here: We're very much carrying a large amount of technical debt owing to the fact that a lot of coders have worked on this engine for years, and while it was rather robust when we got it (and is rather robust at the moment), there's still a bunch of stuff we have to support, some of which being decidedly fragile.
It got so bad at some point that we had to dedicate 4 releases almost entirely to fixing bugs and correcting regressions (3.6.12, 3.6.14, 3.6.16, 3.6.18), with little in the way of big new features introduced. It's very much a matter of "If it ain't broke, don't fix it", and so we see proposals to reengineer huge parts of the engine with a large amount of skepticism.
And during all that, we have to keep an ear out for what the people using this engine to create content want from it, to figure out how we can help them create awesome games. Shutting down development for a year is not something we want to do again, because if we do, it means pissing off what in a normal software development environment would be our customers.
I understand...i think i got all the answers....thanks for your time...
-
I think the thing to remember is that coding features and paradigms and whatnot should be viewed as means to an end, not necessarily something to be valued for its own sake: they're all meant to produce programs that perform certain tasks, and everything else is gravy. The FSO engine performs reasonably well (given certain tolerances of the term "reasonable") and is reasonably understandable (see above), so overhauling it to a new paradigm just for the sake of doing so doesn't serve any real purpose, not to mention introducing all sorts of external issues as The E explained.
(Of course I may be saying this because my initial introduction to OO elements like classes and operators back in college produced a strong reaction of "fut the wuck"...)