Printable Version of Topic

Click here to view this topic in its original format

Dumpshock Forums _ Community Projects _ SR4 Flash Apps

Posted by: Lilt Jul 11 2007, 05:13 PM

I just got my hands on the demo of Flash CS3. Right now, it looks like I'll be getting the full version in a month's time as I just got a contract for a couple of weeks working from home (for which I'll need flash). After working for almost a year as a flash developer (Flash 7&8), I'm looking forwards to turning my expertise with flash towards my hobbies and make some game assistants.

CS3 has some very handy built-in tools for making flash apps for mobile platforms, and I recently also got my hands on a phone with the flash player on it, the Nokia N95. It got me to thinking that I could make some useful in-game tools for players and GMs.

These tools could be run without a bulky laptop detracting from game attention.. The'd run on the player's commlink, so to speak. If the DM does have a laptop, he could load a page in a web browser with a bunch of these little applets on them. They're about 240x320 to fit on the bigger phones, and flash apps are very easy to resize. I could even make them so that if they're run 'big' they act 'big' and display more info.

What I'm looking for are basically a few ideas. Nothing too fancy, a bluetooth-enabled tool is almost definately beyond the capabilities of flash, but I could see some little applets being rolled-out...

My ideas:
Dice Roller (Been done many a time, but now would work on virtually any platform)
Drain Calculator (Keeps track of the drain codes of your spells for you, roll drain)
Mook Tracker (Dm tool, set-up encounters then resist and track damage to mooks)

Applet theory (do people agree with me on these?):
Player tools would probably have fewer auto-roll functions, they'd be more like interactive cheat-sheets. This is because IMHO players would generally want to roll their own dice.
DM tools would have more auto-rolling, for when you don't want to roll 10 sets of dice.

Posted by: mattness pl Jul 11 2007, 10:21 PM

My ideas for SR Flash aps?

My proposition:
MINIGAMES:
- Rigger (a la http://www.download.com/Mexican-Motor-Mafia/3000-7514_4-10408722.html)
- ssam (http://www.fizzy.com/games/swords_and_sandals2, but in dark alley in future Seattle)
- etc.

Posted by: jklst14 Jul 11 2007, 11:57 PM

Sounds great! I personally would love something to automate die rolling. Specifically, something that could generate secret Perception rolls for the PCs with a single mouse click.

Posted by: Lilt Jul 12 2007, 02:30 PM

Thanks for the replies.

I would be interested at some point in doing some games, but I suspect there would be issues with the fact that M$ own the SR games licence. I don't really want to go toe to toe with M$, even if they aren't making very good use of the lisence.

Another problem with games is that they take a bit more output... I'd need someone to do the graphics and stuff, probably sounds too, whilst a simple applet can look good with just a logo and a background.

I'm tempted to make a dice roller that 'speaks' the results actually, to avoid accusations of keeping rolling until good results are achieved. IE: "sixteen dice rolled six hits"... I could just record myself, and it doesn't need to sound too good so the MP3s could be kept fairly small.

The perception tests one is an interesting idea. I may have a look at doing that one at some point.

Posted by: mattness pl Jul 12 2007, 06:04 PM

I know there's very small chance for SR game(s) based on RPG.
I just couldn't resist to say what I have in mind.

Good luck with SR apps, Lilt

Posted by: eidolon Jul 12 2007, 06:15 PM

Ew, Flash.

Posted by: Kagetenshi Jul 12 2007, 06:17 PM

Preach, brother.

~J

Posted by: Lilt Jul 12 2007, 06:45 PM

QUOTE (eidolon @ Jul 12 2007, 06:15 PM)

Ew, Flash.

I'm not sure if that's just a play on the word flash, or a dislike for flash that I've seen many web developers display. In flash's defence:

Flash isn't perfect, it can be slow and it breaks the internet when people try and use it for what it's not meant for (web search engines can't see inside flash files).

What it is good for is quickly making multimedia applets (also games and animations) that will run on 98% of the web-connected computers in the world, and an increasing number of mobile phones. Who cares about speed when all you're doing is generating a few random numbers? Problems with searching only arise if you've got flash-based navigation, or sites entirely done in flash. These are largely unnecessary in any case, and shouldn't detract from what flash can do, which is a lot.

Posted by: Aku Jul 12 2007, 07:44 PM

mayber my Garage program is fueling some of the dislike for Flash

Posted by: eidolon Jul 12 2007, 07:54 PM

Just not a big fan of Flash in general.

Posted by: Lilt Jul 17 2007, 11:20 PM

QUOTE (eidolon)

Just not a big fan of Flash in general.

Fair enough. As someone who's developed with it I can say that I like the environment, it's very easy to pick-up and use with a little tuition, and it handles graphics in an intuitive manner.

The http://movielibrary.lynda.com/html/modPage.asp?ID=169 are really all the introduction anyone needs, and graphical manipulation can be as easy as changing an object's parameters (_x, _y, _width, _height, _xscale, _yscale, etc).

In-general, I've not really had time to start with the apps yet... Some things came-up and my free time from last Wednesday onwards pretty-much disappeared.

Posted by: Lilt Jul 18 2007, 02:22 AM

QUOTE (Aku)

mayber my Garage program is fueling some of the dislike for Flash

Hmm... Had a look at it and it looks interesting. From my experience, I try to keep as much of the details of the program as possible in an external file (or set of external files). This can be a little harder to code initially (you have to write something that'll read it in, but there are lots of XML readers for flash, including some freeware ones. Flash Professional also has one built-in), but has the advantage that you're only dealing with one block of code.

One block of code means finding bugs is much easier, as any bug that's present can be traced to the core code (if it's present across everything) or the external data (if it's only present in one section).

If you're thinking about doing any more work in flash, here are some of my tips:

[ Spoiler ]

The 'help' in the flash environment is very, very, good. Use it whenever you're stuck.

I find trace statements are a much faster way of finding-out what's wrong than the debugger, but maybe that's just my Java and C++ experience giving me an upper hand there.

Coding something specifically, or doing a specific page or frame for a function, is OK if what you're coding is an oddity. For everything else, I'd try and make the pages as general as possible. When you're selecting chassis type, for example, I'd write code that built a set of buttons from an array of chassis_id/name pairs rather than doing a page with X buttons on it. It's well worth learning how to use the square brackets notation to build programs that can cope with an unforeseen number of buttons and similar. IE: use mc.['button'+i] rather than mc.button1, mc.button2, mc.button3, etc. It may be slower in run-time, but it'll save days of time re-doing similar pages over and over again.

In-general we'd make the text for a button as a text box in-front of the button rather than part of it. That solves the problems you're having with different text on the roll-over. A simple colour change for the background (darken or lighten, maybe a different gradient?) is a good substitute for the hop-down-right if the button's not visibly angled. This also means you don't need specific buttons for each item, a general button with a dynamic text box infront can be inserted from the library using attachMovie. This code, if inserted into a fairly standard for loop, will create a bunch of buttons as long as you have an appropriate button movieclip in the library:

this.attachMovie('buttonStd', 'button'+i, this.getNextHighestDepth(), {_x:100, _y:60*i});
this['button'+i].label.text = i;
this['button'+i].button.onRelease = function () {trace(this.label.text)}

Note, the button movieclip would need to be exported for actionscipt (as 'buttonStd') and exported in the first frame, both of these options can be found in the linkage options in the library. It would need a button (a movieclip is generally preferable since flash 7) with instance name 'button' and a dynamic text box with instance name 'label'.

XML is a good format for external files that aren't binary. This is obviously only IMHO, but I find it's easily understood and modified by all (even TV Producers!). Generally: People who've used HTML can cut it, and that's a lot of people.