Writing libraries vs writing apps. - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Writing libraries vs writing apps. (/thread-2168.html)
Writing libraries vs writing apps. - Najdorf - Nov 9, 2008 04:01 PM
I'll start by saying that I'm mostly an amateur coder, nobody ever used my code and I never wrote a "library" stable enough and self contained enough to be called such.
That said I'm getting the impression that writing end user apps (especially games and apps where the user interface is fairly limited) worth playing is actually much easier than writing a library that is worth for others using.
A game is a lot like a black box, it might be very complex under the hood but this complexity is managed by the programmer alone that hides it from the users to which he only gives a very simple interface.
A library instead should permit to do almost "anything" (within the scope of the library of course), and giving such flexibility but keeping things as simple as possible is very hard.
What do you guys think? Did you write some libraries you're proud of (and you dont have to tweak for every different project)?
Writing libraries vs writing apps. - ThemsAllTook - Nov 9, 2008 04:28 PM
Yes, it's definitely a very different problem set. When you're writing a library, your primary concern is exporting a simple, clear, well-defined API. If you're writing an entire game or application, your code can be a big pile of rubbish, but still a very good end product if it works when compiled.
I find that writing an API for others to use is a great coding exercise. It teaches you to explore the full complexity of a problem while keeping the interface and implementation as simple as possible. This experience filters down into the rest of your coding, and you end up writing cleaner and more robust software because of it.
Writing libraries vs writing apps. - McSebi - Nov 9, 2008 05:10 PM
As soon as you start to write a second game similar to the first one it is useful to think in libraries in my opinion. Otherwise you will start to duplicate code. So even if you don't plan to release it for others you should write a library.
As an object oriented programmer I always tried to separate the game's aspects from technical aspects thus keeping it as portable as possible. This ended up in having a game animation library which could be made accessible by others.
What prevents me from doing this is not because it may not be 'complete' in some way but because it had to be well-documented which is the hardest challenge in my opinion.
Writing libraries vs writing apps. - bronxbomber92 - Nov 9, 2008 05:40 PM
Libraries are definitely more difficult to write. For me the hardest part is anticipating what problems I might occur in the future and choosing the right design that will easily adapt to said problems, yet still remain robust and easy to use.
Writing libraries vs writing apps. - sohta - Nov 12, 2008 11:43 PM
From a real-world perspective, setting off to write a library in the first place is a recipe for trouble unless the library itself is the project in the first place. This is especially true in game development.
I honestly recommend the following: Build a program like any other, and throughout the process, any time you create a class, data structure or process, ask yourself: is this "library worthy"? A few simple examples would be: cVector: Yes, cMesh : Yes, cRobot: No.
Anything that is library worthy goes in a library. If the libraries are statically linked, then the executable will be none the wiser anyways. Once a library starts to have a certain "mass". Take a step back and refactor bits and pieces of it. Isolate common functionalities, remove redundancy, standardize interfaces, etc...
If you did things right, when you start another project, you simply have to import your libraries to have a solid starting point.
Let me say this again: If the library is not the product you are shipping, then it's NOT worth your while to see it as one. It should always be seen as a tool, not a goal. This statement may sound obvious, but it is incredibly easy to loose track of.
N.B. All I have said above goes out the window if you are looking for some mental gymnastics, in which case library design and development is ideal.
Writing libraries vs writing apps. - Wowbagger - Nov 13, 2008 12:08 AM
Although I too am an amateur coder, it seems to me that libraries are just inherently more difficult to write, and the responses in this thread seem to back that up. Even if you're adapting it from the engine of a specific project (which is probably what I'd do, especially in light of what Sohta said), flexibility becomes much, much more important, and I think designing something with the amount of flexibility required of any library/API is pretty challenging.
With that said, I'd like to point out something. I can understand why someone might want to write a library if they wanted to release it to the public, but most of the time, is it really worth it to write a full-blown library? Why not just save the best parts of the engine, like Sohta was suggesting, but just leave them as reusable modules of code instead of trying to polish them into an actual, linkable API? I mean, all you really need are the code modules (the objects, data structures, etc.), and they don't necessarily have to be as flexible as they would if they were part of an API (just so long as they aren't dependent or specific to a certain project). It seems as if writing actual libraries would be overkill in most situations, in my opinion.
(Although I can't deny that having a standalone, linkable library for use in future projects would be pretty darn cool.)
Writing libraries vs writing apps. - Bachus - Nov 13, 2008 03:39 AM
Wowbagger Wrote:With that said, I'd like to point out something. I can understand why someone might want to write a library if they wanted to release it to the public, but most of the time, is it really worth it to write a full-blown library? Why not just save the best parts of the engine, like Sohta was suggesting, but just leave them as reusable modules of code instead of trying to polish them into an actual, linkable API? I mean, all you really need are the code modules (the objects, data structures, etc.), and they don't necessarily have to be as flexible as they would if they were part of an API (just so long as they aren't dependent or specific to a certain project). It seems as if writing actual libraries would be overkill in most situations, in my opinion.
There are some people who would definitely recommend you not use frameworks in an attempt to reuse code. Used improperly it's easy to introduce unnecessary bloat and most code just can't be reused as is between projects. If you actually want to make a game, write the game, not the engine/library/framework.
That said, I've got a geometry library I use in all my projects that I statically link in. Super handy, but it's evolved over a decade-ish of coding and a couple dozen projects.
Writing libraries vs writing apps. - Najdorf - Nov 13, 2008 08:38 AM
Yeah I so far i just copy-paste my old files, I try to never remove functionality so that the latest use of a file is always the one to use for new projects, but I don't make an issue of changing the interface or other.
I'm fairly new to c and c++ so my style is still evolving, so I don't see the point in "sticking" with what i wrote.
That said I admire people that write libraries good enough for others to use, they're likely better coders than the rest of us application hackers.
Writing libraries vs writing apps. - backslash - Nov 13, 2008 02:32 PM
I've been gradually trying to beat some bits of code into a more generically reusable form recently. I don't see much point in releasing it as a proper library at the moment as it is little more than a collection of sample code and fairly basic functionality that I got fed up of having to hunt down/copy/paste or re-write all the time, but it should be handy for me. I don't want to have to copy the files into every new project though, so I think it may well end up as a static library. I suppose that gives me an extra incentive to not remove functionality (it'll break the old apps) but it's bound to give me headaches down the road when I realise my sound code is rubbish or something.
I think writing a good library for release is probably a very good exercise in planning and writing good, efficient code, but I know I'm not really up to that at the moment.