ID:109791
 
Next up, we're going to create some basic enemies for our game, and an attack verb that can be used by both the player and the enemy.
If you haven't already read Tutorial #6, you should check it out first. Or, start at the beginning, if you're new to the series!

Attacking
To start off, we'll create a common Attack verb, which can be used by both NPCs and Players.

Step 1.1 The following code can be inserted at the end of Verbs.dm (under the Who() verb)
    Attack()
flick("Attack",src)
for(var/mob/M in get_step(src,src.dir))
var/Damage=max(0,src.Str-M.Def)
view(M)<<"[src] hit [M] for [Damage] Damage!"
M.TakeDamage(Damage,src)
http://www.angelfire.com/hero/straygames/Tutorial/ AttackVerb.png
flick() is a built in proc that will play an icon_state from start to finish on an object.
Since we don't have an attack animation for our player, this will just cause us to disappear.
get_step() is another built in proc, it will return the tile that is one step in the specified direction from a specified object.
In our case, we use get_step() to find the tile in front of the attacker.
We use a for() loop to go through every mob in front of the attacker, and set them to M.
Next we figure out how much damage we dealt. This just uses a basic Strength-Defense formula.
We use max() here to make sure the damage isn't negative.
Then we output a simple message to everyone nearby about the attack and damage.
The last line calls a new proc (TakeDamage) which we will create in the next section.

Step 1.2 Now that we can attack, lets process the actual damage. The following code can be inserted at the end of Procs.dm (under the LevelCheck() proc)
    TakeDamage(var/Damage,var/mob/Attacker)
src.HP-=Damage
src.DeathCheck(Attacker)
http://www.angelfire.com/hero/straygames/Tutorial/ DamageProcs.png
The TakeDamage() proc takes 2 arguments. One for the damage being taken, and a /mob type variable for the person dealing it.
It then does a simple subtraction of the damage from the targets HP.
Finally it runs a DeathCheck proc on them, which is created below.

Step 1.3 Now we need to check if you're dead! The following code can be also inserted at the end of Procs.dm (under the TakeDamage() proc)
    DeathCheck(var/mob/Killer)
if(src.HP<=0)
if(src.client)
world<<"[Killer] Killed [src]!"
src.HP=src.MaxHP
src.loc=locate(5,5,1)
else
Killer<<"<b>You Killed [src] for [src.Exp] Exp"
Killer.Exp+=src.Exp
Killer.LevelCheck()
del src
This proc takes an argument as well, but only one, which represents the killer. It is passed from the TakeDamage() proc using the Attacker.
First, we check if you're actually dead, if your HP is less than or equal to zero.
We then do a quick check if its a player (with a client) or just an NPC, since we'll want to handle their deaths differently.
If a Player dies, we'll let the entire server know =(
Then we'll reset their HP to max.
Finally, we'll relocate them, preferably somewhere safe.

If an NPC was killed, we give whoever killed it some Exp.
We'll use the Exp variable on the Enemy to represent how much they're worth.
Then we'll run the LevelCheck() proc on the Killer to see if they have enough exp to level up.
Then we delete the NPC from existence!

Continue to Tutorial #8: Enemy AI
Nice stuff. It answers a couple of questions I've had. Thanks
Falacy can Tutorial #9 Something about the Interface and The Byond Skins?
For the amount of content you cover this is very wordy and there's nothing people can run. When you write a tutorial you should try to write as little as possible. I'm not sure what you expect people to do with this tutorial - manually copy text from .png images into Dream Maker?

Anyone who has the patience to read this all probably knew 90% of it to begin with. I think this would work much better as a downloadable demo with good comments in the code. BYOND already has a lot of tutorials that are giant walls of text and we can see how ineffective they've been.
Forum_account wrote:
For the amount of content you cover this is very wordy and there's nothing people can run.
Its part of a series, starting in the middle won't accomplish much.

When you write a tutorial you should try to write as little as possible.
This one is a lot longer than most of mine, but it covers an entire battle system (be it a lame one, for now). A sentence to explain what each thing does is wordy?

I'm not sure what you expect people to do with this tutorial - manually copy text from .png images into Dream Maker?
I expect them to actually learn something. If by manually copy it from a .png, you mean typing it into DM themselves, then yes, I do expect that, stated in the first tutorial. If they just want to copy and paste, though, the text version of the code is right there with the images.

Anyone who has the patience to read this all probably knew 90% of it to begin with.
I'm not sure if you fall into that category or not, but you apparently didn't even make it through the 2nd line. Or just didn't care enough to actually go back through them all?

I think this would work much better as a downloadable demo with good comments in the code.
http://www.byond.com/games/Falacy/RPGStarter

BYOND already has a lot of tutorials that are giant walls of text and we can see how ineffective they've been.
Where? The only similar one(s) I know of are by Zilal. And you think mine is wordy...

Maybe I shouldn't call them tutorials, but instead more correctly label them as a series about actually making an entire game from scratch? These tutorials are designed to hold your hand every step of the way. Not only to show and tell you exactly how to do everything, but to explain how everything actually works. So, hopefully, you can go back and effectively do it again on your own.
Vent Matalik wrote:
Falacy can Tutorial #9 Something about the Interface and The Byond Skins?

Tutorial #8 will cover interfaces, at least minimally, since it they're intertwined with setting up macros.
EDIT: Split this one, so that's bumped back to #9.
Tutorials, like any other resource, aren't just one-shot brain dumps where you write everything you can think of about a particular topic. Resources should be written and maintained. If you're not willing to refine the tutorial to improve it, think about why you wrote it in the first place. Are you trying to help people? Or are you trying to show that you're capable of writing a tutorial so that you look charitable? You don't need to post an answer. It's important that you know the true answer, I don't need to know it.

There's no reason a tutorial that only describes the code for a very basic combat system should be over 1,000 words. It's no wonder people make rips - wordy tutorials make the process of creating a game from scratch look complicated.

The word count alone isn't the only problem. You have a lot of text that is just a redundant description of the code (ex: "Then, at the very end, we sleep() for a random amount of time between 4 and 8 ticks using rand()"). That doesn't need to be said at all. The text should explain things that aren't stated by the code itself. You do this to a limited extent - you do explain that without the sleep() call the loop would freeze the game, but you don't explain what the rand(4,8) is for. Some of the descriptions are decent (ex: explaining the New proc) and some just repeat what the code already says (ex: explaining the CombatAI proc).
Forum_account wrote:
Tutorials, like any other resource, aren't just one-shot brain dumps where you write everything you can think of about a particular topic. Resources should be written and maintained.
That's the very reason I'm posting them in areas that can receive comments; to improve them via feedback. If you want to post productive feedback yourself (as you have managed to do this time) then its welcome.

There's no reason a tutorial that only describes the code for a very basic combat system should be over 1,000 words. It's no wonder people make rips - wordy tutorials make the process of creating a game from scratch look complicated.
Everything needs to be explained. I could just throw a functional combat system at them, with no explanation. Nobody would understand it, everyone would just paste it into their game, and be glad it works. AKA a Library.

You have a lot of text that is just a redundant description of the code (ex: "Then, at the very end, we sleep() for a random amount of time between 4 and 8 ticks using rand()"). That doesn't need to be said at all. The text should explain things that aren't stated by the code itself.
sleep() (by name) doesn't have the blatant functionality of making things wait (wait() or pause() probably would have been better names). Though it is a common function here, to somebody who has never programmed before, or even to people who just haven't used DM, its use may be unknown. rand() is probably less confusable, but its explanation goes along with how we were using sleep().
spawn() is even worse off than sleep() is. I'd bet most people new to the language would think spawn() actually spawned things - as in created new objects - which it doens't.


some just repeat what the code already says (ex: explaining the CombatAI proc).
Exactly. It explains what the code does, in plain English. This way anyone reading it should be able to understand how it works.

I do agree this tutorial is too long, and worked on cutting it down while I was writing it. It was originally combined with Tutorial #6, but that was just ridiculous.
Well, I did some minor rewording, and split it into 2 sessions. Maybe that will help.
Your approach is just fundamentally wordy. If you try to explain both the basics about what the sleep proc is, what it does, and how you can use it in creating a combat system, you're going to end up with a very long tutorial.

If you split it into one tutorial that explains programming (vars, procs, etc.) and another tutorial that explains how to program a combat system, you'll end up with two simple tutorials instead of one really complex one. People who understand programming can skip to the second tutorial instead of skipping bits and pieces of the one large tutorial. It's also easier to write each tutorial because you can make clear assumptions about what knowledge you expect the reader to have initially.
Falacy, I really appretiate that you are taking time to explain this to us begginer coders! I for one don't think that you over wording anything, As you said this is very useful for someone who hasn't touched DM or someone who is new to it so I really like that you take the time to explain every detail of it! I really think you should do a tut on Missles!
I like the format of this tutorial since it's short and straight to the point along with visual examples for extra guidance.
Thanks for taking the time to create the series for us programming noobs lol
I tried the Attack verb but the M.TakeDamage(Damage,src) It was a error. What should I do?
I'm having a bit of trouble, it's telling me src.Str is an undefined variable, when it is defined once and used 3 other times in the code, without error.
falacy pleas help me my issue is that in my game the character is walking tro water and wall and trees and doors pleas help
BB-boy, he isn't going to help you. These are tutorials, don't ask for help here. Go to the developer help section. However, it sounds like your mob's density is set to 0 or nothing in your game has a density of 1.
hi i was just wondering where the heck the Attacker and Killer are found in the attack verb ( meaning how does the dm figure out who is attacking and who is getting attacked)
In response to Natasdrol
diagram

Attacker and Killer are defined as parameters for TakeDamage() and DeathCheck() respectively.

In Attack() we see we loop through mob/M in get_step(). For each one we find, we calculate the damage and call M.TakeDamage(Damage,src). M in this case is the one calling the procedure, and as the second argument of TakeDamage() (which is the mob/Attacker, we supply the person that attacked M.)

In TakeDamage() we subtract the damage done from src's health (who is the one calling this procedure, which we saw before was M.) Then, Attacker is passed as an argument into DeathCheck() as it takes a parameter to say who killed src.
Don't know what the heck forum_account is talking about but this help me understand it from the basic. its like that momment you say Now I know. hahah or something like that.
thanks a lot "me lord" lol now i get it! and yes this tutorial has helpped me a bunch also showing me stuff i couldnt quite get just from the guide... like the a.i.
Page: 1 2 3