Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - IQpierce

Pages: [1]
help / Scale problems: <65% scale invisible!
« on: Mon, Nov 19, 2012 »
I was messing with a new feature of my game last night and I discovered one of the effects I use in the game just seems to always be invisible when its scale.x/y values are < 0.65. I had to do a lot of testing to narrow it down to this problem, and I've never seen anything like that before in Flixel.

Then again, I don't know that I've ever scaled anything down that far, I don't use scaling a lot due to its performance implications. I need it in this case though.

Has anyone seen this before or solved the problem? Thanks for any help or insight you can provide.

releases / FlxSWFStates - Level creation in Flash/FLAs!
« on: Fri, Aug 24, 2012 »
I meant to share this before... luckily that means it's *fairly* mature, or at least I've been using it a lot and I see few or no bugs with it. My friend Chris is participating in Ludum Dare (I'm jealous, I wish I had time) and is going to use Flixel... I packaged this up a bit to share it with him, and thought I might at least share it with others.

I've tried DAME and looked at Ogmo and just didn't feel like it was worth my going through the learning curve. I realized that what I really wanted was simple: WYSIWYG (What You See Is What You Get) level design, putting things in 2D space... and that was all. And the frustrating thing was that I can do that easily in other Flash work I do: just make an FLA with the content I want, bam, done.

But Flixel doesn't use the Flash display list and is just a different world from anything you can make with an FLA, right? It seemed like an easy gap to bridge, so I tried bridging it.

FlxSWFStates will:
1. Load a SWF file
2. Look at all the DisplayObjects on the "stage" (root display list) of that SWF
3. Create an FlxSprite OR ANY OTHER DERIVED CLASS from each DisplayObject
4. Give the new FlxSprite the x/y/width/height of the original DisplayObject
5. Optionally give the new FlxSprite the pixels of the original DisplayObject [no, animations are totally unsupported, sorry; rotation also not supported yet]
6. Assign any variables to the new FlxSprite, which you can define in Flash using the Component Inspector (e.g. you can set "vector.x => 50" and the object will have its vector.x value initialized to 50 when created... works for any variable names on your custom classes too).
7. It will then add this FlxSprite to your FlxState. If your FlxState defines a certain custom function, it will go through that function, otherwise it falls back on simply calling add().

There are "Dynamic" and "Embedded" implementations of the Populator which you can use. Embedded uses a SWF that has been compiled (longer compilations, faster at runtime); Dynamic uses a SWF file that's loaded in on-the-fly at runtime (faster compilations, slower at runtime). I prefer Dynamic because you can reload your level's SWF without having to restart the game, allowing for super-fast iteration (which I am addicted to).

Here's the library itself, which is meant be put under the flixel "plugin" folder (though I'm not sure if this is the right place for it at all, oh well):

And here's a minimalist example project that uses it:

(This game was originally something I created in 20 minutes in a nightclub during GDC with Robin Arnott and Rodain Joubert... it's terrible... but at least it can serve as a demo of this plug-in now!)

Here's a bunch more details on where things live in the test project, copied from the email I sent to my friend earlier....

- The FLA file for the level lives in data/levels. Its publish settings are set to publish a SWF under bin-debug/levels/. This is a weird setup for FLA/SWFs, but I had problems getting dynamic-SWF-loading working unless the level SWFs were underneath the same folder (bin-debug) as the game SWF.
- The FLA also includes the libsrc folder, there are a couple of my classes that it has to be aware of.
- Note the component settings on every object in the level. You can set what class a MovieClip should be turned into in Flixel (in this case "Sun" or "Planet"); and you can put arbitrary name/val pairs that will be set on the object at initialization. One planet starts out with a velocity.x = 50 name/val pair.
- Note that BaseSWFLevel takes care of identifying what type of object is being added, and putting it in the right group. Good place to hook up other massaging/handling of those things.
- There's also a hook for after the entire SWF has been loaded in.
- Note that the SWF is loaded in AT RUNTIME so you can totally do the following for maximum productivity:
   - Play the level, and find there's a change you want to make
   - Go to the level FLA, make the change, republish the level SWF.
   - Reload the level (you don't even have to relaunch the game!!!), for instance by stepping out to the main menu and back in, or with a dev hotkey
   - Bam, you're running the changed level, no need to rebuild or relaunch whooo
- The actual SWFState code lives under libsrc/org/flixel/plugin/FlxSWFStates. Note that two classes in there (ObjectProxy and ObjectProxyParent) are things that can be used for Components in the FLA. Note how the object linkage and component setup in the FLA library is setup for the Sun and Planets in there. These examples all use ObjectProxy I think; if you want to do parenting, it works, but you have to make the parent objects be ObjectProxyParent components for the code to recurse into them and find the ObjectProxy children at runtime. I know that this makes no sense, so ask me for more details/examples if you're really curious about this capability... basically it lets you use the Flash MovieClip hierarchy for more modular setup.
- The actual pixels of the thing in the FLA will be used on the sprite created, by default. Making this a great prototype art tool. Zero support for animations though. You can always uncheck "use pixels" on any element's component settings, if you want to set up its visuals in code instead.

Hopefully that's more than enough to get people started. My hope is that this can be a significant alternative for a way to design levels for Flixel, even though it will clearly have some pros/cons compared to the other methods (this has absolutely zero special support for Tilemaps, I've never used them, yes I know they're a popular Flixel feature, sorry). And of course this isn't helpful to indies who don't have Flash, I know.

But hopefully it's useful to the community! Enjoy and let me know if you add capabilities, or discover major bugs, etc.

iOS / Dynamic FlxSprite coloring
« on: Sun, Apr 29, 2012 »
I was emailing "initials" about this the other day, he gave me a bit of a starting point for this discovery...

The original Flash version of Flixel of course allows you to do things like "sprite.color = 0xff0000;" to instantly tint an FlxSprite to be red. When I developed the prototype of my game Connectrode in Flixel, I colored all of the sprites this way in the Flash version...

...Then I brought Connectrode over to the iOS version of Flixel and discovered this capability didn't work! There's a "color" member on FlxSprite's on the iOS version; but if you set it, nothing happens. At that time, I just made special textures for each color, and moved on.

It's a year since then and I'm trying to do a "thank you" update to Connectrode, to thank all the players who bought the game out of solidarity last month (when some drama went down between me, Zynga, and my former CEO). One thing I had always wanted to do was make my "matching colored tiles" game playable by people who were colorblind. To allow for this, I wanted to let players choose their own colors for the 6 piece types used in the game - so, I looked into solving dynamic tinting for real.

Turns out this is pretty simple. Go to the function FlxSprite.renderSprite()... look for the line "glPushMatrix();"... and right after that line, add these lines of code:

Code: [Select]
float redMultiplier = ((float)( _color >> 16 & 0xff )) / 255.0f;
float greenMultiplier = ((float)( _color >> 8 & 0xff )) / 255.0f;
float blueMultiplier = ((float)( _color & 0xff )) / 255.0f;
float alphaMultiplier = _alpha;
glColor4f( redMultiplier, greenMultiplier, blueMultiplier, alphaMultiplier);

The color tinting of FlxSprites will now work exactly as you'd expect. Hope this helps folks!

iOS / Fonts in Flixel iOS - source/example included!
« on: Sun, Jul 24, 2011 »
So I just released Connectrode ( this month and it's doing well on iOS, currently featured by Apple and #10 in puzzle games, yay! It was made in Flixel iOS... someone on the "Games" board asked me how I handled the fonts/text in it and I thought I'd give a detailed answer here.

Okay so, custom fonts. Text and fonts were DEFINITELY the biggest pain in the ass of making this game. I probably spent over 12 hours just messing with font stuff, figuring it out and trying to get it to work (also counting wasted time of trying to do all the text embedded in images and headaches around that).

Long story short, to get my own font working, I had to go copy the FlixelFont.m file, look at its long array of glyphs (flixelUnicharToGlyphMap), and then basically use trial-and-error to try switch over the font glyph indeces in that array with the font that I had imported instead. It was horrible and took forever.

Some advice if you try to go down this road yourself:
1. To figure out what the indices for the characters you want are in the font you're trying to use, I heard someone recommending using "FontExplorer X Pro" (for Mac at least) which lets you see what all the glyph indices are for your font.
2. To clarify what's going on here: this array is a way of saying, for each and every possible Unichar character, where it can find the glyph for that character inside the font's data. Fonts can have a completely different ordering for this data. But that's what flixelUnicharToGlyphMap is for: each entry in that array is for a possible Unichar character, and if you want that char to show up, you put an entry at the right point in the array for the index of that character in your font.
3. The difficulty is knowing 1) which unichar index corresponds to the actual characters (this I believe can be easily determined by looking at the unichar character-code definition I believe), and 2) where that character is within your font (this is what you would find out with FontExplorer X Pro... or, if you're a masochist like me, with hours of trial-and-error, plugging different indices in at random, seeing what shows up on screen when you try to render text with that font, and trying to figure out patterns).

So to hopefully save you guys a bunch of trial-and-error, I will attach here the font file we used (it's a publicly-available font called OCRA), as well as my ConnectrodeFont.h file (which is again a copy of FlixelFont.m, except thatI have my own version of the flixelUnicharToGlyphMap in which I've made it more readable for recognizing where things go, and have commented the indices of some important alphanumeric and punctuation characters).

Fonts are clearly not the strong point of this iOS engine, but if you really want to try to do them, you can dig into all this stuff, and hopefully the digging I've already done will save you a ton of time in getting it up and running!

Post in this thread if you try to hook up your own fonts following this example and get stuck or can't figure out what's going on, I'll be happy to try and help!

UPDATE: Looks like I can't attach fonts, check out the font at

games / Connectrode: pure puzzle game for iOS
« on: Sun, Jul 10, 2011 »
Connectrode, a simple but addictive indie puzzle game made using Flixel iOS, is on the App Store for $.99!

Video on YouTube:



How to play:
Repeat after me - this is NOT a match-3!
There are "chip" pieces on the board and you are given "connector" pieces each turn to place onto the board. If you place connectors so as to "close the circuit" between multiple same-colored chips, then that whole chain of chips and connectors will be cleared from the board. The real trick is that placing a piece can block off parts of the board (new connectors can't be moved through walls of other pieces) - so each piece placement may limit you placing pieces on future turns.
Simple rules, but some complex challenges quickly emerge once you start playing (especially on the harder difficulty levels). There's some subtle scoring rules that can make the game much more challenging for those trying to maximize their score (connecting 3 chips is much trickier than connecting two).

I'm a professional game programmer but I also do indie projects (as "Deep Plaid Games"), and I love prototyping games in Flixel. I decided to design the most addictive puzzle-style game for iOS that I possibly could. I prototyped the mechanics in Flixel for AS3... after dropping the project, my wife encouraged me to mess with it again... suddenly I found gameplay that I fell in love with... the very next day, Flixel iOS went open-source, so I basically stayed up that whole night and ported my code from AS3 to Objective-C!

Later I got in touch with some other awesome Austin indies to finish what was by then called "Connectrode":
  • Brandon Boyer put me in touch with Dale Austin, who did fantastic work with the art and the video
  • My friend Brad Lewis (who worked on I Dig It on iOS and now works for Bioware) helped with art during early development
  • Robin Arnott (who made an awesome art game, "Deep Sea") did the sound effects
  • David Pencil compsed the music (he did the soundtrack for Penny Arcade: The Series, season two).

I'm proud of it as a well-designed, elegant puzzle game... and I love the graphics and sound that the team put together. Since it's a kinda personal game (I was the sole game designer and programmer), I dedicated it to my wife Laura, who encouraged me to pursue the project.

Designing a truly "easy to learn, hard to master" game was an incredible challenge. I hope to do more complex and experimental indie game projects at some point... but for now I'm proud to have made a "pure puzzle game" that I think ranks up there with the best in the genre! Hope others try it and enjoy it! Feel free to ask questions, or share impressions if you try the game.

Shay Pierce
CEO and Wombat Defenestrator
Deep Plaid Games, LLC

games / C.O.O.P.
« on: Wed, Feb 2, 2011 »
Should have posted this here before now...



Play it here!


Keyboard Player:
Move up/left/down/right: W,A,S,D
Shoot up/left/down/right: Arrow keys

Mouse Player:
Place current object type on field: Click there!
Change object type being placed: Click the onscreen button for it, or use MouseWheel to cycle.


C.O.O.P. is a Flixel game made in 48 hours at last weekend's Global Game Jam 2011. We were one of three Flixel teams at the Austin GGJ site, and I think we were the single most successful team there in terms of making a fun, complete game. I led the team (which totaled 9 people), doing programming and providing creative direction. We were very lucky to have a great team of really smart people.

The core idea is that one player (keyboard player) is playing twin-"stick" shooter gameplay, while a second player is using the mouse to place walls and other objects on the board (it's best compared to Tower Defense gameplay). They're both cooperating to keep the "keyboard player" alive as long as possible in a classic Arcade-style survival mode. Every game mechanic focuses on the cooperation and the result is a frantic experience of cooperation with your friend.

You can play it single-player for a while but it's rather boring - grab a friend and try playing it together!

We're planning to clean it up, add a single-player mode, and submit it to FlashGameLicense. Any feedback/advice would be welcome!

Hey, I've been using Flixel for a while, mostly for a project I was prototyping with a game designer friend here in Austin.

At one point I decided that I needed to expose the "tweak variables" in this prototype so that the designer could tweak the numbers in the game directly and get the feel he was looking for. Inspired by this blog by a developer of PushButtonEngine, I thought that the best way to expose this would be to make a Google Spreadsheet that could contain all the variables; the spreadsheet could be edited by me or the designer, and the game would read them and load the values in the spreadsheet to be used in the game. (This even allows reloading variables dynamically at runtime without reloading!)

This turned out to be a somewhat finicky process, but I got it working and thought I would share the results with the Flixel community.

The code is a single self-contained class,

And I made a simple example to demonstrate usage...
You can play the example here:
And the spreadsheet (which is publicly editable by anyone!) containing the 3 tweak values ("gravity", "jumpForce", and "moveSpeed") is here:

Try moving left and right and jumping (using SPACE or Z). Then try changing any of the values in the Google Spreadsheet; hit F1 (you don't even have to reload the game!); and try messing around in the game some more. You should see the new variables being used within a couple seconds of hitting F1, at most.

Finally, all the source for this example, as well as a .PHP file which is necessary to host as a "proxy" for serving the Google Spreadsheet data, can be downloaded from here:

Regarding that PHP file I mentioned... Flash can't directly access Google Spreadsheet data due to permissions issues, but an intermediate PHP file can do so. So long as Flash CAN access the domain that the PHP file is on, everything will work fine.


How to use it in your code: In keeping with the pragmatic philosophy of Flixel, I tried to make it as simple and straightforward, but flexible, as possible. The FlxTweaks has one static function, "loadVars", which takes:

  • An Object ("obj"), which the variables from the spreadsheet will be loaded into.
  • A URL for a spreadsheet's XML data (for the example, this is ... note that the spreadsheet should be set up to "publish to the web", and have the option to "automatically republish when changes are made" checked; I believe it also needs to have "visibility" set to "all"... I haven't experimented with just making this visible to specific users... remember that you can make a spreadsheet visible to all but only editable by some).
  • A proxy URL (a path to a hosted GoogleSpreadsheetProxy.php file that I already talked about).
  • A function to call when loading is done (optional).
  • An array of parameters to pass to the function called when loading is done (optional).

The function will load the spreadsheet data. It expects variable names to be in column A of the spreadsheet, with the corresponding value for each variable in column B. For each of these key/value pairs, it will put them into "obj":

Code: [Select]
obj[ key ] = value;
This means that "obj" could just be an Object, used as an associative array, and that any values in the spreadsheet will be put into it blindly, and your code could even respond dynamically to what values it does or doesn't find in "obj" after it's loaded.

OR, if you want to be more strict, you can do what I do: make a specific, non-dynamic class ("ExampleGameTweaks" in my code) which has a value for each tweak variable desired, and pass an instance of this class in as "obj". So long as every value in the spreadsheet has the name of a set-able value in that class, everything will behave fine. (This even works if the value being set is actually a setter!) But if a variable is in the spreadsheet but isn't in the class, you'll get a runtime error.

If the spreadsheet-loading fails for some reason, the callback function will still be called, but the failure will be logged in the console.

Known issues, and things I'd like to add:
  • During tested I noticed that I pointed this to a spreadsheet that wasn't yet publishable; though the console didn't report a failure to load, no tweaks were actually loaded. Basically I think it didn't get a 404 (it got a "can't access spreadsheet" page from Google instead), so it thought it succeeded. Still, it should be fairly obvious that it failed in this case since none of your tweaks will actually be showing up. But I should add handling for this
  • Currently this just treats the spreadsheet as a big list of key/val pairs. The PushButton Engine usage appears to be more complex and allow for a meaningful 2D matrix of data to be set up. Although you can do a lot with key/val pairs, maybe there should be an alternate handling mode that lets you lay out 2D tables of data in the spreadsheet, and causes each them to be automatically loaded into associative arrays in code.

Hopefully this is useful for a lot of people to make their variables more exposed for tweaking, and especially to allow an interface for quickly tweaking variables without even having to reload, much less rebuild, the game! Let me know if there are issues with this.

This is the first time I've made an addition to Flixel - I guess I'll go look into whether there's a process to add this file to the git repo now? Thought I would share this here first. Should I add this to FlashGameDojo perhaps?

help / AS3 loop performance benchmarks
« on: Wed, Jun 9, 2010 »
I just ran across this blog post on the site of an AS3 developer (unfortunately English doesn't seem to be his first language, but the stuff he produces/blogs is still quite interesting). He set up a series of benchmarks to determine very unambiguously which forms of loops are fastest in AS3:

His takeaways:

    * “for” and “while” loops can be equally fast, while “for each” loop is much slower
    * “uint” and “int” is equally fast, and is much faster than “Number”
    * “pre” vs. “post” is more less the same
    * decrement mostly wins over increment, but in some cases is equally fast
    * Linked-lists iteration performance equals to Vector and is better than Arryas
    * when casting required, linked lists rules them all
    * using ByteArray as list is not as fast as Array nor Vector

No huge surprises here really... but it's nice to see a definitive, practical analysis. Good to know that we should avoid "for each" in performance-intensive loops, for instance.

help / Simple side-scrolling shooter - source code?
« on: Mon, Mar 8, 2010 »
Hey guys,

I've only worked in Flixel a bit before, but I recently had an idea for an "art game" that I thought Flixel would be perfect for. The basic gameplay could be something like Mega Man or Contra; a simple 2D scrolling shooter.

The thing is that I wouldn't have a ton of time to work on the project and was hoping to minimize the work involved by leveraging existing code as much as possible.

So I guess I have two questions:
1. Does anyone have, or know of, code that they've built on top of Flixel for a 2D scrolling-shooter game (or a "2D scrolling shooter engine") that is open-source, or that they'd be willing to share with me?
2. Is there perhaps an even better, non-Flixel engine that would be better suited to my needs? If there's a solid open-source Contra clone online somewhere, that would be a terrific starting point.

This game would be more about the scenarios it puts you in than about the core mechanics, and I figure someone somewhere has created a solid-feeling shooter of this kind that they don't mind sharing, or else an engine to easily create such shooters.

Thanks in advance for any help you can provide guys!

Pages: [1]