What should i do now

ID:1391389
 
Oct 4 2013, 1:32 pm
(See the best response by Ter13.)
Code:
/*
    These are simple defaults for your project.
 */

world
    fps = 25      // 25 frames per second
    icon_size = 32    // 32x32 icon size by default

    view = 5     // show up to 5 tiles outward from center (13x13 view)


// Make objects move 8 pixels per tick when walking

mob
    step_size = 8

obj
    step_size = 8

mob
        icon = 'person.dmi'
        var
                hp = 20
                mhp = 20
                str = 12
                def = 4
                armor_equipped = 0
                weapon_equipped = 0
                nin = 6
                nindef = 3

var
    obj
        gun
            g = new/obj/gun()

turf
        grass
                icon = 'person.dmi'
                icon_state = "grass"

turf
        water
                icon = 'person.dmi'
                icon_state = "water"
                density = 1

world
    name = "My First Game."
    turf = /turf/grass

mob
        Login()
                usr.icon_state = input("What gender?") in list ("male","female")
                usr.Move(locate(1,1,1))

mob
    verb
        OOC(t as text)
            world<<"[usr] says: [t]"
        Say_to_view(t as text)
            view()<<"[usr] view: [t]"
mob/female
        icon = 'person.dmi'
        icon_state = "female"

mob
    verb
        Attack(mob/M as mob in oview(1))
            flick("attack",usr)
            var/damage = usr.str - M.def
            if(damage <= 0)
                usr << "nigga you slow"
                M << "your to fast for [usr]'s attack."
            else
                M.hp -= damage
                usr << "[usr] fucked up [M] and took [M]'s booty with [damage] HP!"
                M << "[usr] fucked up [M] and took [M]'s booty with [damage] HP!"
                M:deathcheck()

mob
    proc
        deathcheck()
            if(src.hp <= 0)
                view() << "[src] dies!"
                src.mhp += 30
                src.hp += src.mhp
                src.Move(locate(1,1,1))
                usr.str += 1
                usr.def += 1

obj
        gun
                icon = 'person.dmi'
                icon_state = "gun"
obj
    gun
        verb
            Get()
                set src in oview(1)
                usr.contents += src
                view() << "[usr] picks up \a [src]"
            Drop()
                if(usr.weapon_equipped == 0)
                    new/obj/gun(usr.loc)
                    view() << "[usr] drops \a [src]"
                    del(src)
                else
                    usr << "take of your weapon 1st"
            Equip()
                if(usr.weapon_equipped == 0)
                    usr.overlays += g
                    usr.str += 2
                    usr.weapon_equipped = 1
                    usr << "you equip \a [src]."
                else
                    usr << "You are already wielding something."
            Unequip()
                if(usr.weapon_equipped == 1)
                    usr.overlays -= g
                    usr.weapon_equipped = 0
                    usr.str -= 2
                    usr << "you unequip your gun."
                else
                    usr << "You aren't wielding this."
mob
    Stat()
        statpanel("Inventory",usr.contents)
        statpanel("Stats")
        if(statpanel("Stats"))
            stat("Name: [usr]")
            stat("Health: [usr.hp]/[usr.mhp]")
            stat("Strength: [usr.str]")
            stat("Defense: [usr.def]")
            stat("Ninjutsu: [usr.nin]")
            stat("Ninjutsu Defense: [usr.nindef]")


Problem description: i dont know what to do / practice doing ter said i shouldnt goto projectiles but i dont know what to do now

Oct 5 2013, 3:37 am
Best response
Well, that's going to be hard to tell you. Programming from a design document is going to keep you from getting stumped, and help to keep you on track. You should always plan out a design document before you make a game.

As for learning to program, I'd advise spending some time reading tutorials on syntax and some common implementations so you can see what other people do.
Oct 5 2013, 3:40 am
IS autoIT a good focus for now?
Oct 5 2013, 3:41 am
What is AutoIT? You mean the basic-like programming language?
Oct 5 2013, 3:42 am
im really not trying to make a game im just practicing so i can help make a game thats why i wanted to know what i should try doing next
Oct 5 2013, 3:43 am
and yes AUto IT is a basic programming language it makes bots
Oct 5 2013, 3:44 am
but if your really good at it you could make more than that i started at that and i had a teacher and that teacher said that DM is easy so decided to try it out
Oct 5 2013, 3:47 am
Also you said i should take it slow so i made a AI system but i got a runtime error
Oct 5 2013, 3:52 am
Well, being good at programming is just really based on how well you understand the underlying concepts.

Things like:

How do software applications allocate and manipulate memory?
What is polymorphism, and how do I use it to my advantage?
When do I use objects, and when do I write raw functions?
How do Virtual Machines work?
How do I manipulate and collate data structures?
Basic Math. (In some cases, it may be algebra, calculus, trigonometry, differential equations, etc, depending on the needs of the project.)

And for game development:

What input/output schemes are popular for what kinds of games and why?
What kind of feedback do players expect from X system?
When is balance necessary, and how do I ensure fairness?
You can, but why would you?
What's the difference between a good idea and a bad one?


Storyline and setting:

What makes a plot compelling?
What are the basic elements of any story?
Understanding of common tropes and themes.
Understanding characterization and when it is important.
Human psychology and behavioral sciences.
Effective writing.
When to tell your story and when to let it be told.
Understanding your audience.
Familiarity and the dangers of being unique.


There are literally thousands of things I could rattle off that you need to understand before you can really begin to understand such a diverse and complex subject as Game development.

Nobody can really tell you where to start, and nobody can really teach you everything. You have to have the drive and motivation to make mistakes and learn from them.

The best way to make mistakes in order to learn game development, is make a game. Or fail to make one. Either way, you will learn.
Oct 5 2013, 3:52 am
In response to Kidmaster1232
Make a game P: It'll give you all the practice you need to ... make a game.
Oct 5 2013, 3:56 am
hmmm :D i would understand this language alot better if i had someone to gimmie projects and proc to use for the proj for some reason im not a good by myself programmer thats how i usually learn they gimmie me 1 proj and i do more than ii am supposed to cause i just understand more out of 1 lesson
Oct 5 2013, 4:00 am
oh yea ter how come i hae not seen any games that you hae made your a good programmer
Oct 5 2013, 4:12 am
but yea ik its not good to depend on others but i find it lonely without someone to learn/code with
Oct 5 2013, 4:22 am
In the professional world, learning is best assisted by peer review of the work. I've put some comments and resources for you to look at below.


This looks like you are creating this object to use as an overlay item, but it is exactly the same as the one they are equipping. You should not create the g, and just use the one they equip to give the overlay.
var/obj/gun/g = new/obj/gun()



obj
        gun
                icon = 'person.dmi'
                icon_state = "gun"
obj
    gun
        verb
            Equip()
                if(usr.weapon_equipped == 0)
                    usr.overlays += g
                    usr.str += 2
                    usr.weapon_equipped = 1
                    usr << "you equip \a [src]."
                else
                    usr << "You are already wielding something."
            Unequip()
                if(usr.weapon_equipped == 1)
                    usr.overlays -= g
                    usr.weapon_equipped = 0
                    usr.str -= 2
                    usr << "you unequip your gun."
                else
                    usr << "You aren't wielding this."




This code has abuse of the colon operator (:). The colon forgoes any compiler checks. As you typecast the M to a mob, then this shouldn't be needed. If you change this down the road forgetting that M should be a mob, the compiler will not warn you.

mob
    verb
        Attack(mob/M as mob in oview(1))
            flick("attack",usr)
            var/damage = usr.str - M.def
            if(damage <= 0)
                usr << "nigga you slow"
                M << "your to fast for [usr]'s attack."
            else
                M.hp -= damage
                usr << "[usr] fucked up [M] and took [M]'s booty with [damage] HP!"
                M << "[usr] fucked up [M] and took [M]'s booty with [damage] HP!"
                M:deathcheck()



This section of code contains usr abuse. If something other than the attack kills them (lets say a projectile), this will cause some nasty run-time issues. [for more on when to use usr vs src, take a look at Dream Tutor: usr Unfriendly]
mob
    proc
        deathcheck()
            if(src.hp <= 0)
                view() << "[src] dies!"
                src.mhp += 30
                src.hp += src.mhp
                src.Move(locate(1,1,1))
                usr.str += 1
                usr.def += 1


A common practice to think about for programming is one function does one job. Refactoring your code to that would make it look like the following:

mob
    Login()
        src.icon_state()
        src.move_to_start()

    proc
        icon_state()
            src.icon_state = input("What gender?") in list("male","female")

        move_to_start()//we have a common place to go to relocate.
            //This allows us to move it at anytime we want in one place.
            src.loc = locate(1,1,1) //locate moves even if someone else is there.

        take_damage(amount=0,mob/attacker)
            src.hp -= amount
            attacker << "[attacker] fucked up [src] and took [src]'s booty with [amount] HP!"
            src << "[attacker] fucked up [src] and took [src]'s booty with [amount] HP!"
            src.deathcheck(attacker)

        deathcheck(mob/attacker)
            if(src.hp <= 0)
                view() << "[src] has been killed by [attacker]!"
                src.increase_hp()
                src.restore_health()
                if(istype(attacker))
                    attacker.increase_power()
                src.move_to_start()

        restore_health()
            src.hp = src.mhp
        increase_hp()
            mhp += 30
        increase_power()
            src.str += 1
            stc.def += 1
            src << "You feel stronger!"

    verb
        Attack(mob/M as mob in oview(1))
            flick("attack",src) //can change usr to src
            var/damage = usr.str - M.def
            if(damage <= 0)
                src << "nigga you slow"
                M << "your to fast for [src]'s attack."
            else
                M.take_damage(damage,src)


Doing it this way, everyone should make their own changes to their variables (as byond is class-full) and it is cleaner in my opinion to see what is going on and debug.

The biggest gain is in re-useability. As programmers in general, we like to be lazy. This means no copy and pasting, and no having to update multiple things in different places in the source.
Oct 5 2013, 4:38 am
lol thanks for does tips all add them to my code right now
Oct 5 2013, 4:58 am
Ter can you message me i wanna talk about a runtime error talking on the forums is no help since you usually answer my question
Oct 5 2013, 4:59 am
In response to Kidmaster1232
Kidmaster1232 wrote:
oh yea ter how come i hae not seen any games that you hae made your a good programmer

Ter13 wrote:
The best way to make mistakes in order to learn game development, is make a game. Or fail to make one. Either way, you will learn.
Oct 5 2013, 5:01 am
so is that a no xD?
Oct 5 2013, 5:09 am
*looks at ter thinking he is writing and not paragraph*