RealBasic

[WarHampster]

They're the same thing...

[Gan]

Don't functions return a value, and methods don't?


-Gandolf

[WarHampster]

Speaking from experience, the methods in silver creator can return values.  

[Silverwind]

Well, after reading quite a bit on Methods in the REALbasic User's Guide, I've come to the conclusion that the easiest way to describe them (in GM and REALbasic context) is that they're user invented commands. The extent of Method design in Silver Creator is being able to write the routine that'll be run when the Method is executed, but the extent of Method design in REALbasic is slightly higher. In RB you can actually alter the syntax of the command, adding additional parameters and such stuff.

I now completely understand what an "object orientated" language is. It's a language intertwined with its interface builder. Many of the variables that you reference aren't created by code visible to the user, instead the interface elements handle them for you. Text fields for example have a "built-in" variable called Text which updates every time the user types something into it, and it equals whatever content the text field holds. So a command such as "Var$ = Text$" (this is GM syntax, but the concept is the same for RB) would make Var equal whatever text was in the text field. The user wouldn't have used code to make Text$ equal anything though, the text field handled the value itself. That's basically what object orientated languages are; languages with interface elements to handle vars.

One of the things I don't like about RB's syntax is how you have to create each variable before you use it. That's gonna be sooooo time consuming!

[WarHampster]

The extent of Method design in Silver Creator is being able to write the routine that'll be run when the Method is executed,

Untrue.. methods in SC can take parameters and return values.

[Mystor]

One of the things I don't like about RB's syntax is how you have to create each variable before you use it. That's gonna be sooooo time consuming!

I always declare my variables before I use them, even though I don't have to.
Not declaring them is bad practice.
For example you don't want to accidentally run r++; before you set r=0; or in flash var i:Number = 0;.
It also creates a kind of a variable lookup table:
foobar = 5; //The number of aliens to start with
name = "SuperAwesomeDude"; //Your Name
temp = null; //temporary variable

Anyways, it is good practice.
Most languages require it (GM probally is set up to check if the variable is defined whenever you use a new variable, that slows down execution time)

Mist (PS Sorry for the rant)

[Silverwind]

Untrue.. methods in SC can take parameters and return values.

Oh? Oh yeah, so it says. The documentation's description is incredibly unhelpful though. Could somebody post a code example demonstrating how to reference a parameters value in a useful manner please? It would be most appreciated.

For those interested, here's the documentation's description of method parameter properties:

- Parameters is where you enter a comma separated list of all the values you want this method to accept. For example, if you enter "var1$, var2, var3$" in the parameters, and your Method Name is "BOB", then you would use this code to invoke your method: "BOB "var1$ value here", someNumberHere, otherNumberHere". When your method script is called, the first value passed ("var1$ value here") is stored in var1$. And so on and so forth.

[Silverwind]

I always declare my variables before I use them, even though I don't have to.
Not declaring them is bad practice.
For example you don't want to accidentally run r++; before you set r=0; or in flash var i:Number = 0;.
It also creates a kind of a variable lookup table:
foobar = 5; //The number of aliens to start with
name = "SuperAwesomeDude"; //Your Name
temp = null; //temporary variable

Anyways, it is good practice.
Most languages require it (GM probally is set up to check if the variable is defined whenever you use a new variable, that slows down execution time)

Mist (PS Sorry for the rant)

True, and for variables referenced frequently I do the same, but for variables used for split second tasks it seems an unnecessary effort. Here's two examples from Tides of Fáden:

Code: [Select]

P1LVL = 1
P1EXP = 500
P1HP = 50
P1maxHP = 50
P1ATK = 0
P1DEF = 0
P1gold = 0
P1weapon$ = ""
P1shield$ = ""
P1boots$ = ""
P1item1$ = ""
P1item2$ = ""
P1item3$ = ""
P1item4$ = ""
P1item5$ = ""
P1item6$ = ""
P1item7$ = ""
P1item8$ = ""
P1item9$ = ""

Code: [Select]

P1name$ = USERASK Name your character.
IF P1name$ = "" THEN GOTOCARD 249
replacecheck = 1
namecheck = FILEEXISTS $P1name$$
IF namecheck = 1 THEN replacecheck = YESNOALERT A character with that name already exists. Do you want to replace that character with a new one?
IF replacecheck = 0 THEN GOTOCARD 249

In the first example I predefined the values of numerous variables even though their values were 0 because they're important elements throughout the entire game. In the second example however, variables such as "replacecheck" and "namecheck" are only useful to this particular routine, (which is small) then they're no longer needed in the game. Having to predefine vars like that seems a waste of time.

[Mystor]

You an probally define vars on the spot is you want.

Mist

[Silverwind]

Yeah, that'll make it easier.

What will happen if I try to create a var already created though? Will it return an error, reset the var's value to 0, or do nothing?

[WarHampster]

Once you get used to programming in C, declaring everything is second nature... I usually just declare variable that I will most likely need to use in the game opening script.

Heres an example of using parameters/ returns in SC... it was developed by Plaza Redd and is extremely useful.

Method Name: ChangeField$
Parameters: source$, separator$, fieldNumber, output$
Return Type: String
 
Code:

Code: [Select]

LET tempstr$ = "" 
 
IF COUNTFIELDS(source$, separator$) < fieldNumber THEN 
   STOPALERT "There are not enough fields in that string!" 
ELSE 
   IF fieldNumber = 1 THEN 
 LET tempstr$ = output$ 
 FOR x = 2 TO COUNTFIELDS(source$, separator$) 
    LET tempstr$ = tempstr$ + separator$ + NTHFIELD$(source$, separator$, x) 
 NEXT 
   ELSE 
 IF fieldNumber = COUNTFIELDS(source$, separator$) THEN 
    FOR x = 1 TO COUNTFIELDS(source$, separator$)-1 
  LET tempstr$ = tempstr$ + NTHFIELD$(source$, separator$, x) + separator$ 
    NEXT 
    LET tempstr$ = tempstr$ + output$ 
 ELSE 
    FOR x = 1 to fieldNumber-1 
  LET tempstr$ = NTHFIELD$(source$, separator$, x) + separator$ 
    NEXT 
    LET tempstr$ = tempstr$ + output$ 
    FOR x = fieldNumber+1 TO COUNTFIELDS(source$, separator$) 
  LET tempstr$ = tempstr$ + separator$ + NTHFIELD$(source$, separator$, x) 
    NEXT 
 END IF 
   END IF 
END IF 
RETURN tempstr$

 

Example Code:

Code: [Select]

 
 
LET string$ = "Apple:Banana:Peach:Tomato" 
LET string$ = ChangeField$(string$, ":", 4, "Orange")

[Mystor]

If You are good at C, why do you still use GM/SC \

and @silver
It depends on the language and how it works.
I would suggest testing it out and seeing how it reacts.

In Flash, it creates a compiler note but does not create an error.
The only time when trouble might occor would be when you give it a diffrent type (For example INT instead of FLOAT)

Mist

[Gan]

Vb.net is just like Rb, though you have functions and subroutines.

Ex Code:

Code: [Select]

'Beginning of code:
Public Class Form1()
Dim GameOver As Boolean = False
Dim YouWin As Boolean
Dim AlianHp As Integer = 40 '40 Hitpoints

'Not going to show all code so...
Private Sub AlianHit()  'This sub is called when Alian is hit by bullet
AlianHp -= 5
Call CheckAlianHp(AlainHp) 'Calls Subroutine at bottom.
If GameOver = true then
If YouWin = false then MessageBox.Show("You Lose!")
If YouWin = false then MessageBox.Show("You WIN!")
Application.Exit
End if
End Sub

Public Sub CheckAlianHp(ByVal Hp As Integer)
If Hp <= 0 then
GameOver = True
YouWin = False
else
GameOver = False
end If
End Sub
End Class

That's just an example of variable and sub/method code. Not actual code because I didn't add in collision checking, writing sprites to screen, or anything else.


-Gandolf

[Mystor]

Interesting language.
The only thing that I don't like about it is how it lacks clear structures.

That allows for simple shorthand but I find it a bit hard to read, for example:

Code: [Select]

If GameOver = true then
If YouWin = false then MessageBox.Show("You Lose!")
If YouWin = false then MessageBox.Show("You WIN!") 

is in your code

That is a bit hard to understand.
I would always write:

Code: [Select]

If (GameOver == true) {
  if (YouWin == false) {
    MessageBox.Show("You Lose!");
  }
  if (YouWin == true) {
    MessageBox.Show("You WIN!");
  }
}

Just to make it more organized (I doubt that that is proper code )

Mist

[Silverwind]

Heres an example of using parameters/ returns in SC... it was developed by Plaza Redd and is extremely useful.

Now I know what it was like for you guys before I made that tutorial on Grid Navs! I don't understand what's happening in the first example, could you comment it please?

The only time when trouble might occor would be when you give it a diffrent type (For example INT instead of FLOAT)

Ah. Reassigning a var's type in RB is easy, but it resets the var's value. It doesn't mention what happens when you reassign a var's type to the same one it currently uses though. I'll have to test it like you say.