Took my friends advice. Now just making tons of mini prototypes in Unity3d. The iteration rate is insane. I have tried loads of quirky little ideas which have spawned new ideas and new directions.

Just written a quick flocking behavior and realized it is probably a good idea to work on my GameObject so that I can have different behaviors for different types of object. This is going to be SWEEEEEEEEEEEEET!!!

Maybe it's the games that are at fault. Allow users to configure their setup and have a choice of input device. <GASP>

Flocking algorithm. This is fun!

LOL!

Don't be afraid to say what you think

Interesting thoughts on writing an engine vs writing a game. I think it is easier to know what to do next when writing a game engine as it is fun to play with cool technology. Writing a game doesn't require all that cool technology it requires a good design and that may mean scrapping that cool serialization/reflection system in favor of "just get it done"

Anyway. I'm rambling.

Back on track: After writing some quick prototypes to see if map generation is a viable option for making fun and interesting worlds (in my case the answer is YES!). I have now re-factored my generation code out into several small components that are surprisingly generic. This has fired me up! I can see how easy it is going to be to make themed maps with unique design flow and built in puzzles.

YAY!

Lots of great links here! I'm writing some map generation code that is based on the following link. It's pretty simple but very flexible and easy to extend.
http://www.squidi.net/mapmaker/map/map03.php

Also Squidi has some cool ideas on generating maps and adding puzzles to the generation process, a very good read.
http://www.squidi.net/mapmaker/musings/m100820.php

The new version of SDL 1.3 has support for multiple windows. So kinda...
http://wiki.libsdl.org/moin.cgi/

But I understand that SDL 1.3 is still in beta...

First pass on a map generation algorithm. Results so far are very promising! This has convinced me that writing a map generation algorithm is way more fun then writing an editor.

Now off to buy some beer for lunch 

Check out this too...
http://forums.tigsource.com/index.php?topic=16972.0

http://www.ogre3d.org/
Ogre is great. It is well written, well documented and well supported. It has lots of graphics technologies that will be of use to you. Of course it is only a graphics engine though so sound or physics etc will have to be added by yourself... OR you could follow 1 of the excellent tutorials on adding sound etc

Personally, I just try to minimise dependencies in the code. Seems to work quite well, as long as you're suitably disciplined.

Agreed! Forward declaration is a good way to do this.
http://www-subatech.in2p3.fr/~photons/subatech/soft/carnac/CPP-INC-1.shtml

I figured out how to create a widget that makes any animation inside it look like an old black and white film. All of the artefacts are code generated, including the fluctuating filter, meaning I can apply this to anything.

http://www.robotacid.com/misc/oldFilm.swf

Yay!

This makes me SO happy :D

I hate algorithm design

There's this game called Minecraft you may have heard of. It's made in Java.

That's the one so slowly developed that it's only just reached beta despite millions of users?

Not trying to "get on the hate" or the "My dads better then yours" kind of debate... but... Minecrafts development has been crazy fast! He managed to go from a static discrete sized map to an infinite world in a few weeks. That is impressive. Streaming worlds are pretty hard and he did it well. And fast!

That is all :D

Is it possible to have an option screen and let people set there own?

Perhaps for ultimate compatibility software rending is an option?

That gives me the shivers! 

I agree that immediate mode is pretty rubbish if you want performance. I was surprised when I saw that SFML used it! That said the question asked was about maximum compatibility so I think using immediate mode is fine as long as you are making a simple game.

My personal preference would be to have 2 classes like MeshVBO and MeshDrawList. Each would be inherited from a virtual class Mesh. When creating any vertex data (a Mesh) the system can check if the graphics card supports VBOs and create the best solution for the current machine. The hpl Engine (used in Penumbra and now open source) has an excellent example of how to do all this!

I will also take this opportunity to say that profiling is well worth doing! I don't think we discuss profiling enough on this forum. Any code can (and should) be made to run faster, often with very little effort.

I guess my concern for this subject stems from a big project I made in XNA. I was very disappointed my friends couldn't play it (main problems were installing prerequisite's and lack of compatible graphics card).

Relating to this comment, you seem to be concerned with the power of peoples machines and what hardware they support. Using SFML is pretty good step especially if you are using the built in sprites and drawing methods. These all use OpenGL immediate mode rendering (from what I remember at least!) so will run on any graphics card that supports OpenGL. XNA requires people have graphics card that supports a minimum shader level.

The concern of making a game run on as many hardware setup as possible is quite close to my heart! Optimise people! <AHEM> Here are some thoughts

• I think the trick is to target a low end setup as a minimum point and work with that in mind.
• Avoiding hardware dependencies (like the graphics cards that require a minimum shader language) is a big MUST! Like I said using OpenGL immediate mode rendering is good though you can do tests to see what the graphics card supports and then brnch your code/do a bit of C++ OOP.
• Frame rate is king! Using a profiler will help with this, or just writing a simple profiler into your code, is well worth doing.
• Code well. This may sound patronising (and I'm sorry id it does!) but correct use of data structures and good code design is going to go a long way to helping you write efficient and fast code.

If you are making a 2D game then generally it should work ok. But. There is always room to make it run faster!


Interesting pop fact for you. Valve have always gathered statistics on users systems. They discovered that a very large percentage played in software rendering despite 3D acceleration being the norm. Also the developers of The Sims claimed that part of the reason for its success was it supporting low end systems. Again with a software renderer. Pretty cool huh?


Hope that all makes sense. I'm a little tired :S

There's the O'reilly "Killer Game Programming In Java"

Thanks for the pointer. Just found a preview online. It looks a little old and still isn't what I'm after I'm afraid It goes through how to make a few types of games as well as some simple systems like and animation system and a particle system etc. The particle system looked the most interesting as it had a section on performance. But the rest is just a little too beginner level for me. Not to worry, so far I have gathered enough tips from forums and a few blogs. Plus, as mentioned before, the Android profiler is EXCELLENT!

I would just pick up a framework like LWJGL

Good tip! I'm actually using a new library called libgdx http://code.google.com/p/libgdx/
It is a cross platform API that wraps Lwjgl or Jogl or Android. So the platform specific stuff like setting up the application, handling when to reload assets (i.e. textures, VBOs), input, sound etc is all handled automatically for each platform. I'm very pleased with it so far. I agree that an existing API is a very good place to start. I would add that it is even better to grab the source to the API and see how things are put together. As libgdx is written to run on low end Android phones upwards so they have done some interesting optimisations. Looking through this code I have already dived in and pointed out a bug for them :D

As for optimisation, I would avoid premature optimisation

Yes of course! This was such a simple optimisation that I had no concerns adding it. I have avoided the heavy optimisations as I still have too many decisions to make. My first piece of code was simply a prototype to answer the question "Can I get X to work on my crappy Android phone within a decent frame rate?" The answer is a resounding "YES I CAN" with no real effort.



Cheers!