And Nox. And Sacrifice.

I'm not sure...








But I would say Rez.

This is going to sound crazy, but since I started this post, I have been persevering, and by god I have learned how to code!  I mean, all the knowledge from doing the same tutorials over and over, it just kind of clicked!  Obviously I have a lot to learn, but I'm past the brick wall stage!  It feels awesome!

This is pure love. 

I was more thinking about something different than the global game jam, but that's an idea, thanks.

I just wanted to know if there have already been jams in Paris (France) before?

I thought maybe I could try see if I can organize one in the middle of the next year (if I can).

I never made a trailer, but when I'm imagining trailers for my in-dev games, I always first imagine the trailer's music. Then I map visual sequences and effects on it.

So maybe aligning your video on a short sample of efficient-alone music might do the trick.


If it's not to show the gameplay.

Too bad there is no easy and cheap way to do the same with your home local network. Licences for those kind of softwares are targeted to companies that have money to spend on tools to earn time.

However, indies most of the time don't need eavy compilation stuff.....


...I'm saying this but just having some libraries in my big project code base make it compile in about 30 minutes on my desktop computer.
I just got a faster laptop (corei7) and it cut the compilation time to 15 minutes.

I made it bearable by carfully deparating my project and libs in modules, to only compile minimal parts of the application. And, obviously, scripting languages help a lot on this problem.

People good at something just persevere.


It's the only quality required. They go beyond frustration to understand and get to the point that they enjoy it.

I've read an article about that, that children taking problems as challenges always get somewhere while others simply frustrates and think they're not good enough. Can't find the link.

Anyway if you really want to program, just persevere in learning until you feel you can do something with your basic skills. Then build something (that will make you learn) then get back to pure learning and then build something (and learn) etc. Never stop. Ever.

With C++0x yes, with scripting language or dynamic languages no because they are not system programming languages. They target easy expression and even with fast execution (like python) they dont allow memory manipulation by nature, that don't allow application-specific optimizations (on memory at least).
The fact that it requires at least 10 years for a language to achieve it's maturity (the point where you can consider it for a serious project) makes me think that it would be hard to have anything else fight with C++0x than D and Go in the coming years, and they are not there yet.

That said, I'll be personally happy only when we got modules in C++, in the following standard (C++15?)

Klaim: Neither D nor Go are credible challenges imho. Garbage
collection makes them terrible for real systems work, and in general I
don't think either has basically any maturity. D has been around
longer, but the split versions/std libraries really make it juvenile
in terms of other libraries available.

I consider them "potential" challengers, they are not NOW but they COULD be.
Currently D provide ways to not use garbage collection so that's not a
point and Go is built in a way that i think is not really "garbage
collection". In any way, they have a point in being designed for
"system software", not general GUI or web app. They have the right
"mindset" and that's the only way to be a challenger to C++.
Now maybe they will never achieve it. Some features of D makes me
think that they will, some other makes me think the other way.
We'll see in 7 years if they matured enough.

Anyway, without support from the game industry, all technical concerns
have simply no sense.

Git and Mercurial are excellent when you just want to commit locally and don't send your shit to everyone. When working alone, on a laptop it allows you to commit a lot and pushing in your main repository later when you get home (if you have more than a laptop like me).

That said, even if Tortoise Git has good interface (but is misleading because it uses concepts names from TortoiseSVN, and that is not a good idea...) git itself on windows is really badly supported. You can get silent errors often and it can have very strange behaviour. In fact it's too hard to implement git in Windows because it's thougt and implemented with linux environement/tools in mind.
Mercurial is better on this side as it's Python so it's easy to hack and easy to get on a platform that provide a python implementation.

I wish there was a soft that would be a mix of Mercurial and Git, that would really be excellent as they offer almost the same things, only their defects make them different from each other.

I Totally agree with Impossible.

In fact, I made recent (personal) researches see what languages currently have the best chances to replace C++ in the game industry. I think that if it have to happen, D and Go are the most credible challengers as they both target the same kind of software : system programming. Now D is the most mature of the two but it's not mature enough yet to be used somewhere else than on computers (not on consoles).

Something tells me that C++ might be ditch out of game dev world only if console constructors don't support it anymore and support another language. At the moment, it's not possible at all.

If D or Go or another language get some way to work with C++ code (instead of only be able to work with C code) then we have a real challenger. C++ have too much code available (for free or not) starting with game engines and basic game engine bricks libraries.

One of the biggest reasons I wanted to start on C++ is that every time I make a game in C#, upon release droves of people complain about having to install the .NET framework, and have huge issues getting all of their dependencies in line. I thought that if I coded in C++ for multiple platforms, it would allow me to distribute my game as a neat little executable without much hassle.

That's the main reason I chose C++ for an open-source tool project to make sure it's cross-platform and stand-alone.

Just for information, you used SFML 1.x  or did you try SFML 2.0 too? I didn't yet try this not-yet-released version so it's just to know if you already have seen interesting improvements on this side.

 - sdl : old, C interface - as it have an old interface, it's full of unintuitive functions, but as it's old it's available on a lot of platforms;
 - SFML : thought to be a replacement for SDL : C++, well thought interface (better with the coming v2.0), simpler to understand, cross platform and cut in several libs (audio, graphics, etc).
 - OpenFramworks : not the same thing than the two others, it's to have a crossplatform environnement with ready-to-be-used tools.


For games, I think using SFML is the best choice: it allows easily building a game-specific-engine over it, life if SFML was a set of bricks to build with.

There was a discussion recently about SDL vs SFML vs others.

I think we don't have enough precision about how is structured your space and graph to really help you. All those answers are valid but it depends on what you already have. Is a zone a box in space? Is it a group of nodes? Are the nodes equally distant? etc.

I use it too but remember that it's a solution for advanced users. Other potential customers will only assume tha the game will provide some way to make it work with non-english keyboards.

Why not simply make your A* direction target the center of the zone and make it stop when it reaches a vertice inside the zone?


Another way to do this is to have another graph for "zones" only.

That way, you use this zone graph to know wich zones the agent have to go through. And inside each zone you'll have another path search to reach the exit of the zone to the next zone.
I've done this before, it works nice but you have to have entry and exit points in each zone (multiple or not).

This one : http://sourceforge.net/projects/wgois/
It's used in sample applications of Ogre rendering engine.

That really depends on the engine/implementation.

I use OOIS (C++) for keyboard and mouse inputs and it takes the local by default I think.


Some engines will provide advanced features to manage localized keyboard, but it's not useful for every games.

The best thing is to make sure there is a simple way for the user to re-map the keys to actions.