Quote:Original post by ArmchairArmada
Though, maybe, it would be better optimized to use enums instead of strings -- though it might be more difficult to later allow scripting to add functionality?

What about FourCC's?

With 64-bit processors fast eight character code comparisons could be made (I assume). However, I have decided that I should favor flexibility and easy programming over optimizations since, as I am working alone, I would rather not needlessly complicate matters. Hobby / indie games do not need every ounce of speed squeezed out of them, I guess. String might suffice.

I'm not sure if I should worry too much about obsessively abstracting the libraries used with my programs. I began writing an abstract audio interface, but didn't really know what I needed. It might be more worth it to simply use irrKlang without further abstraction.

On second thought. I think I would want to have an abstracted audio interface, since 3D sound would be played relative to the camera and I'd rather not have the entities themselves performing the transformations. Either way I think I'm getting too far ahead of myself. I shouldn't try to program something until I will actually need it. I need to keep this in mind.

Quote:Original post by ArmchairArmada
On second thought. I think I would want to have an abstracted audio interface, since 3D sound would be played relative to the camera and I'd rather not have the entities themselves performing the transformations. Either way I think I'm getting too far ahead of myself. I shouldn't try to program something until I will actually need it. I need to keep this in mind.

It's easy to get caught up in trying to develop the "perfect" solution and not actually getting much done. In general you've got the right idea, build what you need when you need it. As you build new tools make sure they are extensible and try not to paint yourself into a corner, but remember that writers often start with a "rough draft" and refine it in subsequent passes.

You shouldn't be focused on making it perfect the first try, you should be focused on making it work without breaking other code. But you should also try not to let too many brittle and bad coding practices pile up before you re-form them into something better because chances are if you leave something and say "I'll get back to it" you won't. Often I'll write a new function and let it grow as it needs to sometimes up to 500 lines (this is typically the largest I let something get before refactoring) and then after I have it working I'll break it up into more logical pieces.

Later when you have enough of a system in place to worry about control flow beyond each individual portion you'll want to do a broad-phase refactoring before going back to smaller details again.

Following this pattern for new module development:
1. Decide what pieces make up your newest module.

2. Pick a place and start.
3. Write it out and make it work.
4. Refactor your newest code. Go back to step 2 when finished unless you are done the whole module.

5. Concentrate on the interface and make sure it fits within the program. Go back to step 1.


Then of course you can always revise more after you have several modules done, this would be yet another layer on top of my example. The point is it is an iterative process. Don't get too hung up on a single pass because that isn't feasible in real development scenarios.

Quote:Original post by snk_kid

Quote:Original post by ArmchairArmada
I shouldn't try to program something until I will actually need it. I need to keep this in mind.

Keep it Simple, Stupid.
Keep it Simple, Stupid.
Keep it Simple, Stupid.

QFE.

Note, this is a general comment on the KISS principle when applied to software, it is still a useful idea to keep in mind, but it has to be tactfully done:

It is a fallacy to assume that just because you keep individual parts of a system simple that the whole system will as a result remain simple. Further, what should be simple? The implementation? The interface? The code?

If we say yes to all of those we'll end up with a simple, but inflexible and non-maintainable nightmare where concrete ideas abound and there is little to no abstraction. By focusing on keeping things simple on a code level we can create a mess of duplication and explicit references. Ideally we want to create a simple interface with a sophisticated implementation where necessary which allows for future extension.

While I agree that it is a good idea to avoid over-complicating things, there is a significant risk of over-simplifying things that really do require more complicated concepts to actually achieve a simplified interface.

In this way I believe Einstein had a much better statement (referenced in the KISS article on wikipedia) "everything should be made as simple as possible, but no simpler." In this way suggesting that one KISS when seeking "Code Structure Advice From the Pros" is itself a perfect example of the pitfalls of keeping it simple. After all, your advice was simple on a surface level, but flawed as well. We want to make sure that things are abstracted "as much as possible" but no further... But this does involve a certain complexity in itself in the dependency of nested abstractions to keep each level clean and simple.

So by all means, KISS, but be mindful of where pennies now can become dollars later.