Monthly archive for January2013

Frustrations over Starling and Citrus

I’ve spent a rather long time trying to get a solid direction going in terms of setting up a back end asset/entity management system. I didn’t want to build one myself. It’s a pain in the ass, and a major time sink. I’ve been sniffing around looking for other frameworks to handle this for me. This week, I’ve been giving the Citrus Engine a whirl, but there have been a few rather important flaws that have popped up.

  • When entering and exiting fullscreen mode, Citrus (and implicitly, Starling), would crash due to a loss of Context Error. It’s VERY frustrating for me to chase down bugs in someone else’s framework, and after a good two days of spinning my wheels, I couldn’t come up with a working solution. Too bad. Citrus was looking very promising.
  • Starling also doesn’t seem to want to scale when Stage.displayState is set to StageDisplayState.FULL_SCREEN_INTERACTIVE. It locks the render area to the stage’s predetermined viewport size. The fix has been to increase the viewport’s dimensions to full screen dimensions, but that is NOT what I want to do. I want the resolution to remain the same (1024, 576 for example), but to have the rendered image scaled to fill the screen. I’m done trying to get this fixed. It’s  a TERRIBLE fault in Starling’s design.
  • Starling also has no support for functionality similar to Flash’s Sprite.graphics.lineTo(x, y) drawing. There are some bandaids offered by other developers, but they lack a means of transforming a texture used to fill a given polygon. What’s more, if you want to have a texture tile in Starling, it CANNOT be from a texture inside of a texture atlas. It has to be in its own separate Texture. THIS IS CRAZY! The whole point of using Starling is to utilize the hardware for maximum efficiency, and texture atlases are a large part of how you accomplish this feature!
  • I can’t seem to find very good information on using Starling for games that aren’t small, casual titles. What I find are articles on “How to make a gem puzzle” or “Angry Birds clone”, which all require a single TextureAtlas  to contain all graphics. If I’m trying to make a game that essentially looks like this, I’m going to need a hell of a lot more than a single texture atlas. Where on Earth do I even start in setting up something to handle this?

If anyone has any practical solutions to these problems, please let me know. Otherwise, I’m back to using Nape physics and my own proprietary image management for Conjurer.

 

Go to comments... →

New Years Resolutions

Resolution #1: More posts on the dev blog

It’s difficult to write a blog and try and keep things relevant and interesting. Try it. You’ll see what I’m talking about. You all couldn’t give a shit if I said “Been two weeks, no progress because nothing is really working yet.” But, on the other hand, living under the judgement of those who want to see my work succeed is exactly what keeps me motivated. So, expect more updates.

Resolution #2: Stop reinventing the wheel.

This is somewhat related to post 1, in that I’ve spent the last couple of weeks trying to build a new back-end graphics and physics component system to an Entity framework that controls all game objects loaded on screen. I’d already written one at BlindSquirrelGames for Beards and Glory, but given that I don’t work there anymore, I can’t really use it. That’s OK! Because that B&G framework was custom tailored to run on mobile devices, and as anyone out there who has worked on mobile game development can attest, it’s a VERY limiting platform. This time around, it feels nice to stretch my legs and not to be so constrained by such an environment.

So, it’s been rather frustrating to start from scratch, because I simply DON’T have the time. So, after doing a lot of research, I’ve decided to use the Citrus Engine. It supports two major features that I have already spent 2 weeks trying to hammer out on my own:

Rigid body physics support using Nape.

GPU-enabled rendering using Starling.

Couple that with the Xbox360 gamepad support (Windows only) that I’ve already implemented thanks to a fantastic Native Extension written by Rhuno, and it’s finally time to start cranking out some new features!

Go to comments... →

First flash… then XNA… now, back to Flash?

Outside of all of the concept art you’ve seen on this dev blog, I’ve been doing a lot of research in preparation for developing the engine to this game. It’s been getting me rather frustrated.

Here’s my dilemma…

Ever since I used XNA at UC Irvine for a game project class, I’ve been really interested in picking it up again. I was hoping to use XNA for Conjurer. It’s such a robust framework, with a ton of support and a long laundry list of indie titles that have seen some pretty good success. I LOVE working in VisualStudio. It’s such a powerful and user friendly IDE. XNA has native support for gamepads, integration with DirectX and can easily handle almost any genre of game type I want, whether it’s a 2D RPG or a 3D racer.

However, I already know how to develop, program, draw and animate in Flash. Been doing it since Flash 3 back in ’99. In fact, I’d go far enough to say that I know it REALLY well. I teach a class on it at a local community college. And for what it’s worth, it’s a really powerful framework and engine. It has a TON of support and a HUGE user base. The player and IDE are constantly updated by Adobe with new features, and it doesn’t look like they’re dropping support for it anytime soon. The major drawbacks that still linger are its speed in comparison to other, lower-level frameworks. A lot of this has been dealt with recently, such as the recent implementation of Stage3D and Worker multiprocessing (Though, in my book, the jury is still out on the latter).

Here’s the rub: I want to make a game in XNA. But, it’s becoming more and more terrifying to realize that I’m on my own at FrenchRoastGames. Art, Tech design, programming… all me (for now). What’s worse, I have painfully learned the hard way that picking up a framework by myself is an incredibly time-consuming and frustrating process. I prefer to learn through osmosis, to have tasks delegated to me from someone who clearly knows what they’re doing, and who can help pull me out of a bind if I get stuck. This likely has something to do with the poorer grades I got at UCI toward the end of senior year. Not fun. Downright demoralizing. Useless TA’s, incompetent colleagues, and overcrowded lectures aren’t a good way to learn the finer points of graphics processing and development.

In short, I don’t have time to learn a new framework. I HAVE TO MOVE. A week spent piddling around on XNA tutorials is a week not spent on development. There is a considerable amount of work to do to build an adequate cross section of gameplay. That cross section must have enough quality to convince tens of thousands of people to donate $10 on KickStarter. This is critical to the success of this game. It has to be a full time commitment by me and a handful of other developers or it will not see the light of day!

One big feature that I am adamant upon implementing is support for game pads. Flash doesn’t have it(yet), which is what ultimately pushed me to XNA. However, recently a couple of developers have been gracious enough to create an Adobe Native Extension for Xbox360 gamepads. It only works on Windows (for now), but it’s a huge step in the right direction for Flash. If I can goad the developers into including support under OSX and Linux (Ubuntu at least), or augment it correctly myself, then I’ll be incredibly happy.

Another big feature was tools development. After working on Beards and Glory for Blind Squirrel Games, I now understand the importance of building quality development tools for other designers. It’s an aspect of game development that is horribly overlooked and underrepresented, in my opinion. For every tutorial and book I need for XNA development, I’d need another book on .NET and WPF to make the level editors, asset managers, and testing apps for the game. This is not an issue with Flash, mostly because of the Flash IDE (asset development and organization), and how easy it is to make level editors myself.

So… as much as I am desperate to move away from Flash, my flagship project is going to have to be built in it if I’m going to get anything shipped on my own.  XNA will have to remain a hobby until I can quickly conjure up a design spec for a project in my head without consulting the Internet. Thankfully, my design requirements aren’t outside of the scope of Flash’s capabilities, and I’m sure the Adobe Game Developer Exchange wouldn’t mind yet another project in their developer showcase. I guess it’s best to make these decisions now, and not further down the production line.

Go to comments... →