Writing libraries vs writing apps.

Member
Posts: 749
Joined: 2003.01
Post: #1
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)?

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #2
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.
Quote this message in a reply
Member
Posts: 22
Joined: 2005.02
Post: #3
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.
Quote this message in a reply
Member
Posts: 312
Joined: 2006.10
Post: #4
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.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #5
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.

- Sohta
Quote this message in a reply
Member
Posts: 67
Joined: 2006.07
Post: #6
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.)

Since when was "Fred" a placeholder variable?
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #7
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.

(Although I can't deny that having a standalone, linkable library for use in future projects would be pretty darn cool.)

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.
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #8
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.

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Member
Posts: 245
Joined: 2005.11
Post: #9
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Tips for writing a tutorial pabloruiz55 2 3,046 Apr 24, 2012 11:11 AM
Last Post: pabloruiz55
  How to start writing games (includes exhaustive list of options) stevejohnson 13 7,324 Nov 1, 2009 12:55 PM
Last Post: Mike Richardson
  Trouble writing a GLUT-like API TomorrowPlusX 2 2,549 Jun 2, 2009 03:47 AM
Last Post: TomorrowPlusX
  Writing an ObcJ function/calling it from C++ Jones 20 9,154 Nov 21, 2006 06:32 PM
Last Post: OneSadCookie
  dynamic arrays, file reading/writing, etc. wyrmmage 6 3,891 Nov 10, 2006 06:08 PM
Last Post: akb825