Thanks for your reply. You made several good points. Let me clarify a couple of things. First, the “attack” button and actions are just “place holders” until I decide what I want to do with the combat portion. In fact the entire Client class is just a platform for making requests. Second, changing anything in the Client for calls to the State machine does not change the State pattern, and all of your points on event handlers are quite helpful.

Where we may disagree is the role of the structure and highly specialized algorithms (or not-so-specialized algorithms). The idea of programming to the interface instead of the implementation implies flexibility in methods. So, I would think that highly specialized algorithms that implement an interface would both maintain the structure without crashing the other parts of the program. The alternative would be a delicately balanced set of algorithms strung together by conditional statements, which have their own set of issues. Changing an algorithm in a conditional based system would seem to be far more tricky to maintain and/or extend than one in a State Pattern where there are no conditional statements (outside of the Client). You could use array or vector objects for storage, but I’m not sure why. I’ve used both in State Patterns, but I did not see a use for them here.

As for a better event handler, I’m all ears. I had to cut back on anything that moved in the SimpleButton objects to improve Touch responses, but like you said, slugs move faster than AS event handlers.

So if you have the few minutes, I’d like to see your redo.

Kindest regards,
Bill

Algorithms are separate from design patterns, are they not? Games require highly optimized and often very special-purpose algorithms. But design patterns, in my understanding, are more about creating higher levels of abstraction to better conceptualize the relationships in the program in order to facilitate quicker coding.

However the downside of design patterns is that they lock down the code (meaning by setting out how objects interact using a specific pattern) it’s hard to quickly adapt the objects to use a different relationship without doing a full nuke&pave. But that’s not the real problem, a lot of the code can be taken for granted and won’t be changed, so patterns are appropriate there.

The real problem comes with efficiency. Sure, some patterns like the object pool, vectors, maps, signals and so on are great tools but high-level patterns need to be used with caution. Using design patterns for rarely executed code is fine. A game menu or inventory screen is a great place to use patterns. The main meat of the engine, the rendering code and the frame loop are not.

As for creating better code – sure, a few examples of what I’d do:

1) remove the repetition in westnow, eastnow, northnow and southnow. I don’t like pasting code. The map changing logic would be moved to another function, moveAvatar(deltaX:int, deltaY:int=0):void

The event handlers would just call a variation of moveAvatar(-1) or moveAvatar(0,1);

2) go further with no. 1 and remove all game logic from event handler functions. Imagine I have to implement a cutscene where the PC attacks an NPC. Would I have to do an attackNow(theEventIJustCreated); ? It’s my own coding practice to have event handlers call functions that do the real action. Since the event handling model in Flash is glacially slow anyway I might as well afford the luxury of decoupling. In time-critical situations I use nativesignals.

3) Use an Array or Vector for storing grids. Support for various map sizes out of the box.

I might actually go and redo this code if I have a few minutes today.

First of all, it does not matter whether the device is mobile or desktop as far as Design Patterns are concerned. Good or bad algorithms can go into good or bad structures.(See http://www.as3dp.com/2011/03/beginners-oop-design-patterns-in-actionscript-3-0-post-1-rolls-royces-in-the-junk-yard/) There’s no over-engineering going on, and if you can show me a better way to create a design for self-aware state, I’d like to see it.

Second, there’s no problem starting with a Q&D prototype. I usually do as well, and then I look to see a way that I could do it so that there’s loose binding and easy to update. Like you, I’ve pulled out Occam’s Razor when it comes to writing code for mobile.

I suppose it depends on which Real World you live in. Design Patterns were developed for Programming in the Read World where the size of the programs are big and changeable. None of us think that the limitations on these early mobile devices will be restrictive forever.

Let’s see a better way to create inter-cell movement in a grid.

Kindest regards,
Bill

While I use design patterns of all sorts in desktop and web applications I’m afraid that the role of design patterns is limited in game development. That applies double so for mobile games.

In game development the best cycle I’ve found is to first create a quick and dirty prototype – and by dirty I mean GOTO dirty, if that speeds up the workflow. Once the prototype is fun and playable comes refactoring. But since game logic is pretty convoluted and messy you never know which way you’ll want to expand the code. Maybe you’ll want to completely rewrite arrows from a vector of data objects (the C equivalent of struct) to classes that extend PhysicsTask. Sometimes proper coding practices get in the way of optimization – function calls are costly in AS3.

The important thing – you need to make it clear that what you’re doing doesn’t apply to the Real World. This kind of overengineering at the prototype level gets in the way of creating the actual fun in the game. It’s a good way to show specific design patterns on an interactive example that looks interesting but this is certainly not the way to create games, ever.

Cheers

¿Did I just get spammed en Español? ¡Ay, caramba! ¿Que pasa?

Memo….

Yeah, the OneNav class doesn’t do much for speeding things up. (I think I said as much.) The final designation does come into play at compile time, but like static objects, the CPU does not have to spend resources at run time determining the exact functions to call. So, indirectly, it saves CPU resources that would otherwise have to be expended at run time.

Kindest regards,
Bill

I had noticed the Size properties. It is clear that Adobe considers MouseEvent to be faster for the reasons noted in the snippet from their docs (above.) However, in testing the responses using SimpleButton objects using the little app in this article, it was clear that TouchEvent worked better–it was more responsive and didn’t get stuck. What did you find in testing it on a mobile device?

Thanks,
Bill

Also, there is a thing I didn’t mention, but already assumed on my first reply, if my thought is indeed true, it would also explain why even using raw touch events needs more resources than plain mouse events. Having a single hot spot means there is no denying in which object on the screen you clicked, however, having an area means you must process that area, check all the objects it intersects with, and choose which one should receive the events (if not all of them do).

This is especially true if you have ‘fat fingers’ like I do!

Cheers,
Bill