Share/Save/Bookmark Subscribe

Friday, April 30, 2010

Game- and mobile dev gun for hire

I took a big step today and handed in my resignation at I-Imagine to
begin doing freelance contract development, with a focus on mobile-
and game development and consulting.
I've signed for my first gig, which will have me working on a really
exciting project for Luma Arcade from June. Of course I'll constantly
be on the lookout for new opportunities, so if you need anything from
advergaming to corporate mobile clients (or know anyone who might) let
me know!
I've got a wide range of experience behind me, including development
on platforms ranging from PC, web and mobile (including iPhone) to PS3
and Xbox 360. Language/tech wise the list includes C++, C#, PHP, Java,
various middleware platforms and soon Flash and XNA.
In addition to development and consulting in these areas, I can offer
training as well.

That's my sales pitch for now, if you have any projects you could use
me on or just feel like donating to keep me in biscuits and tea, I'm
easily reachable on LinkedIn, Twitter, Facebook and all those great
places :)

---
Regards,
Matt

(sent from my mobile, please excuse any typos)

Posted via email from Matt's thoughts

Thursday, April 29, 2010

Flash development workflow for traditional dev teams, Part 1

I'm a fairly old-school developer, and probably a little on the obsessive compulsive side, so the (perceived) messiness of flash development always frightened me a little. Flash development (as I've always understood it) has some nasty elements that go against everything I consider 'proper' development practices:

  • Large amounts of code are essentially stored inside what should be art resources.
  • A large chunk of the project is tied up in a single file that can only have binary differences applied to it (and hence can't be safely worked on by multiple team members without an exclusive svn lock) .
  • Either programming seems largely reactionary to what the artist adds, or the artists are restricted to some obscure naming convention imposed on them by the programmers.
  • There's no clear boundary between user interface and logic layers, with the mix of layers, frames and code potentially anywhere, finding the bit of code that actually does something a pain and unit testing almost impossible.
  • There's no clear documentation system.
  • Code editing in Flash is archaic. No autoformatting, limited lookup and completion, basically it's like coding in Notepad-but notepad's text area doesn't lose focus every time you swap away to another app and back again.
Of course Flash development has some compelling properties that make writing it off completely just plain silly:
  • It gives artists incredible creative power, they can do all sorts of cool stuff without a programmer needing to be involved or writing frameworks and tools for animation, effects, etc.
  • It allows artists to see what the end product will look like at any stage-essentially providing them with unit testing that programmers take for granted.
  • It has a HUGE install base, across just about every platform and does a solid job of delivering on the "write once, run anywhere" promise (especially if you stick to older standards that are compatible with many mobile devices).
  • Chances are, there's no big download required for the user, they are very likely to already have flash installed.
  • There are tons of programmers and artists out there familiar with the toolset, so hiring for teams or finding contractors is made a lot easier.
So when a new project came along that needed to be implemented in Flash and I couldn't find any resources on Flash project management that suited my needs, it was an opportunity to set up the kind of workflow that both programmers and artists on the team could be comfortable with. What follows is a description of the results.
 
Requirements
For reference, these were my limitations:
  • Use Flash Lite 2.0 and Actionscript 2.0 (for the most part this should all apply to other versions as well though)
  • Use Adobe Creative Suite 4 (solutions that removed the actual flash tools from the workflow kind of defeated the point of having artist friendly tools)
I ended up settling on FlashDevelop as an IDE as it does a good job of implementing the code editing features missing from Flash itself.
 
Setting up the project
In FlashDevelop, create a new ActionScript 2 Flash IDE project as shown in Screenshot 1.
You can obviously change the settings to your liking.
 
In the Project view, create the folders (right click the project icon, Add->New Folder) that will house your source and output files. The FlashDevelop wiki suggests a convention of src to hold your source (in this case meaning .fla and .as files and any resources not intended for distribution) and bin for your distribution binaries. It's also worth creating your code package folders at this stage (as in Java style packages, or C++ namespaces). See Screenshot 2 for what the result should look like.
 
By default FlashDevelop uses your project root as the classpath, so this needs to be updated for the new layout. Open the Project Properties (right click the project icon in the Project view, select Properties...) and in the Classpaths tab, click Add Classpath and select your newly created src folder. After clicking Ok in the file dialog, the result should look like Screenshot 3.
 
The main flash file
Now open up Flash, create a new Flash file using whatever settings are appropriate for your project, and save it in your new src folder (directly in src, not in a subfolder). You'll want to configure the file to be exported to your bin folder. To do this open up the publish settings dialog (File->Publish Settings) and on the Formats tab, change both the Flash and HTML File values to include "..\bin\" as in Screenshot 4.
 
If you now compile and execute the flash file (Ctrl+Enter), you'll see the resulting .swf is created in your bin folder.
 
Note: for source control purposes, you can add a rule to ignore all .swf files in the bin folder, to avoid bloating your repository or having conflicts due to binary differences.
 
At this point it's a good idea to set up layers for your (two lines of) Actionscript code, frame labels and scene objects; and to set up the top level state frames for your application. Don't worry if this sounds like the 'messy' flash you've heard of, it's just to keep things well organized.
First add two new layers to the timeline (probably at the bottom of the Flash window, Right Click on the name of the automatically added Layer 1 and select Insert Layer). Now rename the layers, from top to bottom, to Actions, Labels and Objects respectively. To rename a layer, just double-click on it's existing name. Your timeline should now look something like Screenshot 5.
 
Now add the labels for your states. Open up the Properties view (most likely one of the tabs near the top-right of your Flash window). In the timeline, click on the first frame in the Labels layer and set it's Name in the Properties view to Init. You should notice a little red flag now in the timeline indicating this is a named frame. Now add another frame by right-clicking in frame 10 on the Labels layer and selecting Insert KeyFrame. Name the frame (in the Properties view) Menu. Add another keyframe at frame 20, and call it Level. Finally add another keyframe at frame 30, don't worry about naming it, it's sole purpose is to ensure your previous label is visible. Your timeline should now look like Screenshot 6.
 
You can think of these named frames as the main states your application will be in. Init will be the the frame the application starts in (and where we'll do our ActionScript magic), Menu is where the application will be advanced to once initialization is complete to allow the user to interact with a menu, and Level will be the actual game level. At a later stage you can easily add to these states.
 
The application class
Note: This is a workaround for there not being a document class in Actionscript 2. In Actionscript 3 this can apparently be done in a far less hacky way, by specifying an application class in the IDE.
 
Moving back to FlashDevelop, create a new class in your package (right-click the package, Add->New Class) called App, and set it's Base Class to MovieClip as illustrated in Screenshot 7.
 
A class template will be generated for you that includes a constructor and not much else:
 
/**
 * ...
 * @author Matt Benic
 */
class us.benic.matt.App extends MovieClip
{
       
        public function App()
        {
                
        }
        
}
 
Note: The comment block at the top of the file with the @author tag in it is Javadoc commenting. FlashDevelop has full support for Javadoc, a well established system typically used to document Java libraries. The doc generator can be found under Tools->Flash Tools->Documentation Generator..
  
 At this point if you click Check Syntax button on the toolbar your code should compile successfully. If it doesn't, make sure you set the project classpath as described earlier.
 
There should only ever be one instance of this class in existence, and it'll be useful to be able to access it from other classes in the app (no more dodgy calls to a named root document), so add very basic singleton access:
 
/**
* The main MovieClip instance.
*/
private static var instance:App;

/**
* Singleton accessor.
*/
public static function getInstance():App
{
return instance;
}
 
         
Because this class is a MovieClip subclass, Flash actually allows the main document's prototype class to be replaced with it at runtime. To take advantage of this, add a main() function that will achieve this:
 
/**
* Application entry point.
*/
public static function main(movieClip:MovieClip):Void
{
movieClip.__proto__ = App.prototype;
movieClip.init();
}
 
Because the actual MovieClip instance has already been instantiated (with the default MovieClip constructor) it's necessary to do the additional initialization in a standard method. There are tricks to force the subclassed constructor to run, but that seems a little too hacky for my liking. Here's the init method:
 
/**
* Initialize the instance.
*/
private function init():Void
{
// Set static instance
instance = this;

// Register frame event handler
this.onEnterFrame = this.onEnterFrameHandler;

// Jump to the Menu named frame
gotoAndStop("Menu");
}
 
 
In addition to setting the singleton pointer, the init method sets the document's onEnterFrame event handler and progresses the MovieClip to the Menu named frame created earlier. The onEnterFrame event fires every frame and becomes your update loop (there is no explicit render loop). For now just provide a simple implementation for the function that outputs the current frame:
 
/**
* Frame event handler.
*/
public function onEnterFrameHandler():Void
{
trace("Frame: " + instance._currentframe);
}
  
For a complete listing of the App class thus far, click here.
 
Registering the application class 
Now to actually get the App class registered and updating. Go back to Flash, click on the first frame in the Actions layer and open Flash's Actionscript editor (F9 or Window->Actions). Import your package, and call the App class's (static) main function as follows:
 
import us.benic.matt.*;
App.main(this);
 
Now if you run the Flash file, you should see "Frame: 10" repeatedly output to the Output view in Flash. Our custom handler has replaced the document's prototype with itself, grabbed a reference to it, advanced to the Menu frame and is now updating on each render. Note that despite the call to gotoAndStop in the init method, our object is still receiving updates. This is because while the timeline is stopped at that frame, the document itself is still rendering at a steady framerate, and re-entering the same frame. Any objects in this frame, however, will continue animating within their own timeline.
 
For the full project so far, click here. In the next post on this subject I'll go into how you can cleanly import MovieClips from additional Flash files for modular resource control, and associate them with classes in your framework, gaining easy access to their sub-objects.

 

Posted via email from Matt's thoughts

Monday, April 26, 2010

Flash workflow screenshots

Flash workflow screenshots

Flash workflow screenshots

Flash workflow screenshots

Flash workflow screenshots

Flash workflow screenshots

Flash workflow screenshots

Friday, April 09, 2010

Uses for an iPad in our home

A lot has been said about the iPad and whether it's worth getting or not. That discussion is irrelevant in my case right now because a) I don't have the cash handy for one and b) they're not yet easily available in SA yet (unless you count the exhorbitantly priced imports from the likes of have2have.co.za and wantitall.co.za).
That said, based on how useful Nat's netbook has become to have around the house, and what I've seen of the device's capabilities here are (some) of the ways I could see us using it at home if I could get my hands on one:
  • For videos: I'm generally opposed to the idea of a TV in the bedroom, but we've found the netbook is great for watching YouTube and other online videos. The iPad would do this as well if not better (easier navigation without trying to use the touchpad and keyboard lying down).
  • For browsing and reading news,: Again this is a role the Mini 9 (and iPhone) fills well, but I can see the iPad being even more useful in this regard, especially when browsing while watching TV.
  • For radio: I already use the Shoutcast app in combination with a portable Shox speaker to enjoy the kind of radio programming that just isn't available in SA (even if we had decent FM reception in our area). I can see Nat using the iPad for 1920's radio network, myself for Streaming Soundtracks and all sorts of other audio without me having to 'sacrifice' use of my phone.
  • As a family calendar: We use a big paper calendar in the kitchen to keep track of stuff that we need to remember, and I am a heavy Google Calendar user. I can see the iPad replacing the calendar, and allowing me to set up a shared Google Calendar that I can access from my phone-saving me from 'manual synching'. We also use a paper birthday calendar, and between fbCal and Google Calendar the iPad would replace that too.
  • As a photo frame: Some of the smartest 'docks' for the iPad I have seen are ones designed to be used as a photo frame. This allows the 'pad to be charged while displaying a slideshow of photos on the device. Power leeching aside, this would be a really nice use, particularly when we have visitors and want to just flip through photos over drinks.
  • As a shopping list: We use a whiteboard in the kitchen to note down stuff that needs replacing, then when Nat does the shopping (yes, Nat does all the shopping, she doesn't like shopping with me 'cause I question every purchase :p ) she just notes down what's on there and has a list ready to go. Between Evernote, the iPad and our phones, I can see a perfect solution-especially if Evernote introduces digital ink support for their iPad client
  • For board games: Nat and I enjoy a good game of Scrabble, Monopoly or 30 seconds, and now that review sites are getting their hands on Scrabble and proving my suspicions about the suitability of the iPad to borad- and card gaming I can just see how we'd be giving all our boardgames to charity.
  • Oh, and some work too: Nat already uses the Netbook in conjunction with her big screen and separate keyboard and mouse for all her document work. It's not a big stretch to imagine using a decent bluetooth keyboard and VGA-out with the iPad to achieve the same.
From the above, I really can see the iPad as being a really useful, ubiquitous household computer. Do you have any additional unique uses you can see it being used for in a household context?

Posted via email from Matt's thoughts

 

Copyright 2007 All Right Reserved. shine-on design by Nurudin Jauhari. and Published on Free Templates

Afrigator