An ideal pathogen for a widespread epidemic would have several characteristics.

1. It would need to have as long a time as possible to spread. A pathogen like Ebola, that can kill inside of 48 hours, is distressing but not much of a threat for an epidemic. Pathogens with lengthier incubation periods have a better chance of spreading. The longer a disease is active in someone's system without incapacitating them, the better chance it will have to spread.

2. It would need to have a highly efficient method of infection. AIDS is only transmitted through direct exposure to blood, or sexual intercourse. Both of these are infrequent enough that it isn't difficult to take preventative measures. Most viruses are susceptible to exposure to UV radiation. They cannot survive for any length of time outside the human body. Most epidemics are caused by pathogens that can be contracted in an aerosol form. (airborne disease) Sneezing while ill can potentially infect numerous nearby individuals. Prolonged exposure to an individual carrying such a pathogen can almost guarantee infection, without any direct contact or interaction. The flu, or the common cold, are perhaps some of the best, and most persistent examples.

Made even worse with the region lockouts. Is it that hard for a company of their size to do day and date or at least within a few weeks?

To be fair, that probably isn't entirely on Nintendo's head. The common delays for Australia could be due to the approval process your government has for games. Whenever you put a government body in charge of something like this, you have to expect delays. Economic pressures will insure that an industry-regulated rating system will at least be timely. When you slather the process in red tape delays are almost inevitable.

I would consider both C# and Java to be good starting points. Both of them are Object-Oriented languages. Both of them have a degree of memory management and garbage collection. (so you don't have to deal with low-level memory management) I am very fond of OOP, and feel that it is a better methodology for learning advanced programming. Another benefit of either C# or Java is that the two languages are very similar. Learning how to program effectively in one will teach you how to program effectively in the other.

In fact, becoming independent of specific languages is one of the marks of an experienced programmer. Once you understand most of the basic principles of programming, it becomes much easier to switch between languages. Specific syntax is just a matter of practice, most modern languages feature many of the same structures. For my part, I started off learning Actionscript 3.0, and later moved over to C#, and then to Haxe. I've even dappled in a little Obj-C. If I really wanted to, moving over to Java would be fairly easy for me.

I created a Haxe class that lets the user load up graphic resources whether they are building for Flash or C++. You just feed the class the path to the file as an argument, and it does the rest. I'm one step closer to developing for Flash and the iOS concurrently.

I was experimenting yesterday with Haxe, and I succeeded in writing a class that will load up image files for both the Flash and C++ targets. Just a warning, the Haxe C++ target does not seem to like GIF files. If you're trying to develop cross-platform with Haxe, be sure that you use PNG files for your images. You can't use the same method to load images in each target. But using a class that extends the Bitmap class, and a few target conditionals, you can sidestep that issue easily.

Yeah, they had announced that they were going to be doing this at GDC. Unity is porting their runtime game engine to the Flash Player 11 using the new Molehill API. Once Flash Player 11 has been officially released, you will be able to export Unity projects to be played directly in Flash.

The Unity web player is pretty solid, but has never had the install base that the Flash player has. With this new development, Unity users won't even have to choose, they can use both.

I began work on a basic game framework for Haxe. Nothing fancy to start off with, just some basic scene management, some asset importing, and possibly a little camera control. The game I want to make with it is going to be fairly basic. I'll probably want some basic tweening as well. But I can probably either port the Greensock classes or find a Haxe-tweening class that someone has already made. I'm planning on targeting both Flash and C++ with this particular framework.

Do you mean a swf compiled using haxe or the same code compiled with nme?
I have never seen a haxe swf run slower than native as3, although its very easy to make nme choke.

No, I mean just the code compiled with NME. I got everything to run in the Flash player just fine. And it wasn't an issue of speed or performance. I was just trying to get it to do some insane acrobatics. I'm talking about using a sprite that contained multiple dynamically generated shape objects as the transparency mask for another sprite that contained multiple dynamically generated shape objects. (and all of them were animated) I was doing some crazy, complicated drawing routines, and when I tried to get it working using nme it choked.

I'm confident that a simpler program with more basic functionality would work just fine with nme. I had actually started work on another game in Flash, and it occurs to me that developing it with Haxe would be a really good idea. It isn't going to involve any advanced animations or complicated scenarios, and should probably work just fine.

One issue to be cautious of when developing using Haxe is that the C++ exporter doesn't play well with the Embed tag. If you are used to compiling resources into your swf files, you might have to learn to use the Loader instead. I've used the Loader class many times in the past, so its not a big deal for me.

No genre dies out. They just go into hibernation, until the time is right to rise again. Every genre has certain merits, it's what drives us to define them in the first place.

For my part, I still pine for my beloved point-and-click adventure games. We've gotten a bit of resurgence in recent years, largely due to Telltale games. But I've also gotten to play some Ace Attorney, Ghost Trick, Trace Memory, and Hotel Dusk. Professor Layton falls more under the umbrella of "puzzle" game, but it also has quite a few elements from point-and-click's.

In the case of my genre of choice, the cause for the decline is obvious. The growing popularity of first person shooters, along with the increasing importance of console games drove it into hiding for many years. Fortunately, the recent popularity of the DS, Wii, and iOS systems have begun to bring point-and-click adventures back into vogue.

[does]

But when it does run on multiple platforms, you shouldn't have to pay for it more than once. That was his point.

Oh yeah, I get that. But who are you going to pay? In order for the kind of system you're describing to work, whoever is managing it has to make it available on multiple hardware configurations. That is to say, they have to relinquish all control over the hardware that their games will run on. Without some level of control over the hardware, there is no way to secure the downloaded ROMs from piracy. A service like Steam would get around this, but then what about handheld hardware that isn't constantly connected to the interwebs?

Apple is able to implement a system like this for their iOS because they DO have control over their hardware. A company like Nintendo couldn't pull off a system like this. It WOULD be nice if they could at least pull it off within their own hardware families. But I wouldn't hold my breath.

At the end of the day, the sheer licencing nightmare that a ROM pay-to-download system would represent keeps it from being realized. For my part, I think the best solution would be to found an on-line video game museum, and ask companies to "donate" their games for permanent preservation. (and thus approve free distribution) Sure, companies like Nintendo probably wouldn't go for it. But I know there are quite a few companies that would probably approve of their older titles being preserved in this fashion.

Again, when I buy a game, the ability to play it on any device that supports it without having to purchase it again seems like it should be the norm. Kinda like with CDs, DVDs, VHS, cassette tapes, vinyl records etc. etc.

Well...yes and no. Since it is a digital format, it would be nice to be able to use it across devices. But unfortunately, most console games are originally designed for specific hardware configurations. This is part of the problem with Sega games available on the iOS and Android markets. Console games usually play like crap on touchscreens. They were designed for D-pad controllers, and play best on D-pad controllers. Shoehorning them onto controller-less devices just doesn't work.

Even though the software for a game can be run on any hardware powerful enough, it doesn't mean that it should. My cell phone could run just about any NES game, but I wouldn't want to play any of them on it. (tiny, clicky buttons and crappy round d-pad)

I suppose the ideal hardware for ROM emulation would be a USB controller with an HDMI port, emulators stored in permanent memory, and an SD card slot.

I believe one of the more common methods is to provide button objects with a function that they are supposed to execute whenever a specific event occurs. Some languages have a specific "event" type of function for this use. I know that C# uses the delegate system to define events. I'm not sure how this is normally addressed in C++. In AS3 there is no need for custom definitions, as that language already provides a comprehensive event system.

But I don't want to be limited to the Wii or 3DS or whatever system I purchased the re-release of a game for. ROMs are the superior choice because I can play them on a large number of different devices.

A valid argument, to be sure. I would point you to something that Rm88 just pointed out. Playing older games is somewhat spoiled when you are using inferior controllers. One of the advantages of a service like Virtual Console is the options for controllers. The Wiimote itself feels pretty good for most NES games. The classic controller is very good for both NES and SNES games. The classic controller and GameCube controllers are solid options for N64 games. PC keyboards are usable for most games, but never feel as good. And although the 360 controller could probably be used for N64 games, its D-pad has always been piss-poor and would feel terrible on NES and SNES titles. Controller flexibility and feel are a major advantage for the Virtual console.

Yes, it would be much better if someone offered a ROM service that allowed for platform independence. Unfortunately, the majority of classic games that people download ROMs for were on Nintendo systems. And Nintendo are still in the hardware platform business. Until they become platform agnostic, this attitude toward classic-gaming being tied to specific hardware will likely continue.

A company like Sega would probably be much more open to the possibility.

For any of the newer board members, Core Xii is an anarchist when it comes to intellectual property rights and software distribution. It is entirely pointless to argue, or even discuss such topics with him/her/it. Just don't bother, it is never worth it.

When it comes to ROMs, the one real line that you need to make sure you don't cross is financial profit. So long as you manage to avoid that, it is highly unlikely that you are ever going to be prosecuted. If you do turn a profit from the distribution of ROMs, then somewhere there is a record of it, and the IP holders will sick their lawyers on you with a vengeance.

This is why online distribution of ROMs has always been a bit of a grey area when it comes to legal considerations. People who distribute ROMs online for free are not actually profiting from their distribution. In fact, it could easily be argued that they are incurring an expense. (bandwidth and hosting) IP holders' usual approach is to send out Cease and Desist orders before any lawyers get directly involved, it almost never goes to court. Basically, don't sell ROMs, and no one is going to come breaking your door down.

I would still encourage you and everyone else to purchase software whenever it seems appropriate. If you have a Wii, take advantage of the Virtual Console. The emulation they use on that system is actually quite excellent. You will soon be able to purchase older games on the 3DS. Commercial re-makes and re-releases are often a good way to get at older games, including compilation packs. I have a copy of the Sonic Genesis Collection, and can recommend it. It costs $20 at most stores brand new, and has an enormous amount of great older games.

One of your better options is the Sparrow Framework. This is an Objective-C programming framework that has a display list structure that is very similar to what is used in Flash. If you can wrap your brain around a little Objective-C, it shouldn't be that difficult to port your game using Sparrow.

Another option is Cocos2D. This is another Obj-C programming framework. It is not as similar to Flash as Sparrow, but it is performance-friendly and widely used. (so more documentation and examples) Again, you will have to learn some Obj-C to get this working. It also has a few more game-centric functionality than Sparrow, notably a wrapper for a 2D physics engine.

Both Sparrow and Cocos2D are free to use, even for commercial iOS projects. If you want a more AS3-like language to use, and don't mind spending some cash, I would recommend MonoTouch. This is a port of the Mono framework for the iOS. It lets you use hardware-accelerated drawing while also giving you access to native iOS classes. (so you can use iOS's graphical interfaces and tools) It uses C# for coding. The downside is that it has no basic display list, and you would have to roll your own using OpenGL code. For some games this could be quite time consuming.

Another inexpensive, and somewhat more direct option, would be the HAXE C++ Exporter. Haxe is a custom programming language that was designed with the intention of converting projects to various other languages and platforms. It has wrappers for Flash and C++ that allow it to convert flash-centric coding over to C++ for various platforms. (including the iOS) I've actually tried this myself and managed to get it working pretty well. I stopped using it when I discovered that it would choke on some of the more advanced transparency masking that I tried to pull off. This shouldn't be a problem for most developers, I was actively attempting to produce animated transparency masks using nothing but code. Transparency masks still work using Haxe, as long as you don't try to make them as complex and dynamic as I did. The Haxe language isn't identical to AS3, but it is very, VERY similar, and porting your project using Haxe should be a walk in the park. Your only real concern should be performance testing. The Haxe language is open-source, and the C++ exporter is free to use.

In AS3 classes are defined in standard text files. One important thing to remember about AS3 classes is that the name of the text file has to correspond with the primary class defined in that text file. (as does the name of that Class's constructor) So if you are trying to write a class called "PowerGlove", you would have to name the text file that contains that class "PowerGlove.as". As a general rule of thumb, AS3 expects you to only have one class per AS3 source file. This is not strictly enforced, it is actually possible to define two classes in a single source file. But the convention is to avoid this, and it is usually not necessary anyway. If you are a beginner, stick to the 1-class per source file, it will be less confusing that way.

Packaging in AS3 is just a manner of referencing the file structure. You can have your source files stored in a series of folders, and packaging allows you to reference those folders. These folders are always relative to the source file that you are using as your entryway. (the source file you are pointing the compiler to) Package definitions are stated before class definitions, and wrap class definitions. If the class you are defining is in the same folder as your base class, just use a blank package definition.

Code:

//You would name this file "ClassName.as"
package {
public class ClassName {
public function ClassName() {
}
}
}

If your class is in a folder named "Graphics" that is in the same folder as your base class, then you would do your package definition as such...

Code:

// You would name this file "Newclass.as"
package Graphics {
public class NewClass {
public function NewClass() {
}
}
}

And you would reference this fresh class in your base class like this...

Code:

//You would name this file "BaseClass.as"
package {
import flash.display.Sprite;
import Graphics.NewClass;
/* Remember that the base class for your program always has to extend the Sprite class */
public class BaseClass extends Sprite {
private var freshObject:NewClass;
public function BaseClass() {
freshObject = new NewClass();
//Here we actually create an instance of the imported class
}
}
}

I picked up a 3DS at midnight, but didn't plug it in to start trying it until this morning. I opted for the black model, and the exterior is quite slick. I didn't buy any games last night. So this morning I just tried out some of the built in features. The Mii creator is capable. (and as fun as it was on the Wii) I had it take my picture and it got remarkably close, aside from my beard. (had to do the beard solo) The sound recorder was simple but entertaining. The 3D camera was way too much fun. I must have taken 20 pictures of my cat.

Part of the reason I didn't get any games last night was because I knew that Toys R Us was having a buy 1, get another half-off sale. I picked up Tom Clancy Ghost Recon and Pilotwings resort a little while ago. Haven't tried Ghost Recon yet, but Pilotwings seems like it will be a fun diversion. The 3D takes a little getting used to, but it works well with the flight mechanics of Pilotwings.

Game development is such a varied discipline, that there can never be one systematic approach to it. Everyone comes up with their own personal style of designing a game. This is what helps to give each game its own unique personality. The quirks of the designer SHOULD come through in the final product.

For my part, I like to follow these steps in "designing" a game.

1. Come up with an experience that I want to impart to the player
2. Figure out how to structure the game mechanics to achieve the desired experience
3. Figure out how to program the desired game mechanics
4. Figure out what artistic styles and motifs would best serve the desired experience
5. Create the art based on the desired styles
6. Figure out what music and sound effects would best sere the desired experience
7. Produce and compose music and sound effects
8. Stick a fork in it, its done.

Ultimately, I feel that everything should boil down to the player's experience, and all elements should serve that goal.

I'm just amazed at how fast the project is growing thanks to these API/softwares!

Yeah, Flixel is a pretty easy API to start working with. One of its biggest advantages is the number of capable example projects that it has available. You always have working methods to look to when trying to figure features out. And SFXR makes sound effect creation quick and easy.

I managed to cook up a Viewport system for my OpenTK game framework. I was originally planning on developing a full camera manipulation system Framebuffer Objects. And I did actually produce a working prototype for that. But I decided that it would be faster and more performance-friendly to create a Viewport system instead. I'm still ironing out a few wrinkles, but I think its going to work well.

It's called "nostalgia".

Yes, but there are plenty of new games that actually play off of existing nostalgia. Marvel Vs. Capcom 3 is an obvious recent example. The gameplay and tone are very reminiscent of Marvel Vs. Capcom 2. Ditto for any of the New Super Mario Bros. games. Last years Donkey Kong Country Returns would be another fine example. As would Punch-Out for the Wii. These are all recently released games that cater directly to nostalgia, often with brilliant execution.

Just because you have a soft spot for nostalgia doesn't mean that you need to turn your nose up at anything fresh on the market. There are plenty of recent titles that can scratch that itch.