Somewhat belatedly we're pleased to announce the release of Eets: Hunger it's Emotional for OSX! It was released on Steam last December, and you can check it out here
Whew. That was quite an effort for a small team like ours. It was a labour of love. While it's not the only thing we've worked on this past year, we've certainly taken our time when getting it done.
While it is a port (for us) and the game content had already been completed since the release of the PC version it was still not a jobn for the faint of heart.
Klei Entertainment when originally developing the game had not envisaged that the title would be destined for several other platforms. As such it was written largely in native windows APIs such as DirectX, Direct sound, windows threading and so on. There was little abtraction in the graphics, sound and IO layers.
So we added all of that. We abstracted the graphics layer and put into place an OpenGL driver for the OSX port, we went through a similar process for sound support making use of OpenAL. For threading we just used pthreads for the most part. Perhaps we should have abstracted but we didn't in that case. The shaders were written in DirectX style assembly language and to move them over to OpenGL they were ported into HLSL.
Everytime we finish a title we're reminded of what it takes to actually finish a game.
You feel like your done, when it's feature complete; the graphics and sound are working, the control system is squared away and yet - you're really just half way.
We admit we felt like we'd finished when we reached this feature complete stage; we knew better intellectually but emotionally we fell for it all over again.
At feature complete, you start the gruelling bug fixing stage. It's amazing how many bugs a few good testers can find. We had hundreds, many pretty small but it adds mountains of time to completion. After bug fixing, you then have to package and prep for distribution, this is also suprisingly time consuming. Sorting out distribution platforms quirks, further testing, prepping marking art, liasing with the publishers, partners, testers, reviewers and so on - and we had a lot of help.
Nothing really beats the feeling of finish a title though. At least from our point of view. There is something deeply satisfying about it. I guess that's why we're in this business.
We hope you enjoy Eets for OSX! We certainly enjoyed getting it out there.
Showing posts with label Eets. Show all posts
Showing posts with label Eets. Show all posts
Thursday, January 27, 2011
Thursday, October 22, 2009
OSX: Carbon Event Loop not firing - Application unresponsive
In the development of Eets I've been using Apple's Carbon API. As some of my peers have correctly pointed out Carbon is slowly being deprecated, at least publically (outside of Apple). I'm pretty sure I've read somewhere that the Carbon API is still being heavy used to support the features underneath (for example in the Cocoa API). So this will likely be the last time I get to use it on any serious. I've already noticed that Googling for Carbon problems doesn't return a boatload of results. So I figure it's a pretty naive way of telling that Carbon it's really where the action is these days.
I'm a little saddened by this. I think it's a well designed and useful API and I've found it quite enjoyable to use but it's clear that slowly C and C++ fall out of favour (yes, yes not without good reasons - I guess I'm just getting old and nostalgic).
In case of the possibility there are some others out there still plugging away with Carbon or at least having a bit of a play, this post is for you!
I had a particularly annoying problem the other night, and it stumped me for longer tham I'd like to admit. It was only some old crusty websites and a mailing list archive that gave me any clues as to what the problem might be. So for the sake of "paying it forward" I just thought I'd mention this problem I had and hope it might help somebody just like me. It was a very unintuitive problem. Most likely because I don't completely understand the way Carbon works with it's disk based resources.
Eets, the title I'm working on, is basically a C++ and Carbon application. I am using CMake to generate the Xcode files. When the products are build, the .app directory and files are cobbled together mostly by hand (or by a script I wrote). I'd used interface builder to setup the basic window and toolbar settings. Somewhere along the line I'd obviously changed something outside of interface builder in the interface nib files.
In my C++ code I've setup the basic Event loops, Events and Event Handlers. My problem began after adding some features and a compile. The main window would open but the whole application would just freeze. The menu wouldn't appear and the application window wouldn't respond to mouse clicks or drags. The window would just sit there and lose focus to any other window in it's way.
I noticed this specifically happened once the code had started up and entered the RunApplicationEventLoop.
I kept thinking I'd setup the Event loop incorrectly or there was a bug in my code. I spent ages trying to work out what I could have done wrong. When I paused the application in the debugger the callstack looked like the one below.
I eventually worked out what the problem was. It turns out that
RunApplicationEventLoop was freezing, and it was basically not handling events properly. This occurs when the CFBundleExecutable value in Info.plist file of the application bundle doesn't match the application name (set by "PRODUCT_NAME" in the build preferences of Xcode). Deep down within Carbon this apparently stops events from working.
Annoyingly Eets, at the time, wasn't even being built as a bundle so I had to change that. It was time consuming and fiddly to do so - as CMake doesn't really have great support for Xcode application bundles, frameworks etc. It's getting there ... slowly.
After I changed CMake to create an application bundle and setup the Info.plist and .app directory structure, Eets is again working. I didn't change any of the C++ code to fix it. I just setup the .app as apparently required. Well I did learn something, even thought it wasted some time.
I hope this is of use to some Carbon API users out there.
I'm a little saddened by this. I think it's a well designed and useful API and I've found it quite enjoyable to use but it's clear that slowly C and C++ fall out of favour (yes, yes not without good reasons - I guess I'm just getting old and nostalgic).
In case of the possibility there are some others out there still plugging away with Carbon or at least having a bit of a play, this post is for you!
I had a particularly annoying problem the other night, and it stumped me for longer tham I'd like to admit. It was only some old crusty websites and a mailing list archive that gave me any clues as to what the problem might be. So for the sake of "paying it forward" I just thought I'd mention this problem I had and hope it might help somebody just like me. It was a very unintuitive problem. Most likely because I don't completely understand the way Carbon works with it's disk based resources.
Eets, the title I'm working on, is basically a C++ and Carbon application. I am using CMake to generate the Xcode files. When the products are build, the .app directory and files are cobbled together mostly by hand (or by a script I wrote). I'd used interface builder to setup the basic window and toolbar settings. Somewhere along the line I'd obviously changed something outside of interface builder in the interface nib files.
In my C++ code I've setup the basic Event loops, Events and Event Handlers. My problem began after adding some features and a compile. The main window would open but the whole application would just freeze. The menu wouldn't appear and the application window wouldn't respond to mouse clicks or drags. The window would just sit there and lose focus to any other window in it's way.
I noticed this specifically happened once the code had started up and entered the RunApplicationEventLoop.
I kept thinking I'd setup the Event loop incorrectly or there was a bug in my code. I spent ages trying to work out what I could have done wrong. When I paused the application in the debugger the callstack looked like the one below.
#0 0x900074c8 in mach_msg_trap ()
#1 0x90007018 in mach_msg ()
#2 0x90191708 in __CFRunLoopRun ()
#3 0x90195e94 in CFRunLoopRunSpecific ()
#4 0x927d5f88 in GetWindowList ()
#5 0x927dc6f0 in GetMainEventQueue ()
#6 0x927fe1c8 in GetApplicationTextEncoding ()
#7 0x927fb698 in RunApplicationEventLoop ()
#8 0x0000a264 in main (argc=2141449080, argv=0x38810040)
I eventually worked out what the problem was. It turns out that
RunApplicationEventLoop was freezing, and it was basically not handling events properly. This occurs when the CFBundleExecutable value in Info.plist file of the application bundle doesn't match the application name (set by "PRODUCT_NAME" in the build preferences of Xcode). Deep down within Carbon this apparently stops events from working.
Annoyingly Eets, at the time, wasn't even being built as a bundle so I had to change that. It was time consuming and fiddly to do so - as CMake doesn't really have great support for Xcode application bundles, frameworks etc. It's getting there ... slowly.
After I changed CMake to create an application bundle and setup the Info.plist and .app directory structure, Eets is again working. I didn't change any of the C++ code to fix it. I just setup the .app as apparently required. Well I did learn something, even thought it wasted some time.
I hope this is of use to some Carbon API users out there.
Tuesday, October 13, 2009
Eets: Hunger. It's Emotional coming to Mac OSX
We hinted at the coming of Eets in an earlier development log post. Now we can tell you that Eets. Hunger. It's Emotional is on it's way to the Macintosh. We love this quirkly little platform puzzler and we hope that Macintosh owners will too.
Eets was originally developed by Klei Entertainment for the PC. Later in 2007, Klei developed Eets. Chowdown for the Xbox 360 LIVE Arcade which was well received. Klei have now moved on to some new and exciting titles but it was their wish to see Eets come to the Macintosh. That's where we stepped in. We're now very excited to be part of bringing Eets to a new (and our adored) plaform.
Eets has been described as a homage to some classic games of the past the likes of Lemmings and The Incredible Machine. With it's bright colours and eccentric cast of creatures you quickly find yourself endeared by this title. Players must navigate Eets to the end goal, a "puzzle piece", of each level by using a mix of beasties and contraptions with their own unique abilities and properties. Prankster Whales, Marshomechs, Chocolate Cannons and Radioactive Gingseng all play a part in solving the puzzles preventing Eets from getting where he's going. Food is greatly important to Eets and it directly affects his mood, thereby changing the way Eets will navigate his way through the level. We all agree, Eets is a very hungry animal - although it's not clear what kind of animal he is. At first sight it's not unreasonable to think of him as a dog, but I've seen him described as a tadpole with legs and teeth.
Adding an extra dimension to the title is the inbuilt level builder allowing for user generated content. It adds hours of entertainment to Eets, when you've had your fill of playing through the levels shipped with the game.
Bringing it to the Macintosh has been quite a challenge. It was engineered originally with little expectation of it ever coming to the Macintosh platform. Written directly on top of the Windows API and DirectX we've had to recode large parts of it to run it on the Macintosh; including a total rewrite of the graphics code to make use of Open GL. It's coming along nicely with the game almost playable (see very early development screenshot below).
Eets was originally developed by Klei Entertainment for the PC. Later in 2007, Klei developed Eets. Chowdown for the Xbox 360 LIVE Arcade which was well received. Klei have now moved on to some new and exciting titles but it was their wish to see Eets come to the Macintosh. That's where we stepped in. We're now very excited to be part of bringing Eets to a new (and our adored) plaform.
Eets has been described as a homage to some classic games of the past the likes of Lemmings and The Incredible Machine. With it's bright colours and eccentric cast of creatures you quickly find yourself endeared by this title. Players must navigate Eets to the end goal, a "puzzle piece", of each level by using a mix of beasties and contraptions with their own unique abilities and properties. Prankster Whales, Marshomechs, Chocolate Cannons and Radioactive Gingseng all play a part in solving the puzzles preventing Eets from getting where he's going. Food is greatly important to Eets and it directly affects his mood, thereby changing the way Eets will navigate his way through the level. We all agree, Eets is a very hungry animal - although it's not clear what kind of animal he is. At first sight it's not unreasonable to think of him as a dog, but I've seen him described as a tadpole with legs and teeth.
Adding an extra dimension to the title is the inbuilt level builder allowing for user generated content. It adds hours of entertainment to Eets, when you've had your fill of playing through the levels shipped with the game.
Bringing it to the Macintosh has been quite a challenge. It was engineered originally with little expectation of it ever coming to the Macintosh platform. Written directly on top of the Windows API and DirectX we've had to recode large parts of it to run it on the Macintosh; including a total rewrite of the graphics code to make use of Open GL. It's coming along nicely with the game almost playable (see very early development screenshot below).

The big things left remaining to address on the Macintosh version of Eets are sound and some control issues. We're pretty confident the majority of the really heavy lifting has been done and progress from this point on will be straight forward (touch wood).
We'll keep you posted on progress as we get closer to releasing this fantastic title for the Macintosh.
Monday, September 21, 2009
What's in the works
As a recently formed independent games studio, we've been asked a number of times what our game plan is (pun intended). Starting the studio in Western Australia after working for some big name developers and publishers in Europe represents quite a change. Not only a simple change in geography but a huge change in proximity to the big market zeitgeist, talent pool and investment/funding opportunities.
Despite having some experience in the industry to fall back on we're under no illusions as to what we can realisticaly achieve in a given timeframe. Not to mention we're all a bit older now than when we first entered the industry. No midnight crunches for us while trying to support families and preserve relationships. Initially we're going to keep things simple.
For me that means the first and most import goal is publishing something. Set attainable goals and achieve them; get the dev cycles going and something on the table. Don't get me wrong, I want to create something special, but even Speilberg didn't create his finest films on his first foray out the door. So something special, but achievable.
We were thinking about how this studio might work months before we left our industry jobs and made the migration to Australia. Looking around at opportunities to achieve our goals we did find a path that we think is a good place to start.
It's always been my feeling that to create something worthwhile, it never hurts to understand what makes something worthwile. This thinking walks hand in hand with the ability to identify greatness in others or another's achievements. It was this thinking and a fortuitous meeting of minds with the developers from Data Realms that laid the path we would choose to take for an initial foray into Indie Game Development.
Data Realms have spent years crafting a beautiful indie game known as Cortex Command. The first time I played it was a hurried affair in a lunch break. My initial exploration didn't do it justice but my interest was perked. A few weeks later with more time on my hands (and with a freshly downloaded build) I was able to spend enough time playing Cortex Command to begin to truely appreciate it. I felt then and still feel now that Cortex Command is one of those creative products that has some sort of destiny. With an idea in mind and a fanboy's appreciation in my heart, that motivated me to bring Cortex Command to the Macintosh. Spiritually, the Macintosh version of Cortex Command is the first title for Kruger Heavy Industries. The fact that it was mostly completed by myself before the company was formed probably only matters to the record keepers on Moby Games.
Later in the piece we were very happy to have elected to be involved with Cortex Command. It did very well at the last Games Developers Conference 2009 in the Indie Games Festival, picking up two awards (Technical Excellence and the Audience Award) (some video coverage available here).

Cortex Command is still actively in development, but is largely code complete - at least as far as the Macintosh porting effort is concerned. It's bugfixing and build making for the most part until release. A day we look forward to greatly. Dan, Prom and the rest from Data Realms are doing a fantastic job.
So, what else is in the works for Kruger Heavy Industries? Fresh from our experience porting Cortex Command we picked up another great game we felt deserved some love on the Macintosh. Currently in active development is the Macintosh version of Eets: Hunger. It's Emotional. It was developed by our friends over at Klei Entertainment. One of their first titles, it's been lavished with much love and attention to detail by the Klei team. We won't tell you too much about Eets right at this moment as we're looking forward to that in a future post. For now we would like you to know we're really looking forward to having Eets playable on the Macintosh and putting that second building block into the foundation of our little studio here in Western Australia.
Despite having some experience in the industry to fall back on we're under no illusions as to what we can realisticaly achieve in a given timeframe. Not to mention we're all a bit older now than when we first entered the industry. No midnight crunches for us while trying to support families and preserve relationships. Initially we're going to keep things simple.
For me that means the first and most import goal is publishing something. Set attainable goals and achieve them; get the dev cycles going and something on the table. Don't get me wrong, I want to create something special, but even Speilberg didn't create his finest films on his first foray out the door. So something special, but achievable.
We were thinking about how this studio might work months before we left our industry jobs and made the migration to Australia. Looking around at opportunities to achieve our goals we did find a path that we think is a good place to start.
It's always been my feeling that to create something worthwhile, it never hurts to understand what makes something worthwile. This thinking walks hand in hand with the ability to identify greatness in others or another's achievements. It was this thinking and a fortuitous meeting of minds with the developers from Data Realms that laid the path we would choose to take for an initial foray into Indie Game Development.
Data Realms have spent years crafting a beautiful indie game known as Cortex Command. The first time I played it was a hurried affair in a lunch break. My initial exploration didn't do it justice but my interest was perked. A few weeks later with more time on my hands (and with a freshly downloaded build) I was able to spend enough time playing Cortex Command to begin to truely appreciate it. I felt then and still feel now that Cortex Command is one of those creative products that has some sort of destiny. With an idea in mind and a fanboy's appreciation in my heart, that motivated me to bring Cortex Command to the Macintosh. Spiritually, the Macintosh version of Cortex Command is the first title for Kruger Heavy Industries. The fact that it was mostly completed by myself before the company was formed probably only matters to the record keepers on Moby Games.
Later in the piece we were very happy to have elected to be involved with Cortex Command. It did very well at the last Games Developers Conference 2009 in the Indie Games Festival, picking up two awards (Technical Excellence and the Audience Award) (some video coverage available here).

Cortex Command is still actively in development, but is largely code complete - at least as far as the Macintosh porting effort is concerned. It's bugfixing and build making for the most part until release. A day we look forward to greatly. Dan, Prom and the rest from Data Realms are doing a fantastic job.
So, what else is in the works for Kruger Heavy Industries? Fresh from our experience porting Cortex Command we picked up another great game we felt deserved some love on the Macintosh. Currently in active development is the Macintosh version of Eets: Hunger. It's Emotional. It was developed by our friends over at Klei Entertainment. One of their first titles, it's been lavished with much love and attention to detail by the Klei team. We won't tell you too much about Eets right at this moment as we're looking forward to that in a future post. For now we would like you to know we're really looking forward to having Eets playable on the Macintosh and putting that second building block into the foundation of our little studio here in Western Australia.
Labels:
Cortex Command,
Eets,
game development,
Studio,
Western Australia
Subscribe to:
Posts (Atom)
