Sunday, December 18, 2011

Loading Zones

Let me try to elaborate on where I am in the games development right now, as I feel I have not discussed that in a while on this blog.

I have just completed the zoning system for the default world.  There is only 1 world in the game right now, but it would be easy to add more.  The games first world is split up into blocks, and the players view follows the character around, keeping the character centered on the screen unless he is up against the sides of that zone.  When you reach the edge of the zone and push up against the side, the game pauses for 1 second as it swipes over to the next zone.  I tried to make this effect as much like Zelda 3 as possible from SNES.  

There will not be loading screens between zones, thanks to preloading of the 4 surrounding zones.  I have found however that there is sometimes a short period of time when when you first enter a zone that you cannot enter a new zone.  This is because the surrounding zones have not finished preloading yet.  I think this is still vastly superior to a system like that of my last big online game, CND.  The sliding into the new zone also creates a unique effect that few games have used since Zelda.

Here is an overview of my progress so far.  I tried to put it in order of when I did what:

I know this is a boring post so here is a comic.
  1. Map making client
  2. Game client loads in map
  3. Game client loads in player
  4. Player basic movement
  5. Player collision with map/walkable areas
  6. Screen centers on player
  7. NPCs in game
  8. NPCs wander around
  9. allows for actions such as swinging a sword
  10. Added fireball action
  11. Moved data for actions to webserver
  12. Moved data for NPCs to webserver
  13. NPC Perma-death / replaced by new NPC
  14. Worked heavily on Mario World Builder
    1. Tons of bug fixes
    2. Tile System totally overhauled
    3. Multi-select groups of tiles at a time
  15. Decided to use Mario World Builder for both WORG2 and Mario2
  16. Adjusted World Builder to work with WORG
  17. Adjusted WORG to work with World Builder maps (still no collision with world tiles)
  18. Overhaul of classes and re-organization of code
  19. Major bug fixes
  20. Reprogrammed classes entirely... Now based on spritesheets
  21. Wrote 5~ pages of lore for world and class backgrounds
  22. Decided on a combat system and drew out classes/combat structure
  23. Put classes and other data into webserver database
  24. Re-zoning in game
  25. Re-zoning with zelda-like sweeping effect
So whats coming next?  Here are 4 things I have in mind right now, in order of how I plan to execute them:
  1. Assign classes to NPCs so they use different skills
  2. Empty zones self-populate with trees and NPCs
  3. NPCs at further zones are higher level
  4. Bug Fixes (Esp. collision detection with map / Improvements to World Builder FLA)
Sadly I do not think I will be able to get through all these things this quarter because I only have a couple weeks off to think about this and then I am back to grad school.  However, I do hope to have these 4 things done by Spring and to start working on Multiplayer.  Oh, and I have like 20 topics for blog posts written down somewhere... Haha.


Data Management

the action table, this is where the magic
happens, literally.
So as I continue developing my combat and class system in my mind, I have been starting to move some of it to my games database.  When I say game database, what I am talking about is my webservers mySQL databases, which are accessed in game via php.

I am excited to share these tables related to this project that I current have in my database.  I created some scripts on to make it easier for me and other administrators of the site to make modifications to these tables...  The thought being that if the tables are saved on my webhost and easily accessible via the website then it will be much easier to make modifications in the future when I am not feeling like re-compiling the finished game over and over to do simple things like add or modify skills, classes, character visuals, etc.  Likewise, my moderators on the site can make changes if they are needed, such as nerfing a skill that is overpowered, etc.

I can't help but notice that even in the AAA MMORPGs they have to bring the servers down just for some simple updates to how much damage a spell does, etc.  I find that annoying.  In fact, in the ideal Online RPG, skills and classes would be set up to balance themselves automatically.  I have a lot of ideas on how to do that, and I may bring them into this game (especially because the open class system I am using in this game will be difficult to balance), but that will have to be left for another blog post.

the character sheet table contains the information of
the hundreds of playable characters and creatures
So lets go over some of these tables, shall we?  In the top right we have the actions table, where spells and skills are carried out.  It is one of the more complex tables because I really wanted to make spells vary.  For instance, using what is already established here in the game and on this table, you could have a skill fire a spell which floats in front of the player for 1 second, then explodes in all directions.  Or how about one that fires at the enemy, and when it hits the enemy it fires back at you and heals you when it hits you.  How about one that shoots a strong projectile straight ahead but has poor homing capabilities so is less likely to hit the target?  Or one that slowly accelerates forward, and if it doesn't hit the enemy within a few seconds comes back to you?  It is all possible because of the class and this handy database.

the attributes table, this is where you 'level up'
 To the left here is a table to hold the attributes.  In this game, attribute points are everything (this is especially true since there is no item or inventory system in the game yet, Ha!).  They decide what your profession is, what your skills are, and how powerful you are.  You can choose to raise one of your attribute points each time you level up.

Below this text is the skills table.  It is pretty lonely right now as I still just have two skills in the game, a simple swinging of a sword and a fireball attack.  I just added this skills table in tonight because I wanted my NPC's to be a bit more functional:  Before tonight they would always swing a sword at me in retaliation, and I would only have the Fireball spell.  Now NPC's are assigned a profession and they use the skill associated with that profession.  So since there is just two skills, all the magic users are shooting fireballs and the other professions are swinging a sword.  :-)

the skills table contains just two skills right now, these two.
Finally is the professions table, below.  This  is where information about each class you can play as is stored, including a description to help players choose a class and for the game's future website to catalog the possible classes you can play as.  I say class in its loosest sense.  I believe strongly that in a real virtual world that there are no classes, but instead various choices of paths you can take.  Players should be free to mix and match their choices as they please.  That is what a true sandbox is like.  

the professions table.
If you click on this image you will get a little hint at one of my chosen professions for this game, the Elicitator.  The name means to bring out the best or to motivate others, which is why the Elicitator is a buffer.  I want to bring varied and interesting classes to this game.  This may mean that each class will only start out with one or two spells, but since you can mix and match classes this will not really be a problem.  The silly thing is that in most games, players end up just using one or two spells anyways.  When you are designing an indie game you cannot afford to make content that people are not going to or are unable to experience.  That is why it is important that each skill put into the game is utilized by players and there are no 'useless skills'.


Friday, December 2, 2011

Roles in Multi-player RPGs

When making a games combat, there are some very key decisions to be made about roles in combat.  Typically, the 'Holy Trinity' is used in MMORPG combat:  The tank takes damage, healer heals warrior, nuker kills the bad guys.

In this article I will be taking a break from talking about the technicalities of making my RPG and discussing its future combat gameplay.

A quote by someone; not me.
So where did the holy trinity come from?  In Dungeons and Dragons I don't remember ever rolling to see whether the warrior was maintaining aggro.  In fact, if you go into a difficult combat in D&D, the last thing you want to do as a warrior is try to get EVERYONE attacking just you.  That's suicide even if you are tougher than anyone else (because you aren't tougher to the extreme that the Holy Trinity requires, and the healer couldn't keep up with that damage).  It's generally a good thing for damage to get spread around a decent bit in D&D.

So where does the 'holy trinity' 3-role system come from?  It evolved in early MMO's such as Everquest.  Everquest was developed with a D&D class system in mind and there was no intention for having the holy trinity within the game.  However, the 3-roles were an inevitability as players got into higher end raiding and the need and availability of specialization increased.  This level of specialization is simply not available in D&D...  Probably due to healing spells not being as powerful, and all classes having larger amounts of health and no mana regeneration.

The holy trinity does not make sense on most levels
It is unrealistic to pretty much any setting, whether you are in a fantasy world or flying around in spaceships.  It may break immersion to some degree.

But even more problematic is making your gameplay unique and interesting under a system that has been used by at least 50 major online RPG's by now.  As an indie developer it is incredibly important that every feature in your game is in itself unique and fun gameplay...  The holy trinity is not. 

Roles help build a connection between players and their game
So should an indie developer scrap the Holy Trinity?  Here is an article that thinks so, and it outlines how to create roles without the Holy Trinity.  In the place of a 3-role system it wants to add several more features to create many new roles for players.  Many of these new features would require an AAA budget to incorporate.  Given the poor economy of 2011, no AAA game designer would touch something that has not already been proven to work several times over... So I am not even sure who this article is addressing.

Let me discuss for a moment why roles are important.  Simply put, they work on a social level.  Players really enjoy feeling 'needed'.  I have actually read about and experienced myself friends talking about how good it felt when their group 'needed' them.  Girls especially seem to become territorial when someone with the same role as their character tries to join the group.  Ie, if your group has a warrior already and another warrior joins, they will be aggressive or passive-aggressive towards the other warrior.  You see this in normal social circles in real life as well.  If you are the jester of your group of friends and another person shows up who also enjoys entertaining everyone, you may feel threatened by them.  The sense of having a role within your group builds a connection whether its in a circle of friends in real life or in-game.

I would like to move away from the holy trinity, but the concept of it is compelling and I think it is something that developers can evolve as oppose to completely remove.  Having ROLES that make players feel NEEDED is good game development.  The holy trinity is just one way of doing this.  It is the job of an indie multiplayer RPG developer to find simple yet effective ways of creating roles that fall outside the mainstream 'holy trinity'.

I will explain how my RPG will do this in a future article.


Friday, November 4, 2011

Merging Ideas

Over the last few weeks I have been finding time to program again, with a focus on my Mario World game...  Or more specifically, the World Builder for this game, which I will soon be using for my unnamed RPG project, WORG, as well.  Hence why I am back at the blog!  I will have a video overview and some information on the blog coming soon about the new world builder.

This character sprite sheet is automatically chopped up so
the characters are instantly playable using the
'characterVisual' class.
This post will be deticated to the new character importing system.  As you can see in the picture to the right, I have many sheets with characters like these ones to be imported into the game.  I wanted to create an easy way to get a lot of characters into the game quickly, and thats when I created my CharacterVisual class, or 'sheet sprite' system.  What it does is it takes sheets like this one and chops them up automatically into characters so that I do not have to do it manually in flash.

This will make it easier for players to create custom characters and NPCs in the future.  I think I will keep the ability to upload these sheets as administrative-only though, for quality control.

Below is the function that I found online which makes it very easy to extract individual frames from this larger image.
private function cropBitmapData(sourceBitmapData:BitmapData, startPoint:Point, width:Number, height:Number):BitmapData {   var croppedBD:BitmapData = new BitmapData(width, height);   croppedBD.copyPixels(sourceBitmapData, new Rectangle(startPoint.x, startPoint.y, width, height), new Point(0, 0));   return croppedBD.clone();   croppedBD.dispose();}

You can read about it more on this webpage.  This method of importing characters makes importing new characters easy and is vastly superior to my old method of having a 'character' movieclip, and placing each character on a different frame of this movieclip, then in a movieclip within that movieclip having different frames for the different walking animations.  Not only is this new method less resource intensive, it will be much easier to import characters.   I have already imported over 100 characters, and have spent maybe 1/20th of the time doing it as I did in my Chip N Dales MMORPG game!!!


Friday, August 26, 2011


 Making a game solo on a tiny time budget isn't easy.  It requires you to take a new path in almost every decision you make, because every moment spent building something that's already been done is essentially not good enough.  How could a single programmer compete directly with real developers?  Uniqueness is the only way.

Which makes it even harder for this game, because I want it to feel like a traditional RPG.  I will be adding twists as I go and trying to spend as little time as possible on things that have already been done.  Thats when I came across This Page.  A list of over 7,000 bad-ass fantasy names.

So they have now been loaded into a database for my game, and marked with a timestamp when they are used so not to use them multiple times.  Now when an NPC is generated in the game, it pulls a name from that list and assigns it a visual (and in the future, other stats).  This newly formed NPC is added to another database where other NPC's information sits.  When players play the game, they will interact with these generated NPCs.  When an NPC dies, it will not respawn- Instead, a new NPC will be generated to replace it.

So what does that do for the game?  Well, nothing yet.  But it could have some major implications for where the game heads from here, because now I am committed to this path.  Now I will be looking for ways to invest players into NPC's that might not always be around.  Here are some wild ideas:
  • NPC's have an opinion on you depending on your actions.  It takes hard work to get an NPC to like you, but you benefit in different ways from this.
  • When another NPC/player kills an NPC that likes you you can choose to carry that high opinion on to the NPCs friends/family by avenging the NPC's death
  • Bosses could still exist but would always be unique
  • Certain NPC's that are especially powerful, live in high player population areas and well liked by players would become targets for players to try and kill
The above are definitely not plans; they are just things I came up with as I am typing and will probably make a point to not look at them again.  But these are the possibilities and it is choices like this that makes an RPG stand out.  But for now I will be content with killing all of the NPC's that have dumb names, and leaving the ones with cool names and cool looking sprites to live.  That is simple, but in a strange way I am already feeling like this game is a true world where I have an impact.  What bigger impact is there than world permanence?  Isn't it ironic that NPC impermanence creates world permanence?

Thursday, August 18, 2011

Combat Decisions

Choosing a structure for combat is important because it builds the general feel of the game. For this game, I have opted for something that resembles the popular phone game zenonia. I would say that this is a mix between traditional RPGs and diablo.

I wanted fast-paced combat with a lot of visual cover-ups, because this is an online game and there are several different character avatars and I do not want to create sprites unique to every avatar performing every combat move. So there has to be a lot of explosions and visuals that will cover up the characters underneath. This probably means taking arcade style aim is out (because we want our characters to be difficult to see), which is good anyways because having to aim at enemies doesn't work well with online rpgs because of latency issues. Latency issues means we will need a targetting system like those seen in most RPGs. But the game will still feel like an arcade game because of the fast pacing, auto-targetting and over the top (character covering) visuals. I prefer my games to have an arcade, retro feel. I also like them to not require a mouse because two hands on the keyboard is more conducive to typing, and encourages chat.

Our player tar

a red circle appears under the closest
enemy- the one you have selected.
gets NPCs and objects of interests using a simple check to see what object is cloest to our player. I quickly noticed that this causes problems because our target often ends up being behind the player while intuitively we would hope to be targetting an enemy that is standing in front of the player. So I added a modifier to my function that checks distances between things so that it considers a point 50 pixels in front of the player (depending on the direction the player faces). Also, dead NPCs are given less priority (their 'distance' is multiplied by 5).

Adding Depth

Classic games that are built on twitch (player skill at aiming) arguably do not need as much depth because the player can enjoy their improvement over time in their aim, etc. But since my game will feature targetting instead of manual aiming, it will need to capture depth that RPGs tend to have. Even more so, because unlike many RPGs this game will primarily use an auto-targetting system, so we will not have that added strategy in choosing targets that many RPGs have. In the future I may wish to add this functionality, but right now I am seeing it as an unnecessary complication.

RPG's Are Complicated For a Reason

That reason is that learning is fun. Players want to feel like they have achieved something and that they are doing so more efficiently than the normal player (or at least more efficiently than they did last time they played). Although an RPG is not twitch based, it is important that players still feel that they are improving at the game. Watching their characters improve is simply not enough, because then the game feels like a timesink that anyone could do. Which makes you feel better? Knowing that you spent X amount of time more in a game than a friend, or that you are X amount better at a game than a friend?

This translates to complex combat systems that play off of realistic/intuitive ideas such as: Killing enemy healers and nukers before tanks, conditions such as poison that drain life over time if not cured, positioning your player strategically, switching poses/stances to match the fight, complex skill trees, attributes, resists, etc.

Why Aren't there More Indie RPG Games?Well, I already answered my own question: RPG's are really complex! Anybody can program a hunting game where you have to quickly shoot ducks that pop out behind bushes, etc. And those games are easy to program and can be very rewarding to play. They work off of the players own progression of improvement of their hand/eye coordination to make the game fun. RPG's need a lot of depth to make up for this areas where it lacks.

So when you take on a RPG project you have to realize what you are getting in to. How can one add depth and complexity to an RPG's gameplay while minimizing the complexity of it's code? Well, I am not entirely sure yet myself. But I have 3 strategies that I am thinking of using right now:

  1. Replace traditional life/mana bars with a new system that is easy to program but will add complexity to the game. (my HAMS system) 
  2. Dumb down attributes, classes, skill trees, etc into a system that is both functional and easy to code. (my skillpoints system) 
  3. Lower the games expected audience age. A game like this will never reach the same realistic complexity that someone would expect from current MMORPGs or Dungeons & Dragons, and setting realistic goals is important. 
I will be going into more detail about points 1 and 2 when appropriate, but for now we need to think about programming those first few skills!

Thursday, August 11, 2011

Wandering NPCs

Click the link in the main text to play
There really isn't a game yet, so I suppose it depends on your definition of playable...  But I am going to post it anyways.  Try this example of the game, the first build ever of my new game.

Why So Many NPCs?
In this example, there are many many NPCs wandering around.  I had some fun increasing the amount of NPCs to see what the game can handle before it starts to slow down, and you should get a totally normal framerate with that many NPCs.  In fact, I was able to go up to 400 NPCs before I started seeing the framerate drop.  Once all the other elements of the game are added in (especially multiplayer networking) this won't be the case, but right now it was fun to see so many characters on the screen at once without lag.  Lag is a serious problem when you are coding a game with AS3, especially one that is online multiplayer with real time combat (as opposed to turn based combat).  I will definitely write another article about that in the future.

Class Structure & Pathfinding
So I started working on my client, obviously, and quickly flushed out a movement system for the character.  The character you control is of class 'Player' which is extended from class 'Character'.  Class 'NPC' also extends class 'Character'.  I can already tell that the class 'Character' is going to be one of my biggest, messiest classes that the game revolves around.

Because I want both NPCs and Players to be capable of pathfinding to a given spot on the map, all my movement and pathfinding has to be part of the Character class.  In fact, right now my player class is very very small.  It simply checks to see what keys the user is pressing, and passes that on to the Character class via an (x,y) point variable, p.  p.x=-1 is analogous to pressing the left arrow key, etc.  Theres only about 10 lines of functional code in class Player so far.

I was seriously considering spending a LOT of time on this and making sure the pathfinding algorithm was perfect.  To do that I would need 3rd party code, and I considered it a while.  I think in the future I will need to adopt 3rd party code and a better system.  Right now, the Character class can be told to go to a tile, but if there is an object blocking it's way it will fail to reach its intended target.  If I choose to make a quest system, cinematic system, or multiplayer content then this could be a serious problem.  Characters would constantly get stuck on things, and then I would have to put in some quick fix code to make the character jump to their intended location.  It would be buggy and messy looking.  So its something to keep in mind for the future.

Click for full size image.  This diagram shows real results
from use of my wander radius code
Wander Radius
So I have a basic NPC movement code that moves the NPC to their target location (part of the Character class).  I still needed to add in code to have the NPCs decide where to walk.  Thats when I did my wander radius thing that you can read about in the picture attached to the right.

The NPC wanders randomly around, and if they move too far from their origin point then they will only wander in directions towards that point.  A value I call wanderRadius controls how far away from that point they like to wander.  The code for this is about 50 lines long.

I am opting to use real physics like I usually do for this game.  So there is acceleration, velocity, and location variables for each object (players, NPCs, and moving spells) in the game.  But I have the friction coefficient up so high right now (0.5 per looping frame) and the acceleration so high (2) that you cannot tell.  I chose to use real physics because I know I might want to have some slippery ice floor or something of that sort in the future in the game.  :-)


Saturday, August 6, 2011

The Map Editor Version 2

Let me point out that at the time of writing this I am actually 3 or 4 blog posts ahead of myself so I am sort of back tracking to talk about the current version of the map editor.

The tilesheets (top) each have their own
frame in a tile mc.  That mc is masked.
The first version of the map editor worked, but I opted to expand it a little more before beginning to program my game client.  I knew that I could not make more than a tiny area using the 'click to circulate through tiles' method and I needed an easier way to navigate my tiles.  Also I had a ton of tiles that I wanted to use (most which I found on google images), but no way to import them into flash without going through each one and removing each tile from the tile sheet one at a time and creating a new movieclip for that tile (or actually a new frame within one movieclip).  Then using gotoAndStop(frame), the tile was selected.  Now, the tilesheet is selected in the same way, and then the tilesheet is masked so that only one of many tiles on it can be seen.

Some of many tile sheets.  Some had to be
resized so their tiles were 32x32 pixels
This is a questionable way to code a tile system, at best.  But it is a good way to quickly program such a game.  Ideally however, the tilesheets would be split apart using a 3rd party program, uploaded to the internet, and then reorganized together into the map editor.  Then when the game client is loading it gets a list of the tiles used in each zone and while that zone loads it loads in each individual tile.  Instead of using one mc that contains all the tiles, each tile would be loaded separately.  It would help a lot with lag and just be smarter programming, and I did use this system with my Online Mario World game, as seen on  However, it took me a lot of time to program this and now it is so large that after looking at it I decided against adapting the system for this game.  Instead I am starting fresh with this simple masking system, and if in the future lag becomes a problem because of too many of these performance heavy tiles, or if I want to make larger maps with more tiles, then I will adopt a better tile system.  Sometimes short cuts have to be used when you don't have a lot of time to program.  

The mc is relocated so that the tile we
want falls under the 32x32 px mask.
The 'correct' way of doing it took me 5 or so AS3 classes, a 3rd party program, and a couple php scripts.  The simple masking system I am using for this game takes only a few lines of code, as seen in the picture to the right.  So if you read my last post about the 3D grid, you might find it interesting that each element of the 3D grid now has 3 variables:  the tilesheet, and the x & y location on that tilesheet where our tile is located.

Another modification I quickly realized I needed was to add another shortcut (I used M) to switch between two modes.  One mode where dragging the mouse while holding the mouse button drags the map (so you can create zones bigger than the small screensize)  The other where dragging the mouse while holding the mouse button fills in any tiles you move over.  That way you do not have to click each tile just to place grass, etc.  It saved a lot of time and headache.

So right now I have a nifty map editor with 3 layers, 5 or so tilesheets, and many key shortcuts:  I, E, S, M, T.  You can test this version out here:

It uses a different zone specially for this test version, so it does save correctly.  The map editor is not meant for players to use though, so there are bugs that I ignore since it is just for my use right now.


Wednesday, August 3, 2011

The Map Editor Version 1

The Code
The map editor is a stand-alone client apart from the main game client.  They will not be sharing any code.  I have broken the map editor down into 6 classes:  Main, Map, References, SaveMap, TileChooser, Ui.  Most of the interface happens on the Map class, and you can probably guess what the rest is for.  

Within the Map class is a 3D array called grid.  This array contains the visuals of all the layers of the map; it is essentially the data of the map...  So it will be what is uploaded to the games database and saved in the end of the day, and the only piece of the map editor that the real game client will ever see.  Since this is a tile-based game, each tile has its own element on the grid array.  grid[0][1][2] would be represent layer 0, x location 1, y location 2.  The value will be an integer based on what tile is chosen for that location on the grid.

This is pretty standard stuff and can be seen on most RPG making tutorials.  A similar 3D array holds the instances of each tile (the visual representation of each tile), which I call images.  It is important that the array is 3D, not 2D.  Obviously the game is 2D, but I want to have some layers on top of the players character and some behind.  I will probably be sticking with 4 layers:  Layer 0 will contain the basic background tiles (usually grass or cobblestone).  Layer 1 will contain objects like bushes, houses, and doodads like tree trunks.  Layer 2 will contain the player and interactive objects like NPCs or signs.  Layer 3 will contain foreground objects like the top of trees.  That way when the player walks behind a tree the tree stays in front of the player.

Using It
Clicking on the map goes through the tiles.  So if you click on a piece of grass, it turns into a barrel.  If you click on a barrel, it turns into a stone.  If you click on a stone, it turns into nothing.  If you click on nothing it turns into grass.  There are only these three tiles.  During my next expansion to the map editor, I will be adding more tiles and a new system for choosing your tile, because once there are 100+ tiles the map creator really will not want to click so many times just to find the single tile he wants.

This code takes the mapdata already retrieved from the
server and adjusts it  so that the grid is the correct size
Right now there is a small box labeled 'circulation'.  This is a temporary fix for the problem where I do not want to click through the tiles.  If circulation is empty, then all tiles can be clicked through.  If you fill it in with a number like '1', then only that corresponding tile will be in the circulation when you click a tile.  So entering '1' alone in the circulation box effectively makes any tile clicked into grass.  If you press I (for ID), whatever tile is being hovered over is added into circulation.  If you press E (for eyedropper), the circulation is cleared and the hovered tile is added to circulation (alone).  Other keys include T to toggle map editing (so that you can easily drag the map around and see different areas of the map without making accidental modifications), and S to save the map.

It is effective enough to make a small map, but I think I will be working on making it better before I start working on the game client.

This is version 2 of the map editor.  I don't
 have any screenshots of version 1 saved.
The maximum map size right now is 100x100 tiles.  I don't think it would be a problem to make that bigger, but I probably wont go over 200x200 because of lag.  200x200x4 layers could mean 160,000 tiles in one zone!  That is actually not very much compared to what is seen in some games, but because we are working with AS3, that is quite a bit.  AS3 is notorious for not being able to handle a lot of movieclip objects at once.  So instead the game will need to be broken down into zones, which is a good idea anyways, because I may want it to be that players can enter houses or dungeons in the future.  I included zones in my scripting, but right now the game always refers to the same zone: 'testzone2'.

We will see an example swf that you can actually play with in the next blog post.


Why Programmers Suck & My #1 Strategy

Why Programmers Suck
You can think of me as an anti-programmer.  I did not learn to program in school, and I would never recommend programming as a career.  I do not want to become stuck in the monotonous world of making software for other people.  Or just having a boss in general.  The only bosses I want to have are the ones at the end of a dungeon in Zelda: A Link to the Past.  The only time I want to program something for anyone but me is NEVER.

Why I've never taken a CS class
If I do program a game I don't want to be making it for myself, even.  As in, I do not want to design an elaborate game and then have to spend months programming something that is already planned.

My Strategy
Which brings in my programming strategy for this game: Do not plan.

Planning destroys the fun of seeing what happens next.  When I am already thinking about the skill system for my game, then how am I going to find the motivation to program the basic combat?  When I am already imagining how my elderworld will operate, how does one find the patience to debug a simple map editor?   Getting ahead of myself has been my achilles heel of every game I have ever programmed.  I start getting too excited, and then I end up disappointed that things aren't moving along faster.  Don't get me wrong, I will be writing this intelligently, with comments and with room for adding in whatever I might dream up in the future...  But leaving //?? comments all over my code is a sure way to get burnt out, so I will not design the game details ahead or make decisions until they come up in the code.

For any aspiring programmers I encourage you to start small, and do not let yourself plan out anything too elaborate until you have laid down the basics.  You, like me, are a game designer first, and a programmer second.  But we don't have a legion of chinese sweatshop workers to do our grunt work for us, so you need to find a way to enjoy coding.  That means dispersing choices, decisions, and game design throughout the coding experience. Also, keep clean, well structured code that you will be able to read later.  You do not want to feel frustrated at any part of development.  Frustration can easily lead to working ahead of yourself, short-cuts, messy code, and bugs.  Make sure each part of the game is smooth and working how you want it to before moving on to the next, exciting part.


The Structure, RPG Maker, and Other Languages

Why Not RPG Maker?
I like to code everything from scratch, which might seem tedious given the availability of game creating programs like RPG Maker, etc, but I just can't stand trying to figure out how to do what I want to do in those programs.  Even if there is a way to customize things how I want, I can't stand figuring it out.  Since I am not a professional programmer, I have a difficult time understanding the complexities of other peoples codes or syntax of new languages.

Some tilesheets I've found for the
game online, 32x32 square tiles.
For example, I am using blogger for this blog.  I am going against a huge part of me that wants to code this blog by hand in HTML.  Why?  Because there are a lot of simple little things that I cannot stand for the life of me about this blogger website that I am already noticing, only a few minutes into using it.  Some I can fix, some I cannot.  I suppose it comes down to stubbornness and a passion to control every element of my design.  I recognize that as a fault, but I still can't help but be amused when I am at a party and somehow a conversation takes a wrong turn into programming (it happens more than we are willing to admit, doesn't it?)...  And I get asked what software I use to code my websites.  I reply 'HTML' and 'PHP'. They look at me, shocked...  WHAAT!

So I am programming this game in Actionscript 3, the flash based programming language.  And I encourage any kids looking to get into programming as a hobby to learn a real (object based) language like AS3 or C sharp.  It is more difficult at first but more rewarding in the long run.  On second thought, I encourage you not to get into programming at all, I'm sure you have better things to do.  Also I will be using PHP for database communication and (if I decide to make it multiplayer) the game server.

The Game Structure
To begin, the game will be broken into 2 flash based clients.  One for making maps and one for playing the game.  The Map Editor right now is not built for anyone but me to use...  It is really complicated.  In fact, I was pretty confused how to use it myself.  Oh and it has bugs.  The game client I will start posting on this blog when I have working versions done.  Then if I make the game multiplayer there will be a game server written in PHP, but I will also be making an additional flash client to use as a game master:  Ie. control the NPCs and any other dynamic content within the game.  I know that it would be possible to have this incorporated directly in the PHP server, but from previous games I have made I realize now that messing with the server is a bad idea.  It is too difficult to debug in its current state.  I am sure I will be writing a lot more on that if I get around to making this a multiplayer game in the future.


Getting Started

An Introduction to Me and this Game
Today I will be starting to create a new game, which is untitled.  I know nothing about it yet except that it is to be an RPG built using flash actionscript 3.

My Website,
My name is Lysle Shaw-McMinn, I am not a professional programmer, but I have been making websites since I was 11 years old and games since I was 14.  I made my first multiplayer browser based game when I was 17, which was quite an accomplishment at that time when multiplayer browser games were very rare.  I am now 24 years old and in grad school to become an optometrist.

You can find my games on my website, and maybe someday you will find the game I am working on in this blog there too!  More likely:  I will never finish this game. 

Why program it if I don't plan to finish it?  I program for relaxation and fun, and when this game becomes neither, I will stop.  If this is my last post on this blog then holy shit, I got bored quickly, didn't I?