Component Based Programmin'

Like every good Game Dev student interested in low level graphics I started writing a small game engine for my Data Structures and Algorithms for Games and Simulations class. I've learned a lot but what I wanted to write about was the magic of writing a component based system.

There's a reason Unity uses a component system for it's engine. It's elegant and modular; intuitive and powerful. It's a really great programming paradigm whether you're writing something simple or complex. Needless to say that actually writing a system like Unity is far from easy, but it's also really rewarding.

The way my engine is structured is that there are GameObjects and Components. GameObjects store Components, and Components store a reference to their parent GameObject. This creates the first architectural problem I ran into; making sure that there's no recursive header includes can be a bit tricky when the GameObject needs to include every derivation of Component.

From there I can have all the logic of the game modularized into core components and drastically cut down on the complexity of the architecture. Each GameObject just runs the Start, Update and Draw functions of its components. As an end user all I'm really doing is changing the core values of these core components and I can make some neat stuff appear on screen.

The big upside to all of this is that it makes it really easy to add scripting to a system like this. After some more core functionality gets sorted out an the game loop is modernized a bit I'm hoping to add Lua or Python scripting support.

Meetup 3: RocPY

Roc Py happened again. What even happened. I can't really remember all that well because I pretty much fell asleep. Not really, that would have been rude but the talks were far from engaging.

First up was the talk on the python module itertools. A neat little module that seems to double up most of the basic functionality of python with an iterable return value. I guess that's useful and flexible but I feel like that just adds an added layer of complexity on top of the possible Python Programming Paradigms. It's just another thing that you have to decide to use when writing something in Python. Are we using classes? are we doing a more functional style? are we using tabs or spaces?  are we using default or itertools? There are so many questions I ask myself whenever I write something in Python and I end up just getting confused.

Next were the lightning talks. Franky I can't really remember what they were about. I know that Ross Dylan gave a nice talk on distributed systems but as a game dev student it largely went over my head. Deployment isn't really a thing I ever have to worry about, or at least not yet.

The main talk was completely beyond me. I could not pay attention to it in the slightest. Something about using python to script advanced camera equipment? I feel like what took over an hour could have been summed up in 20 minutes. I get that not everyone is a great presenter but it was a tad ridiculous how long it took to reinforce the point that Python is a useful scripting language. There were very few useful code examples and the slide deck was just kind of a mess. I'd much rather have preferred a shorter talk with more hands on demo which I didn't even have time to look at.

Maybe it would have been much more enthralling if I enjoyed using Python but as it stands I was thoroughly unimpressed.