Experiment: Building a Flash client in less than 2 hours

I finally unwrapped my copy of Flash and decided it was time to experiment a bit.

Using javascript for Golemizer allowed me to ship the game after a year of development but wasn't of great help for marketing purpose. Most portals and review blogs/websites are focusing on Flash games. Golemizer could have fit some of them but since it's not in the Flash category, it complicates things a bit (it's true that most of these websites will concentrate on casual games but a lot also includes multiplayer games and I've seen Sherwood Dungeon embedded quite often). In the end, a lot of them won't just bother with the game since it's just not made in Flash.

Javascript seems to fit better the PBBG market which doesn't have the same access to visibility (mostly through voting websites but reaching the top takes a lot of votes and to get votes you need visibility which you don't have because you're not at the top of the list...).

Point taken: go where the crowd is. You need to make it easy for them. Don't assume that because your game is "oh so great" that people will come by themselves. You need to go at them and they currently are around Flash games. So Flash it will be for the next project.

So after some research, I finally found two samples that helped me. The first links Flash to a web service and the second is used to read JSON data (used by the web service). Both are using free third party libraries since it seems that Flash thought it would be a good idea to not provide any support for web services in their last version. Go figure...

Using these two samples, I had a basic Flash chat client linked to Golemizer's code less than two hours later. It feels good to know you were right to take some design decisions in the past :-). I changed absolutely nothing to Golemizer's code and the Flash client is actually quite simple.

The only functions from the web service I'm using are:
- doLogin
- sendMessage
- getChat

These commands are pretty much the only one needed to build an interface for Golemizer (add getEvents and you're set). Once you have those, you just need to deal with the data you're receiving from the web service.

So I don't see anything but a chat box but since Golemizer is only using /commands for every actions (move, craft, attack, ...), I can roam the world in text mode calling the function sendMessage("/somecommand with paramaters").

/teleport dock *poof*, the server change the location of my character and I can see what players are saying at the dock. /do 54 and *poof*, I just started a crafting process for a table. /addpart 3465 *poof* I just added some wood to the crafting process. /mute "bad player" *poof*, just muted someone. /smile *poof*, I just sent an emote. I'll stop there cause I could go on all day like that ;-)

So, when will we see a Flash interface for Golemizer? Not yet. I'll first experiment this with the next project (that 90% of mechanics are already coded, it is much more simpler than Golemizer). If I'm satisfied with the final result of this game I might then build a new interface for Golemizer. From what I'm seeing so far, with appropriate time, this shouldn't be so difficult to code.

edit: here's the libraries I used

For JSON it's as3corelib
http://code.google.com/p/as3corelib/

And for web services
http://code.google.com/p/as3webservice/
http://www.wellconsidered.be/as3-webservice-component/

Read More......

Native JSON support coming to your browser!

Finally! This will greatly improve client performance for Golemizer (and next project not yet ready to talk about)!

Communication between your browser and Golemizer's server is done using a web service sending JSON data. To parse the data received in JSON format, the javascript function eval() is used. Native support of JSON will make the parsing of this data much faster than using the eval() function (without talking about other disadvantages but eval() was still faster than a custom built json parser).

Less client-side lag!

Source:
http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/
http://ajaxian.com/archives/native-json-in-firefox-31-joins-ie-8

Read More......

Fitting Golemizer in a 730x510 or 840x700 area

If anyone have ideas or can help...

In my quest to reach a larger audience, I need to figure a way to create an alternative interface of a smaller size. The point is to be able to submit the game to game portals so they can show Golemizer on their own website (without any pop-up). Not being a Flash game makes it harder to convince portals to put the game on their website so I need to make it easier for them.

The ideal size to reach would be 730x510 pixels which is beginning to be a little small but also seems to be a size that most website can host.

The size 840x700 pixels is probably a more realistic target though can still be a bit large. This is the size at which Runescape appears on kongregate.com. Anyway, that would be better than nothing.

The currrent size of the game is 1020x730 pixels.

Some parts of the "play zone" would have to be cut. It would have to work a bit like Starcraft (move mouse to borders to scroll to area not seen). Other than that, it would remain the same. I already have a prototype for this and it seems to be working fine.

Everything at the bottom of the "play zone" would required to be changed. I'm not really good at interface design so if anyone have ideas... Many things can be done. Tabs can be added, scrolling areas, multiple toolbars that can be scrolled (think toolbars in WoW) and so on. While being at it, things like buttons, the wooden border and colors could also change.

You can check the following website to get a clue of what can be done: http://scripteka.com/

Anyone can help? I'll probably post an ad to look for an artist if it can be done on small budget. If anyone know an artist that you think would be able to do a sketch, please let me know.

You can check Golemizer here: http://www.golemizer.com

Read More......

Character's creation and login screenshots

Those are actual screenshots from the test version (click to zoom). I'm in no way a graphic artist but I kinda like how this came up (credits goes to Lost Garden for the wood and Charas Project for the avatars).

So this means that I'm now starting to set what will be the final look of the game. At this stage, pretty much all systems are in and stable and now it's time for yet another testing pass, then IE compatibility checks, optimization and finally building the actual game (world, skills, lore, ...).

Still a lot of work but it's getting closer to release each day.

Read More......

Movement: Arrows VS point and click

From the start movement has been handle by keyboard arrows. I'm not really a fan of point and click movement in 3d games and my model was SWG. Move with arrows and click on skills located in the toolbar.

I never really looked back until yesterday when I was messing around in my 2 zones world.

If your gentle with the keyboard, the actual system works just fine. However, when you start doing fancy maneuvers (long run, switching direction really fast), the results are unpredictable.

It's true that it's been a long time since I worked on movement and that I'm now at that point of checking back everything but the technical limits of javascript and browsers might bring some problems.

When an arrow is pressed, a message is sent to the server, the event listener for keys is detached from the browser and is reattached half a second later. The listener is detached because constant key pressed brings some heavy loop that the browser have some difficulties to handle.

While the /move action is sent to the server, others /move action can be receive from it to show movement of the character on the screen. Between each /move action received, an animation process takes place to animate the character going from point A to point B.

As you can see, a lot of things are happening to move a character and synchronizing all of this can become quite difficult (and I'm not even talking of what happens if the client computer slows down). The character on the screen might not be at the exact real location with the result of the player holding too long the arrows and then the character moving 1 or 2 square too far from the desired location.

Like I said, all of this is not a problem is you're gentle with your keyboard... but I don't expect players to be (or the right thing to say would be I can't ask players to be). Now the question I'm really not sure to know the answer right now is "Will I be able to make the movement process more stable the way it is currently handled?".

There's probably some tricks I'm missing or maybe those tricks would be a bit difficult if not impossible to do in javascript. So that brought me to think about point and click movement.

First, a lot less signals would be sent to the server. To move 10 squares left, only one click would be needed compared to 10 /move commands with the keyboard.

Second, the ending position would really be for sure the desired position. No more "oops, I hold too long the arrow while the interface was trying to catch up".

So far it's all good. The downside is that more work on the server is needed to calculate character's position when a movement is asked (well, a new coordinate to go to is sent). I don't see this as a great problem but there's surely a small challenge there.

With arrows movement, the server is dumb. It only check if movement is allowed in this direction. With point and click, it needs to calculate all coordinates the character needs to hit in order to get to the desired location. I could do this in two ways.

The first would consist of going in straight lines. Player clicks on the interface, character try to go in this direction, if there is an obstacle it stops. The player then have to click somewhere else to get around the obstacle.

The other way is to use what the NPCs' AI is using: path finding. The code is already done for NPCs so I could easily use it for PCs as well. Player clicks on the screen, coordinate is sent to the server, server calculate best path to reach the destination, movements are sent back to clients one after another with the correct downtime between each movement (so the animation match the real location of the character) and if an obstacle is met, the character will go around without the need for the player to click elsewhere.

The main (only?) problem I see with the latest is that characters might sometimes go to places players didn't expected to reach the destination. Of course, the player would be able to change it's course by clicking elsewhere, sending a new destination coordinate to the server while the previous path to be sent is dumped.

What impact this would have on the interface? It's probably a bit early to know exactly since the toolbar isn't yet implemented. For now I'll probable just add it anyway while keeping the old method not too far and alpha testing should shine some light on this.

Anyone have some comments on this? Any links to keyboard VS mouse articles?

Read More......

Getting a responsive interface

Now that one was a nice challenge. In the first 3 demos, you might notice that movements of avatars were done one after the other and not in a fluid way. Of course, it was ok for the prototype but it was clear it would be unacceptable for the final interface.

After 4 days of pulling my hairs, I finally got it.

My first shot was to lock the keyboard while movement was processing. What I mean is that when a move event was received, the interface couldn't send more /move commands to the server until the animation was done. You need to remember that avatars are moving inside a grid and there's no "free" movements here. So when you move your avatar, you're moving from one cell to another.

Of course, this first shot gave strange results. The avatars were lagging and strangely, I had some difficulties to reset the keyboard state (well, the keypress event) to allow back movements. Anyway, it gave me some weird looking code so I knew I was off track.

After I tried to separate client movement from server events, meaning that a player's avatar movements were handled only by the client while events were sent to server for other players to see. Again, that wasn't a good approach. I ended up with the avatar not showing where it should really be on the server and again weird code for synchronizing events sent with movement on the client. That and all my collision logic was thrown out the window this way (to prevent the current avatar to walk over buildings and such).

Finally, it came to me. All events really need to be raised by the server (as movement) to make sure that what is seen is really what is on the server (assuming there's no lag). Any avatar (current player included) should really only move when the server allow it. And an event sent to the server should really not be aware of what's happening on the screen. The delay between each moves is handled on the server anyway.

So now, each events received are added to an array of events linked to an avatar. Then each avatar has its own thread looking for events inside its array. If an event is available, it is executed and the loop is on hold to prevent 2 events being shown at the same time on screen. This way, I've been able to get fluid avatar movement while a key is hold.

All of this seems pretty trivial now that it's working but I had a hard time figuring out the good way of doing it. Now, I need to do some heavy cleaning on this code and will probably have to tweak some interval values for the loops.

The demo will have to wait since I want to have at least what I had in the last one before showing it. One's thing sure now, things are really getting exciting!

Read More......

When to do the boring stuff

In every project, there's always some part that are just not that exciting. Some people like to get it done first to keep the icing for the end. Me, I say "do it when it's needed whatever it's fun or not". Well, I just "finished" the login/create account/forgot password system...

I've done more "login interface" than I can count. Each time I tell myself "Great, I'll use this in every other projects". Unfortunately, this is rarely the case. There's always some different twists, different needs and while you could probably come with some generic module to start, sometimes it's just easier to start from scratch. Some might say it's my design skills that are just terrible but if I take a look back at what I've been working on, I don't feel ashamed.

So the work on the interface is started and it's probably be as much job as doing the server side. That's ok, I'm gonna learn a lot. That will be the first time I'll use that much things like Script.aculo.us and Prototype and it will be just exciting to see what will become the "final product" evolving.

Read More......