It's also nearly impossible to succeed commercially with a retro shareware game today -- a few people have tried it: Noitu Love 2 for instance, Gravitron 2, etc., but those have a very niche audience. Try to imagine if Braid, or World of Goo, or even Aquaria had used 320x200 resolution and 256 colors. No matter how nice they looked to fans of pixel art, they probably wouldn't have sold even a tenth of what they have sold with their current art style.

Yes, that is a very true statement.

The idea with Monocole is that it would have a rendering pipeline that would let you switch implementations between Directx / OpenGL. (eventually)

What Alec means with this, is that he'll be writing his own implementation which then calls either OpenGL and DirectX. This is common for a lot of older engines, although not so much today (depending on the engine developer) since the cost for cross platform is increasing quite a bit.

Engine -> Abstration Layer -> OpenGL / DirectX

It's quite a bit more work, but it is worth it for indie engines. Depending on the engine though, it may not even be neccessary to support DirectX unless the engine is destined for DirectX only platforms.

Most game objects should only need one audio source component and one renderer component. More complicated game objects could be set up with child game objects.

Hmm, that could be quite limiting and frustrating.

For example, a rocket game object could require more than a single render component and audio component. You may need a sprite rendering component for the missle itself, another sprite rendering component for the flare behind the rocket (its seperated so that it can animate independently from the missle sprite), a particle rendering system for the smoke trails. An ambient audio component would be required that plays back a general thrust sound, an another audio component that plays occasional sounds (so that it doesn't sound too boring). That's already five components for a rocket. For complex things, this obviously can increase even more!

I suppose the ultimate trade off, for me anyways, was to not allow other people create external systems for my own engine. People couldn't create a new rendering system ... but they could create new render components. The majority of core systems I'd create, but if somebody needed a new system to handle .. let's say some weird network access storage system; they would have to modify my engine quite a bit to do that.

Can I expect a stencil buffer to be supported even on old cards?

No, not really. Not as an expectation anyways, but perhaps you may want to test for them.

How many bits can I hope for?

1 at the minimum, some may support 8, and anything inbetween.

The last time I employed the component system, I did a little more segregation to help keep things fast. Instead of a one all and be all component system, I split up the base component classes into system specific components instead, such as a PhysicsComponent, RenderComponent, AudioComponent and so forth. However, I can see how this might be a problem if you need it to be ultra flexible, so much so, that you may encourage entire systems to be developed as well.

This was mainly for performance reasons more than anything else I found, since some of my game objects then were containing thirty to forty components in them and trying to iterate over the entire list of them started to get very slow particularly when I just needed to find components that I needed to render, play audio and so forth.

The engine design is looking good so far however.

We're (probably) going to use the BQ engine to make a small game, which means improvements to the engine for all!

Cool, look forward to the changes you'll be proposing. Hopefully it won't mean I have to change the editor code too much. Looking forward to the improvements. 

This site is bad. I can't even view it without an appropriate plug in.

What do you plan to do for independent game developers? Do you supply them funds in order to build their games, or do you plan to just get finished games and then do deferred payments?

I think its about development times. Indies don't have three to four years to develop a title, and thus within their budgets they sometimes have to employ retro methods. After all, with graphics these days, as long as it is true to what the developer wants to represent is there any more reason to have high resolution, highly detailed art?

If an 8 x 8 pixel sprite can represent a shotgun for both the designer and the player, is there much more the player can ask for?

I also think that most indies developer freeware, donation ware or absurdly cheap games and thus won't have massive amounts of money to spend on art as well as money to continue development for a long time.

Lastly, I think for myself, I just like that sort of art.

Thank you for sharing, especially the numbers as most people don't really release details like that. Thank you!

I'd like it if the tile and script browsers stayed above the main window, like the Tools.

Alright, this will be implemented in the next version. By default those windows will be set to stay on top, but can be turned off when it is implemented.

Also, when the main window's maximized and you open the script or tile browsers, they appear to the right of the window, off the screen.  (At least, I think that's what happened.)

Ahh yes. I shall fix this for the next version.

What else... tool-tips would be nice!  And maybe text at the bottom of the window or something that immediately shows what button you're over.

I'll try to add these for the next version.

how do you delete objects and how do you rotate tiles?

You can't at the moment. Again, I will implement this in the next version.

Continuous painting of tiles

Ahh yes, a good usability suggestion. I shall add this in the next version.

All of these issues have been logged on Mantis by. I'll try to keep it updated between here and there, but it'll be easier if everyone with bug reports or usability suggestions could sign up and report their issues there for me

The link to Mantis is, http://www.digitalconfectioners.com/mantis

Hey, instead of BQed wrapping the BQ folder, could it work from within the BQ folder?  I'd like to pack it in with the next big update...

Well, BqEd actually does this by default right now. It does actually have a path that you can set eventually ... I just need to enable it!

Changes:

• MDI style interface was used here so that the level panel could be moved around
• Paint tile types now
• Fixed critical error when saving maps
• Fixed tileset palette resizing errors, when it first appears it shouldn't be tiny
• Fixed rounding errors between the editor and the game

http://www.digitalconfectioners.com/download/bqed/BqEd02032009.zip

I have something like 10TB worth of bandwidth per month on my web host at BlueHost which is somewhere in the US of A, I assume. I'd be willing to host repository of games if you need to. I also have a ridiculous amount of space, so that won't be a problem. I plan to keep this web host for the next decade or so.

Probably, after all you have access to all the nVidia extensions like their implementation of geometry shaders.

Unfortunately, I think what you'll have to do is just to spend time to try them all out and see which is best suited for your project.

The main problem I have with OpenGL is that it is an open standard. This is a problem for me because many graphics vendors may or may not implement any set of features (ARB or otherwise) for their graphic accelerators.

Typically, when I decide to do any complex OpenGL, I normally extract cap information from the drivers. However, there have been instances when cap information have been false positive. This means that the driver reports that the graphic accelerator has a feature, but when in fact the graphic accelerator eithers ignores the extension or it uses the CPU to do the majority of the calculation.

This stems from the fact that any one is allowed to interpret the standard in any way they wish.

That's the only real annoyance I have with OpenGL really, and it frustrates me as an engine developer because I simply can't really tell if a person's card is capable or not, without resorting to extensive testing and have a giant list of cards that are supported.

There are future shaders and pipelines that will probably not make it into the OpenGL API (without the use of vendor specific extensions), a good one is the geometry shader. DirectX 10 (and the soon to be 11) can enjoy using the geometry shader since all vendor must comply with Microsoft's standards in order to be DirectX 10 certified (I believe) ... however for OpenGL, I think only nVidia at the moment has bothered to develop OpenGL extensions.

Still, I use OpenGL myself simply because it has the possibility of being cross platform and because I am more familiar with it myself.

It's been great fun working together with BMcC. There needs to be more collaborative projects on TigSource really.

I think I got it right with the rotations and so forth... adding a screenshot button. This should be handy for uploading screenshots to the forums.

BMcC

Are you able to include -map option to the game executable? That way I can launch the game using the map as a command line param. This will let me launch the game from the editor, making it even easier to test the map.

Awesome, you have now.

It really depends on what kind of web browser game you want to build. Secondly, you also need to know if you will be building a fat client or a thin client. From the sounds of it, you're wanting to build a thin client.

Unless we know more about what you are attempting to build, it's difficult to provide any decent feedback.