Miguel's Dreams Factory

More Fun Shots

2011-10-11T14:24:00.000-07:00

I'm pretty excited as my graphic artist is now finished with most of the tileset work and now it's time to do backgrounds and monsters!

Slowly but surely, the story seems to progressing. I know have tons of ideas for little quests, it's just a matter of implementing them and herding the player through the global story.

Anyway, here's some more screenshots.

Fun Shot - #?

2011-09-09T23:10:00.000-07:00

Hi All,

Working on adding static background images to the game.
Because I used OpenGL, scaling came free!
Here's some snapshots.

The Art of Storytelling

2011-06-02T19:42:00.000-07:00

It's been a while since my last post and that's mostly because I've been working a full time job.
I thank God that I got this sweet gig as a mobile app developer.
This gives me the chance to learn and develop for iPhone/iPad and BlackBerry. Which means more potential clients for the game.
That, however, is in the distant future. I've still got to get the Android release out there.
What's even better is that the job doesn't require insane hours. I've still got plenty of time to work on SolomonRPG.

So, toward the goal of releasing the first version, I've slowed down development of the game engine and am now focusing on the art and storyline. This doesn't mean the engine has stalled, I just feel that it's at a point where it's good enough and has enough features that I can start concentrating on other critical aspects of the game.

Believe it or not the programming is not the most important aspect of a game.
At least for what I've had in mind since the beginning.
I really hate many of the MMORPGs out there for a few reasons.
For example, Pocket Legends, has great gameplay and graphics but I have no idea what the story is.
Granted I've only seriously played it for a few days. There is no insentive to play beside just leveling up and collecting items.
What's even worse is how you can actually buy items and powers using real money.
I hate this. It cheapens the game and feels like a sell-out move.
Another thing is the story, or lack of story.

What I love about RPGs are the stories. I remember the good old days when I played the greats. Breathe of Fire, Chronno Trigger, YS 1&2, Secret of Mana, Zelda, Final Fantasy, etc.

These games ruled in the story telling aspect. They introduced characters and story lines that progressed and changed, climaxed and concluded. Some of the characters would even die.
Now in most modern MMORPGs this notion is gone. They are not true to their ancestors and have become nothing more than a cheap quest fill system to make some quick cash without actually making a game.

I'm not saying that I think the story line that SolomonRPG has is any better. In fact, it might be worse because I'm not a professional writer. I haven't written a story for a long time

I'm saying it is a unique challenge to have a few races/classes and develop stories around them.
These stories have to be cohesive to build/narrate the story of the virtual world. They have to drive to a point and a conclusion. There is drama and conflict in the middle.

At the same time, you must keep in mind the constraints of the virtual world.
For example, the engine was designed to use a magic battle system. So you have to give a good background/narrative has to how or why the characters are able to use magic.
You have to motivate them to continue to level up and interact with the virtual world.
You also have to keep it simple enough where casual users don't have to read through tons of text to be able to pick up the game and play.

These and other factors make story telling challenging. These are the types of questions that forced me to really examine the story:

What am I doing here?
What is my goal? What is my history?
Why is this town here, why are the other towns there?
Why are those monsters there? Where did they come from?
Why do I have to fight them? Why do they fight?
Why should I do a quest?

Furthermore, the idea of having to write a bunch of brain-dead short quests that don't really tie into anything was not acceptable.

Back to the things I hate about most MMORPGs. You may have noticed that in the Android market you'll see that most MMORPGs are crappy website type 'games' that don't even have any moving graphics. You click on a button and you see some text change. Boring!
To top it off these games don't offer anything in terms of story telling either.
They usually consist of the same old: Go here, get me X of these, and I'll reward you with this.

This is why I never play World of Warcraft, what's the point?
I don't care about the characters, and I don't care about leveling up for the sake of leveling up.
I guess the only real motivation there is the end-game. Where you can battle against other players and do party raids. That's the real fun in leveling up.

SolomonRPG doesn't have a raid system, or even PvP yet. So, I had to come up with a concept that'll motivate players to co-operate and level up. To continue playing toward something.
However, in there lies yet another issue. What to do once the story 'ends'?
I guess at some point I'll have to implement PvP and raiding of a king.

This is the reason I have been so quiet for the past few months.
This adds yet another challenge to making SolomonRPG possible.

In the coming months I'll keep you updated on any progress I make.
So far I have the world story premise but I'll hold off on telling it for now until I polish it a bit more.
I'm also in the progress of making character lists and dialog for each one.
Creating an end-story that will be where all the sub-plots lead to.

These are all new aspects for me, but thankfully God's been giving me the chance to meet some really smart people who have helped give me tips and advice on how I should tackle this.

Anyway, for now I'll just post some random art for the game. These are all still concepts.
Wish me luck, and don't forget: Jesus is King!

P.S.
Here are some snapshots of some of the custom art and maps that I've gathered so far.
None of this is final, in the end I'll probably use tons of pixel art for the old school feel.
Also, thanks a bunch to Kinou Games for being awesome. They've done a bunch of custom tilesets and character sets. They've also been helping me with the art style and map concepts. All in all, I HIGHLY recommend them for anyone who needs good game art at decent prices.
(The first hand drawing is by a personal friend of mine.)

Android: Canvas Frame by Frame Animation Tutorial

2011-01-12T16:24:00.000-08:00

In this tutorial I will outline how to play an animation on a canvas on Android.

As you may already know, the canvas is the standard way of drawing on Android.

Drawing to a canvas is fairly straightforward. You typically extend a View class and override the onDraw method.

In this case we will override ImageView for the sake of simplicity.

I will be using Eclipse for this tutorial.

First, create a new Android project with Eclipse. You can use 1.5 as the target. I've named the application animationtest.

Also, make sure you create a default activity, I call mine 'DefaultActivity.'

The package name I'll be using is com.solrpg.animationtest.

After you have created your Android project, create a new class named MyAnimationView.

This class will extend ImageView and we'll do our drawing here.

MyAnimationView.java: http://github.com/therevoltingx/android_animation_test/blob/master/src/com/solrpg/animationtest/MyAnimationView.java

Now, your view is ready to use. Because DefaultActivity simply sets the activity layout to R.layout.main we'll need to modify it.

So, open up res/layout/main.xml and remove the TextView entry and replace it with your custom view using this xml: http://github.com/therevoltingx/android_animation_test/blob/master/res/layout/main.xml

Now we're ready to display our animation. I have prepared a set of png images from a gif.

You can see the original gif here: http://solrpg.com/resources/attacks/2/2.gif

Then I imported them into res/drawables/ naming them shark_0.png shark_1.png shark_2.png and so on.

Where each number is the frame, all together this animation is 16 frames.

Now it's time to go back to MyAnimationView and add our animation code. Basically, android calls onDraw every time the view needs to be drawn.

Typically this only happens once when the activity view is being set up.

After that, we have to call invalidate() on the view to have Android call onDraw().

First, we have to load the resource drawables into an array of bitmaps which can be drawn on the canvas.

So, we add a loadAnimation() method to MyAnimationView. This method simply loads the frames from the res/drawables/ folder into a list of bitmaps.

In the example, we load the bitmaps when the default activity is created.

Once all the bitmaps are loaded, the animation is ready to be drawn.

Now, back to our onDraw method.

First we have two private state variables called mIsPlaying and mStartPlaying.

Every time onDraw is called we check wether either one of these is set and draw the bitmap frame accordingly.

In order to start an animation we simply set mStartPlaying to true and call invalide() to have Android call onDraw().

When an animation is playing the variable mIsPlaying is set to true it checks which frame it has to draw.

In order to know which frame to play we need two variables play_frame and last_tick.

play_frame is set to the frame index of the animation that we're about to draw.

last_tick is set to a system time stamp. This time stamp is set every time a frame changes.

This lets us calculate how long the current frame has been drawing.

Once a specified amount of time has passed it increases the play_frame counter and calls invalidate()

Now you're ready to draw the animation. We add a method called playAnimation() which simply sets mStartPlaying to true, then it calls invalidate().

In the tutorial application I added a button that when pressed calls playAnimation().

That's it! Drawing an animation this way is fairly easy, I hope someone finds this helpful.

Project link: http://github.com/therevoltingx/android_animation_test

A Holiday Release - SolomonRPG:Alpha 0.3

2010-12-19T11:58:00.000-08:00

SIGN UP NOW - ALPHA

Download the client: SolomonRPG.apk

Signup here: http://solrpg.com

OVERVIEW

It's been a few months since I last made a release.
With the restlessness of the holidays, and finally achieving some sort of stability I've decided to make another alpha test release.
Here's a breakdown of the issues and notices for this release:

HOSTING
Because I am unemployed at the moment, I can't afford to keep my linode running without any sort of income. I've gone ahead and shutdown the previous Linode I had setup so I don't waste money.
As with the previous release, I'm hosting the server on my home server so things will be noticeably slow.
I've made the http://solrpg.com point to my home server as well. Because I'm sort of at a feature freeze I hope that I won't be messing with the server that much.

ANDROID CLIENT
I've gone ahead and spent some time polishing the client code. Making sure it'll work in various resolutions and just polishing up the lifecycle of the application. I've tested it on a few G1s running Android 1.5 and Android 2.2 and it works just fine. I also tested it in the emulator with larger screens and it seemed to work just fine although it's unusably slow in the emulator.

ERLANG SERVER

This whole project has been centered around learning Erlang. These past few days I took the time to learn about the Erlang OTP application setup. Creating an .app file, bootstrapping the application when the VM starts, creating a proper application supervisor, and updating the various sub servers to die and restart more gracefully. I also added things like database connection pooling. This was very fun and I learned a lot about the Erlang ecosystem.

SCRIPTING SERVER

I finally added the concept of switches and created my first real 'quest'. A switch, can hold any given value. Anything from a string, to a boolean, to an integer, or float. Each switch is defined by a name, and needs to be defined with an NPC. Once it's defined, you can use it globally in other events. Here's how my first quest looks like. This is real game scripting code:

Generic person NPC:

importPackage(com.solrpg.solomon_scripting)

var PENDANT_SWITCH = 'village_pendant_quest';

Solomon.defineSwitch(PENDANT_SWITCH);

if (Solomon.getSwitch(PENDANT_SWITCH))

{

Solomon.message("Thanks!");

}

else

{

describeQuest();

}

function describeQuest()

{

var MessageStr = "Hey, if you find a pendant in the forest, please bring it to me. \

My mother gave it to me, and it's not of much value, but I'd be happy to pay a \

small reward for it.";

Solomon.message(MessageStr);

}

Dropped pendant NPC:

importPackage(com.solrpg.solomon_scripting)

var PENDANT_SWITCH = 'village_pendant_quest';

Solomon.defineSwitch(PENDANT_SWITCH);

if (Solomon.getSwitch(PENDANT_SWITCH))

{

Solomon.message("It's empty.");

}

else

{

Solomon.setSwitch(PENDANT_SWITCH, true);

Solomon.message("You've found a pendant");

}

I've also added support for catching errors and when the script fails to load. A message is simply sent to the player, so the creator has to make sure there are no mistakes in the scripting code by constantly testing them in the client.

The Future

Certainly the most time consuming aspect of the game seems to be the story development and map making. My girlfriend is helping me create maps for the games and she's really good at it, so that's a load off for me. Now I'm just concentrating on coming up stories, making maps, fixing bugs, and stabilizing all the features.

However, there are a couple of features I'd like to implement sometime next year:

HTML Tileset Editor
NPC Auto Walking
Compress data sent over network

None of these features are critical to the game. The NPC autowalking is something I'd like to see soon. Right now all you see are moving water, moving players, but I'd like to have the option for the NPCs to move as well.

Compressions of data is sort of important, this is actually just needed at a couple of critical points. When teleporting from area to area and when first logging in. Not a priority.

There are also plenty of lesser features I have to implement before releasing the game, but those are the big ones

WORKING ON NOW

Mainly just brainstorming with my girlfriend on the world map. She's making the maps on RMXP and then I select whichever tiles she used and compact the tilesets and import them into the game.

I'm also polishing the battle system.

I also had to implement leveling curves which was pretty fun.

Basically, it's a way to keep track of how many experience points are needed to get a certain level.

Each class has the following attributes:

level, exp, hp, mp, attack, defense, speed, and critical_hit_chance.

Each class has a certain algorithm to calculate how many exp points are needed to reach a certain level and what to set the attributes to when the player reaches those levels.

Then I used a jQuery chart library to generate some tables to visualize it better.

I still have a bunch of story related work to do, here's my TODO list for the release:

Full concurrent world map
4 races with full story lines
All races and content up to level 20
Monster and monster parties for all world areas
Integrated multiplayer communication and party management
Fully working multiplayer battle system with stats
SOLRPG.COM -
Full documentation of game overview and gameplay
Fully working site with minimal feature set, doesn't have to be perfect

SCREENSHOTS

The Erlang Game Loop

2010-11-20T14:41:00.000-08:00

After my last blog post I took the time to signup for Linode and setup my application there.
After running a few tests it was apparent my initial game loop was flawed.
Even with the beefy hardware the erlang beam process was hitting 300% after around 50 areas.

My initial approach to the game loop was a bit naive.
When loading each area I would spawn an erlang process with a game loop that would grab all the players in that area and process any new move flags, pathfinding, checking collisions, updating character positions, etc.

I figured that even though this was CPU intensive it shouldn't be too much of a problem. I was wrong.

However, if you pay attention you'll notice I can easily improve this by having a global game loop, and processing all the players regardless of their area.

So, the old was was something like this in pseudo-code:

foreach (areas)

     load_layout_into_memory()

     bootstrap_ets_tables() 

     start_game_loop(area_id)

end

It took me no longer than 30 minutes to update the code. Now it looks like this:

foreach (areas)

    load_layout_into_memory()

    bootstrap_ets_tables()

end

start_global_game_loop()

I then ran some tests on my Linode, first I had to set my ERL_MAX_ETS_TABLES to 7000.
I was able to load over 3000 areas with the beam process hovering around 10%. Great!

It now seems like SolomonRPG should handle well for a good while. There are a few things that need to be smoothed out, but for the most part everything seems to work.
With all these areas the only issue is now running out of memory but Linode has some good plans for adding more memory. And although I haven't done much testing, thanks to Erlang, I think I can just add more nodes and have them process sets of players.
For example, have node1 process players 1 - 1000, node2 1001 - 2000, node 3....
Or perhaps separate them by area. Either way should be easy to implement, damn Erlang rocks.

On The Road to Release - Part: 1

2010-11-19T02:30:00.000-08:00

After having ported the map editor to HTML and Javascript, I also took the time to setup a domain and implement the player's website.

The final url for the game is: solrpg.com

There is still a lot of work to do, though, before I release the client in the Android Market and enable signups.
Here's a breakdown of what's needed or being worked on.

For reference, here is the hardware I'm developing the SolomonRPG server on:

1 Core CPU - AMD Duron(tm) 1.2GHz

1GB -  DDR RAM

80GB - PATA Hard Drive

Cent OS 5 - x86

Hosting - Linode
At the moment, the domain is hosted on my only spare computer at home.
Obviously, I can't release the game because my upload speed is pathetic.

Linode has a hosting plan that starts at $20 a month. I've been hearing good things about them, and I'm excited to try them out.
Here's what the basic hosting plan includes:

4 Core CPU - Intel(R) Xeon(R) CPU L5420 @ 2.50GHz

512MB - RAM

16GB - Hard Drive

Cent OS 5 x86_64

The Solomon server holds a lot of small bits in memory ram, such as player credential, player location, status, tileset layouts, etc.
Simply storing a player and area definitions in memory can be a scaling issue
However, from preliminary tests reveal the real wall seems to be the game loop for each area.

Each area has a process that handles all the game logic for that area. Each game loop runs at a variable 60FPS.
This is fairly CPU intensive, and my development machine starts giving out at barely 20 areas.

At the moment, I'm not sure if I can optimize this. Perhaps by having a game loop for each Erlang node and try to squeeze the game logic there, but I haven't given it much thought.
I want to do some tests on the Linode host itself to see if its worth my time to optimize.

Content Creation
The fun part is creating content for the game. Creating tilesets using Gimp and constantly testing them out and choosing which tiles to use.
I have choose carefully because tilesets have to be as small as possible. The bigger the tileset, the longer it takes to load in a mobile phone.

Mapping out areas is also quite fun, I have to first map out the world on grid paper with a pencil.
Then, mapping out each area using the new editor.

Story making is another challenging aspect. For that, I'm turning to my favorite book in the world, The Bible. In the coming months, I hope to continue carefully reading the Bible and implementing some of the cool stories into the game. I want people to know that I'm Christian and that God was the only one who helped me make this game, I never would have been able to get this far by myself.

Polish, Polish, Polish
Continue to refine the SolomonRPG codebase and try to fix as many bugs as possible.
Make the client not drain the phone battery.
Lower the SolomonRPG CPU requirements.
Implement scripting in Erlang using erlang_js (MAYBE)
Make teleporting from area to area as smooth as possible.

Funds and Revenue
If I am unable to lower the CPU requirements, it'll be very expensive to release the website for the game. Ideally, I'd like players to create as many areas as they'd like for free.
I will have advertisement in both the client and the website, but I'm not sure if it'll be enough.
I don't have a budget for the game at all, and I'm trying to save up enough to sign up for the Android Market and the first month of hosting. Anyway, I'm thinking of adding a donation button to the blog. We'll see though.

New Puppy!!

2010-10-20T00:24:00.000-07:00

For the longest I've been wanting a dog. Finally, this weekend I went down to the animal shelter and picked up a Staffordshire mix. Here are some pictures, it's sooo awesome!

Player Map Making in the Browser

2010-10-13T02:53:00.000-07:00

After spending some time creating maps and thinking about story telling, quest designing, and map making I've decided to move the map making process to the browser.

For one, it'll help speed up the flow of the development of content for the game.
I've decided to use jQuery for this.

Since the beginning I've thought about the ability of players to be able to create the story and world around them. The infrastructure was set up with the thought in the back of my head.

So, now that I've decided to port the map maker to a web interface I've also decided to add the ability for players to make the world.

Here's a break down of this new feature-set:

== Player Web Interface + Web Map Maker ==

Each player has a login to the web interface.

One can create maps using existing tilesets.

In each map one can create events/npcs.

Npcs are javascript driven.

World is empty except for current areas

Player creates account either in web or in client (pre-allocates X scripting switches)

Player can then create areas.

Set Name, Select a tileset. Width and height are 20x20.

Area Settings:

Name

Troops (if empty, non-battle area)

Encounter Rate

The area is automatically added to the system.

Player can add event and script them as necessary

Regular players cannot modify stats.

Only an admin can link the outside world to you.

You can ask to be teleport into your created areas. When done you can ask to be returned to your previous position.

Needed Features:

Upload character sets. (OPTIONAL)

Create item

For fast scripting:

A list of switches (filter by 'created_by_you', 'system_switches')

A list of items (filter by 'created_by you', 'system_generic_items', 'created_by_others'

Areas must be able to be deleted!!!

Scripting (Pseudo-code):

/*********************************************************************************************************************/

//Merch Area Trader - 10x Small Wolf Claw Quest

//Go to the forest, collect 10 wolf claws and come back and i'll give you a red pin

if (checkSwitch(25)) //quest_finished_yn

{

//player already finished this quest

message("Hey, how u liking that pin?");

return;

}

if (checkSwitch(24)) //10x wolf claw quest

{

//player has accepted this quest, check the status...

var nWolfClaws = getItemCount(1005); //number of walf claws collected

if (nWolfClaws >= 10) //small wolf claw

{

//the player has collected the necessary amount of claws...

setSwitch(25, true); //quest_finished_yn

addItem(1006, 1); //add 1 red pin item, created by me

message("Well done! You've earned this pin!");

return;

}

else

{

//player has NOT accepted this quest...

message("Man I need me some wolf claws, go fetch me 10 claws and I'll give you this shiny ribbon!");

var response = choice("Do you accept this quest");

if (response == true)

{

//player has accepted the quest....

setSwitch(24, 10); //10x_wolf_quest

message("Great! Good luck!");

return;

}

else

{

//player didn't accept the quest...

message("Fine then...");

return;

}

/*********************************************************************************************************************/

I want to make map making as easy as possible. Event/NPC making will be way more difficult. It'll be scripting based. The cool thing is you should be able to create areas, modify, and test them using the master server with the android client. Once approved these areas can become part of the larger world and story.

The scripting will be very RM2K/RMXP inspired and powered by Javascript, so hopefully it'll be easy to use. I'm guessing the most challenging aspects will be the new territory such as scripting in a multiplayer context.

With this detour there is going to be a significant delay in the release of the game, however there should be no reason this can't be achieved in a reasonable amount of time.

I'd be interested to hear any thoughts on this!

Update:
Here's some snapshots of the work in progress:

FunShot, Making Maps

2010-10-11T11:07:00.000-07:00

For the next few months or so I'll mainly be working on adding some content to the game.
Mainly making tilesets, prototyping the maps in RPG Maker XP, creating the maps in my own custom editor.
After that I have to work on adding quests and adding more features to the scripting system for this.
Getting close to a release. Stay Tuned.

Technical Diagram 1A

2010-10-08T04:54:00.000-07:00

I was bored so I thought I'd map out the game's network architecture.
Each component in itself is complex.
This is the most basic diagram with the server running in a single machine.
However, it should be fairly easy to decouple each component into separate servers and scale as necessary.

Anyway, now I'm working on creating tilesets to continue mapping the game.
The SolomonRPG game engine is at version 0.3.
It's solid and stable enough where I can finally concentrate on adding and creating the content!

Fun Shot, 3 A.M.

2010-10-05T03:20:00.000-07:00

Just working on the battle system...

Setting Up a Queue Consumer with RabbitMQ's Erlang Client

2010-08-03T09:59:00.000-07:00

Ok, so in this post I will outline how to set up a consumer using the rabbitmq erlang client.

We'll start with a basic chat server in which clients can post and listen for messages.
Continuing from my last post: http://developingthedream.blogspot.com/2009/10/rabbitmq-erlang-client-yay.html
You now have a basic project skeleton to start building your server. We'll call the project chat_server.

I followed this blog post http://mutlix.blogspot.com/2007/10/amqp-in-10-mins-part3-flexible-routing.html for a visual representation of the AMQP specs,
although it's outdated the basics are the same.

So, the project would look like this:

chat_server/
chat_server/db
chat_server/deps
chat_server/ebin
chat_server/include
chat_server/src

Now inside the src/ directory, we'll create these files:

src/master.erl
src/chat_server.erl
src/test_client.erl

I made a mistake in my last blog post regarding how to properly symlink the rabbitmq dependencies.
Unlink any previously created symlinks:

unlink /usr/lib/erlang/lib/rabbitmq_common
unlink /usr/lib/erlang/lib/rabbitmq_erlang_client

Now create some symlinks in the deps folder:

cd deps/
ln -s rabbitmq-server/ rabbit_common
ln -s rabbitmq-erlang-client/ rabbitmq_erlang_client

Here's the content of the Makefile we'll be using.

.SUFFIXES: .erl .beam

.erl.beam:
    erlc -W $<

ARGS = -pa ebin \
       -pa deps/rabbit_common/ebin \
       -pa deps/rabbitmq_erlang_client/ebin \
       -boot start_sasl -s rabbit

ERL = erl ${ARGS}
ERLC = erlc -I . -I deps +debug_info -o ebin

MODS = src/master.erl src/chat_server.erl src/test_client.erl

all:
    ${ERLC} ${MODS}

run:
    ${ERL}

clean:
    rm -rf *.beam ebin/*.beam src/*.beam erl_crash.dump

We'll start with the master.erl file which basically sets up the exchange, queues, etc.
Mainly bootstraps the server.
Here is the content of master.erl:

-module(master).
-include_lib("deps/rabbitmq_erlang_client/include/amqp_client.hrl").

-export([start/0]).

start() ->
    RID = amqp_connection:start_direct(),
    Channel = amqp_connection:open_channel(RID),

    X = <<"global_chat_exchange">>,
    Q = <<"global_message_queue">>,
    Key = <<"global_message_queue_publish_key">>,       %%our routing key, all clients have this

    amqp_channel:call(Channel, #'exchange.declare'{exchange = X, type = <<"topic">>, nowait = true}),
    amqp_channel:call(Channel, #'queue.declare'{queue = Q}),
    amqp_channel:call(Channel, #'queue.bind'{queue = Q, exchange = X, routing_key = Key}),

    io:fwrite("bound queue: ~p to exchange: ~p using key: ~p~n", [Q, X, Key]),

    amqp_channel:close(Channel),
    amqp_connection:close(RID).

Here's the breakdown of the start() function.
I'm not doing any sort of error checking, take a look at deps/rabbitmq_erlang_client/test/test_util.erl
for more complete code.

First, we connect to rabbitmq.

RID = amqp_connection:start_direct(),

We simply call start_direct in the amqp_connection module and receive the connection id. (this is just the id of an erlang process)
Next, we open a channel which is pretty straightforward.

Channel = amqp_connection:open_channel(Pid),

Afterward, we bind the queue to the exchange using a routing key.

So here's our names:

X = <<"global_chat_exchange">>,
Q = <<"global_message_queue">>,
Key = <<"mysecret">>,       %%our routing key, all clients have this

amqp_channel:call(Channel, #'exchange.declare'{exchange = X, type = <<"topic">>, nowait = true}),
amqp_channel:call(Channel, #'queue.declare'{queue = Q}),
amqp_channel:call(Channel, #'queue.bind'{queue = Q, exchange = X, routing_key = RoutingKey}),

Here we tell the erlang rabbitmq client to declare the exchange.
You can look at the file: deps/rabbit_common/include/rabbit_framing.hrl for all the record definitions.
You can specify things such as the exchange type and other things.

Now, first we'll start by compiling this module manually to go over the erlang shell.
Run 'make run' to start the rabbitmq server. You'll be greeted with the shell.
Compile the master module by typing:

c('src/master').

You can now run the code like so:

master:setup().

Now we're ready to start consuming messages. So, the content of the first draft of chat_server.erl is:

-module(chat_server).
-include_lib("rabbitmq_erlang_client/include/amqp_client.hrl").
-compile(export_all).

start() ->
    RID = amqp_connection:start_direct(),
    Channel = amqp_connection:open_channel(RID),

    Queue = <<"global_message_queue">>,

    spawn( fun() -> consume_loop(RID, Channel, Queue) end ),
    self().

consume_loop(RID, Channel, Q) ->
    amqp_channel:subscribe(Channel, #'basic.consume'{queue = Q}, self()),

    receive
         #'basic.consume_ok'{} ->
            io:fwrite("subscribed to queue: ~p listening for messages...~n", [Q])
    end,
    receive
        {#'basic.deliver'{delivery_tag=Tag}, Content} ->
            amqp_channel:cast(Channel, #'basic.ack'{delivery_tag = Tag}),
            handle_message(RID, Channel, Content),
            consume_loop(RID, Channel, Q);
        Unknown ->
            io:fwrite("unknown message: ~p tearing down~n", [Unknown]),
            teardown(RID, Channel)
    end.

handle_message(RID, Channel, Content) ->
    io:fwrite("got message: ~p from pid: ~p on channel: ~p ~n", [RID, Channel, Content]),
    todo.

teardown(RID, Channel) ->
    amqp_channel:close(Channel),
    amqp_connection:close(RID).

Here we open a channel and spawn a process to consume messages from the 'global_message_queue' queue.
You've seen the start of the code in master.erl.

Queue = <<"global_message_queue">>,   %%Here we declare the queue name to be passed around
spawn( fun() -> consume_loop(RID, Channel, Queue) end ),    %%spawn a process and return immediately
self(). %%return our process id (unused)

Here we spawn a process that loops forever consuming messages from the 'global_message_queue'

consume_loop(RID, Channel, Q) ->
    amqp_channel:subscribe(Channel, #'basic.consume'{queue = Q}, self()),
    receive
         #'basic.consume_ok'{} ->
            io:fwrite("subscribed to queue: ~p listening for messages...~n", [Q])
    end,

Here, we start the loop by telling the server that we're ready to consume on the queue 'Q' by calling amqp_channel:subscribe.
We immediately recieve a confirmation message and continue.

    receive
        {#'basic.deliver'{delivery_tag=Tag}, Content} ->

We wait for an erlang type message which contains a valid amqp message.
We save the payload to the variable 'Content' and the delivery tag to 'Tag'.

            amqp_channel:cast(Channel, #'basic.ack'{delivery_tag = Tag}),

We immediately acknowledge that we've received the message.
You may wish to move this after you've processed the message.

         handle_message(RID, Channel, Content),
      consume_loop(RID, Channel, Q);

We send the content to the handle_message() function and then loop again to wait for messages again.

        Unknown ->
            io:fwrite("unknown message: ~p tearing down~n", [Unknown]),
            teardown(RID, Channel)
    end.

If we get an unknown message for any reason we exit and tear down the channel and connection.
The handle_message() function simply prints the content of the message to the screen.

Now you can compile the module like so:

c('src/chat_server').

Start the consumer process by typing:

chat_server:start().

Now we can start publishing messages, this is the content of test_client.erl:

-module(test_client).
-include_lib("deps/rabbitmq_erlang_client/include/amqp_client.hrl").
-export([say/1]).
say(Msg) ->
    RID = amqp_connection:start_direct(),
    Channel = amqp_connection:open_channel(RID),
    X = <<"global_chat_exchange">>,
    Key = <<"global_message_queue_publish_key">>,

    Packet = list_to_binary(Msg),

    Publish = #'basic.publish'{exchange = X, routing_key = Key, mandatory=true, immediate=false},
    amqp_channel:call(Channel, Publish, #amqp_msg{payload = Packet}),

    amqp_channel:close(Channel),
    amqp_connection:close(RID).

First we turn the message into a binary for delivery:
    Packet = list_to_binary(Msg),

Here we simply turn the message to a binary.

    Publish = #'basic.publish'{exchange = X, routing_key = Key, mandatory=true, immediate=false},
    amqp_channel:cast(Channel, Publish, #amqp_msg{payload = Packet}),

First, we declare a variable 'Publish' which sets up the publish options.
Then we call 'cast' instead of 'call' simply because we WANT to wait for the message to be published.
The reason we want to wait is because we immediately close the channel.

Now you can compile the module by running:

c('src/test_client').

And test it by running:

test_client:say("hello world!").

You should now see the output from your consumers which have read the message.

This concludes this introduction to using the rabbitmq-erlang client.
You can find the full test project available at: http://github.com/therevoltingx/chat_server

Any comments, questions, etc are welcomed!

Fun Shot! #2

2010-07-28T19:53:00.000-07:00

Hi all, here's a snapshot of notes on the battle system UI flow.

Enjoi!

As The Grind Continues

2010-07-22T09:18:00.000-07:00

After releasing a super alpha version of the game so far, I've just been grinding along.
Nothing entirely interesting has happened in the last month, here are some of the things improved and/or added:

Stabilized name display and tile animation
Added team functionality
Added personal messaging functionality
Battle against monsters [Draft]

The most tedious part was starting the battle system, i turned to rpg maker 2000 again for inspiration.
Fusing together its old school battle system with my own vision of the game (and with the limitations of man power and working with Android.)
Battling is turn based, like an animated card game.
Each player or monster takes a turn. (Attack, Defend, Special Attack, etc)
Everyone takes turns, according to different stats, damage is dealt and players are chosen for attack. (Level, Speed, Defense, etc)
An animation is played for each attack and players can attack or do things like defend or use items.

At this point many things are finished, but the battle system is still in a rough stage.
I've gone to pains to keep a clean code base though, so I can tweak the settings as I see fit.
So far, for the battle system I've written:

Erlang:
A single module/process handles all the battle systems such as creating the message queues.
Periodically stores to global database and keeps track of handling turns
Stores and executes monster battling action patterns
Waits and notifies players when a turn is taken
(566 lines of code.)
Java/Android:
A dialog activity is launched when it's notified a battle has started
Bootstraps battle UI, downloads resources accordingly
Listens for events and displays battle animations
Have the player select a monster and take attack, etc. (TODO)
The main class is 481 lines of code so far, but a lot of code is in its own class, and I'm lazy.
Perl/HTML/SQL:
Add data schemas for new battle system components (attacks, teams, monsters, battles, etc)
Add to the existing admin functionality the necessary components
This includes a web UI for managing: monsters, parties, attacks, backdrops, etc.
The Client->Server Battle module is only 63 lines so far.
The Admin->Monster Management module is 263 lines, (fairly complete.)

There is still plenty of work to be done, no one said it would be easy. I think the battle system is one of the most challenging aspects of making any game. I hate math :p

Super Alpha Test (Tech Demo)

2010-06-21T23:36:00.000-07:00

UPDATE: Due to major updates in the server, this client no longer works. Stay tuned for further releases!

Hi all,
Today I am releasing a super alpha version of the game so far.
However, it's still not much of a game. This is more like a tech demo.
This is mainly to get some very early feedback on what I've got so far,
to gauge the interest in it.
I also hope to pull in a bunch of testers to help me further develop the multiplayer aspect of the game.

Please note that it's still really buggy and unpolished, I also don't have a production server and am using my development server.
So expect plenty of downtimes and broken server communication.
Also, the game was developed with an Android 1.5 (stock G1) and doesn't fully work with 2.0+ just yet.
Make sure you have TasKiller ready, you'll need it.

So with that said:
You can download the latest alpha apk here.
Use the signup word: 'douchebag'

Features so far:
Signing up for an account
Camera movement via trackball
Touch based movement, click on the tile where you want to move to.
Area to area teleportation, just step over some of the NPCs and you'll get teleported. (not polished)
NPC/Event/Player activation. Long touch a player or npc for the player menu to come up.
Tile animation, check out the water move.
Remote player display and movement (not fully polished)
Character name display (though it hurts FPS, it'll be optional)
Zone chat
All multiplayer enabled

Feedback, Comments, Questions, Testers, etc:
therevoltingx@gmail.com

Fun Shot!

2010-05-21T14:59:00.000-07:00

Pressing forward, I've added a few features to my custom map editor for my game.
Including:
* Better toolbar icons (for the meantime)
* Muti-tile select/paint
* Eraser
* Area/Layer Clear
* Layer VIew Toggling - Alpha blending support in wxWidgets is weak :-(
* Toggle view grid and tile indexing/numbers information

This will help me make maps for the game.
I've also started to use the excellent Inquisitor RMXP tileset.

Here's a couple of shots of a map I designed using that tileset and the new features I've added.
Enjoi!

On The Road to an RPG

2010-05-14T23:48:00.000-07:00

During the past couple of weeks I've been thinking how I wanted to handle the RPG aspect of the game.
Since I come from an RPG Maker background, I'm familiar with the event/switch system it implements.
However, bringing this into an MMO aspect was a bit of a puzzle. The answer turned out to be simple, and once I got all the details together I set forth into making a scripting engine for the game.

The scripting engine uses JavaScript and it aims to resemble an RPG Maker functionality in script form.
It was also challenging figuring out how it could handle many players at once, from the rough tests it seems that i can handle the load just fine, but only time will tell.
I'm not sure I should even be blogging about this, since it's part of the backend server and the project is not open source.
However, I find it too exciting not to talk about.

So, now that I'm able to sew together an RPG I've started 'prototyping' the game using RPG Maker XP.
The graphics that RMXP uses are pretty much identical to the ones I've designed to be used by my game. This will make finding an artist and transferring ideas much easier.

There is a mountain of work to do with the software, but I'm working on it. However, it would be great to get some help with mapping, scripting, quest designing and story brain storming. I'm also in talks with some artists that have offered to make the art (tilesets, character sets, sprites, etc.) for the game, but nothing too serious yet.

Let's Chat!

2010-04-22T15:18:00.000-07:00

After taking a brief vacation, I'm back working on my game.

I was heavily inspired by the Android game 'Pocket Empires' which I think is brilliantly designed.

Integrating the chat involved working with Perl, Erlang, and Java all at once, but I got it mostly done in less than a week.

Most of the time was wasted fiddling with the Android UI toolkit.

So here's a screenshot of the rough results, of course multiplayer enabled!

New Client Screenshot

2010-03-17T22:37:00.000-07:00

After a lot of work on the game's multi-player code, I've seemed to have wrapped up most things regarding real-time movement.

Though it's not perfect, it's working quite well, so I'm posting a screenshot with 3 players on the screen at the same time.

Videos should be coming as soon as I get some time.

Status Report 2/19/10

2010-02-19T12:24:00.000-08:00

So, after a good 6 months of development for my game it seems that things are coming along nicely.

So here's a status of how things are going:

Android 2d Engine (Completed Features):

Loading areas and displaying rendering to screen
Independent frame-rate animated tiles/sprites
Pixel based camera movement
Character/Object loading/rendering

Android 2d Engine (Upcoming Features):

Pixel based character/movement inside the area (DONE!)
Character idle animation
Render strings. (i.e. player names/levels/status)

C++ Area Editor (Completed Features)

Loading previously saved areas.
Editing and saving areas.
Editing tileset properties (Tileset Editor).
Works on Mac OS X, Linux, and Windows.
No immediate upcoming features.

Master Server (Completed Features)

Validating users
Pathfinding character movement
Track object/character positions/status/collisions

Master Server (Upcoming Features)

Save player information

Fun Shot!

2009-12-30T22:16:00.000-08:00

Haha, here's a picture of my notes for handling movement in the game....

Game Editor Screenshots

2009-12-30T22:09:00.000-08:00

And now some shots of the game editor in action....

First Client Screenshot

2009-12-23T13:52:00.000-08:00

The first screenshot I'm uploading of my game running on an android device. More to come soon!

Android/T-Mobile G1 + Cent OS 5

2009-12-22T13:34:00.000-08:00

Fix for udev:
http://code.google.com/p/android/issues/detail?id=1586

WTF Am I Doing? (Non-Technical)

2009-10-09T10:25:00.000-07:00

Growing up as a kid I always loved T.V. shows like Pokemon, Digimon, Monster Rancher, Yu-Gi-Oh! and many others.

Although I was never into the card games, I dreamed of really being able to battle monsters.

So now that I'm all grown up, I haven't forgotten about my childhood dreams. I am now a computer software developer, and it seems that I finally have the chance to make my dreams come true.

With the rising of mobile computing devices it seems like the time is ripe.
So this is what I imagine. A digital world like Digimon, filled with 'monsters' that people can battle against each other at any place and any time.

I also envision a single (expandable) digital world, where everyone can interact with everyone else. Where monsters roam free, and can be truly unique. A self-sustaining world.

So, how do I achieve this? Well, I'll use the tools that are at my disposal.
I'm choosing google's Android platform to develop the actual game. For simplicity it's going to be 2D. I already have the prototype ready, and am now in the process of integrating it with all the other parts.

Of course I'm going to need a server side program, or God.
The God is being written in erlang, it controls the world. However, it really knows nothing about it. It simply takes data in and spits data out.
This is truly the brains of the program.

I'll also need a designing program or Architect. This is heavily inspired by programs like RPG Maker. I remember building my own custom battle system for RM2K back in the days. But I digress.

I've already finished the prototype for the Architect as well, but there is a lot of work yet to be done. Since this isn't particularly exciting I've only programmed it for what I need so far, but I need do add a lot more.

So, I've gotten some of the basics done. However, as some of you will know, developing a MMORPG type game is a lot of work.
So, in the hopes of gaining a bit of extra cash I've started this blog to detail my journey.

If anyone is interested in helping you can e-mail me at therevoltingx(@)gmail.com.
I plan on making the game open-source so it can continue living when I move on to other projects. (Robots!)

Don't worry, I will retro-blog all my progress so far going back to the beginning with setting up a solid 2D game engine with android.
However, I'm concentrating on the God program at the moment, so most likely any new blog posts will be about that.

Regards,
Miguel.

RabbitMQ + Erlang Client = Yay!

2009-10-07T21:33:00.000-07:00

UPDATE: Read the second part at: http://developingthedream.blogspot.com/2010/08/setting-up-queue-consumer-with.html

Creating a new erlang project based on the rabbitmq erlang client.
Please take these instructions with a giant grain of salt as I am still an erlang noob.
This is how I got started on my CentOS 5 machine.
I installed erlang via yum.
Everything else is installed manually.

First, create a proper folder structure for the new project. This seems to be pretty standard in some of the erlang projects I've seen so far:

project/
project/db/
project/deps/
project/ebin/
project/include/
project/src/

Then install the latest version of rabbitmq and the rabbitmq erlang client like so:

cd deps
hg clone http://hg.rabbitmq.com/rabbitmq-server
hg clone http://hg.rabbitmq.com/rabbitmq-codegen
hg clone http://hg.rabbitmq.com/rabbitmq-erlang-client
cd rabbitmq-server && make && cd ..
cd rabbitmq-erlang-client && make && cd ..
ln -s /path/to/project/deps/rabbitmq-server/ /usr/lib/erlang/lib/rabbitmq_common
ln -s /path/to/project/deps/rabbitmq-server/ /usr/lib/erlang/lib/rabbitmq_erlang_client

This downloads and builds rabbitmq and the erlang client to the project's deps/ directory.
Then it links it to erlang's lib directory.

Now it's time to create a makefile to simplify building the code.

Makefile.am

.SUFFIXES: .erl .beam 
.erl.beam:  
erlc -W $< 

ERL = erl -pa ebin -boot start_sasl -s rabbit -mnesia dir 'db' 
ERLC = erlc -o ebin 
MODS = src/consumer.erl 
all:  
${ERLC} ${MODS} 
run:  
${ERL} 
clean:  
rm -rf ebin/*.beam erl_crash.dump

Now we're ready to go and write a consumer using the erlang client, coming up next.