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.


Messages - IQpierce

Pages: 1 [2]
21
iOS / Re: iOS Canabalt Problems/Solutions
« on: Mon, Mar 21, 2011 »
That sounds great - I always had a feeling that the method I had chosen for fixing those retina/zoom issues was a bit of a hacky workaround. (But it works for me so I'm running with it for now.)

I agree with adding FlxG.accelerometer for sure. But in Flixel's spirit of also providing many "useful but simple" other utilities, I'd suggest that you also offer a "FlxG.accelerometerFiltered.x" value that returns the value tracked with a highpass filter (probably with a separate FlxG variable to control the factor applied to that filter): http://stackoverflow.com/questions/142944/how-do-you-implement-a-highpass-filter-for-the-iphone-accelerometer

That seems to be one of those things that everyone implements on every game, so why not put it in the engine so you don't have to rewrite it over and over? And having the accelerometer seems like it would be a boon since games with mechanics like Doodle Jump could then be made more easily.

I just remembered one of my major other complaints about Flixel on iOS: Buttons. Is it just me or are the buttons terrible? I didn't see any built-in way to do a "pushed" state (I ended up hacking/reusing the "disabled" state for this - the fact that it supported a disabled state but not a pushed state was boggling for me); and its method for detecting a push are pretty hacky so far as I can see (just a "finger released over this button" check, rather than ensuring that the finger was actually pressed down on that button to begin with - and very fast 1-frame-long taps seem to not register as presses at all).

Of course there were caveats about the iOS engine and maybe this was one. It seemed like methods for a proper push-detect were in the code, but commented out. I should probably stop complaining about it and go fix it instead - but I did want to mention it in this thread as a possible caveat around using the engine. If your gameplay is heavily based on GUI buttons, you may have some issues with the engine in its current form.

22
iOS / Re: iOS Canabalt Problems/Solutions
« on: Thu, Mar 17, 2011 »
Need to check this thread more - as you say we Flixel iOS dev seem to be a small community. :) Maybe once we put our games out, if they have any success, the engine will get more attention among the iPhone community - as you say it seems like the existing Flixel userbase maybe isn't the most logical one for jumping over to iOS development. Objective-C is not exactly as easy to learn as AS3.

I hadn't dealt with the texture atlas issue, since my simple puzzle game uses so few textures that I haven't bothered with compiling an atlas.

Regarding the odd function names: when you think about it, it makes sense. The function names with "param1:param2" are exactly as descriptive as normal function names - which do not actually contain any descriptions of what the parameters are in the actual function NAME. Therefore when you make a function call in AS3:

takeAction("foo", 2);

When you just look at that code right there, you have no idea whatsoever what those parameters are.

This would normally be a strength of iOS, in that you could look at such a line and it would be:

[self takeActionWithName:@"foo" andNumTimes:2];

Much more informative...

BUT when you're trying to build a language-translator, you want to keep it simple; so when you come across the AS3 line above, your script has no idea how to translate that into the Obj-C line above - because from that line alone, it has no idea that it should name the parameters "Name" and "NumTimes".

Hence giving the params deterministic (but uninformative) names of Param1:, Param2:, etc., makes it easier to translate the code line-by-line.

And in AS3 etc., the only way to remind yourself what the parameters to such a function call ARE from looking at such a line is to use your IDE's dynamic info/autocomplete/whatever that tells you about the function. The real problem is that Obj-C/XCode has less great features for that case, since it usually doesn't need it.

Oh and I'm not surprised to hear that QuadTrees aren't in the iOS engine, given the slow collision and the fact that they were a later addition to Flixel AS3. If someone brings those over to AS3 it would be awesome.

23
iOS / Re: iOS Canabalt Problems/Solutions
« on: Sat, Mar 12, 2011 »
I don't see any signs of anyone else actually working on Flixel iOS games yet, which surprises me - but hopefully that means my game will be the first iOS game using the Flixel engine save SemiSecret's own games?

Anyway axcho, my experience with it has been good so far. I had prototyped a puzzle game in AS3 Flixel and had it in a solid/fun state just when Flixel iOS was released. A few nights later I basically did a long coding session to "port" the game - literally copied/pasted over my AS3 classes and functions and just "translated" from AS3 to Obj-C line by line - and sooner than you would think, I had my puzzle game up and running in the engine.

I've never actually used Cocos2D on iOS or any other platform, so I'm afraid I can't compare them. I can only say that, if you know how to code in Objective-C/Cocoa and are used to all the weird quirks of it (like the unbelievably clumsy syntax for manipulating NSArrays and NSDictionaries), then coding in the Flixel iOS engine will otherwise feel very pleasantly familiar.

There are some quirks; you'll see many places where the methods have odd names for Objective-C methods. Specifically where most Obj-C coders would name a function something like "attackTarget:WithWeapon:", you may see a Flixel function that looks like "attackParam1:Param2:". I realized that this was to ease automated translation from AS3 to Obj-C (which Adam has mentioned they were working on, but which they haven't released and possibly haven't finished): it makes it easier to translate an AS3 function call like "attack(trgt,wpn)".

Honestly what I miss most is the Greensock libraries (TweenLite/Max and TimelineLite/Max). Having such nice, well-animated tweens, and being able to setup and and "play" a dynamic script of events (and do it all with so few lines of code) are definitely things I miss. But that's not really Flixel-related so I'm digressing.

I did find that performance of my game was worse than I expected when I had many particles with collisions going on - but I only got that working in a rough form and I may not have been doing it the most optimal way. But I took out the collision on the particles (I didn't really need them to collide) and now it performs quite well with many particles moving onscreen at once (say 60+, with about 100 other less active sprites in the scene as well), even on my 3G and with little optimization (I'm not even reusing a pool of particles).

24
iOS / Re: iOS Canabalt Problems/Solutions
« on: Tue, Feb 15, 2011 »
Although I got to refresh my memory on OpenGL by digging into the FlxGame::update() function and tweaking the way it does translation/scaling/rotation of the screen for the various zoom modes...

Ultimately my fix was simple: in my FlxGame's primary init function, where it calls [super initWithOrientation...], I no longer ever pass in TRUE for the "useTextureBufferZoom:" parameter (the code provided with Canabalt was passing in TRUE when using an iPads or Retina display). I do however change the "zoom" parameter to be 2.0 when Retina is enabled - and everything just works, the game is scaled up 2x.

Note that I'm not making an iPad game, just an iPhone game that I need to be sure works on iPhone 4... so I haven't tested how this changes iPad behavior yet. In other words, YMMV.

For anyone still looking into fixing this "properly" in FlxGame.m, here's the progress I made:

Around line 760, there's this block of code:
Code: [Select]
if (!textureBufferZoom)
{
switch (gameOrientation)
{
case FlxGameOrientationPortrait:
glTranslatef(backingWidth/2/_zoom, backingHeight/2/_zoom, 0);
glRotatef(actualAngle, 0, 0, 1);
glTranslatef(-backingWidth/2/_zoom, -backingHeight/2/_zoom, 0);
break;
default:
case FlxGameOrientationLandscape:
glTranslatef(backingWidth/2/_zoom, backingHeight/2/_zoom, 0);
glRotatef(90+actualAngle, 0, 0, 1);
glTranslatef(-backingHeight/2/_zoom, -backingWidth/2/_zoom, 0);
break;
}
}

I appended this else block:
Code: [Select]
else  // !textureBufferZoom
{
if( gameOrientation == FlxGameOrientationPortrait )
{
glTranslatef(240, 160, 0);
glRotatef(180+actualAngle, 0, 0, 1);
glTranslatef(-240, -160, 0);
}

}

Essentially this attempts rotate the screen correctly for an iPhone 4 screen. Again this is untested on iPad, and these hard-coded magic numbers probably need to be factors of width/height like in the code block above... this is just what I experimented with and found to work on iPhone 4 retina displays.

There is a major problem with this that I didn't solve however, which is that the bottom 3rd of the screen wasn't being rendered - it was just showing up as black. Input was accepted in this area however. I started looking at the glViewport calls higher in the function to try to resolve this, but I failed to get anything working, and then I realized I could just use my much simpler solution above.

If nothing else, hopefully this will draw Adam's attention to this issue - I'd need to refresh myself on OpenGL more, and read through the Flx rendering code more carefully, to really understand what needs to be done in that function - hopefully this is something he could fix quickly though.

25
iOS / Re: iOS Canabalt Problems/Solutions
« on: Mon, Feb 14, 2011 »
Just did a little research, this issue only appears to happen if you call FlxGame::initWithOrientation with the value FlxGameOrientationPortrait. If you call it with FlxGameOrientationLandscape (as the Canabalt example does), everything behaves correctly.

I'm seriously considering hacking my game to have this Landscape orientation but just rotate everything I put onscreen... but I suppose I'll look deeper into what the real fix is.

ADDENDUM: D'oh, I hadn't noticed that the fact that this is specific to Portrait has already been reported. Still looking into this anyway.

26
iOS / Re: iOS Canabalt Problems/Solutions
« on: Mon, Feb 14, 2011 »
Did anyone find a fix to this issue with the Retina displays? I'm working on a Flixel iOS game and just ran into this...

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

C.O.O.P.



--------------------

Play it here!

--------------------

Controls
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!

28
games / Re: Super Merio Rampage!
« on: Fri, Dec 24, 2010 »
First of all, good job re-creating so much of SMB in Flixel... I'd encourage you to be more original in the future, but for your first game, it can sometimes help to make a clone of something else!

Second of all, I found what I played of this interesting and think that "SMB plus bullet time" is a neat idea worth exploring...

But I find this control scheme impossible to deal with. Pressing UP to jump just doesn't work for me, or for anyone who actually played SMB I'd imagine! I'm also more used to using the arrow keys for controls than WASD in this type of game - I'm proficient at FPS games but just because I use WASD there doesn't mean I want it everywhere.

I'd suggest adding a third (and probably default) control scheme that uses the control scheme that seems to be most standard for Flixel games: arrow keys for movement, Z to jump, X to fire. The fact that Z and X are actually right next to the Shift key you're using for bullet-time seems to make this an ideal control scheme (holding Shift while moving, etc. started to give me a hand cramp!)

A nice first effort though, I wanted to play more of it but just couldn't get past the controls in the end. :)

29
games / Re: Cat Astro Phi
« on: Fri, Dec 24, 2010 »
First of all, the music and sound are fantastic!

I liked this game, but I think I would have liked it better if it was bigger on challenge rather than being almost 100% exploration... or at least if it had had more interesting exploration than just "traverse a maze" ... there were crate mini-puzzles and so on, but few of them were really challenging.

30
If you press F1 in my example game at any time, the game will go re-fetch the values from the spreadsheet, and you'll see it using the new values immediately.

Try playing the example game and changing the jump power factor between, like, 1 and 1000, and then refreshing in the game by hitting F1! You'll see the tweaks applied in realtime without having to reload the game.


31
Nice. I just tried "freezing" the first column, I wonder if that will work.

Not too worried about the "griefing" element since it seems like a pretty helpful, constructive community around here.  ;D

32
Also, I like the idea that we now have a "wikified game"... the game here:
http://www.deepplaid.com/FlxTweaks/TweaksExample.swf

Is having its functionality driven completely by the publicly-editable data here:
https://spreadsheets.google.com/ccc?key=0Av_wyO3Jq2o6dElFM1kyaFpzNlpTSHhnN3JDNnQ4d0E&hl=en

...If we wanted, the Flixel community could use this as a testbed for what combination of gravity, jumpForce, and moveSpeed values felt ideal for a simple platformer, and continually tweak these numbers into perfection...

...Or they could immediately change moveSpeed to be negative so that all movement is backwards...

...Or they could delete all these variables and add nonsense ones, so that the game will crash at runtime. :) Oh well that's the power of wiki, and I assume these spreadsheets have the ability to roll back to previous revisions if someone breaks it!


33
Request granted! You should be able to do this using the class I just uploaded here, "FlxTweaks.as": http://flixel.org/forums/index.php?topic=2799.0

Instead of creating an in-game interface, this lets you put variables into a Google Spreadsheet. In the example linked in that thread, you should be able to go change the values in the publically-editable spreadsheet, hit F1 in the game, and see the new values taking effect immediately.

Happy tweaking!  8)


34
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, FlxTweaks.as: http://DeepPlaid.com/FlxTweaks/FlxTweaks.as

And I made a simple example to demonstrate usage...
You can play the example here: http://www.deepplaid.com/FlxTweaks/TweaksExample.swf
And the spreadsheet (which is publicly editable by anyone!) containing the 3 tweak values ("gravity", "jumpForce", and "moveSpeed") is here: https://spreadsheets.google.com/ccc?key=0Av_wyO3Jq2o6dElFM1kyaFpzNlpTSHhnN3JDNnQ4d0E&hl=en

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: http://www.deepplaid.com/FlxTweaks/TweaksExample.zip

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.

(If you use this method in a publicly-released game, PLEASE RE-HOST THIS PROXY PHP FILE ON YOUR OWN SERVER AND POINT YOUR GAME TOWARDS THAT ONE, NOT THE ONE ON DEEPPLAID.COM THAT I USE IN THE EXAMPLE!)

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 https://spreadsheets.google.com/feeds/list/tIE3Y2hZs6ZSHxg7rC6t8wA/od6/public/basic ... 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?

35
I have to say that I'm skeptical about the Flash side of this. There was a lot of bad blood created between Apple and Adobe by that whole fracas.

I do want to hear about what happens to the first app(s) submitted after this, that are built using Flash CS5. If Apple rejects those (I understand that they're easily identifiable based on the way that Flash packages the app contents), that will tell us a lot.

...But not everything. If the apps submitted are actually low-quality (run sluggishly, use non-standard UI no good reason, etc.) and/or if they don't match up with the approval guidelines (which are linked in that article I believe), then it won't tell us anything about a bias for/against CS5 apps.

Personally, I'm eager to see the iPhone version of the Flixel engine released, hopefully followed by an automated converter of Flixel games from AS3 to Obj-C/C++/whatever. Since such apps will be compiled entirely in Apple-approved languages, there's no reason for them to be rejected.

36
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:

http://blog.yoz.sk/2010/05/myth-buster-benchmarking-loops/

His takeaways:

Quote
    * “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.

37
help / Re: usersThatNeedHelp++
« on: Mon, Mar 8, 2010 »
Just a quick note: You may want to look at "Terminal Velocity", a game that was made in Flixel in about 6 hours by me and ~8 other dudes a couple months ago.

http://code.google.com/p/austin-flixel-jam/

It's "a game about falling", and it's open-source, so you may find a lot of helpful stuff by looking through its code.

38
Ohh, I think that Mode might work for me racter! I thought I'd seen all of AA's small Flixel games, obviously I didn't look hard enough. Need to explore his repositories as well it seems.

If there are any more sophisticated ones that are open-source, I'd still appreciate people posting those as well. But this seems like more than enough of a starting point for a simple shooter.

39
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 [2]