Development Hints: Behind the scenes of Technarhia MMO

Talk about game designs and what goes behind designing games.
Post Reply
User avatar
Nihilant
Posts: 47
Joined: Wed Aug 31, 2011 8:24 pm

Development Hints: Behind the scenes of Technarhia MMO

Post by Nihilant »

[ATTENTION: long post! xD]

This is about the Steampunk MMO game 'Technarhia' - read a bit here, with screenshots and youtube video of a gameplay.

This post is meant to help new developers of MMO games. I am not an experienced coder or developer, but I guess my own experience can be useful for anyone that's in the same position where I was about a year ago :) So here it is:

How I came to idea to make a game

1. My previous knowledge. I knew enough of html and bits of javascript some 3 years ago. Then I helped a friend with some graphics for his Flash game and I got hooked to Flash itself and made some games up until a year ago. Then I thought it was a good time to start making a MMO game in Flash, since I actually wanted a Steampunk MMO that's not about furry creatures, manga eyes or that require some big 3d acceleration.
2. What I did know:
- the work will be constant learning,
- the learning will be hard at times,
- there won't be much 'free' time to spend on game-making if you do regular daily job and come back tired,
- game-making will take at least a year under those conditions,
- I will be making big changes to already finished parts of the work, resetting some of my own progress.
3. What I wanted to make:
- a 2D point&click Flash MMO game,
- a simple game engine that allows for updates in no time,
- something 'catchy' in the gameplay, that will keep players logged in,
- game setting that is not widely used but is still part of 'big' genres,
- catchy design that is still intuitive enough.

How I worked:

1. Planning your time. Knowing myself, I concluded that if there's any important out-of-home work to do after about 11:00 AM, I better not start working on the game in the morning. Also, if I'm going drinking, no work on the game after I come back - I make lots of typos if I'm coding even a bit drunk, so I didn't want to spend time on fixing such stupid mistakes. My most productive time, though, seems to be either (very) early morning or early evening, especially if I have at least 5 hours free.
2. Using your 'free' time. With all that in mind I wasn't starting anything if I wasn't sure I'll be able to finish it. Thus, if some big but important work was ahead and I didn't have enough 'effective' time to finish it, I'd just split it into logical parts and work on one at the time, allowing more time for putting it all together later.
3. Learning things. As I worked I learned a lot, which also meant I had to go back and change some of previously 'finished' code as I learned to do it better. Going back is what you must count on, and it's not a drawback - it's actual progress :D
4. Making pauses. When you are tired or something doesn't work for Nth time - stop. Rest. Then do some other thing that you know you will do right - it will help you regain some confidence to go back to 'problem' later. Search forums, blogs etc. for solution to a thing you don't actually understand but make sure you don't only copy/paste the solution, but understand it so that it becomes part of your practice.
5. Testing. Test everything! Even if the code I'm writing is 100% part of regular practice, I still test it if it's longer than some 10 lines :) Keep an eye for typos: they are my worst nightmare since I type fast, and they've been giving me headaches many times! I have the regular problem of typing faster than removing the finger from 'shift', so 'playerName' becomes 'playerNAme' in an instant. Learn your mistakes :D
6. Talk with someone about what you're doing. They don't need to have any profficiency in coding/designing, they only need to be either good listeners or have good imagination. I had several people to talk to daily as I worked on the game, and they were fast to spot inconsistences, bad or just plain stupid ideas :D
7. Work within your limits. Yes, you will learn as you go, but I think we should stick to what we know at the time we use the knowledge. Even if later it turns out you could have done something better, it's still important to push forward and see the result. We'll later change those things with new knowledge, but we will have full image of where it belongs and what really makes the new knowledge better. If you are only starting to code in some language do not go for 'best' choices, go for those that you understand fully.
8. Choose your languages and stick with them. That's my suggestion anyway. I wanted actionscript+php and nothing else. There were times when it seemed like a bit of javascript or jquery could help, but I've decided to stay away from that. Why? Simply because "a bit" of another language seems to me like "a bit of laziness" - said javascript could have helped at times, but why not go a bit deeper into actionscript/php and find a solution that does the same? I believe it makes it more fun and helps understand more. If I always reach for "a bit" of other language to patch the problem I won't be getting better at all - I'll just have a patched game. Of couse, there must be some situations in which your preferred languages cannot give a solution. But so far I've managed to stay 'unpolluted' xD
9. Write down and draw everything. Lay down your concept, relations between your files, structure of objects, supposed actions of a player, anything that you can imagine. The more you do it the easier it is to code stuff, keep the logic and understand what you've been doing when you get back to it later.
10. Choose a 'target' group of players. For me it's steampunk fans, then regular sci-fi fans and finally players that meet the needed software conditions. It means that I expect steampunk fans to play it even if they don't have the needed resolution to experience the game in the best way (for example, if they have under 1200(x650) resolution) while I don't expect many regular sci-fi fans to go with it.
11. Keep setting some deadlines. Set vague deadline for finishing the game ("a year from now"), but have some more precise deadlines for particular parts of work ("login/register screen must be done in 2 days", "combat screen should be finished next week"). You won't stick to your deadlines usually, but having them set is important to keep you working!
12. Be honest to yourself. Some things can't be done in set time because the language makes it too hard or complicated, but sometimes it's just our laziness or the lack of knowledge. Just be aware of your limits and skills and chew it bit by bit. Maybe you can't progress on that particular screen only because you want to devote more time to your loved one or family, or have some RL problems that need your full attention - and it's all ok: but being honest to yourself will keep your confidence stable when it comes to coding the game.
13. Gather test-players as soon as you're certain the test version of the game will be ready soon ("soon" might be a week or a month or two!). If they have the way to keep bugging you if the game is not ready when you said it'll be, the pressure will help you work faster - because it's a pressure from friends and not your boss :D

Rules I tried to follow while designing the User Interface

1. It must fit the setting/genre of the game. In my understanding and with my approach to aesthetics, if I see medieval vignettes on sci-fi game I just close it. Same goes for baby-face-big-boobs-girls-images on a game that has nothing to do with adult themes, etc.
2. Pick a color scheme for the GUI. My game's genre is steampunk so it's 2-3 shades of orange, some brown and red, black and that's it. White text where needed, to accentuate important info.
3. With the game concept laid already, I wanted to keep each 'page' of the game in the same or at least similar shape: I have 'main frame' that holds most important details for the player and all the buttons to individual screens/pages within the game, with each loaded page (inside that main frame) having the same structure: 3 panels, visually discernible and used for different things on that particular page. In other words, the GUI looks like webpage.
4. I decided to have a 'template' button for a game, that will be used on all buttons that are placed inside each screen/page: the button is easily recognizable and wide enough to keep the text/label.
5. My wish was for a user to play the game without scrolling, so I've settled with 1200x650px dimension of a game. Might not be best option, but I figure most users should have resolution of their monitors big enough for that.

Rules I tried to follow in PHP files

1. It was expected to have some queries having the same structure on several requests, so making a 'template' php file with query was a good idea. While I did that in most cases, I still have some stuff that can be optimized better.
2. As they always say: "Never trust user's input", so all php files need to check the POST data received for what they are meant to be: the POST data needs to be cleaned for sql queries, set to right type (int as int etc.) or checked against expected values (from some array, for example). Same as the above, I still have some of those checks to add.
3. All PHP files have the names and comments that help me find the one I need fast.
4. Similar to first paragraph, and in accordance to object-oriented programming on Flash's side, the php code should be abstract as it can be: so that updates on Flash side or database will not require additional coding in php files themselves.

Rules I tried to follow in ActionScript

1. Comment the hell out of it. Can't hurt, and helps a ton when the code is getting big. Also, even if my native language is Serbian, comments are in English: if I ever need to share the code or ask for help, the reader probably knows English much more than Serbian xD
2. Use arrays and loops whenever there's more data to work with or check: I even made arrays for things that are at this point not used in any looping. Might be taking some size in classes atm, but if later (with some updates) I need to use them I know where they are and how to reference them. (Already proved helpful after I added some updates.)
3. All AS files should be structured in the same way: variables definitions and functions all ordered the same way on each AS file and having big commented headers for ease of browsing. I've put all 'less important' functions (number formatting, string operations and preparations etc.) at the bottom of each file, for example.
4. Whenever the logic and common sense say that the functions/operations defined in the code are not essentially related to that AS file, I move them to individual file or make new object that has those functions, and reference that object from the 'parent' object's AS.
5. As with rule on php files, I tried not to have same chunks of (abstract) code appearing on each AS file, but still need to optimize it more towards that.

Rules I tried to follow in the game concept

1. I wanted an open-ended game that will not become boring after year(s) of playing (like some of the games that I've been playing or currently playing). As long as the game engine allows for stockpilling resources or currencies, without much risk of losing them, I believe the game will become boring for players that progress the most. It will also show new players that they have long way to go to get there too, so might discourage them from even trying to play. So I decided to:

- Put into the game only the things that don't come from nowhere. Imagine trading aspects of a game: if some 'NPC' planet or base sells and buys stuff on it's own, it means credits/money is coming out of nowhere. Players only need to keep trading and they'll become richer - for the price of heading towards inflation ingame which makes it all worthless after some time. So I decided not to have any set currency ingame. Anything there is, must come from spending something. The resources that players extract and use in building things ingame are related to spending of Action Points (that regenerate in certain amounts during the day/hour/minute). Although you can get resources in various ways other than extracting (like from espionage missions or exchanges etc.) it's still related to what you invest in them. Thus, every item that exists ingame is made by spending something - and thus players become the ones who set the value of items when they exchange them (exchanging airships, designs, traits etc. for resources).

- Make the game dynamic and fluid. It's a conflict game where you really 'progress' only when you get in conflict with someone. Certainly you can sit back and gather resources for a while, but the players who actually regularly spend them are going to get even more - since some of their other attributes (like Reputation, Power or Social Status, no need to explain them now xD) are directly related to resolutions of conflicts and give good bonuses. The game offers the actions of a trader or a miner, but it's all in the function of future conflicts - a player basicly just prepares for conflict, and no item ingame has any real value until it's set into motion.

- Allow for shifting of power. There are many games that - by their mechanics or players' actions - actually tell you right away: "Do not attack anyone, you're too weak!". My idea was that dynamic game must give a chance for a newbie or a weak player to do something big, which also means it must put veteran or rich players into position to constantly defend what they have. So, in Technarhia there are 2 things to keep it that way: 1) airship combat and 2) Reputation attribute. It's easy for realtime games to rely on skills of a player that 'operates' a vessel - you need to react when enemy moves, you need to rotate etc. But in non-realtime game it's a bit harder to achieve and I saw many games that actually 'hardcode' lots of tactical options and leave weak vessel at the mercy of strong one, since the most important difference becomes how fast can you click. In Technarhia (as you might see from the youtube video) you issue 'commands' to ship, like 'Move', 'Turn', 'Fire' etc. They all take some time to finish (depending on some attribute of the ship) and in actual combat even if it does mean a 'faster' ship will maneuver better than the starter ship, the starter ship still has a chance to gain tactical advantage (through planning or pure luck!) and actually shoot/damage the stronger/faster one. There is also an 'angle' in fire, which rises/lowers your chance to hit, so seems like anything is possible. During the testing, we had combats that lasted anywhere from a minute to 18 minutes of constant moving, turning and firing, with ships being destroyed both due to being weaker and due to their owner making bad tactical choices even if in stronger ship. As for Reputation attribute, it's meant to reflect the XIX Century 'gentleman' approach in the game: if you take on stronger or richer, you are awarded more Reputation, whereas if you pick on weaker and poorer you lose Reputation (which is, suffice to say, important attribute). The result of all that is the situation in which really strong or rich players actually become juicy targets! It pushes stronger players into more action to secure their status, and in turn it puts them at risk of losing that status.

2. The main game options should be easy to grasp during one day, with subtle details taking more time and expriments to learn. While you can always count on older players helping the newbie (through chat for example), he must understand the main concept and way to start progressing ingame. In this testing phase of my game I haven't finished all needed details in that direction, but will do: starting message for newbies, some place inside the game to actually suggest several possibilities on early gameplay etc. At this moment, I have extensive help inside the game screens, which are accessible on each main headline (like 'Design Airship', 'Extract Resources' etc.) with simple click on a '?' icon.

3. Items ingame should be personalized/specific as much as possible. There are several levels to that. First, the Trait system (which is kinda similar to 'card' system but is different in some aspects) has all Traits named - they're not just a bunch of numbers. For example, there is Airship:Crew or Espionage:Agent traits that are named after (imaginary) persons, Workshop:Technology or Workshop:Inventions named after real technology/inventions etc. and you also have set maximum of traits you can have, which means you will give more attention to what you need, what you produce and when you produce it you will actually use it. Second, there is maximum of airship designs and actual airships that you can have, so it kinda 'attaches' player to his ship - again it's not just a bunch of numbers but when you lose a ship you can really say "damn, there goes 10% of my fleet!" and actually feel the loss xD

EDIT: Added text

In addition to 1st and 2nd level in previous paragraph, there's the 3rd: no ingame items that have no specific use. We all know of games that have dozens of 'trade' items. Most of those items are only different by the name and all act the same: you buy/sell them for profit. Why would a game need dozen of items that work exactly the same? I've always believed that the need is one that creates the action: so I settled with only 3 resources that are used in different amounts for different purposes. A player suggested adding more resources and my answer was: until the game gets into the stage where new resource is needed for the actual different game options, I am not putting anything of that kind.

Rules I am trying to follow in regard to reactions of players (testers)

1. Take only ideas that promote the gameplay as you want it. As hinted in previous paragraph: I'm willing to add (and actually adding) only the things that promote main concepts of the game, and that is conflict and dynamics. There are dozens of interesting and fun suggestions already, but some of them are on the level of cosmetics: like mentioned new resources, and some are really against the concept: like giving players the options to see/know some stuff that might in fact stop them from starting a conflict or make the conflict to disbalanced to the side of stronger and more informed.

2. Listen to all they have to say. No player can have stupid ideas: they're playing your game after all, so if one has a stupid idea you're the one that made it possible ;) Suggestions aside, players also give great comments and you should be thankful to each of them. I'm saying this because there are Creators/Admins that just ignore most of the things their players say.

3. Test-players are your best source of information about the game engine. Many people already noted: there is no way that creator of the game can envision all the possible bugs and unexpected behaviour of the game once it's live. Some things are just details that you neglected/forgot to do, but some are game options that you never imagined a player would try but it's still allowed within the game engine. Also, test-players should be of various 'kinds' - from experienced gamers to your granny or younger brother: each can give useful information about some aspects of the game (young brother might just say: "I have no idea what I'm looking at!" xD) and you should pause to think of each of them :)

--------------
Well, that's it for now :D Would love to hear your comments and experience :)
Last edited by Nihilant on Wed Jul 25, 2012 4:07 pm, edited 1 time in total.
User avatar
OldRod
Posts: 1321
Joined: Sun Sep 20, 2009 4:26 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by OldRod »

Awesome writeup!

Just gave it a quick read - will read it more indepth later. Thank you for posting this!!
User avatar
hallsofvallhalla
Site Admin
Posts: 12031
Joined: Wed Apr 22, 2009 11:29 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by hallsofvallhalla »

I am still reading through this but good stuff so far and thank you for it. Will add more when I finish
User avatar
Nihilant
Posts: 47
Joined: Wed Aug 31, 2011 8:24 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Nihilant »

Thanks guys, would really like to see comments later on. I've added few more paragraphs. Cheers.
User avatar
Ark
Posts: 427
Joined: Wed Jun 01, 2011 10:25 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Ark »

Awesome! Thanks for the hints.
Orgullo Catracho
User avatar
Jackolantern
Posts: 10893
Joined: Wed Jul 01, 2009 11:00 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Jackolantern »

Very cool write-up! It is interesting to see other people's development and design process, and definitely interesting to see what you were wanting to make going in :)
The indelible lord of tl;dr
User avatar
Sharlenwar
Posts: 524
Joined: Mon May 28, 2012 7:14 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Sharlenwar »

I skimmed over this, and it is definitely amazing. Great job on writing up your experience and all of that. Surprising as it may seem, this will help many people who will come to read this post.
Deep within the Void of Quasion, a creation.

**My Corner of the Web**
***NEW***GrindFest - My own PHP/MySQL game!
Sharlenwar's Adventures
Torn-City - Massively multiplayer online text based RPG
User avatar
Jackolantern
Posts: 10893
Joined: Wed Jul 01, 2009 11:00 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Jackolantern »

I stickied this because I personally think it is a great read, and Technarhia looks amazing and quite deep, so I think it would be a crime for anyone wanting to make a browser game to pass this up :) And seeing how we have no stickies in the Game Design section, this one seems like a great start! Great work!
The indelible lord of tl;dr
User avatar
Nihilant
Posts: 47
Joined: Wed Aug 31, 2011 8:24 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by Nihilant »

Thank you, Jack :) I've said it in the other topic, but yeah it's in testing phase and on free server (which will surely close the account as soon as we get their attention xD) so I'm reluctant to gather too many testers at this point. However :D If any of you guys want to test it out, feel free to PM me and I'll get you a link :)
User avatar
tmcdonnell
Posts: 4
Joined: Tue Mar 15, 2011 8:15 pm

Re: Development Hints: Behind the scenes of Technarhia MMO

Post by tmcdonnell »

Great 'Behind the scenes' post.
Thanks
Post Reply

Return to “Game Design”