Functional programming is really taking off – as it should! It provides some great short-hand ways of implementing complex or minimally annoying long-blocks of code very quickly. Though it does have some slight drawbacks in terms of maintainability and code clarity (try to debug closures without any sort of special tool / support in the debugger, you’ll go crazy). A classic example is the in-line support of functions (i.e. anonymous functions / lambda functions). If you need to write a custom comparison function for a sorting algorithm, several languages give you a simple framework to work against. The stdlib library of C gives you access to qsort, where you must implement your function and pass said function-pointer to the qsort function. It’s far from complicated, but the catch is that it isn’t flexible, as you can’t write this code in-line with your qsort function call.
Java takes, as expected, an OOP approach: your object must derive from the Comparable class and implement a basic set of required functions. Once this is done, you can sort your data using generic sorting functions in Java’s array implementations. Yet, this limits you since a class can only have a single comparison implementation, meaning you would have to re-derive from your base class, re-implement the Comparable class functions, and do quite a bit of overhead boilerplate code just to support different comparisons.
This is where lambda-functions step in with the best solution: it supports simple syntax and in-line embedding of code. Python, as an example, allows you define the comparison function through their standard sort function, and even better: the syntax is clear and condense, so no boilerplate overhead is required.
What’s interesting is this notion of lambda has become so helpful in many higher-level languages like Java and Python, there are several groups and companies implementing equivalents (and more!) in lower-level languages. Objective-C now has block-support, which allows for anonymous functions, threading of such functions, and even closure support! Though the latest C (C11) standard doesn’t support it, C++11 does in a somewhat unique way: slightly odd syntax (done so no new major syntax changes are required), implicit return types (not unusual, but I like C and C++ for their pseudo strong/weak-typing), and its bizarre variable closure operators / property symbols (the syntax looks like “[=]” and more). I do applaud the standards group to sticking with adding big ideas, but introducing little syntactical changes.
All in all, I’m glad that lower-level languages (C, C++, etc.) are taking advantage of powerful programming constructs like lambdas, and integrating them with great performance so we can use them on embedded systems (such as the iPhone). Though this new kind of programming is far from a revolution, it is a welcomed natural evolution of programming languages, and I hope to see even healthier improvements like this in the future!
Finally, I can write about Nova Legacy, which has been a few months in the works and nearing completion for public comercial release!
Nova Legacy is a top-down 2D real-time resource and strategy game. You start as the lone survivor of a post-apocalyptic world-war, and must survive long enough in space to find a new home-world for you and your survivors. You control a single ship that has the ability to collect resources in space, build other ships, and must try to defend yourself against enemy humans or aliens, as well as grow your army through growing your space-base. This project originated from a challenge proposed on Reddit’s r/GameDev subreddit, where the goal was to develop a fully working game in 30 days, much like LudumDare‘s 48-hour game dev. challenge. I wrote about this challenge on my Google+ page, and immediately received some interest from a few fellow Penn State students. After a bit more networking, we had a full team of friends, friends-of-friends, and professionals from all over the United States: three programmers, two artists, a musician, and a writer.
We started the project by developing a general design document. I’m sort of… obsessive when it comes to these documents, so I wrote as much as possible about the general interface, game rules, mechanics, and every possible detail under-the-hood and above. Check out the document here!
After this basic game design document, I wrote out all features and tasks that had to be complete, splitting them into a few categories: Art, User Interfaces, Sound, Marketing, and programming. As of right now, after constant work on refining and developing tasks, we have about 130 tasks. What’s interesting, though nothing new in the software dev. world, is that these tasks constantly evolved over time. Other programmers took complex tasks and split them into more detailed sub-tasks. Artists and our musician did the same, breaking down a request for drawing a ship into drawing multiple states of the ship, ship components, reusable sprites, etc. Check out this task-list document here!
Since I’ve never lead a large group of people with different jobs and different backgrounds (until then, I’ve only worked with fellow programmers), we decided it would be best to do some “basic” management routines: we all introduced each other by email, and met formally through Google+ hang-out system. It was absolutely brilliant! Not one of my people was physically near me (some were in Pennsylvania, some in Virginia and one in South-Carolina, while I’m in Washington state), yet we worked out all of our issues using phone-calls, Skype, and the hang-out system. Frankly yes, it would have been far more effective being in-person in the same area, but using (free, even better!) telecommunication tools really worked well enough to get all of our work and meetings done in our respective schedules. As a manager thought, regardless of our tools and meetings, it was still incredibly hard to pace our work out. Every member either had a full-time job, family, or was looking for a job, (or a combination), so even though we had a great task system and tools, we naturally fell behind in some weeks and jumped forward others. I suppose this is only normal, though to a hopefully less extent, in a regular software dev. job.
Our general software design approach was to develop our game in Unity3D, a powerful 3D engine that allowed entity-model C# scripting. The architecture was, as Unity3D really forces you to develop this was, was a basic entity-model system: all on-screen entities, GUI, graphics, music, etc. were stand-along entity scripts. A script could be launched by another, and could also retain relationships across entities. Though not at all a clean solution, it is the real-world practical solution. Our code became messy at times, but we at least could develop independently of one another and only integrate entities as a whole when we wanted to. We developed some stub code, but quickly realized it was still better to just avoid any sort of code until an entity was strong enough to stang on its own. We did heavily use C#’s inheritance model, since that really helped with under-the-hood entity management, but otherwise any graphics-related work was always pushed off to Unity3D.
A tool we only started using later in our development cycle was Unity3D’s in-game level editor, though it proved to be incredibly time-saving. Before, we had only used text files in special INI-like configuration syntax, but that quickly worked against us as we had to start describing complex properties of entities (such as sprite animation groups, explosion effects, etc.) Related to this issue was the issue of unintentionally re-implementing many built-in features of Unity3D. This error is common when new to a platform, but looking back it was absolutely another issue that worked far too much against us. We ended up re-implementing a sprite engine, thinking it would speed up our performance, but we should of simply treated the world as a true 3D space and used an orthogonal camera to render in a 2D-like view.
As I mentioned at the top, one of our big goals was to do this project in 30-days… and we did it! We developed a fully playable fully working game in exactly four weeks! The problem though is the game we had made didn’t have all the “fun” features we wanted, such as damaged ship animations, or smarter AI (at the time, our AI targeted the closest enemy ship and simply shot at it). Over time from July to September, we had developed all of the features we wanted after our initial 3o-day push: our AI now used some neat motion-control algorithms to fly around targets. We even had cool ship contrails that would swing around based on the ship’s movement. We had a fully-working GUI and level section system, with a story that would pop-up before and after every game session! We got as far as deploying on Android and iOS!
So where’s this game? Great question! Sadly, we failed to talk about business seriously since day one: though we were all willing to invest into the group for software tools or more, none of us were willing to give-up the capital needed to pay for a full copy of Unity3D, which would of ended up as not-so-nice $3.5k. Lesson learned: know your platform and know its licenses before you start writing code. We are now, after a short break, working on porting the game from Unity3D C# to Google’s PlayN Java platform! We’ve got marketing materials, new music, new art, and more all in our release cannon, ready to blow up the indie game universe, but we can’t light the thing until our final efforts of porting are complete.
In the mean time, we are going to do two big things: We’re going to open-source the Unity3D version of the game next year, and we’re now releasing all of our private internal-testing videos to you, immediately! Check them out!
Imran Nazar has written a great GameBoyemulation tutorial for the Javascript programming language, using new features of the HTML5 standard (mainly canvas). I’ve gone through six out of the 10 articles, and have posted my code onto GitHub for others to use. I chose to develop the code in pure C (the 1999 standard) for the sake of multi-platform support, and to allow component-integration with other apps I have (the OpenGL bitmap rendering system is being ported to a desktop version of CoreBasic).
The GameBoy device is essentially a custom Intel 8080 / Z80 processor, with a 160 x 144 4-color LCD screen, and 8 button input. From the outside perspective, the device seems easy to emulator, but internally, it is much more complex. The instruction set is not particularly complex, though it does allow for single and double byte instructions (which can complicate emulation), and RAM / ROM is mixed in the same continuous memory layout. What really has been challenging to implement has been the graphics architecture: the LCD screen is not directly mapped in memory in the sense that it is the content which the processor should manipulate. Instead, it is a special formatted buffer that expects definitions of sprites (small bitmaps) and sprite-maps (how these sprites are to be laid out on-screen). To make things even worse, there are several layers and a pseudo-mixed buffer for the sprite sources and maps. Regardless, it’s been a blast to figure out the basic mechanics and implement each of Imran’s articles in C.
One of Imran’s article’s best feature is the addition of some visualization graphics. The outlines and details of how memory is mapped, how sprites are laid out in memory, and others are really powerful in their ability to get the main points across. Thinking back, I still feel as though I should of have put more graphics and helpful diagrams in my computer-graphics book. I’ll absolutely work on that, especially in the new “introduction to matrices” chapter for the second edition.
An example graphic from Imran’s site: the general memory-layout of the Gameboy device.
As of right now, I have the basic emulator up and running in OSX, with I/O and graphics support. I’ll continue developing over the holidays on this system and hopefully get more and more features (such as the window sprite layer and ROM bank-switching) implemented. Others can easily integrate it with Visual Studio (Windows) and GCC (Linux). Check out the source code from here, on GitHub!
For those that would like to develop their own Gameboy Emulator (a great programming exercise), check out the following links that I’ve used to compliment Imran’s work, and to help me better understand the system as a whole:
