french_hustler

At Minigore 2 I did really cheap rain effect using couple hundred simulated particles which was each rendered as mesh that contained around dozen actual raindrops. This keep fillrate quite minimal. That reindrop bunddle Mesh was duplicated to same VBO 20 times so it was possible to render 20 particles with one rendercall. Each particle was frustum culled and tested against y = 0 plane. If collision to ground plane happened watersplash effect was spawned which used quite similar pseudo instancing trick. Particle was re-emitted after collision and emitter cube followed camera. Whole effect used around 10 render call without any dynamic geometry. Rain was added just before release so we didn't have that much time to fine tune the effect. It's actually even use snow flake texture and was vertex colored to hide this fact.

Edit: the effect start from 1m6s. Tried to link straight for it but did't quite nailed it.

That looks really awesome!

Sounds like you are interested in the actual game mechanics.  I don't think it directly deals with engine programming.  I feel like engine programming deals much more with the field of software architecture.  Game mechanics like the ones you've mentioned deal more with algorithms.

There are countless aspects to game programming that deal with computer science.

Just thinking of the different specializations offered at my school, here are the ones I can think of:

- Software architecture

- Computer graphics

- Computer vision

- User interface programming

- Algorithms

- Sound engineering

- AI / Machine learning

Also, something that is very simple but that helped me a lot in debugging the actual shader code... Have a way to recompile your shaders during run-time.  This has really saved me a lot of time, especially since reloading resources at the beginning of the application takes quite a long time.  Now I can make tweaks within my shaders without having to restart the whole app.

I know it's pretty trivial, but it really increased my productivity.

I'm assuming every opaque object to be instanced. So yes

I don't have inputs on your questions but I'd like to know why you assume all opaque objects to be instances?

I would assume that there is some performance hits if there are multiple unique objects each being drawn as a single instance instead of drawing them the "regular" way.

Could you please expand on this?

Thanks.

I think that your solution is good if it works for your game's requirements.  However I do not think it is scalable if you will add many more different "items".  Eventually, with such hierarchies, you'll end up pushing common functionalities up to parent objects which will result in a "god" parent class.  If this works for you though, I don't see the need to change it.

The way you handle and store your entities will also be based on your game's requirements.  If holding the memory for enetities in big datastructure is good enough, then there is no problem.  This will not scale well if your have massive amount of entities.  You have to think about what you do with these entities and how many you have in the game and whether the datastructure you use will be efficient enough for your needs.  If it does become a bottleneck, then you might consider using different datastructures or reorganizing things in many smaller "pools".