next »

[Layl]

Well there's good reasons why stuff like that is taught in classes. Saying you won't use it simply because it's taught in classes doesn't make much sense. Of course, if you would like to prove me wrong, I would love to see a snippet of code as well.

[ஒழுக்கின்மை (Paul Eres)]

i never copied and modified any code and as a result have huge problems reading other people's code. i literally made up my own level generation algorithm for my roguelike because i didnt understand any of the tutorials i found. so there's that.

well, i think that people should be familiar with conventional code, and able to read it, even if they don't create it themselves. being able to read the conventions is an important skill for indies/hobbyists to have, but i don't think it requires copying code to be able to do that; you can learn to read conventional code without writing in that style yourself

Well there's good reasons why stuff like that is taught in classes. Saying you won't use it simply because it's taught in classes doesn't make much sense. Of course, if you would like to prove me wrong, I would love to see a snippet of code as well.

and those reasons are...? besides the standard "shared conventions allow people to read each others' code" idea, i haven't seen any reasons in this thread to use conventional code. if there are reasons other than that, i'd like to see them. and, as mentioned, that reason isn't sufficient for indies, because indies tend to work alone, not in programming teams. if you just make small games on your own for fun, why are conventions needed?

(also i don't think you read my posts correctly; i wasn't saying that i personally don't use conventional code, i said that i, unfortunately, do. i'd like to shed the habit one day though)

[ஒழுக்கின்மை (Paul Eres)]

a request for examples is fair though, i'll try to find some examples of what i mean. for now, here is something i do fairly often in my own code, which i believe is readable, but which is unconventional and not recommended:

select(a)
{
   case 0: b = 2; break;
   case 1: b = 6; break;
   case 2: b = 62; break;
   default: b = 0; break;
}

it's unconventional to put multiple statements on one line. most programming style guides recommend separating all that middle stuff into 3 lines each. but to me, the way i wrote it above makes more sense, and is more readable, than stuff like:

case 0:
   b = 2;
break;

case 1:
   b = 6;
break;

to me that type of stuff takes up too much space, and is less readable rather than more

[s0]

w/r/t conventions: idk how conventional my code is (probably not very, i never read a programming book in my life), but i used to not use tab and just had everything in a straight column. the problem was that the code was extremely hard to read (and extremely hard to pick up again if i stopped working on it for a while), esp with things like nested loops and stuff like that. now i use the tab key to indent lines of code, which i understand is the "normal" way to do it, and it's just a 100 times easier.

personally i don't think the "aesthetics" of code are that important because there's no directly observable relation between the process and the result in programming and most people are never going to see the code anyway.

[Boreal]

That's what I love about Scheme - the syntax is so fluid that it's really easy to write nice, clean, elegant programs.  The code above would simply be this:

Code:

(define b
  (cond (0 2)
        (1 6)
        (2 62)
        (else 0)))

[ஒழுக்கின்மை (Paul Eres)]

@CA - yeah, i think indenting is generally useful, although indenting standards can vary. someone can invent their own method of indentation rather than using the recommended one

for instance, another thing i often do is:

set_draw_color(c_blue);
   draw_line(123,34,644,7535);
set_draw_color(c_white);

that is *not* how you are supposed to use indentation, because the statement in the middle will always happen regardless and it isn't in a set of braces or dependent on anything, but i feel that type of indentation can make my code more readable (to me, and i'm the only one who will ever read it anyway). the reason i do that is because everything in between the two lines will be drawn in blue, so it's "grouped" logically, even though there is no actual grouping in a braces set

[Netsu]

For short statements like in your example people do it all the time, I don't see anything wrong with it. Just remember to fill in spaces so that statements are aligned horizontally:

Code:

select(a)
{
   case 0:   b = 2;   break;
   case 1:   b = 6;   break;
   case 2:   b = 62;  break;
   default:  b = 0;   break;
}

Programming conventions are usually established to make code MORE readable, and if they stand in the way of that people will often break them, just like you do, I doubt anyone would complain.

[Layl]

The confusion here I think is that conventional code isn't just style guides. The only purpose of code style conventions is indeed to make code consistently readable. And that example, indeed, was a decent place to break off from conventions that say that case blocks have to be written like that. I use similar looking switch blocks in my code as well.

An example of different types of conventions, for example in C++11, is to use smart pointers instead of raw ones. So use unique_ptr and shared_ptr instead of *. This convention is there because, in general, smart pointers are all you need and are much safer. There are situations in which normal pointers are better, in which case you can go ahead and use normal pointers. As long as you document it with a comment and note why you decided to break convention there.

I think it's not a good idea to break from conventions just because you want to write unconventional code. What use is there in doing that in situations where following the conventions would not give worse code?

[Boreal]

Three-character tabs?  Interesting...

[Netsu]

@CA - yeah, i think indenting is generally useful, although indenting standards can vary. someone can invent their own method of indentation rather than using the recommended one

for instance, another thing i often do is:

set_draw_color(c_blue);
   draw_line(123,34,644,7535);
set_draw_color(c_white);

that is *not* how you are supposed to use indentation, because the statement in the middle will always happen regardless and it isn't in a set of braces or dependent on anything, but i feel that type of indentation can make my code more readable (to me, and i'm the only one who will ever read it anyway). the reason i do that is because everything in between the two lines will be drawn in blue, so it's "grouped" logically, even though there is no actual grouping in a braces set

Yeah I did the same thing when programming in OpenGL, with glBegin and glEnd working like braces for blocks of code. It's still a conventions, just not a very popular one since a better way to write it would be:

Code:

draw_colored_line(a,b,c,d,e)
{
  old = get_draw_color();
  set_draw_color(e);
  draw_line(a,b,c,d);
  set_draw_color(old);
}

draw_colored_line(123,34,644,7535,c_blue);

[Layl]

The way I do indenting with blocks like that is I wrap it in an IDisposable object. That way I can put it in a using block like this:

Code:

using(var active = _shader.Activate())
{
    active.Stuff();
}

It's not the best of ways to do things probably, but it makes sure that even in the case of exceptions, my resources are always freed again.

[RealityShifter]

I developed the habit of looking up example code, and instead of copy and pasting (except if it's a one liner) I'd re code it. so that I'd understand it. I'd code a section of it using a naming scheme that matches the rest of my code but then I'd run just that part and echo the variables to see what was going on. I'd take the code a part and look inside.

Now a days I don't usually use examples, I'm looking up references every day but figuring out how to manipulate the code to do what I want comes naturally.

[ubik]

For what it's worth, I dismiss Depression Quest because it's a pathetic, terrible game written by a non-programmer who cynically promoted her tripe in the most repulsively venal ways.  The fact that Social Justice Warriors take terrible umbrage at at any criticism of their Cause Celebre is hardly my problem and I will continue to say what I think about it.  

As a game it's hardly noteworthy one way or another since there's so much trash out there but the actions of the author and the censorious, unpleasant attitudes of those who use it as a political marching drum certainly are noteworthy and are symptoms of something much larger.

The fact remains that programming in general is one of the most difficult things around, and game programming specifically is one of the most difficult sub-fields.  How deeply you get into it is up to you but as with any technical field, studying the field WILL DEFINITELY HELP.

A lot of people want to be told that things like programming aren't technical and that's just not the case.  You definitely can learn as you go, it'll just take you a lot longer because not only will you be working at programming, you will be reinventing computer science at the same time and that is an extremely tall order.  The proof is in the pudding and skill and knowledge of craft will put you far above those who disagree.

They'll be part of the Big Inclusive Crowd competing with each other and you'll be standing on the shoulders of giants.

Otherwise, you can always try sleeping your way to the top.

[Netsu]

The fact remains that programming in general is one of the most difficult things around, and game programming specifically is one of the most difficult sub-fields.

What's so difficult about game programming in particular? It's definitely one of the easiest fields and with the help of all the advanced tools and engines that are out there it's becoming even easier, to the point where you don't have to be particularly good at programming to make good games.

Unless for you game programming = engine programming.

[ubik]

What's so difficult about game programming in particular? It's definitely one of the easiest fields

Things like business logic programming are much, much easier because it's almost all boilerplate.  With games other than the most trivial, performance and efficiency are going to be issues for the foreseeable future.  You are always going to have to understand logic and it's impossible to entirely elide that.

To the point where you don't have to be particularly good at programming to make good games.

It's all written for you by the guys who studied, and again you're down there competing with all the other people who use those tools.  Gamemaker finally did produce a few games I would say are excellent, especially Hotline Miami, but you still have to know programming to do anything nontrivial with maker apps like that and the more nontrivial your game, the more programming you will have to know.  At a certain point you have to begin wrestling with engine constraints that may make things more difficult than if you wrote your game from scratch.  Still, the number of good games produced in those apps is surprisingly low even to me and there may be a number of reasons for that but I'd argue that it's because the people who gravitate to them do so because they think it's going to be easy.

No offense intended to the original poster but this entire thread is an example of what I mean.  People are sold these tools on the basis that you don't need to understand programming in order to make great games with them.  That's just not true and the people who buy them are left asking questions on forums about the bare fundamentals of the craft.

[Netsu]

No one denies you have to understand logic and be able to program on SOME level.

But I'm guessing making Hotline Miami was (from a pure computer science perspective) easier than let's say writing a compiler or interpreter for any complete language out there.

There are three things difficult about video games as I see it: computer graphics, AI and physics. And there is no reason to write your own graphics or physics engine if you already have one, and for free. Even people at 'big companies' with 'real programmers' that don't use Unity or GM know this and often buy engines from each other or use the ones that are already out there, because it's cheaper, faster and will probably work better if it's been already tried.

In the end, when you make a game, do you really think the one that is programmed better/was more difficult to program will be more popular? This is like the least important thing in a video game.

[RealityShifter]

i never copied and modified any code and as a result have huge problems reading other people's code. i literally made up my own level generation algorithm for my roguelike because i didnt understand any of the tutorials i found. so there's that.

well, i think that people should be familiar with conventional code, and able to read it, even if they don't create it themselves. being able to read the conventions is an important skill for indies/hobbyists to have, but i don't think it requires copying code to be able to do that; you can learn to read conventional code without writing in that style yourself

Well there's good reasons why stuff like that is taught in classes. Saying you won't use it simply because it's taught in classes doesn't make much sense. Of course, if you would like to prove me wrong, I would love to see a snippet of code as well.

and those reasons are...? besides the standard "shared conventions allow people to read each others' code" idea, i haven't seen any reasons in this thread to use conventional code. if there are reasons other than that, i'd like to see them. and, as mentioned, that reason isn't sufficient for indies, because indies tend to work alone, not in programming teams. if you just make small games on your own for fun, why are conventions needed?

(also i don't think you read my posts correctly; i wasn't saying that i personally don't use conventional code, i said that i, unfortunately, do. i'd like to shed the habit one day though)

Just wanted to comment on the topic of conventional code. I think it slows down solo indie programmers, like myself. I'm constantly improving the way I code, still finding new ways of doing things that are more efficient resource wise but also more efficient in regard to easily understanding complex code and the speed at which I can produce features for my games.

I think adhering to conventional code hinder such personal progress.

[s0]

For what it's worth, I dismiss Depression Quest because it's a pathetic, terrible game written by a non-programmer who cynically promoted her tripe in the most repulsively venal ways.  The fact that Social Justice Warriors take terrible umbrage at at any criticism of their Cause Celebre is hardly my problem and I will continue to say what I think about it.  

As a game it's hardly noteworthy one way or another since there's so much trash out there but the actions of the author and the censorious, unpleasant attitudes of those who use it as a political marching drum certainly are noteworthy and are symptoms of something much larger.

ok so you are that guy.

anyway please keep this bs out of here, thankyou.

[InfiniteStateMachine]

@CA - yeah, i think indenting is generally useful, although indenting standards can vary. someone can invent their own method of indentation rather than using the recommended one

for instance, another thing i often do is:

set_draw_color(c_blue);
   draw_line(123,34,644,7535);
set_draw_color(c_white);

that is *not* how you are supposed to use indentation, because the statement in the middle will always happen regardless and it isn't in a set of braces or dependent on anything, but i feel that type of indentation can make my code more readable (to me, and i'm the only one who will ever read it anyway). the reason i do that is because everything in between the two lines will be drawn in blue, so it's "grouped" logically, even though there is no actual grouping in a braces set

That's not super out of the ordinary if you use braces. I do that when I have a similar situation. Some might say to refactor it into a function but I don't like a ton of small functions because they can be difficult to follow. Jon Blow mentioned in a talk he does the same thing as well.

The way I do indenting with blocks like that is I wrap it in an IDisposable object. That way I can put it in a using block like this:

Code:

using(var active = _shader.Activate())
{
    active.Stuff();
}

It's not the best of ways to do things probably, but it makes sure that even in the case of exceptions, my resources are always freed again.

If you need the resource to be freed then that's fine but if you just want a block of code why bother to do the idisposable dance? you could declare it locally in the block.

[Dacke]

i don't think it requires copying code to be able to do that; you can learn to read conventional code without writing in that style yourself

I never said you had to copy. Just that it's a completely legitimate way to learn (be it in programming, languages or art).