The title says it all : can you recommand a collision-only library for 2D gameplay shumps?

I've looked in depth at Box2D but it seems overkill for a non-physics-dynamics SHMUP.
Is there a popular collision library for SHMUP? Something optimized for bullet hells would be perfect.

I've serach in google but it don't return a lot of interesting results and get wickly to 3D collision libraries (I could use one maybe...).

Just to put a clear comparison, here's the MIT licence :

The MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

(from http://www.opensource.org/licenses/mit-license.php )

MIT either, right?

Argh licence choice is hell...

Hmmm I'm starting to feel like if it would be a better idea if other people could feel free to build awesome (commercial) games over my original code... after all it's not like I'm a specialist and the code is a bit naive I guess...

The more I think about it, the more I think I should use a MIT licence to allow any kind awesomeness to occur - and let people help fix my code.

I still have another big commercial project so I'll certainly give this one for free.

Do you think it's a bad idea to go with the MIT licence?

Yes I want to let people script new levels.

Thanks for your advices, I think I'll go as you said.

Hi everybody!

I wanted to ask for your experience about this :

I have this little shmup prototype that I'm currently refactoring to allow me to add some features. I need to do this because currently I don't have enough of the game to make a full level and it's required to demonstrate the point of the gameplay.

Now, as it's a little game project, and I'm using it to test some "new" things like ChaiScript, CMake, cross-platform compilation (I mean that it's the first time I'm trying to make a game run on several platforms).
I thought that it's a little enough game to put it open source.

But I hesitate.

I know that the game potential might allow me to do interesting things later. Like maybe building a sellable game on it.

But if I put the code open-source, will I have problems with trying to sell a game on it?

I was thinking maybe providing the core system open source and the level-design + resources would then be part of a sellable game - not provided as open source.

What do you think?

The best way to answer the initial question would be simply to open source the code and let us know to make us try and check if it's useful and generic enough for our uses.

So clean the code, make some simple doc (like your example) and put it somewhere in a public repository with a simple web page. Google code hosting (http://code.google.com/hosting/) for svn and mercurial, gitorious.org or github.org if you use git, bitbucket.org if you use mercurial, etc.

Then we will simply try and maybe suggest improvements and find potential bugs that were not visible in your own usage of the lib.

Not sure that you'll have to compile for this lib, I think that's headers-only. (anyway you'd better use CMake apparently to build the last boost versions)

Anyway yes if you avoid boost, don't count on it. You can extract one library only by using the installer provided at boost-pro.com but that's not perfect.

As they are planning to have a new library distribution system (http://ryppl.org) that would allow to get only what you need from boost (and others), maybe when it's officially running you'll have a good way to extract (and automatically compile) some specific libraries of boost with their dependencies.

Personally I always install boost on computers with C++ dev on it because it's a bit like my STL++. As I always have it in the environment I don't need to think about if I have to add it to a project or not.

Anyway my suggestion was more if you already use boost, yes.

As I pointed in the same thread, for simple access/writting to JSON there is boost::property_map that works for xml,json and the infor format.

I still suggest you take a look at yaml too.

Excellent information!

I still ask myself if it would have worked if it was a new product/name/author.

I guess that "build your name first" always apply for this to work.

My game is an RTS that require explicitely that you get a keyboard (in fact the mouse is optional  ) and is based a lot on player's strategy customization so I voted for other OS as it's in The Plan(tm) . A console wouldn't allow any of this.

If you use TinyXML, please try RapidXML too. It was designed to fix the interface and performance flaws of TinyXML.

A) If you don't need xsd or dtd validation then:

 1. If you use Boost (a recent version), you can use the Property Tree library that uses RapidXML as implementation for parsing XML. It also allow using other formats as stated in this page. As you want a human-readable thing, then I would recommand to use the Info format if you go this way.
 2. RapidXML Seems to be the current faster xml parsing lib around here.
 3. TinyXML is simple and fast enough in most cases (and takes a lot of memory but that's worth it).

B) If you want some xsd or dtd validation (for a tool app in C++) then:
 1. Xerces is what you need.
 2. Libxml++ might be interesting.
 3. If your tool uses Qt, it already have a good library for xml parsing and another for validation and other high level xml-features.

Now if I may suggest some alternatives to XML : XML being a language for inter-portability and not for human readability, there are better alternatives that you can easily embed in your game if a) you want the user (player or dev) to change the files without having to manipulate a tool; and b) you don't need several apps to read/write your data file.
So the alternatives that are good for human readability are :
 - Info (the special format used in boost::property_tree - I think it's only available there though).
 - Yaml - made to be human-readable, see the website! If you have some python scripts, it's also easy to manipulate with Python!
 - JSon (also available in boost::property_tree) - if your data are not too nested and don't require type checking.
 - Ini (also available in boost::property_tree) - if your data are only simple associations.

Now go son, you've learn everything I know.  

This thread (with a sum-up at the first post) should be sticked. It's really useful information.

If I remember well, there is still ways to have shared files for an app on Windows (even Vista/Win7 that otherwise will create a user-specific folder anyway if you write in the program files directory to manage old apps behaviour).

Have to check that too.

If you're doing it only for pleasure then use anything you like yes. If you're doing it to build your life on (making a indie business and living from it), you'll have to make sure that you don't have too many doors closed that might be fatal to your projects.

When you finally have a great game in your hands which needs porting to consoles, you can still rewrite the game in C++. You probably saved already way more time by that point than porting it needs.

It's not like once you use GameMaker, you can never go back (see Spelunky).

Well that's a possibility too. I think that depends on the complexity of the game. I know for example that the game I'm working on can't be done with flash or game maker. I could have prototyped it in Python, that's true. Now I'm more fluent in C++ than Python so I guess it was easier for me to go this way. Good point anyway.

I taught myself C++ one year ago (I was 16) with the goal of building games.

Needless to say, I never acually built anything remotely game-like using the thing.

With school and APs, learning how to do both code and design at once was too much.

Six months and many fruitless attempts later, I decided to settle for Game Maker- ultimately, it gets the job done.

Eventually I'll build a game using C++, but right now, I'm focusing on learning the design aspect. Doing your first game with C++ in a trial by fire is just fucking masochism.

I fully agree.

That's why you should know why you're making your game. For learning and pleasure, any language that you like is good. I personnally use C++ and Python even for simple prototypes but I'm fluent in C++, have a lot of years doing it. If I didn't made simple games when I was young using Basic and later Visual Basic, then I wouldn't have the taste of pleasure of making a game.

If you're going to be an indie, the language you choose is pretty irrelevant aside from your own personal tastes. If you like c++ use it, but not because it is the "standard" for mainstream companies.

That is just not true.

There are thing to consider in some cases of indie style.
When you say you're indie your either trying to be or being serious.
If you're trying to be, you want to make a lot of games like those on the compo around here.
After some time (or maybe from the beginning) you'll want to be serious.

At the moment you're making a game and trying to be serious, you cannot end with an half baked game, a prototype like a lot of games around. You have to make something complete.
As it's serious, the language then have an impact on 2 sides that you'll have to really consider:

 1) Portability : know the real potential of cross-platform of your language. If it is not cross-platform, or not on all platforms, know wich ones because you have to know where you'll never be able to put your game once out in the wild. At the moment, C++ is guaranteed to be cross-platform (but sometimes with some work, and you have to use only cross-platform features or isolate non-cross-platform ones, provided by compilers or OS API most of the time). Python is two if you're using cross-platform game engine with it (pygame or sfml). However I'm not sure for Python on consoles (NDS is a no-no, XBox might work, PS3 I don't know). C# can work on Microsoft platforms but forget about other platforms, etc. So if you don't want surprises, stick with C++ or C. Also, On consoles, constructors don't alway provide compilers for something else than C and C++. So if you cant get a vm on the console, you can't use a vm-based language. etc.
 
 2) Libraries : At the moment, C++ provide the wider range of libraries I know, about games and not-games. C# and Java might comme just after it but C++ have libraries about almost everything. If you're not making something...conventional (I am not) then you'll have to build some kind of framework to build your (specific) game engine on. That suppose, in the best case, you have access to sources of your tools, because any problem can be fix without having to wait for a bugfix release. You'll not be able to do that in languages that, for game developpement, rely on engines and libraries that are written in C or C++. If you work with C++ you'll be maybe able to bugfix yourself with a specific version of each the libraries. Don't understimate the problems you could have using opaque libraries. Businesses have been broken by this kind of problem.


If you're doing it only for pleasure then use anything you like yes. If you're doing it to build your life on (making a indie business and living from it), you'll have to make sure that you don't have too many doors closed that might be fatal to your projects.

(sorry for the necromancing but it seems important)

I just hit this question/answer that got me to this blog post that is really interesting on the subject of Component-Based Architecture. Leads also to Functional-Reactive Architecture that I didn't heard about before!

Thought people here will be interested.

In fact, almost all new licences that are not heavily marketed for months have low chances to be great sellers. They have some if they provide something awesome enough to "most of the buyers" to sell, but other than that they are coming from nowhere so they are not known enough. About that : http://www.lostgarden.com/2006/03/never-innovate-halfway.html

To me, Sacrifice did things in the strategy genre that are still not achieved again today. Like allowing the player to risk his commanding aptitude to go alone in the warfield just to release a Tornado that, if casting well timed and not interrupted, could make your opponent's army fly around, with the ground viewpoint making it fantastically amazing.


Now I understand it was first marketed well, then shortly felt in limbs because a lot of people didn't "think" while playing. It require a bit of intelligence to play while not seeing the whole world. You have to plan your way of fighting according to the combination of your spells.

Nox had too this spell coordination that made it excellent but the problem wasa that it was sold as a solo play game even if the whole interest of the gameplay was releashed in multiplayer, where players fought using tricks exploiting the side effects of spells.


I love side effects.

I find physics games the "easy way" to get some. Portal is one of the few games that had the smartness to not rely only on physics, but on "more than physics" too.