ID:189389
 
What are some things that make you have your own unique style of coding on BYOND?

For me here are some that I can think of:

  • I NEVER EVER use comments in my games;
  • I use while() procs to tell users to input something else;
  • I like to keep all insides of a proc bunched up, then slightly space apart between types on the first tab;
  • I filter through lists very finely to get rid of wrong stuff, instead of telling the player, "You can't do that." afterward.
  • On graphics, now, anyways, I can't release a game if I think one of it's graphics aren't very good.
  • I lose interest in making a game if I can't be playing the alpha version of it by 2 days. I also lose interest in a game if I get too many bugs in the beginning (I guess this would account for all bugs, BYOND and code bugs, but I seem to get alot of BYOND bugs when I first start a game.).

    [EDIT]

  • I, like Foomer, never ever keep things that deserve spacing, scrunched together.
  • I also like to have a different coding file for different things:

    Admin.dm
    Attacks.dm
    ChoosingHTML.dm
    Communication.dm
    Computers.dm
    Computers 2.dm
    Custom Level.dm
    Custom Level 2.dm
    Custom.dm
    D Attacks.dm
    Dementophobia.dm (The game name .dm file always includes login proc, and anything that has to do with character selection, stating, and contains all the main vars.)
    Filter.dm (Every single one of my games contain this file. It is the Filter() proc and uses deadron's dd_replace_text() to replace cuss words with friendly gibberish.)
    Instructions.dm (All my recently made games contain this one.)
    Items.dm
    Levels.dm
    Major Attacks.dm
    Meters.dm
    Movement.dm
    Projectiles.dm


  • I also like to do as many icons as I can think of that the game will need to be started off, before any coding.
  • I never keep multiple strings on one line if it would require a ";" to do so. Otherwise the only time I put multiple strings on one line if it is a) Only 1 other string, and b) The first string is an if() statement.
Kunark wrote:
  • I NEVER EVER use comments in my games;

    In the words of the host of Hollywood Squares when someone makes a dumb move: Maybe that'll work out for you...
Kunark wrote:
  • I lose interest in making a game if I can't be playing the alpha version of it by 2 days. I also lose interest in a game if I get too many bugs in the beginning (I guess this would account for all bugs, BYOND and code bugs, but I seem to get alot of BYOND bugs when I first start a game.).
    </l>

    I hear that...
    For me:
  • I cant stand to do easy tasks, so nine out of ten games I make never get more enemies/items then I need to test the systems.
    </l>
  • I wont release a game unless its free of all spelling errors, and any verbs or screen objects are neatly organised.
    </l>
  • My combat systems tend to look good, but actually have no insides (Ie, battle calculations are M.hp - src.str)
    </l>
Kunark wrote:
  • I lose interest in making a game if I can't be playing the alpha version of it by 2 days. I also lose interest in a game if I get too many bugs in the beginning (I guess this would account for all bugs, BYOND and code bugs, but I seem to get alot of BYOND bugs when I first start a game.)</l>

    I lose interest when i cant think of anything else to put into the game, as i have no creative ability at all
I have problems with finding impossible or almost impossible things to do, then i give up and quit working with byond for a while. Im currently in the grove.
In response to Scoobert
For me..

1. No comments.
2. Trial and error until whatever it is is worked out. =P
3. I don't do RPG games, so I wouldn't know. =P
4. Absolutely HATE HUDs and client.screen in general.
5. Postpone working on the game or utility for a long while if I can't find a way to fix a bug, and return when I improve my ability.

=P
In response to Lazyboy
Lazyboy wrote:
i have no creative ability at all

Aha! I'm not the only one =)

I rarely comment my code. I only comment code in projects that I may allow other people to see at some point in time, or good project ideas that I may later come back to.

I might as well face it, I'm addicted to HUDs.

Well, not necessarily HUDs but screen objects in general.
Foomer's general rules for programming:

  • If you've gotten past the part where you make graphics, you're doing good.
  • General purpose comments go above procs, unless certain parts are especially quirky and require an additional comment to clarify. Variables have their purpose commented a few tabs to the right.
  • If a process is repeated in several difference places, turn it into a proc and use that instead.
  • Avoid having multiple lines of code on the same line, even if DM does allow it.
  • Variables should always have meaningful names.
  • Verbs are evil. Avoid them at all costs.
  • Procs are always capitalized AndLookLikeThis(), while verbs are always lowercase text and use _ between words like_this.
  • Make it look good the first time, because chances are you'll never get anywhere with it, but you'll at least be able to impress someone by giving them the code.
  • Always use spaces to seperate stuff, as in, "if(1 + 1 == 2)", not "if(1+1==2)".
  • Never finish anything.
  • Anything else is purely subconscious.
In response to OneFishDown
I would love HUDs if they only supported text, without forcing you to make your own.
Let's see here...

<l>
  • I like to organize large projects into separate dm files for each object type, and for each specific purpose of object type I use (if I use an object type for more than one purpose, each purpose gets its own file)... Aside from all player and world code (Login, client info, variables, procs, verbs, etc) which all remain in the default [gamename].dm

    For instance, Murder Mansion has the following .dm files:
    AI.dm (specialized mob coding, so it gets its own file)
    murder_mansion.dm (as explained above)
    objHUD.dm (all hud objects)
    objinteractive.dm (all other objects)
    turfarchitectural.dm (all non-interactive turfs)
    turfinteractive.dm (all interactive turfs)
  • I like to copy and paste libraries into their own .dm files within the game's set... That way, I can make changes to them without affecting the original, and I can also have easier access to modifying them if I need to...
  • All of my games are now equipped with a notes.dm file, which contains nothing but commented notes on the game's progress, planning, design, to-do list, etc...
  • Speaking of comments, I prefer to change the default color for comments to red, to make them stand out better... I also use comment lines within the regular dm files to further divide types... Say if I have two types of interactive objects in a dm file...I label where each one starts with a comment line... This is for ease in finding them when scrolling through lengthy code... I rarely comment any of my own code, though... Only if I need it during the development of systems (like if I can't keep track of how each little bit works together, I leave myself comments... But in general, I don't comment very much...)
  • Lately, I've been extremely against verb panels... And all of my projects are now HUD operated...
  • Speaking of verbs, I'm very much against the naming convention of naming verbs using lowercase words... It is my opinion that if the player is going to see this word in a verb panel, it should be capitalized to make it look better... Lowercase verbs in verb panels looks sloppy to me... However, I also name all procs with uppercase words as well...so I've got to be careful on how I name things... But this is becoming a moot point, since I'm moving away from coding verbs at all...
  • I LOVE WHITESPACE! I space between everything (like Foomer instructed below in his example math equation)...and I never put code on the same line... Every one of my if()s has the next line indented below it... Even if it's only one little thing... I double space between anything that doesn't go directly together... Meaning all procs have spaces between them (but all lines included in each proc are single spaced) and all object type definitions are double spaced... Variables and such defined under an object are single spaced...
  • I simply cannot work on a project until I draw icons for it (well, I can start it, and get it to the point where I have to start assigning icons)... I can't add any new objects to the code until I've got the graphics done for them... And I refuse to use "place holder" icons... Which means a LOT of my development is wrapped up in drawing... And as for that, my method of choice is the good old built-in dmi editor... Pixel by pixel is the best way to go...
  • One of the only things that kills my interest in development is when I come to a point where I've got a bug I can't seem to fix, or I come to a point where I don't know how to do what I plan to do next... If one of those things happens, then I stop working... I guess it's because I'm progress-oriented... Once sufficient progress stops, I lose interest...
  • I strongly dislike writng pseudo-code outside of the compiler... I don't mind wrting up things on these forums as examples or whatnot...but I can't do it for my own projects... I've tried and tried (especially when I come up with an idea when I don't have access to Dream Maker)...but I have a strong dislike for it... I've got to be able to code something in, and compile it right away to feel that any pprogress has been made...
    </l>

    And I think that's about it for my programming/development quirks...
In response to SuperSaiyanGokuX
my coding style?

Hmm...let's see:

-my comfy leather chair
-using a trackball instead of a mouse
-cool breeze from the window
-black or green t-shirt (which ever is cleaner)
-loose shorts or jeans
-large bottle of Rootbeer
-pizza
-RUSH music
-and preferably my three monitors facing away from sunlight on bright days

...that's my style

:)
In response to digitalmouse
I prefer rootbeer in cans.


*looks over*

I've drank four tonight.
In response to Jotdaniel
Hehe just by looking forward I can tell what drinks I have drank this month.
In response to digitalmouse
Me?

Ay, you should see my code. AARRGG! Code hurt eyes! Spanish tan (last 11 days :-) ) disappear from ugly code!

Still...

Current coding style: (Good)

1. EVERY main feature has it's own .dm file.
2. Avoid huge numbers of icon files: ugly
3. Split things up into the tinniest sections possible for ease of 'navigation' and bug spraying.
4. Split everything up with spaces.
5. Make sure cat isn't clawing leg
6. Don't drift into doing something different
7. Red Hot Chilli Peppers playing in background

Other (urg) style (EVIL!)

1. Single, messy .DM file. (So bad I'll gladly send excepts of The Outlands source to anyoone who wants to take a look)
2. Faster is better
3. To busy to put music on
4. No blank lines
5. (My worst habit) drift into OPL, BASIC or another language dissaccosiated with BYOND

BTW, OPL is a programming language used on my old (11 years) organizer. I'm currently making a text-adventure game system with it.

Also, Digi, what video card do yo have? My old schools ICT co-ordinator had three monitors, and he could only find one card to support all three.
In response to digitalmouse
My revised style

Almost asleep frrom coding all night
sitting on chair with legs on bed
tv above monitor turned on to some useless tv show
quilt from bed layed on body
listening to rammstein or other music through headphones
goto bed at 2 in the morning before college/university starts
empty fast food rubish littered across room
dirty clothes on floor
window and blinds closed

[edit]
well im sorry that im an australian and that we goto university over here
[/edit]
*tries to remember the bullet HTML tag...*
Aw well:

-I use a lot of different DM files. obj.dm turf.dm mob.dm admin.dm [gamename].dm login.dm battle.dm etc

-I also use a lot of different icon files.

-I'd rather waste endless hours re-coloring icons then making them black with shades of gray, and using the rgb proc.

-Many of my verbs lead to procs

-I change my comments color

-Everything is very spaced out, and more organized than being all cramped together:
if(BLAH)
return 1
-I also try to do all the icons before the game, but I end up doing more anyway.
In response to Airjoe
When in doubt, quote someone who knows. :P
In response to Hazman
Hazman wrote:
Also, Digi, what video card do yo have? My old schools ICT co-ordinator had three monitors, and he could only find one card to support all three.

I have the on-board video card, and two old S3 Trio 64V+ cards. One of the later will soon get replaced with a Radeon-based card so that I can play more of the graphic-intensive games that have come out in the last year or so.
Here are some of my little quirks:

<l>
  • I never comment (No one's ever gonna see my programming besides me, so why comment if I know what it does?)
  • I hate leaving empty space. I ALWAYS fix programming indentation in a library if I look at it. (EX: if(usr.bleh >= usr.bleh2) <<BAD, GOOD>> if(usr.bleh>=bleh2))
  • Also, I hate having to make something twice such as an icon. So, I just put in some black/grey scale and use the Blend(rgb()) function.
  • I absolutely HATE having disorganized code, I ALWAYS make a new .dm file for each atom type/project (EX: hud.dm, mobs.dm, objs.dm)
  • I likeo to use the tree to organize my items nicely, so I can easily find something in one category or another.
  • I usually define procs and vars under atom/movable.
  • Also, I hate the "verb/stat" panel. I consider those to make a graphical game look unprofessional. I prefer the use of HUD over using the Stat() and verb procs.
  • I mainly try to use lists as much as possible to store information.
  • And, as a side note: I prefer to make a general "door" with its own set ID so I just use a simple for() to loop through other doors with the same ID and locate the mob there.

  • </l>
    And, that's my programming preferences. I probably sound wierd, but hey =p
In response to Goku72
Goku72 wrote:
  • I never comment (No one's ever gonna see my programming besides me, so why comment if I know what it does?)


  • Commenting is to help you remember what things do when you ditch the project for a few months and check up on it again later and can't remember how on earth it worked.
  • I hate leaving empty space. I ALWAYS fix programming indentation in a library if I look at it. (EX: if(usr.bleh >= usr.bleh2) <<BAD, GOOD>> if(usr.bleh>=bleh2))


  • Its probably a good thing that no one will ever see your programming besides you then. :)
Page: 1 2