The 3rd "Muriyari Flash Game Porting Project" (Murigee) 48h rapid game development contest and the Ludum Dare 48h rapid game development contest are happening at the very same time, August 28-30. Funny coincidence but also a testament to how little interaction there is between the Japanese and "Western" indies.

http://murige.blog58.fc2.com/
BABARAGEO (Ginormo Sword) and Neko Games are usually participating in this one.

It's not a problem between japan and "the west", it's a general problem, there are way too many "indie" game making competitions nowadays.
You can't take a shit behind a bush if you don't have two compos watching you behind your back.

It was but five years ago or so that I was yearning for these things to happen every weekend because they were so helpful for my skills at that time.

Nowadays my projects are all way too big, though. I might try one when I want to get back into fast prototyping.

I am in the midst of writing a haXe/Flash data pipeline and am using two techniques:

• Code generation from an external script. This would be the approach where you write one big string. It has a limitation in that if your class contains too much data, Flash will choke on it.
• Embedding binary data in the SWF and using stub classes to access it. I do the embed with swfmill.

In the past I used more XML, but XML doesn't map well to a lot of data structures. It's a document format, after all. I prefer JSON, but Flash doesn't have built in support for that, so it's slow to parse. Hence I've ended up going down the route of building binary data from JSON.

Basically expect that the more complex your game's data needs are, the more you'll have to build out a customized pipeline to support them. Doing a good job with the pipeline pays huge dividends in iteration time so it's well worth it.

http://joeberkovitz.com/blog/2008/10/15/controlling-audio-latency-in-flash-10/
http://ubuntuforums.org/archive/index.php/t-1146361.html
http://stackoverflow.com/questions/227674/latency-in-playing-short-sounds-in-flash-9-actionscript-3

Flash has high-latency audio as a rule and you cannot expect this to change any time soon. I recall reading that in older versions of Flash(like 6 or even earlier) it was timed to be quite tight and sync well with animation, but the timing mechanism was too CPU-heavy and they were asked by Microsoft to tone it down.

Also, Linux Flash is the red-headed stepchild of Flash and half the new features of Flash 10 don't seem to work on it the last time I checked.

I have a few thoughts on this subject.

I think the quantity of dialogue and its context are the most important factors. A certain subset of players will actively try to ignore dialogue until you can demonstrate otherwise that it's worthwhile to pay attention. For these moody, red-faced, hyperactive players, the only goal is to "beat the game" and that means speeding through everything as fast as possible. So before you can do anything else with the text of your story you have to win them over; they're your toughest audience.

This means that you should work hard to reinforce everything crucial to the story via multiple elements and build in a real relationship between all aspects of the game. I advocate short and snappy dialogue for most games because it supports the interests of the hyper-players, but more importantly, I think you absolutely can't just dump dialogue into a game and use that as the only source of story context.

Game writing's presentation tends to be a split between boxes of text, perhaps with a throwaway portrait, spoken dialog/voiceovers and messages played/shown during gameplay, and full on movies. I have problems with the text boxes and the movies: text doesn't mesh well with the highly visual environments of most games, and movies are just plain too expensive and time-consuming to do well. Spoken with jawflap seems to work decently well during gameplay, as do short in-game messages. But they fall short for anything decently lengthy.

That leads me to consider alternatives to the plain text box - text with other presentation methods. I think the best medium to draw from for text box alternatives is comic books: if you want to stop the game to show text, show a nice, big, impressive character portrait to go with it. Have them do something. Add some special effects on top. It doesn't have to be animated, just dynamically posed. A dynamic picture invites the player to ask "why is the character doing that?" That is a mystery that adds weight to the text and make it more important, and that will induce players to read, no matter what you've written.

Showing character actions alongside their dialog is a huge part of Phoenix Wright's presentation, though since they had a budget, they went all the way and fully animated it.

Styling text, as mentioned elsewhere in the thread, can be effective, but the things you can do with that seem pretty limited, overall. You can control pacing through the speed of text display, but you can't represent the other nuances of voice other than with melodramatic OVEREMPHASIS methods. Every little bit counts though.

Allowing dialogue to be skipped should also be mentioned as a double-edged sword; it's a valid complaint that including lengthy unskippable sequences is annoying, but the hyper-player will be encouraged by such features to skip crucial dialog and subsequently set themselves up to get stuck and frustrated later. So I would advocate "less text" before "text you can blast through."

But the main point I had going into this ramble is that the only reason we've standardized on square text boxes and tiny portraits is because old games had to use them to fit resource limitations. We should avoid them unless we're intentionally going for that look. It's much more appealing to think "graphic design" for these elements and really push how far you can go with just text, static images, and effects.

I walk about two miles every day. I go to the gym a few times a week and do some weights and the rowing machine. Rowing is pretty good all-around exercise, but I have to be in the just the right position as far as food is concerned to have a successful day training.

My own conclusion is, diet motivates exercise. If you're eating stuff that makes you feel lousy, you aren't going to want to go out and run around or think hard or do anything significant. So work on that first.

I've shifted towards a diet that tries to maximize nutrition per calorie by way of avoiding the foods that are lowest-nutrition and substituting in slightly more expensive alternatives, and that seems to work really well. Without really putting any effort into it I've got the most toned look of my life and it only impacts my exercise in that sometimes I need more energy, so I end up in the situation of preparing for calorie-intensive activity by eating a donut or something a few hours before.

[mysterious social collaboration platform]

Another CMPS80K almunus represent I was there for the first session of that class.

I would love to play your game, but I hope you'll be unoffended if I have absolutely no interest in signing up for your website. Is there any way we could just cut to the chase and get a direct download link to the game?

Yeah, I'm kinda turned off by a "login to mysterious social collaboration platform" prompt. If it's a public resource shown to a public site, it should be accessible to guests.

Edit: Let me list all the failures of advertisement, distribution, and packaging that I have had that would deter a lesser user.

• I don't have a clue what the game is about
• Registering for PersonaVita
• I had to "join" the spaceworm Vita to see the download page
• Download link is small, placed at the bottom, and not displayed as an anchor tag
• Game did not run in Win7 without turning on Compatability mode
• Game did not include PhysX DLLs or mention them as a requirement

Assume that at each step you cut your potential player base in half. That's overestimating some and underestimating others, but the long and short of it is that this is OK when you demo it in a controlled environment, but barely anyone is going to try this game the way you have gone about releasing it to the public.

Additional note for those involved in that startup: Even after registering for PersonaVita and skimming over the site and the intro video, I still have no clue what it's about or how it helps me collaborate on anything. So at the moment it's a huge fail for me. The video was, in fact, utterly worthless as it just says "this site is way awesome, there are these things called vitas, once you understand them you'll like them." Please come up with some real user stories and market those, so that I know what this thing's useful for.

(I took a few more minutes to evaluate all the features. Perhaps someday it'll have potential as a combination social network/blog/wiki/forum accretion, but right now the value proposition is just way too vague.)

Now I am going to reboot my computer so that hopefully (fingers crossed) I can actually play this game.

Edit 2: Did not work. Copied PhysX dlls into the source directory and the error changed from "failed to load PhysX" to GM's famously vague "Unexpected error occurred when running the game." I started investigating a little more to see if GMPhysics was at fault, but ultimately decided this goose chase isn't worth any more of my time.

Sorry!

Copyright 2009 James W. Hofmann.
This software is licensed under the terms of the GNU General Public License, Version 3.0.

Ludamix Editor (aka. lxedit, pronounced "lick said it") is a general-purpose tool for 2D games or game-like applications. I wrote it for my own projets, but am putting it up here with minimal support for your own use; contributions are welcomed.

lxedit contains editors for sprite metadata and for maps. The sprite metadata editor lets you associate a single image with a sprite, and set a pivot and hotpoints. The map editor uses stamped/scaled/rotated graphics, tiles for collision, and point-based entities. All data formats are in JSON for ease of editing and portability. The map editor is designed to scale well to small-to-medium-sized maps; it is not meant for extremely large or densely populated designs.

Ludamix Editor is built with Python 3.1 and PyQT4. When these dependencies are installed simply run "src/lxedit.py" to begin. The window layout is designed for 1024x768+ resolutions.

Well, it took me way longer than expected, and I slacked off on updating, but I've finally got something to release! It's not a packaged all-in-one binary, I'm afraid - it takes some effort to support that that I don't feel like going through at the moment. I'll be starting a thread in announcements as well.

[generic platform for idea expression.]

A quote from something I wrote a while ago.

To summarize a major concept that I developed earlier in the article, I observed that randomization makes the game experience more homogeneous - and therefore less varied and interesting in certain ways, because the mechanics can no longer be taken to extremes.

I should also mention game narratives here and how they interact with randomization; we've seen some ballyhooed attempts in the last few years to have computers generate narratives on the fly, remixing some preexisting elements with a combination of pseudorandom behaviors and deterministic rules to simulate the storytelling process. These attempts actually go at least as far back as 1983's Murder on the Zinderneuf, a murder mystery with a set of 16 characters, all of whom could be murderers or victims, and scripted plotlines for every combination. (This is my best guess without doing lots of research. There's some hair-splitting to be done over where the line is drawn between narrative and gameplay mechanic. Cluedo(Clue in the U.S.) is a randomized murder mystery, but it has no motives driving the narrative. And randomized games in general date back milennia, of course. )

But it's only been recently that more and more attention has been focused on making a broad simulation and letting the computer, rather than some combination of crafty design and scripting, do the "heavy lifting" that drives the narrative. Examples of the newer generation include Facade and Storytron in the academic/experimental realm, and Farcry 2 in AAA gaming. And the underlying problem with these is, I think, with the simulation having to be "broad" and not "deep" - lots of nuances and rules, vs. compact definitions that are simply computationally heavy. Things like natural language, climate patterns, geology, and biology are hard for us to tackle because of their breadth, and storytelling ranks among them. As with Roguelike games, these "sim-narratives" face the same challenge of needing to establish broad, recognizable patterns throughout the story. And they get the same problems, worked around in more-or-less the same ways; by making most situations nearly identical, and by making all plots converge to the same set of outcomes.

I think it's possible to improve on this, but just look at how long it takes to develop a Roguelike, and then multiply that by the time it takes you to write up a self-consistent, entertaining story. And then assume the quality will be worse than the story you wrote because of the homogenity problem. I can only conclude that narratives based primarily on hand-crafted scripting will give better results for the foreseeable future. A light sprinkling of simulation can go a long way, of course.

Reflecting on this now and in the current discussion, I would add that it's easy to get caught in the technical angles and say "because the state of the game/level of interactivity is different when you enter a cutscene, it is no longer related to the other part of the game." This is how I interpret mewse's original position.

The problem with that is that the game starts when you find out that it exists. The experience develops as you read more about it, see marketing materials, hear opinions of others, etc. By the time you actually boot it up you may have had your mindset shaped by any number of different sources. The smallest little thing can turn your opinions around, and for that reason you can't throw away non-interactive elements and consider interactivity alone. You are working with a generic platform for idea expression. And that means anything can be done towards the pursuit of conveying that desirable "message that breaks reality." Hence my comment on the first page that we hew closely to the loud, attention-grabbing, instant-response forms of interactivity - more subtle aims would be better supported by more subtle means.

edit: clarify

If nothing else, you should learn some Python so that you have a "benchmark" with which to compare the features of other high-level languages. It will let you learn some functional programming style(albeit not to the extent of a true FP language), non-strict OO, reflection, metaprogramming, dynamic types.... it doesn't always use the cleanest, purest, or most powerful methods available to implement these features, but it gives you enough to decide whether you want more of it via another language.

You're worried about performance, but in most cases you can do back-of-the-envelope calculations or quick benchmarks to figure out whether the implementation is too slow or too memory-intensive, and then profile your way to a fast result as you code. But as a rule of thumb, if you're comfortable with the processing power available to a ~1995 era PC running C code - slower if you process tons of object instances and lists, and faster if you use mostly library code and typed arrays - you'll never encounter a performance problem in Python that can't be solved. You can figure out what's doable just by looking at the games from 15 years ago - a lot of stuff from then is graphically constrained mostly by low-detail 3D and low-res 2D, and you have an out from those limitations via the GPU and libraries like Ogre and Pyglet.

Also, not everything you're going to write is going to go into the shipping game. Once the possibility presents itself(and it becomes a lot easier with a language like Python) you'll want to make custom tools, scripts, converters, just generally making your develop/build/test cycle easier... those things oftentimes don't require C, or if they do, it's for a key algorithm that needs micro-optimization.

[profit]

This has come up before.

But I humbly suggest that you look at the business and not at the contract, because dollars will always trump the letter of the law.

• We already know that Mochiads, as-is, is legit and not a confidence scam.
• Its leadership is likely to change hands because it's a VC-funded company and likely headed towards an IPO in the future.
• They currently use this clause to allow your game to be distributed and promoted over their systems.
• Even if they wanted to do something with your IP, it costs time/money to do so, which subtracts from their current business.

So the risk you run, at most, is that Mochiads gets new executives with the stupid idea of getting out of the "Flash game infrastructure business" and into traditional publishing. Not only is that a waste of their core competency, the result would almost certainly be a class action lawsuit from angry developers. It would be business suicide and you might stand to profit from their stupidity.

That said, under the current leadership I would expect the right decisions to be made. (I've met some of them in person. They do genuinely care about the business they're in.)

We've clearly wanted synthesized voice for some time now, given that every other asset in a game has been synthesized by this point, and usually for the purpose of expanding content.

Who says synthesized voices can't be emotional?

I play a

for that song regularly on the local arcade's ITG2. Haven't passed, but I'm getting most of the way through now

I say D9's quite a good film cause it gives you something worth talking about afterwards. That was all Shakespeare's plays needed, after all.

For instance: The high growth rate of the prawn population(1.8m to 2.5m in 3yrs). If that continues, it will end either in outright mass-murder measures or the government caving in and granting additional freedoms.

The imperfect nature of Wickus: it is his combination of hubris, selfishness, and willingness to ignore/neglect others that gets him into trouble throughout the movie; he isn't just an unwitting everyman. The bulk of the rising action of the plotline occurs because he starts fooling with something he doesn't fully understand - the fluid container, the Nigerians, the command module...

The balanced tension between the humans and prawns: at various points in the movie both sides execute a member of the other suddenly and brutally. Even though the humans are ostensibly in control, what's implied is that an all-out battle would be very costly for both sides. This makes it a bit different than the traditional oppressed ghetto scenario.

Let's think about it this way. If you want a game with fast, immediate responses to your every action, is that game also going to be able to develop a nuanced plotline? Probably not.

We're doing - at best - the storytelling of an adventure comic, only because that's all we have room for when we make games that are primarily about the down-and-dirty details of wandering around, collecting objects, solving puzzles, fighting, and blowing things up. We typecast ourselves by choosing such mechanics, and if we opt to limit that insatiable desire for immediacy, we can get something more like King of Dragon Pass or Higurashi no Naku Koro ni - very literate games with complex storytelling aspects.

(I've just spent about three months of off-and-on work trying to craft the best story possible within the limits of typical hyper-responsive shooting/exploring gameplay. From my perspective, you really can't take it very far without the pure metaphor approach.)

If I think it will take too long, I don't do it.

If I don't understand it, I do something related and smaller to learn.

Increasingly, it's the first problem, not the second. Regardless of the field or the task.

Hmm. I'm going to play devil's advocate here. I actually wish you all the best, but I recognize myself at a younger age and would like to offer mentoring-ish advice.

A multiplayer online game for your first game is going to be a very tough project(in order of toughness, typically: single-player -> local multiplayer -> online multiplayer -> MMO ), and from what I'm seeing there, your chances are low because there's too much noise - too much talk, not enough action. The fact that you are going to such lengths to document and reach out is, in fact, a huge red flag.

Just consider - how much time will be spent shooting videos and administering that forum, that could instead be spent on game-making? And having school and anything else on top will suck up enormous amounts of time. I had lots of trouble making progress at gamedev until college because my time was so fragmented and other things were stressing me, and I wish I had realized then what scale I should have been working at to make progress.

It'll be harder to make the game than to talk about it at first because you don't know the process yet, but just by spending time thinking up tasks that are related to the game(e.g. how to implement "x" feature, how to create "y" assets), and then coming up with prototypes and examples that resolve them - not even full/integrated solutions, necessarily, just demonstrations - you'll gain some understanding and momentum. Put all your attention on the basic skills and the most fundamental elements of the game, and then make something with that, even if it isn't your original plan.

Personally I developed a game where we didn't have time to prototype and test all our interacting systems before they went into the game and had to rely on 'it'll be fun when it's done'. It ranks up there as one of the most nerve racking and occasionally downright unpleasant experiences of my life. I never want to spend 3 months developing something and not even know if it's an enjoyable game until the 10 week mark.

I did this, except the space was more like 18 months. Making art, constructing levels, designing enemies, all done blind while the tools and framework were being put together by the programming team. I find it absolutely horrible, but I didn't have much choice - there wasn't going to be time to do it later. I just had to hope that it would all work out all right; that by acting like I knew what I was doing, I'd forge some sort of path that would arrive at the correct destination without too many bumps.

I hope I don't have to work like this again.

I've had to "seat of the pants" my designs four or five times now, on projects of varied scope, length, and restrictiveness. In fact, the one I'm working on now is kind of that, but kind of not. It's a game I've done twice already, but this third try is a huge scope expansion. The first game set down the basic concepts, the second experimented with said concepts(I tried to boost the scope, but really wasn't able to do it at that time), and now this one is going to take the whole thing to the next level and make a blockbuster hit; at least, that's what I'm banking on. Wish me luck But really, the more I do this kind of design work, the more comfortable I feel with it.

The thing about prototyping is that it can only prove a certain scope of ideas; once the game gets big enough, the player's experience is really a "whole is more than the sum of its parts" problem, and I think the only way you can know at that point what works is to bring the game all the way to a late-alpha/early-beta state and start picking up the pieces. It's like the difference between writing a few paragraphs of fiction writing in isolation, versus writing a whole novel.

The beauty of the larger-scale game is that it becomes a platform into which you can roll up lots and lots of ideas over a long period of time. If things go well, you can nail where you want to go, and use that as your motivator, long before the tools and tech are in place to implement any of the specifics. Even if the game's been playable for weeks or months and isn't living up to expectations, you can still come up with ideas and mechanics that turn the gameplay around in surprising ways, exploiting the existing code and data to do something new and completely unexpected.

Right now I'm enjoying the luxury of doing a slightly larger game by myself. Yes, it takes quite a while and you need a certain environment and mindset to do it. But I think the result is going to feel really solid.

You can use BitmapData.draw() to render vector animations to bitmaps. That alone will probably let you do whatever you need.

There is also DisplayObject.mask but in practice it probably won't give you the result you want:
http://www.cynergysystems.com/blogs/page/andrewtrice?entry=fun_with_masks
DisplayObject.mask cuts up a preexisting DisplayObject, but it seems to be more of a "cool effect" usage than a "gain performance" one.

Otherwise, no, I don't know of any special masking functionality. When I need to have things move over each other I either let the scenegraph do it for me or just overdraw. A warning: Flash has terrible blit performance with alpha-transparency on non-Windows platforms, and it doesn't let you do color-keyed blits either. So doing almost anything with large moving sprites is likely to destroy frame rate on Mac/Linux, but oh well.

My suggestion would be basically to take the Flash timeline approach and fit it into a regular grid. Every frame contains any number of layers, but more importantly it should be emphasized that layers on one frame are actually unrelated to layers on the other frames. It is up to the user to decide the best way to organize their layers to make sense of them.

The panel for this should avoid abstract markers at all costs. It should instead give a scrollable overview of the grid with cropped/resized thumbnails, DND, and copy-paste - and it could be here that you allow the user to visually align and organize the elements that remain constant from frame to frame, without actually giving them a "real" data relationship. All the user would need to do then is select layers horizontally adjacent to go forward and backward through the frames. If stack order changes during an animation, it is very easy to see on the grid, so long as the thumbnails get cropped and sized correctly.

With this setup there's a little bit of added effort to go between frames because the layers are considered independent of each other, but the chances of doing the wrong thing go down because the user has more organization options - if the user learns to make ample use of the grid and the tools are provided to make it convenient to do so, then it shouldn't be a problem to compose any kind of animation.

I started a partial rewrite that solves all my problems by applying some formal structure that I was forgoing before. Even with that, I still plan to have a release ready this week. I'm also going to write up a tutorial based on this experience so that anyone interested in writing tools has a starting point.