An A+ for effort; the indelible, scarlet letter of the dullard.
Not a Member? - Login or Create an Account...MC Offline
Wednesday the 21st of March 2018 @ 07:01am
Front Page Projects Your Profile About

Filed Under: Journal - Development - Game Development

It's been an unfortunately long time since I've hacked at the new code. Some contract work and much needed rest has been in the way for a little while. Rest assured I've been doing some reading and trying to extend my knowledge. Now that I've at least made some basic things work, I want to start reorganizing the old N2L libraries into something I can use now. That means I have to start picking and choosing pieces to move and how to rebuild them.

The Good

To be fair, some of the things that were done well.

  • Good use of virtualization. It came later than it should have, but interfaces & implementations are a wonderful thing. For this kind of code the efficiency hit of virtualization has little effect compaired to raw processing of game events.
  • Oscillators. They're awsome.
  • SDL was not a mistake. SDL is a great thing. Good community, clean API, runs perfectly.
  • cAutoPtr. Nuff said.

The Bad

Since my first (modern) attempt at throwing together a game library, I've learned some things that should have been apparent to me. Unfortunately, very little is apparent to someone before they learn it :(. First thing I want to do is make a list of the things I know I did wrong.

  • Multi-lib library package caused lots of extra complexity
  • Too many dependancies within the class tree. Tall class tree's are great, but not so that they look good.
  • Not everything has to be a class. Procedures crammed into classes are not object oriented.
  • Too much black magic. I tried to focus on simplicity and keeping black magic out of things... but it crept in to avoid forcing calls to initializers and the like. It really just obscures and obfuscates complexity.
  • Error capturing was good, but not robust enough. It was impossible to intelligently capture errors within the code.
  • Too much conformity is a bad thing. No templates where there should have been templates because of a focus on compile time efficiency. Compile time is not where you'll get nailed in month 6 of development.

The ... *shrugs*

Things I'm not so sure about

  • Event managing. It had potential but I never really got to test it. I like the idea, but it could come back to haunt me if I switch to a multi-threaded event processor.
  • Resources. It's a great idea, but it just wasn't all there. Something was muddy about resource data vs. resource objects. That confusion shows in the code.


Reader Comments

©2018 Aaron Cameron