Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualszecs

Posted 10 January 2013 - 11:17 AM

As stated in the article, breaking down the program in hilariously small chucks and always making a small but playable thing is the most important thing. I say always make something playable, like a prototype. You can't make a game, no matter how small pieces you have broken it down, if build it from "left to right". You have to work more or less on all part of the program a bit. You can't fully implement the graphics for zero to full if you can't interact with the game. You can't fully implement the internal workings if you can't interact with it and don't see a thing. You can't fully implement input/interaction from zero when things doesn't do anything and you can't see anything.

I think you get the idea. Today, I have no feelings when I see a blank page, even if I'm learning a new thing. I just get started with it, make many prototypes as I learn and make some prototypes for the actual project I'm working on.

For my current job I have to make a automatic data acquisition and instrument controller program in Labview for an endurance test. I started Labview about 2-3 weeks ago and I already have about 10-12 prototypes of random learning stuff, and 3 prototypes of the actual project for testing different things. Labview is a graphical dataflow language, as I saw, many programmers utterly hate it, because it's so different than most text languages.

That all folks, blah blah

#3szecs

Posted 10 January 2013 - 11:16 AM

As stated in the article, breaking down the program in hilariously small chucks and always making a small but playable thing is the most important thing. I say always make something playable, like a prototype. You can't make a game, no matter how small pieces you have broken it down, if build it from "left to right". You have to work more or less on all part of the program a bit. You can't fully implement the graphics for zero to full if you can't interact with the game. You can't fully implement the internal workings if you can't interact with it and don't see a thing. You can't fully implement input/interaction from zero when things doesn't do anything and you can't see anything.

I think you get the idea. Today, I have no feelings when I see a blank page, even if I'm learning a new thing. I just get started with it, make many prototypes as I learn and make some prototypes for the actual project I'm working on.

For my current job I have to make a automatic data acquisition and instrument controller program in Labview for an endurance test. I started Labview about 2-3 weeks ago and I already have about 10-12 prototypes of random learning stuff, and 3 prototypes of the actual projects for testing different things. Labview is a graphical dataflow language, as I saw, many programmers utterly hate it, because it's so different than most text languages.

That all folks, blah blah

#2szecs

Posted 10 January 2013 - 11:16 AM

As stated in the article, breaking down the program in hilariously small chucks and always making a small but playable thing is the most important thing. I say always make something playable, like a prototype. You can't make a game, no matter how small pieces you have broken it down, if build it from "left to right". You have to work more or less on all part of the program a bit. You can't fully implement the graphics for zero to full if you can't interact with the game. You can't fully implement the internal workings if you can't interact with it and don't see a thing. You can't fully implement input/interaction from zero when things doesn't do anything and you can't see anything.

I think you get the idea. Today, I have no feelings when I see a blank page, even if I'm learning a new thing. I just get started with it, make many prototypes as I learn and make some prototypes for the actual project I'm working on.

For my current job I have to make a automatic data acquisition and instrument controller program in Labview. I started Labview about 2-3 weeks ago and I already have about 10-12 prototypes of random learning stuff, and 3 prototypes of the actual projects for testing different things. Labview is a graphical dataflow language, as I saw, many programmers utterly hate it, because it's so different than most text languages.

That all folks, blah blah

#1szecs

Posted 10 January 2013 - 11:15 AM

As stated in the article, breaking down the program in hilariously small chucks and always making a small but playable thing is the most important thing. I say always make something playable, like a prototype. You can't make a game, no matter how small pieces you have broken it down, if build it from "left to right". You have to work more or less on all part of the program a bit. You can't fully implement the graphics for zero to full if you can't interact with the game. You can't fully implement the internal workings if you can't interact with it and don't see a thing. You can't fully implement input/interaction from zero when things doesn1t do anything and you can't see anything.

 

I think you get the idea. Today, I have no feelings when I see a blank page, even if I'm learning a new thing. I just get started with it, make many prototypes as I learn and make some prototypes for the actual project I'm working on.

 

For my current job I have to make a automatic data acquisition and instrument controller program in Labview. I started Labview about 2-3 weeks ago and I already have about 10-12 prototypes of random learning stuff, and 3 prototypes of the actual projects for testing different things. Labview is a graphical dataflow language, as I saw, many programmers utterly hate it, because it's so different than most text languages.

 

That all folks, blah blah


PARTNERS