Average Software, the fact that you have a degree have no value here. You need to provide arguments for us to work on, not more, not less. Diplomas don't prove anything - specially in our domain.

Anyway, I see your point but I see that it's a pure theorical point that is simply not pragmatic AND isn't even realist or practical. Because only if there was a common architecture for all computers that what you say would be true. As it's not the case, then it's not.

I understand that this might not always get the results you want, but it's still the right way.

That assertion makes no sense. We might want to get a specific result here (and games are in this specific case). So it's not "the right way".

Just like returning the wallet you found might not get you a reward, and you might want to just keep the money, returning it is the right thing to do.

There is no logic in this example.

I understand that this might not always get the results you want, but it's still the right way.  Just like returning the wallet you found might not get you a reward, and you might want to just keep the money, returning it is the right thing to do.

Perhaps it's my military background, but I always attempt to do things the right way first (I've seen what happens what convenience is chosen over correctness, it never ends well).  This is why I feel dirty when I have to bundle dependencies, I know it's wrong and it makes me feel guilty.

Most of this issue on Linux comes from Windows developers that have been doing this years over there because of Windows' lame library model.  They come to Linux and expect to be able to do these the same way, without realizing that a lot of people resent the practice, particularly those running the more "hardcore" distros, like me.  A lot of us left Windows because of crap like this and we don't want to see it infecting Linux.

Please first, as slembcke said, don't assume anything about our experiences (you woudln't even be able to imagine people's here experiences as they are so wide). I might be mainly (but not only) a Windows developper but I fully agree on what you said on the theorical point of view.
Now Games are just a specific case of closed software that is his own full purpose. It uses the system as an environnement to exist in but it is not a tool to be used inside the system.

The experienced you have while developping military soft. are certainly biased or, if yuo prefer, games programming is naturally biased because specific. You cannot generalise by making converge your experience only with pure theorical perfect organization. In the real world, there is no inter-domain way to do things perfectly so ther is not "right way" for every softwares. Take a look for example at web developpement. I mean, not simple php website but really web-application with really tricky systems behind. You might be surprised as much paradigms use in embedded and classic application developpemnt are just plain wrong.
I also seen things plain wrongs while simply passing from C++ to Flash for example, because the whole system don't work the same.

In games, first, all depends on what you target, so let say you're on windows/linux/mac. NOw that it's said, all depend on what your game needs. 3D? 2D? Audio? etc. All that, cannot be the same for all (type of) games. The only common point might be that they communicate (in the end) with the system that itself communicate with some drivers.

So to make it clear : in GAMES, we need predictability because we simply need to control the User Experience. That mean that any software behaviour that is not known have to be isolated or forbidden - you just CAN'T afford to have undefined behaviour. It's worse when the code is not your's (that's why graphics drivers developpers need to be in contact with big 3D games company to know ealy about what to fix in their drivers).

Even when you allow extension points in your programms, you know exactly what entry points of code will be called and even can control and limit the exentions ability to manipulate your game. For example by providing a scripting system, you make sure only functions of the game that you want to expose can be run and that there will not be any additional dependencies.

Predictability is REQUIRED for games. As you said yourself, assuming the system always have correct dependencies that behave always exactly the same is just plain wrong - so to make sur we have the right dependency with a specific version of our games : we bundle. Simple and efficient.

Maybe what you don't understand is that on linux system, everything is organic, so we know that the system is less predictable than on windows or even mac. That's a good thing for a lot of software but again that's the worse environnement for games.

By the way, Windows also have system dlls that you can rely on (for example DirectX) but you still want to have specific versions. Linux AND on windows works alsmot the same on the depency system, it's just that Windows don't assume anything in your way of organizing your software while Linux does. Now, knowning that you need predictability for games, and you make games, and you want it to work on several platform, or whatever the platform - we don't even care - you still need to have the same dependencies, in the same versions, so you just bundle things together.
All that paragraph to say : don't assume that we need to bundle because most game devs are windows devs. It's because it's about GAMES. Assuming this is like an insult on to the common sense of all the game programming industry and indie scene.

(did you know that even on consoles almost all the system libraries are embedded directly in your games? that's also for predictability )

(and "correctness" is orthogonal to the issue here)

It should be avoided whenever possible.  If you need to do it to make your program work, than it's obviously not possible to avoid it, but that doesn't change the fact that it's an incorrect OS practice.

This have nothing to do with the OS. Bundling with your dependencies is valid for games, as explained, whatever the platform, whatever the dependency system. We need to have a fixed context. That's a need, not an ideal.

Once again, I understand why people do it.  I understand that people sometimes have to do it.  It's still wrong.

O__O; So there is no arguments in being right because that's the only correct solution?

You're not making any argument other than "it's wrong" or "it's right". What I understand is that "it's not ideal" or "it's ideal" but it just can't be a "right" answer if it's simply not applicable.

You seem to be interpreting my statements as some kind of attack on your character, that's not what I'm saying. 

Oh no, not at all  don't worry, it's just a technical discussion, everything is OK. (I might use big capital letters just to be sure you see some important statements but maybe I'm abusing of it, sorry)

I see that you agree that we need the bundling solution, but that's not ideal, ok. What I don't understand is that you still assume what's not applicable is the correct solution. Looks like some kind of logic fault?

I see opinions collide here, mostly POV from user vs. developer.

I don't agree, that's more a software-theory POV vs a pragmatic-reality-checked POV.

Just be pragmatic:
Do you want an ideal but in real life unrealistic approach (nicely shared libraries with different versions, with always compatible interfaces) ?
Or an a tad ugly approach but simply working.

Guess which the user cares for most.

I fully agree.

An players are users with the less technical fault tolerance.

[asking for introducing unknown code]

If you want a black box, go develop for consoles.  Home PCs haven't been black boxes since the 8-bit era.  Ever hear of "DLL hell" in the Windows world?  Developers' attempts to turn Windows into a black box lead to that problem, and a lot of programs are still digging their way out of it.

I used to work on a program like that, it wasn't fun.

Again, I'm talking about a SOFTWARE black box. Most games on Windows only require at least a specific version of DirectX to be installed on the system, not anything else. That's because we provide the dlls of the dependencies we need. They ARE black boxes and they work fine.

DllHell only happen when you think the user system's might have a better version of the dll and try to use it. This is just asking for introducing unknown code in you own software - the exact opposite of predictability. For some kind of tools that's a good way to think about. For most non-dev-user-targeted softwares, it's simply wrong to assume anything about the user's system, other than the minimum configuration.

That's like relying on PATH addresses, that's practical if you know the system your software will be installed on, it's not practical at all if you don't.

This is why you open source your project, and if it's any good, people will make (and even maintain) the packages for you.  For cases where nobody makes one, the user can build from source.

I was wondering how long it'd take for this to come up.  Look, I'm a fan of open source and all, I've even released some myself and have contributed to other projects (some of which were commercial, so I'm perfectly aware that open source software can be sold). However, not everything is open source, and Linux is not only for open source. We're not discussing open source here.

Same here, I'm open sourcing some game code currently.
Still I know from other's long experience (study big open source projects life, it's fascinating) that some kind of software just can't live in open source state if they are owned by a company. Open sourcing is not good for everything.

So no, we shouldn't open source everything.

That said, that's another subject and if you want to discuss that, I suggest you create another thread.

We're making games, we need predictability, we need to be sure the same version of the game runs the same everywhere (as far as possible). If there is a better version of a dependency on the system, it might well break the game!

And a better version of the dependency might well make it run better.

It might! In that case, you bundle that better version in the next version of your game, and everyone benefits. Isn't it great?

Exactly what I meant.
And if the new version of the dependency is bad, your game still Just Works(tm).

For games you don't care about the user's system. You want predictability. So you want to "bundle" (maybe not the way this tool do it but provide your own dependencies anyway).

You don't care about the user's system?  Someone is nice enough to obtain your game, possibly in exchange for money, and you don't care about their system?  I can't believe I just read that.

Pretty sure he meant that you don't care what may or may not be installed on the user's system, because you've bundled what you need. Obviously you care that your game works on the user's system, and that the system isn't harmed in any way by your game.

Yes that's what I meant. You don't care about the environnement, if you prefer, because most of the time your game is it's own full environnement.

That's why I'm talking about games as black boxes, not the computer itself, just the game software. The game really runs in the player's mind. You shouldn't require the player to know anything about the software that provide the game experience. Each time you make the player aware of the dependencies or internal structure of your game, you break the suspension of disbelief even before the player started to play (that's also why some game isntallers are so elaborate : they preparet the player's mind, making it forget about the fact that the installer is currently copying files and doing not-pretty things). Showing dependencies is like showing your own guts to people.

I must add that I would have agree on the shared library thing with Average Software if it was not about games but about, for example, developpement tools.

But we can't generalize on this matter, that's why all those different ways to make binary modules exists.

I too have to admit this tool isn't useful for games, for several good reasons exposed here.
However, I have to react to a few points :

No, bundling does not defeat the purpose of shared libraries.

Yes, it does.  The point behind shared libraries is that they're shared.  When you bundle them they aren't shared.  They're used exclusively by your application.

Wait, you're over-generalizing : I have several shared libraries in my game, that I made myself (other than some dependencies like Ogre - THAT I'll NEVER TRY TO BUILD MYSELF, bu sure of that)

The point, in my case is to share the binary with
 - my own app code (I need some module separation for some reasons)
 - extensions/plugin (other's libraries that could be loaded in my game and I need to provide a shared library to plug their binary in)

Now I guess you're speaking about the dependency libraries shared by the system, not those that are used only by your app and provided by it.

The core problem of linux bundling seems to be that : you can provide your own dependencies with your app, not installing those dependencies on the client system, simply using them by your app - but if you do this you can't get the benefit from a better version from the user's system.

But who cares?

We're making games, we need predictability, we need to be sure the same version of the game runs the same everywhere (as far as possible). If there is a better version of a dependency on the system, it might well break the game! So not bothering about this and just having an update system with the game seems to be a better idea than avoiding any shared library or assuming the user will install libraries at the time he JUST WANT TO PLAY (even if he's a linux user).

When I talk about bundling libraries being wrong, I'm addressing it from a computer science/OS practices perspective, where it is well known to be a bad thing.  As I've mentioned before, libraries are meant to be shared across all applications, and bundling ruins that.

For games you don't care about the user's system. You want predictability. So you want to "bundle" (maybe not the way this tool do it but provide your own dependencies anyway).

The best is to simply not have so many damn dependencies.  I wish people would get away from crutches like SDL and SFML and learn to open a damn window the real way (seriously, it's not that hard).  I have my code down to a handful of dependencies, and all of them are pretty much standard on Linux distros, so I don't need to ship anything on that platform.  I have to ship a couple on Mac, and significantly more on Windows, but I never statically link, because I have more respect for my users than that.  If some Windows guy already has the ogg vorbis dlls, he has every right to delete mine and use his, and I was never impugn that by statically linking.

Are you mad? Not every game developpement can afford to spend some months simply bleeding code to get a window, some sprite system, even a 3D engine. We can get all that for free and that's what we need libraries.
Now we could simply compile them as static libraries but sometimes it just don't fit the need (as in my case where i need the plugins to be able to manipulate Ogre).

In short, yes, you may sometimes feel justified in bundling dependencies, but you should feel guilty about it. 

YOU feeel guilty.
I never have. I prefer a closed black box game that Just Works(tm) than an half-implementation starting point software that requires you to get all the right tools before you can PLAY. It's  not tools, it's games, it don't work the same and it's why there is a separate game folder in most linux distributions.

Black boxes let the player concentrate on the game and forget about the software.

That's what I understood before and thought it was a good thing to be free to do as I said.

The takeaway from all of this is that you don't need to develop your game specifically for Steam. Just make a kick-ass game, and then start shopping it around to the various distribution services available. No matter what development system you are using, you will probably be able to integrate it into these distribution systems down the line.

I think that's the most important thing. Even if I'm planning (on long term) to have a community system for my game, I'll not base it on Steam because I don't know if I will have a deal AND I want to have full control (as in informations hosted by me and only me) on the community system.

Really?
I thought most of the accepted games in steam were just one of those :

 1. The steam teams find it fun to play.
 2. It's a (hardcore?)gamer-centric game.
 3. You're a big game company and you are willing to pay to be on steam.

I can't find any other logic than that in their choice.

That said I never tried to submit nor even contact them for business so it's just what I'm guessing by looking at their catalog.

Are you sure you need to use steam libraries to be on steam? As far as I understand, their library is only needed if you want your game to use some steam features, and all the flash or fusion games cited that have been on steam don't use them. I think you can get on steam without changing your code, but you'll not be able to exploit some features like getting basic account informations. For some games that don't seem to be a problem.

Wow, looks like very interesting! 

Will have to try that to make sure it really works...

Personally I used a fixed grid because I'm using a fixed level size. And I don't actually instantiate buckets I don't need. But I'm in AS3, I'm not penalised for multidimensional arrays, and because it's ECMAScript - everything is already a hash table.

So yeah - my approach is likely not C friendly because I've dumbed it down and specialised it for simulating crates.

Other than having an implementation ready in the language, I don't see the problem with C an C++ ?

C++ too have a hash table (std::unordered_map or boost::unordered_map if you don't have a recent compiler) and it only needs to provide the hashing function if it's not already implemented in the standard. Maybe an implementation can be done using that?

The code is online. I'll update this thread once I've setup my collision system, just for you to have a look, see if it might be better. (don't hold your breath though)

In fact my main bottleneck don't seem to be the spatial partition but certainly more the "color" matching feature - because there is 4 butllet colors, plus one ennemy/bullet color plus one blocks color (with well choosen colors). Depending on the colors and what collide with what, there is not the same effect. I've made a table see what should do what when colliding with what and now it's clear to me that I first have to make the collision rules work before maybe optimizing the collision resolution.

I'm putting my code (without the collision system I started to code) online as it's open source : http://code.google.com/p/radiant-laser-cross/
edit> I'm pushing the code, it might not be visible yet.

There is only player ship control for now but I think I can make something of it through time.

st33d> I'll take a look, thanks!

Oh thanks for the explaination, it's very clear!
It's like a quad tree with only one depth level and with a trick to avoid multiple collisions detections when not valid.

Ok I'll isolate the collision resolution system to first implement a naive big for loop - to make sure the code organisation work - then try the algorithm you're talking about - to optimize the collision resolution.

For a game where you only care about collisions that happen onscreen, I'd still use a fixed size grid to accelerate the collisions. Far easier to implement.

By grid you mean some kind of quad tree?

I think these tutorials are what you're looking for implementing collisions for a bullet hell game:

http://www.shmup-dev.com/forum/index.php/topic,1635.0.html (AABB based)
http://www.shmup-dev.com/forum/index.php/topic,1636.0.html (Circle based)

I'm currently making a bullet hell shmup game, and this forum has some great information in it.

I wanted to have a look at those links but it seems that the whole domain is down... any idea what's going on? Can I find the same informations (about bullet hells) anywhere else?

As said by pm, I'm still interested too

Maybe you could try making a game with SFML, there is a Ruby AND a Python binding : http://www.sfml-dev.org/download.php

I'll try the D language exactly this way. It's good to have a simple game library available in each interesting languages!

That's what I think too.


I'll try to keep everything in aabbox and circles, it'll simplify the design anyway.

Now that I think about it... I might need oriented BBox collision too :/

I'll implement all that manually anyway.

Well, by reflex I prefer to look for a already-widely-checked-code library instead of coding my own buggy-and-not-so-well-thought implementation, but if you don't know any simple library to do that, I'll write the (simple) collision system.

My project is about bullet colors (Ikaruga for the win) so maybe I'll have oportunities to specialize/naturally-optimize for my specific case.