Design-Focused approach.
Well it seems that these days too many games are just thrown together, with the programmers literally playing a hit-and-hope game to see if their game idea will be any good. I'm writing this small article today for the BYOND community as a little guide for new and perhaps even existing users. Call it a quick-start guide or whatever.
Registering
BYOND is an entire online programming and gaming community, and to use its software properly you'll need to register. Registering is simple, simple go to http://byond.com/register to register what we call a key.
Keys are the same thing as usernames, they're your identity throughout the community. You can create more than one for testing purposes, but we prefer you don't.
Once you've registered a key, you'll get an e-mail with an activation number, punch that into the provided link and you're all set!
Downloading
The next important thing for you to do is to download the program. You can get BYOND on Windows, Linux and Mac. However most features are available on Windows. To download BYOND, go to http://byond.com/download/ and pick your version!
Getting Started
This part is more of a warning than a guide. People on BYOND are more or less split into 4 main 'communities' which tend to keep to themselves. There are the oldbie-gurus who just hang out in BYOND chatrooms, play the odd-game here and there and are mainly just cynical and tend to be mean to new people; so don't mind them.
Then there's the DBZ/Naruto/General Anime category, who are basically just people who love Anime. A lot of these people are complete idiots, but some of them are actually quite decent guys.
Thirdly there's the game-machine community, who are just like a lot of people working on their own games constantly, give up and try another project. This happens a lot in BYOND and it'll likely happen to you without the proper planning. More on that later.
Lastly, there's the kids who don't fit in with anything else, they can't program, but they love the games. They mainly hang out in some of the popular games.
The difference between my interpretation of 'noob' and 'newb'
'noob' - A 'noob' is a new member of the community who does not have the motivation, self-respect or capacity to actually genuinely learn the programming language, tends to troll around and cause trouble because they have nothing better to do with themselves. Those who do 'try' to learn the programming language, tend to expect people to work for them, and give them full systems which they complain about if they don't 'plug and play'.
'newb' - A self confessed new member, the 'newb' tends to be interested in learning about the program, and all he can. He will search for information and learn. In the future the 'newb' (as opposed to the 'noob') will be a valuable member of the BYOND community.
Ready to go? Sure?
Well once you have registered, downloaded and installed BYOND, you can run the 'BYOND' program (the blue one) and then enter your login details. Once you're in you'll be greeted with your lovely BYOND Panel. That's yours. It's your source to playing games.
So what do you want to do? If you're here to play games, then go mad! Click the 'Find Games' button to search through the games available on BYOND (It'll open up a browser). If you're here to learn the BYOND Programming Language (DM), then the next part is for you.
Meet the Dream Maker
To give you a quick-fire taste of programming in the DM language, there are a few good tutorials you can use. The best in my opinion are Zilal's tutorials, or ZBT's, available at the links below. They are designed to give you a really fast introduction to the basics of BYOND. They're really helpful to get you started, and to find out if you really are interested.
If you're interested in making a Action/RPG game, use this link to get started:
http://www.byond.com/members/ DreamMakers?command=view_post&post=36143
If you're interested in making a Board/Strategy game, use this link to get started:
http://www.byond.com/members/ DreamMakers?command=view_post&post=36233
If you're interested in making a Text MUD game, use this link to get started:
http://www.byond.com/members/ DreamMakers?command=view_post&post=36273
Once you've had your intro to the language, you should know whether or not you want to continue with the language. If it's for you, then you're gonna want to learn everything you can. The best place to learn everything is the DM Guide which has nearly everything. You can see the guide here: http://www.byond.com/docs/guide/
After that, you may be confused about some things, if so you can use one of the following resources to get help!
BYOND Developers Page - http://www.byond.com/developer/
BYOND Developer Forums - http://www.byond.com/developer/forum/
BYOND DM Reference - http://www.byond.com/docs/ref/
BYOND Chatters - http://www.byond.com/games/Xooxer/Chatters
You can't go wrong at any of the above links, I'm usually in Chatters and I'll be willing to help you out, the forums are full of people who are more than happy to help, the reference is great for getting intimate with the functions available in DM, and the developers page is great for general articles of interest and learning new features and interesting methods.
Making Games - Hit and Hope?
As I mentioned above, most games today on BYOND are thrown together, like a hit-and-hope game of pool. The chances are it'll turn out crap, but some don't. Don't take the risk, save our sanity!
Everyone can learn to make games. It's easy. Making GOOD games however, is an Art. It takes effort and commitment to make a truly addictive game on BYOND. It just doesn't happen overnight. Those of you who think it does, you're either a genius or a fool. I'm betting on the latter.
So how do you make a good game on BYOND?
The first thing you need to do is think of a good original idea. You can't rip people off. Not only is it not right, but if you do, the entire community will boycott your game. Apart from the DBZ guys. They do the whole 'not original' thing all the time. :D
So you have your idea. Sit there, brew it up in your mind for a few days. Think about how you can do certain things, think about how you're going to 'balance' the game, how you're going to make the player hang on the edge of his/her seat, sit up playing your game all night. What makes gamers tick?
Once you're sure what you want your game to be about, you need to write it all down. Not programming, design! You're not ready for programming yet!
Design Documents
With Game Development, most developers have HUGE design documents detailing every single option and condition within the game. BYOND makes things so much simpler with it's Built in Graphics/Movement system with DM. Not only do you need less documentation, but implementing your ideas becomes about 10 times easier with the correct design.
You'll need two documents for your game design, which'll evolve as you program the game. They're never 'finished'. They're workable, but not finished; The Concept, and the Specification.
The former is not required, but it makes writing the specification much easier.
The Concept
The concept is a design document in which is usually about 2/3 pages long. You write down a brief 'setting' or 'story' to engage the reader in the idea, describe a scene within your game. Next you'll need to write down the overview of the game. What type of game, what it's going to be called, how many players it's gonna use, what features you need to include, what features would be nice but not required, etc. This document exists to aid you.
The Specification
You're going to need to list everything you're going to include in the game. That may sound like a daunting task now, but believe me, if you just start programming your engine, putting in everything is going to get annoying when you suddenly realise halfway through your 'movement' system, that you've forgotten to define some variables, forgotten to provide some vital figures, and you're off on a hunt to get that sorted which CAN at times take all night.
List the following things in the Game Specification:
- Game Overview (List of features, type of game, etc)
- Players
-- All player options
-- Player Creation - How does it work?
-- Player Handling - How will you handle players?
-- NPCs - Are NPCs required? Artificial Intelligence? Describe it.
- Items
-- What items are you going to need?
-- How do you pick them up, drop them?
-- How do you use them?
- Administrator
-- How are you going to control your players online?
-- How many options will you give yourself and other admins?
- Icons - What icons are you going to need?
- Sounds - What makes a noise? You need to describe the sounds you'll need.
- Other - Anything else you think is relevant.
Starting your Game
Once you've finished the Specification you should take a break for a day or so, get your energy back up. But after that, you're ready to go! Full throttle! Yeah! ... and stuff.
The first things you'll want to do is build a foundation for you to build the game on. A few base variables, objects, a map, and some basic systems to work from, set up key systems testing as you go, and then prioritise other features. Which is the most important?
Do you need to re-write the built in movement system? How? Consider these things.
Work through the specification making sure everything you've written down is programmed into the game. As you go along, and reach milestones, like, you finish a certain system, make sure you test it. Compile often, and test often. There's nothing worse than writing a whole game, hitting 'compile' and watch about 900 errors pop up at you. (It's happened.)
Once you've reached the last page of your specification, you should be done. But you're not.
There's always the last minute changes, the last minute balancing. Maybe a certain weapon is too powerful, tweak it a little to damage less. Maybe you forgot to program the hair-styling system. Double check everything. Make a tick-chart! Cool!
Testing & Debugging
Debugging is the best way of finding out how bugs occur. After every stage of a procedure that you believe is bugged, add a line of information to output to the world informing that the previous statement was successful.
That way, the last message you get means the next statement after that is your problem. Then you find out exactly what's wrong.
Easy!? Yep.
Polishing & Publishing
Ready to let your game be ripped to shreds by the community? Make sure you have fixed all the bugs you can find, and then host it online! Hosting is easy.
When you Compile and Run your game, you can see the the 'File' menu. Simply click that, click 'Options and Messages' and then set up your hosting from there. A good port I'd recommend is 6001, as that's the port BYOND likes to use to connect to the hub. =] Speeds things up a bit.
Dealing with Complaints, Suggestions, and Admin Requests
It's going to happen. Complaints come and you're gonna have to deal with them. Take them in your stride. Most complaints are either given because something is genuinely bad, in which case, oh well, you tried, or because they're jealous of your work, in which case, just laugh. Suggestions is obvious. If it's one you think would help the game, add it! Admin requests.. Well let's just say unless you think the guy is trustworthy, don't even think about it. :|
Anything else?
I don't think there's really anything else to be covered really. If you have any questions I'll be in Chatters mostly, or just ask on the Forums.
Enjoy BYOND guys, and welcome!
Aug 6 2008, 10:22 am
|
|
IcewarriorX
 |
So....People are noobs because they don't want to mess with the DM language? I get it now.
|
Well not exactly, a 'noob' is someone who just doesn't want to do all the work themselves and are too impatient to sit down and learn for themselves how to do certain things. The same can be said for various other instances, such as video games.
| |
To be honest I've never made a Game Specification in my life. Normally because I just start with a basic idea and patch on new things as I go.
I never make games that are going to be finished then left aside. A constantly evolving game is a constantly fresh experience, which is the only way a BYOND game can end up prospering in the end. -M | |
This tutorial is designed as a quick start guide to new members of the BYOND community using a design-focused approach. It allows them to follow it to get their game into a working condition.
I am in the process of writing another guide for design-based expansion of games. Also for someone saying they never make a game specification you have an awful lot of games based on non-BYOND games in development. How many of them are actually playable? | |
Nice guide, only spotted one typo: They do the whole 'not original' thing al lthe time. :D
I'm sure this will help plenty people out too. | |
My bad.
| |
Another typo is "adminstrater". The preference is "-or" for that word.
(I've never quite understood the difference between "-er" and "-or", however. "-pt" becomes "-pter" while "-te" becomes "-tor", apparently, but I see no actual reasoning behind it.) | |
I USED TO BE A NEWB!!!!! When do I become a respected member of BYOND :(?..... Perhaps Im not quite done being a newb? Am I a ---b? =).. Anywho, the guide seemed pretty well put together... However, I disliked reading so much.. Sorry =)... As for people hastling you over spelling errors, look at it from this perspective... Spelling was the only thing they could find wrong with what you said ;)...
| |
Very nice, and mostly true I would say, and the comment below me has too many .'s, I think he should have ran out by now ^^
| |
One thing I would have said about making a game is the way you do things.
You basically said make variables/icons/stuff then add features to the game. What I personally do is start off by making the very basic things that only I need to do stuff. A small map where I can test things and so on. After that I start working on systems the game will use, and then I will finally add content to the game. Basically I will first make a place to put and test items, then before making items I will add systems to get/drop items and to use them. Once that is finished then I will actual items (items that will be used in game, I might make test items to test that picking up/dropping/using items works). Much the same, I wont add monsters without a working, flexible AI that can support the sort of monsters I want. The above should really be common sense, and if done right you can make a robust system and get all of the hard work out of the way, then adding new items/monsters/quests and what not becomes easy and takes seconds to do. | |
Using the design focused approach, making the variables, icons and media first is useful because you already know what you need, and once those are defined, it becomes much easier to make the systems.
| |
AZA wrote:
Using the design focused approach, making the variables, icons and media first is useful because you already know what you need, and once those are defined, it becomes much easier to make the systems. Even if you plan everything out there is no way of telling exactly what variables you will need. Until you actually make something you will probably not know the exact specifics of what is needed. You might know it will work in a certain way, but that is about all. Basically, until I start making X system I will not define any variables for it, because I have no idea just what sort of variables it will need. Anyway, that wasn't what I was getting at. You didn't give very much information about how you would go about making a game. You said "define stuff, then make it" basically. What I was trying to say was before I even add any items to the game (except for maybe test items) I will add all the systems that are needed to support these items. Picking them up, dropping them, using them, equipping them and so on. I would also make these systems as flexible as possible, so they are quick and easy to use and adding new features to them would not effect anything else. An exampe would be for items, all item effects when used are stored as a datum of type itemeffects, these datums are stored in a list the item has and when used the list is looped through and each datum has a proc executed. Doing this new datums can be made without it effecting anything else, nor does the system need to be changed to work in these new effects. You get the idea, before you build a house you make the foundations, otherwise the house will just collapse. Before you make a game you (should) make the foundtations, otherwise the game probably ends up being to hard to continue with making. | |
Before you build a house, though, you need the raw materials, blueprints and tools. Otherwise you can't do it.
You may not need them until a later time but you make sure you've got them none-the-less. Besides, this guide is focused on newer members getting a kick-start in the game creation community here with smaller games, not hugely complicated games that take weeks if not months to make workable. For -that- I'll be making a separate guide which will be ... very big. It's already in creation. | |
I'd heavily advocate against writing variable names down. Mostly because that seems like a whole lot of work for something that will inevitably change over time several times.
The general idea of using design documents however, is definately a valid one. | |
Okay so there's issues with the order of implementation of game specific content. The rest of it still stands.
| |
Nice tutorial, me mucho gusta!
| |
i was trying 2 do zilias tutorial but, when i tryed 2 put grass into my map it wouldnt show up like it said it would....i think i did a mistake in my codes...can u plzz help and give me the codes in putting grass.
| |
Okay, a load of typos and grammar issues corrected (Thank you Nadrew)
Also, Forest of death: Make sure you have set the grass icon and icon_state (if you have defined an icon_state within the .dmi file) like this: turf/grass icon='youricon.dmi' //This is the file icon_state="youricon_state" // this is the icon_state (the name underneath the icon) If that doesn't help, feel free to show the code, and I'll tell you where you're going wrong. | |
how do i make anime byond games | |