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.
Monday, November 24, 2014
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.
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.
Thursday, October 30, 2014
Vid Review 2: Simple Made Easy
Who
Rich HickeyWhat
Simple Made Easy
Where
It's on Infoq over here: http://www.infoq.com/presentations/Simple-Made-Easy
When
Date Published: Oct 20, 2011
The Gist
It's a talk detailing a big problem with production level code which is the extreme level of complexity that software today is written with. Hickey details the sorts of programming paradigms that are inherently complex and goes into detail about the alternative programming styles that can help lower complexity of your software.
The Good
- I like how he explained how things fit in the mind and how we can only focus on so many things at a time
- In conjunction to the above I think the point he made about needing to bring in the understanding of any dependencies of your code into your mind as well and this can lead to a large amount of things required to understand an originally small piece of code.
- Did a good job at giving alternatives to the common complex programming paradigms he described
- His opening explanations of easy and hard, simple and complex falls pretty flat
- The video didn't show his graphs and slides :(
- I think he overstates the importance of the need for simplicity just because the end user wants it to be easy, not necessarily simple and that need of ease inherently leads to a higher level of complexity; you can't expect a client to relearn things just because you made them simple.
- Does he actually expect people to write code with minimal complexity?
- Why is syntax inferior to data and is there anything we can do about that anyway?
- Variables are complex, does that mean we shouldn't use variables?
A nice video if you're interested in complexity in code and the state of the software industry. It's a bit trimmed down from the original talk because the slides aren't part of the video but it is interesting. If you're a higher level programmer writing corporate level code this would be interesting, if not it may go over your head. 6/10 levels of complexity.
Tuesday, October 28, 2014
XO Smoke Test
Well smoke testing my XO went mostly fine.
Everything worked except for running external bundles. When I put the Sudoku activity on either one of my flash drives, copying it to the XO didn't end up with a running activity. What happened was that the XO would recognize the files, let me launch the bundle from my flash drive, but it would fail to run. I tried copying it to the XO's memory and got the same result. This happened with two flash drives.
Then when I tried to install the StarChart activity from sugar labs I got an even worse result. The download completed surprisingly quickly but when I opened the journal there was no Icon, unlike the bundle copied from the flash drive. Also telling this downloaded bundle to open yielded... nothing. No error, nothing. The device just acted like nothing happened.
Everything else worked as planned. Audio plays, books can download, connections work everything besides side-loading bundles works fine.
Another thing I noticed was that there was a strange issue where if the laptop was nudged a little bit the wrong way, or if it was having some sort of hissy fit, the mouse would move around like crazy and just kind of click all over the place. Not sure what caused that, it would just seem to happen but I did notice it particularly after accidentally nudging the computer a bit.
Only idea for what could have caused the issues was that I left the XO on battery for a week or so with no charging, and then moved from the Gnome desktop to Sugar with no reboots. A full power cycle may fix some things.
Everything worked except for running external bundles. When I put the Sudoku activity on either one of my flash drives, copying it to the XO didn't end up with a running activity. What happened was that the XO would recognize the files, let me launch the bundle from my flash drive, but it would fail to run. I tried copying it to the XO's memory and got the same result. This happened with two flash drives.
Then when I tried to install the StarChart activity from sugar labs I got an even worse result. The download completed surprisingly quickly but when I opened the journal there was no Icon, unlike the bundle copied from the flash drive. Also telling this downloaded bundle to open yielded... nothing. No error, nothing. The device just acted like nothing happened.
Everything else worked as planned. Audio plays, books can download, connections work everything besides side-loading bundles works fine.
Another thing I noticed was that there was a strange issue where if the laptop was nudged a little bit the wrong way, or if it was having some sort of hissy fit, the mouse would move around like crazy and just kind of click all over the place. Not sure what caused that, it would just seem to happen but I did notice it particularly after accidentally nudging the computer a bit.
Only idea for what could have caused the issues was that I left the XO on battery for a week or so with no charging, and then moved from the Gnome desktop to Sugar with no reboots. A full power cycle may fix some things.
Thursday, October 23, 2014
Meetup 2: ROC Py
I went to ROC Py, the Rochester Area Python users group again this Tuesday. The talk this month was mainly focused around Bridging Python with other languages. The speaker outlined and demoed the use of python with languages such as C, Fortran, .Net and even Java. Overall I liked the talk, it was well delivered, gave a good walkthrough of the procedures of extending python and for the most part I was interested throughout the whole thing. Where I draw issue is with the concept of bridging libraries.
In my opinion, you should never bridge languages for anything other than a library. If you need to do some very fast computational procedures and you're considering writing CPython, your best bet is to just write it in C or C++. I don't care how familiar you are with Python and how much you love it, there's a rule with programming. You choose the right language for the right job. Python is good for simple scripts and other lightweight applications. Many people choose Python over C for simple programs because of its ease and readability. You sacrifice both of those when you start bridging Python with C. If you need to do things very fast, just use C or C++, please.
The exception to the rule here is libraries. Why? because sometimes you need to do something that's just not exposed to your language without going deeper. For example I had to write a native plugin to Unity and I used C++. I've also written android plugins and for that I used Java. Why did I do this? Because Unity C# simply can't access DirectX and OpenGL the way I needed to. This was a plugin to be distributed next to Unity, not as a core part of a project. If you wanted to write an OpenGL layer into Python (for whatever reason) fine, use CPython, but even in that case I see C being a better option overall.
Something like Jython or IronPython (Python in Java and C# .Net respectively ) I understand a little bit better. Jython compiles down to java classes which should make it about as fast as Java on the bytecode level, but I doubt that the compiler is really doing a good job of optimizing that Python so the speed may not be actually as fast as Java in practice. IronPython is pretty much the same but .Net compiles down to machine code. Again the compiler optimizations are going to matter here so you may not quite get the speeds you'd expect from C# or VB. At least with Jython you keep the portability of Java but IronPython I don't really get. I don't really trust the Mono compiler all that much and Mono runs in a VM outside of Windows so you'll be taking a performance hit even further.
At the end of the day it doesn't seem like speed is going to be a big enough gain to offset the complexity of bridging Python to another language. I think it's a better idea overall to use Python to what it does well.
In my opinion, you should never bridge languages for anything other than a library. If you need to do some very fast computational procedures and you're considering writing CPython, your best bet is to just write it in C or C++. I don't care how familiar you are with Python and how much you love it, there's a rule with programming. You choose the right language for the right job. Python is good for simple scripts and other lightweight applications. Many people choose Python over C for simple programs because of its ease and readability. You sacrifice both of those when you start bridging Python with C. If you need to do things very fast, just use C or C++, please.
The exception to the rule here is libraries. Why? because sometimes you need to do something that's just not exposed to your language without going deeper. For example I had to write a native plugin to Unity and I used C++. I've also written android plugins and for that I used Java. Why did I do this? Because Unity C# simply can't access DirectX and OpenGL the way I needed to. This was a plugin to be distributed next to Unity, not as a core part of a project. If you wanted to write an OpenGL layer into Python (for whatever reason) fine, use CPython, but even in that case I see C being a better option overall.
Something like Jython or IronPython (Python in Java and C# .Net respectively ) I understand a little bit better. Jython compiles down to java classes which should make it about as fast as Java on the bytecode level, but I doubt that the compiler is really doing a good job of optimizing that Python so the speed may not be actually as fast as Java in practice. IronPython is pretty much the same but .Net compiles down to machine code. Again the compiler optimizations are going to matter here so you may not quite get the speeds you'd expect from C# or VB. At least with Jython you keep the portability of Java but IronPython I don't really get. I don't really trust the Mono compiler all that much and Mono runs in a VM outside of Windows so you'll be taking a performance hit even further.
At the end of the day it doesn't seem like speed is going to be a big enough gain to offset the complexity of bridging Python to another language. I think it's a better idea overall to use Python to what it does well.
RIP: A Remix Manifest Vid/Lit Review
Who
This was a film Written and Directed by: Brett Gaylor
What
RIP: A Remix Manifesto
Where
It's on Vimeo over here: http://vimeo.com/8040182
When
Date Published: 2009
The Gist
It's an overview of the state of "Remix Culture," the challenges it faces and the social implications by the precedent it sets. It outlines the battle between consumers and corporations over who controls media and why you should care about who wins.
The Good
While it may be a bit inaccessible to those unfamiliar with copyright laws or to those who don't care, if you want a good overview of the state of copyright law and you want to learn a bit more on the subject this is a good watch.
This was a film Written and Directed by: Brett Gaylor
What
RIP: A Remix Manifesto
Where
It's on Vimeo over here: http://vimeo.com/8040182
When
Date Published: 2009
The Gist
It's an overview of the state of "Remix Culture," the challenges it faces and the social implications by the precedent it sets. It outlines the battle between consumers and corporations over who controls media and why you should care about who wins.
The Good
- Did a good job outlining what copyright is and what is currently wrong with it
- Gave good examples of the current effects of the copyright laws
- Made you understand and sympathize with the opinion of the author
- Spent a bit too much time with Girl Talk
- A bit overly doomsday-ish to subvert your emotions
- It preaches to the choir a bit
- Where is this out of date
- Has Girl Talk received any legal action
- What are the current actions being taken to fix copyright law other than breaking it
While it may be a bit inaccessible to those unfamiliar with copyright laws or to those who don't care, if you want a good overview of the state of copyright law and you want to learn a bit more on the subject this is a good watch.
Thursday, October 16, 2014
Team Proposal - Number Munchers
Members:
Honeybunch - amt3824@g.rit.edu
Faokryn - faokryn@csh.rit.edu
Susan - slunn@csh.rit.edu
Project - Number Munchers:
Our team decided to work on a Number Munchers clone. Number Munchers is a game where you need to eat all numbers that meet certain criteria (i.e. multiples of two) while avoiding nasty monsters.
Roles:
We're kind of forgoing roles at this point. We don't need a whole lot of graphics or sound so everyone's job is just going to be writing a bunch of code.
Source Code:
Will be hosted here
Upstream Mentors:
Easy Parts:
Setting up PyGame
Getting the basic game working
Making sure that the content matches up with the NY state math requirements
Hard Parts:
Optimization
Troggle AI
Balancing random content
How to overcome obstacles:
Getting the base game done is the main goal and overall should not be that difficult. It's a game praised for its simplicity so re implementing it should not be impossible. Obviously we won't be doing the exact content from the original but will be mixing it up with Fractions, Geometry and other requirements from the common core for 4th graders. The hard parts are just going to take work. Troggle AI is going to take a decent amount of work without overloading the hardware as later levels will be having multiple AI routines. It's just going to take a lot of playtesting to make sure the game is fun yet challenging.
Honeybunch - amt3824@g.rit.edu
Faokryn - faokryn@csh.rit.edu
Susan - slunn@csh.rit.edu
Project - Number Munchers:
Our team decided to work on a Number Munchers clone. Number Munchers is a game where you need to eat all numbers that meet certain criteria (i.e. multiples of two) while avoiding nasty monsters.
Roles:
We're kind of forgoing roles at this point. We don't need a whole lot of graphics or sound so everyone's job is just going to be writing a bunch of code.
Source Code:
Will be hosted here
Upstream Mentors:
Easy Parts:
Setting up PyGame
Getting the basic game working
Making sure that the content matches up with the NY state math requirements
Hard Parts:
Optimization
Troggle AI
Balancing random content
How to overcome obstacles:
Getting the base game done is the main goal and overall should not be that difficult. It's a game praised for its simplicity so re implementing it should not be impossible. Obviously we won't be doing the exact content from the original but will be mixing it up with Fractions, Geometry and other requirements from the common core for 4th graders. The hard parts are just going to take work. Troggle AI is going to take a decent amount of work without overloading the hardware as later levels will be having multiple AI routines. It's just going to take a lot of playtesting to make sure the game is fun yet challenging.
Subscribe to:
Posts (Atom)