Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bricks]

It doesn't matter what language you use, once you have enough "low level" functions, all that is left is the raw equasions, and math is usually independant of languages. Pick the language you want, and is probably works, so write the basic underlying essentials, and if you do it right, everything will be very easy.

This is basically my perspective - I can handle the logic no problem, so it just becomes a matter of breaking down help files and finding the relevant functions and syntax.  I get a little frustrated with the whole variable declaration finagling, as it leads to some of the more frustrating bugs (aka "Since when is 3/2=1?"), but I can deal with it.  Also, file reading/writing is something that seems to differ with every language.

On BASIC - it was the first programming language I learned, and it was all self-taught at a fairly young age.  (I still recall being beaten by my pong AI the first time I tried it - happiest loss of my life.)  I guess it can lead to some bad habits, but I also had the opportunity to work through the logic of things.  By the time I was taught what a command loop was, my response was "Yeah, no shit.  You actually have a name for that?"  I also learned how to debug without the use of sissy break lines and other features, which IMO take longer to set up and watch than they are worth.  Visual BASIC, on the other hand, was a total waste of my time.

For the record, the only reason I would think M$ is "teh evil" is because they messed with perfection.  Windows 98, you will be missed.  I've got Vista ready on the Bootcamp for compatibility issues.

EDIT:  I'd like to point out to you all that I misspelled opinions.  Come on, people.  I deserve some sort of admonition for that.

Also, talking about efficiency - I have something of a skewed perspective, because I generally program simulations that end up having hundreds of separate units all calculating and coordinating their movements relative to each other.  As I thought about it more, I realized that there isn't really going to be that much calculation going on.  Currently working through a little design doc so I can get all my ideas sorted out.

[Armok]

All languages are basically the same/equivalent!

WFT? That kind of statement makes me cringe.
Of coarse there are similarities, but there are very, VERY important differences. Anyone who claim Python and Assembly are the same I can only conclude have not tried different level languages.

Then there are the odd languages, like Lisp...

If all languages were the same, nobody would bother inventing new ones.

[qwertyuiopas]

Nearly every single language, except a few odd ones, supports 1+5 as (part?) of an equasion.

Once you code the I/O, what is left approaches pure math, where most languages are very similar.

[Armok]

Uum, no, they are NOT similar. Unless you have a very very strange and inefficient programming style only small fraction of programming will be spent on that kind of pure math, and even then the syntax of anything more advanced than + - * / still varies between languages, and sometimes even those.

[qwertyuiopas]

Okay. Stop and think.

Almost every language has basic flow of control.

Almost every language can edit variables based on basic math.

Few languages have similar I/O.


Elminate the last by writing functions to convert your data to graphics and input into your data.

All that is left is manipulation of data from within a loop, that occasionally branches off for output.


Now, manipulation of data almost exclusively revolves around math. You add the velocity to the position, after collision checks that are made of, you guessed it, MATH!

Spoiler (click to show/hide)

Color key:
MATH
I/O
FLOW OF CONTROL
SELF-WRITTEN I/O SIMPLIFICATION

void fWriteInt(FILE *f,unsigned int i)
{
    fputc(i%256,f);
    fputc((i>>%256,f);
    fputc((i>>16)%256,f);
    fputc((i>>24)%256,f);
}
void fWritePstr(FILE *f,char *str,int length)
{
    int x,s=strlen(str);
    for(x=0;x<length;x++)
    {
        if(x<s)
          fputc(str[ x],f);
        else
          fputc(0,f);
    }
}
void editor_newRoom()
{
    currentRoom=malloc(sizeof(struct room));
    currentRoom->name="title";
    currentRoom->width=16;
    currentRoom->height=16;
    currentRoom->prev=0;
    currentRoom->next=0;
    currentRoom->data=malloc(sizeof(unsigned int)*currentRoom->width*currentRoom->height);
    ZeroMemory(currentRoom->data,sizeof(unsigned int)*currentRoom->width*currentRoom->height);
    currentRoom->image=newBmp(-1,-1);
}
void writeRooms(FILE *f, int version)
{
    int x,y;
    fWriteInt(f,version);
    switch(version)
    {
        case 0:
          fWriteInt(f,0x00000001);
          if(currentRoom->background)
            fWriteInt(f,0x00000001);
          else
            fWriteInt(f,0x00000000);
          fWritePstr(f,currentRoom->name,256);
          fWriteInt(f,currentRoom->width);
          fWriteInt(f,currentRoom->height);
          for(y=0;y<currentRoom->height;y++)
          {
              for(x=0;x<currentRoom->width;x++)
              {
                  fWriteInt(f,currentRoom->data[x+currentRoom->width*y]);
              }
          }
          if(currentRoom->background)
          {
              fWriteInt(f,0x00000000);
              fWriteInt(f,currentRoom->background->width);
              fWriteInt(f,currentRoom->background->height);
              for(x=0;x<currentRoom->background->width*currentRoom->background->height*4;x++)
                  fputc(currentRoom->background->data

• ,f);

          }
          break;
        case 1:
          fWriteInt(f,0x00000001);
          fWriteInt(f,0);
          int pos=ftell(f);
          if(currentRoom->background)
            fWriteInt(f,0x00000001);
          else
            fWriteInt(f,0x00000000);
          fWritePstr(f,currentRoom->name,256);
          fWriteInt(f,currentRoom->width);
          fWriteInt(f,currentRoom->height);
          for(y=0;y<currentRoom->height;y++)
          {
              for(x=0;x<currentRoom->width;x++)
              {
                  fWriteInt(f,currentRoom->data[x+currentRoom->width*y]);
              }
          }
          if(currentRoom->background)
          {
              if(1)
              {
                  fWriteInt(f,0x00000001);
                  fWriteInt(f,currentRoom->background->flags);
              }
              else
                fWriteInt(f,0x00000000);
              fWriteInt(f,currentRoom->background->width);
              fWriteInt(f,currentRoom->background->height);
              for(x=0;x<currentRoom->background->width*currentRoom->background->height*4;x++)
                  fputc(currentRoom->background->data

• ,f);

          }
          int end=ftell(f);
          fseek(f,pos-4,SEEK_SET);
          fWriteInt(f,end);
          fseek(f,end,SEEK_SET);
          break;
        default:
          break;
    }
}
void editor_saveRoom()
{
    OPENFILENAME OFN;
    char name[512];
    ZeroMemory(&OFN, sizeof(OFN));
    OFN.lStructSize=sizeof(OFN);
    OFN.hwndOwner=hwnd;
    OFN.lpstrFile=name;
    name[0]=0;
    OFN.nMaxFile=sizeof(name);
    if(GetSaveFileName(&OFN))
    {
        FILE *f=fopen(OFN.lpstrFile,"wb");
        writeRooms(f,1);
    }
}

I didn't colour the whole thing, but you can clearly see that nearly ALL I/O is contained with self-made helper functions.
You can easily port the math and flow-of-control to any language, and by porting the helper functions, very little true I/O needs to be rewritten rather than ported.

(Technically, the pointer syntax will probably change, but the fact that the data type's member is being accessed will not.)

[Armok]

Your statement is true, ABUT C++ USING YOUR STYLE OF PROGRAMMING! And, with different (often inefficient) programming styles you can have it like that in (probably) a bit more than half of other languages as well.

However, not all people use that style. In most languages it is suboptimal, loads of code is often dedicated to language concepts like objects, in many kinds of applications the main coding consists of stringing together libraries, some programs are doing very little math-like stuff but insted consists of mostly I/O stuff, some languages DON'T have those, flow control (especially if you go beyond the very most basic stuff) and things like functions are done in different ways, and so on, and so forth. The list goes on forever.

I am not basing this of some theory read in a book, from a purely abstract, mathematical standpoint you might even e right in some technical way. But I have ACTUALLY PROGRAMMED, in python, in assembly, in C++, and those are very, VERY different experiences, different ways to think, often times different work flows.
I won't claim that I'm a highly experienced or professional programmer, I am not, but I HAVE tried quite different kinds of languages, I speak from experience.

[qwertyuiopas]

Okay, let me put it this way: would you EVER think of directly putting all the output code inside your main loop, for anything even as complex as a roguelike?

Doubtful.

You would at least have a function that draws the map to the screen.

Similarily, in any complex roguelike, you probably have a function that writes text to the text-area, and pauses for a more key if it gets too long.

Any language that supports splitting code into functions or procedures, you will likely use them for common tasks.

So, you will probably, for any sufficiently complex project, write a function of your own around the language/library's input or output, so that it accomplishes an entire task in one function call. This way, you don't have to force any bit of your code to render a textured quad whenever something changes on the map. More likely, you have it update an internal map array, that then gets drawn out in the desired method at the appropriate time.

However, any "real" language since C's syntax became popular, will support c=a+b relatively unchanged.
ASM, lisp, and brainf***(and similar intentionally nonstandard languages) are all that I can think of where addition is handled diffrently.

And I doubt any new learning programmer would EVER pick one of those as their first language, except possibly ASM if you go back maybe 40 years.


Thus, your mathematical equasions and most of your flow-of-control remains relatively unchanged across any beginner's language you pick, and most others as well.


Also, my example was plain C, not C++.
Also, what was your assembly experience? Linoleum? I looked at that, long ago, but the effort required to write text to the screen was just so massive that you absolutely HAD to outsource it to a library or at least a subroutine. That way, you reduced it one step(or in this case, kilometer) closer to the pure, crossplatform, math that everybody loves, since few languages dare to disrupt it's ancient beauty.

Not every language has '0' translate to 48, and not every language supports named functions that handle passing arguments. Not every language has a stack visible to the programmer, and some don't even have one at all. Some (joke) languages have less than ten distinct commands, and some have over a thousand libraries. Some use zero-terminated strings, some put the length in front instead. Some are interpreted, some compiled, and some both, but the one thing all have is the ability to add, and most of them use a standardized symbol that looks like +

[Armok]

Not all programs are games. Not all games are rougelikes. And even a rogelike is not made by only adding numbers.
Yes, you use a function to outpt text. But you still need to format the text, and different languages have different tools for that. in some languages the function is best contained in a class, others in a library, others it's right in the same file as the code using them. In a rougelike, the spesifics of how objects are handled is probably going to matter a lot, and that varies tremendously between languages. again, the list goes on and one.
Of course there are similarities, huge similarities, but saying that all languages are the same thing is plain false.

[TheDarkJay]

It's an oversimplification made to prove a point. Programming logic is practically universal. Once you learn the basic logic behind what how code flows, it is very easy to 'jump' from language to language. Many programmers can pick up a language they've never seen before, and after a few hours of experimenting get it doing things that would have took a month or more of study if they were entirely new to the world of programming and it was their first ever language.

You have to learn new syntax, new functions, new terminology, new tools and new means to the same end, but ultimately the overall logic of programming languages remains.

That being said: With Python, the need for python to be installed in the users computer will drive away some users.

Installing Python on the target computer is only necessary if the developer is lazy. If you're using CPython, then you can use py2exe or py2app. If you're using IronPython, then you can compile that straight to an .exe. And with Jython, that compiles back to a .jar or .class or whatever it is that Java uses. Hell, these days I've seen Python compile to Javascript. And most of these methods will take care of including and packaging the various libraries you call into the directories they need to be in anyway, so that's another issue gone.

Interesting, I wasn't aware of such things though it would make sense for them to exist...likewise my Java statement isn't entirely true, there do exist Java compilers that output .exe files not dependent upon the JVM, a relatively uncommon, though not unheard of, practice. Like I said outside of programming circles I practically never see Python used as anything other than a scripting language and aside from glancing at it briefly (as one does) I've not put much effort into the language.

[timmeh]

I agree with TheDarkJay.  I started with Game Maker and RPG Maker.  Once I got GML down, I tried Dark Basic and BYOND.  I don't know if anyone here has every messed with BYOND, but the syntax has very little in common with any of the other languages I've used, except it's basic math.  Despite that though, I learned all kinds of things about program flow and logic from all of my experiences (even RPG Maker), which I've been able to apply not only to games, but to everything else I've written as well.

The syntax may differ, and execution may differ (object, sprites and such in Game Maker, events in RPG Maker, classes and structs in C++), but the logic remains the same.  Once I knew how to load graphics and sounds into a game, the game's logic would be similar in C++ to Game Maker.

[Outcast Orange]

I agree. The only reason I was able to pick up C++ so quickly,
was because Jamagic had a very similar syntax.
And I've been screwing around in that for a years.

[Armok]

Learning a new language is fast perhaps, because the concepts are SIMILAR, but it is still a different experience to use a different language, and most importantly not all languages are suited for all tasks.

[TheDarkJay]

Learning a new language is fast perhaps, because the concepts are SIMILAR, but it is still a different experience to use a different language, and most importantly not all languages are suited for all tasks.

I called it an oversimplification for a reason. Indeed not all languages are suited for all tasks. That being said, nowadays 'multi-purpose' languages are often favoured over the very specific languages, if only due to the 'time learning vs time producing' trade-off. This is a relatively new development, and indeed I have spoken with an individual who currently works for IBM, and back when he was in university his response to most tasks he was given was to create a new language specifically designed for solving that tasks.

Even then, the same basic logic exist in all programming languages because ultimately they have to be built into the same machine commands. You can take different approaches, but because they're all built upon the same framework, and the same basic concepts can apply universally.

Of course this may not apply forever, and I do dream of a day when computers become Trinary (using no current for 0, positive for 1 and negative for 2 or a similar system) XD

[eerr]

Learning a new language is fast perhaps, because the concepts are SIMILAR, but it is still a different experience to use a different language, and most importantly not all languages are suited for all tasks.

We are not talking about languages being identicle.

The switching costs to using a diffrent language become lower merely by learning one.

Ie, there is not serious lockin for performing math in one language compared to another.

I/O however, is language specific. It is also custom to each language.

[Bricks]

On a less controversial note, I'm finally starting to understand why my Python wasn't working!  Yay Apple for making it horribly confusing!  Now I need to relearn some syntax and start playing around with Pygame's features.