Dave "Dak Lozar" Loeser †
A Game to teach programming
Author
Hey all,
It''s been a very long time since I''ve posted in this forum...
Here''s what sparked this post:
Over in the Game Programming forum there''s a post entitled "Programming is Hard." It''s one of the typical post here on GD, someone is a bit miffed and they post a rant and then everyone (including me) adds their two euros worth...
But this post is not about that, no sir. This post is about an ideal that I have had for some time... it''s really just the tip of an ideal and I present it here for everyone to... hmm, well... add their two euros *GRIN*
A little background... I know that there are games that include programming (C Robots, C++ Robots and on an on...) as the foundation of the game but these games do not teach potential programmers to code, they are more of a tool that lets novice through expert programmers show off their coding skills.
Ok, so what''s this game that I''ve been thinking about? What I have in my mind is, as I said, just the tip of the game; here it is:
The game would have levels... each programming task that you successfully complete allows you to move to the next task or level (multiple task per level).
The task would be as simple as providing directions from point A to B or to more difficult things like A to C to B to D to E without crossing over you path or backtracking...
The interface would be fully point and click drag and drop - if anyone has ever seen AmigaVision; that’s the interface that I envision.
Anyway, I know there’s not much in the way of detail but I just wanted you guys to let you imaginations run wild with this and I look forward to all of your euros
Dave "Dak Lozar" Loeser †
Dave "Dak Lozar" Loeser †
Programming isn't hard. It's a piece of cake. I've taught complete computer neophytes what machine code is all about in less than 2 hours. This was during my first ICT GNVQ lesson. (And before you ask: yes, it did 'click' with them... and no, I didn't scare anyone away either!)
The trick isn't to fret about maths and all that fluff -- when I started out in IT during the 8-bit era, most CPUs couldn't even handle floating point numbers natively. 'Maths' is counterproductive. What it takes is an ability to grasp the concept of cause and effect.
The secret is getting people to understand how computers _think_. Once people understand what computers actually do, everything else starts to fall into place.
Your suggestion is a sound one. I've been toying with building something similar. My free time is minimal though, so I'm not holding my breath until I start. There's also the small matter of this concept having been attempted on a number of occasions already.
The problem with designing a graphical programming systems is that you need to forget about merely translating a traditional programming language into a visual form, and essentially design something from scratch that fits the graphical medium.
Most attempts have failed precisely because of this--they've just gone for the "let's make it look like a flowchart" approach, which is fundamentally flawed: Flowcharts are merely blocks of text in boxes, which defeats the point of a graphical programming environment. (It doesn't help that flowcharts were designed for early almost-procedural languages like COBOL.)
When I attempted this project last year, I realised that it was actually far easier to design a graphical representation of low-level (i.e. machine code-type) programming. Higher-level programming is more difficult as programming languages get very abstract very quickly as you start going up the ladder. (How do you differentiate a 'struct' and a 'class' clearly using icons?) The solution is that a fully graphical language is needed. This is a lot harder than it sounds, but it's an interesting area to explore. Not least because if we ever want to program computers using speech rather than typed words, we'll also have to design a 'spoken' programming language. (Verbose languages like COBOL are actually a better fit for this than something like C++ or Perl.)
I think I have tons of notes on this stuff still lying around my hard disk somewhere. Once I get this f#!%ing database done and dusted, I really ought to dig them out.
--
Sean Timarco Baggaley
[edited by - stimarco on June 7, 2002 10:41:45 PM]
The trick isn't to fret about maths and all that fluff -- when I started out in IT during the 8-bit era, most CPUs couldn't even handle floating point numbers natively. 'Maths' is counterproductive. What it takes is an ability to grasp the concept of cause and effect.
The secret is getting people to understand how computers _think_. Once people understand what computers actually do, everything else starts to fall into place.
Your suggestion is a sound one. I've been toying with building something similar. My free time is minimal though, so I'm not holding my breath until I start. There's also the small matter of this concept having been attempted on a number of occasions already.
The problem with designing a graphical programming systems is that you need to forget about merely translating a traditional programming language into a visual form, and essentially design something from scratch that fits the graphical medium.
Most attempts have failed precisely because of this--they've just gone for the "let's make it look like a flowchart" approach, which is fundamentally flawed: Flowcharts are merely blocks of text in boxes, which defeats the point of a graphical programming environment. (It doesn't help that flowcharts were designed for early almost-procedural languages like COBOL.)
When I attempted this project last year, I realised that it was actually far easier to design a graphical representation of low-level (i.e. machine code-type) programming. Higher-level programming is more difficult as programming languages get very abstract very quickly as you start going up the ladder. (How do you differentiate a 'struct' and a 'class' clearly using icons?) The solution is that a fully graphical language is needed. This is a lot harder than it sounds, but it's an interesting area to explore. Not least because if we ever want to program computers using speech rather than typed words, we'll also have to design a 'spoken' programming language. (Verbose languages like COBOL are actually a better fit for this than something like C++ or Perl.)
I think I have tons of notes on this stuff still lying around my hard disk somewhere. Once I get this f#!%ing database done and dusted, I really ought to dig them out.
--
Sean Timarco Baggaley
[edited by - stimarco on June 7, 2002 10:41:45 PM]
I think this game sounds like a neat idea. But the very first step, in my mind, to creating it is to design and implement the scripting language. You''d have to decide, do you want it to emulate C or C++ so programmers can move on to it without being daunted? Or do you want a more intuitive language like Visual Basic?
I would go with an intuitive language. Teaching programming is not about teaching C++ syntax - it''s about algorithmical design (and using words that probably aren''t real, like ''algorithmical'') and using variables and numbers to make things happen. So you would want to make a relatively simple scripting language, and you''d introduce new elements of the language as the user completes the "levels."
~CGameProgrammer( );
I would go with an intuitive language. Teaching programming is not about teaching C++ syntax - it''s about algorithmical design (and using words that probably aren''t real, like ''algorithmical'') and using variables and numbers to make things happen. So you would want to make a relatively simple scripting language, and you''d introduce new elements of the language as the user completes the "levels."
~CGameProgrammer( );
Author
quote:Original post by stimarco
...I think I have tons of notes on this stuff still lying around my hard disk somewhere. Once I get this f#!%ing database done and dusted, I really ought to dig them out.
Hi stimarco,
Hey cool - I''d like to exchange some thoughts with you... if you''d to email me we can compare notes, as it where.
quote:Original post by CGameProgrammer
...do you want it to emulate C or C++ so programmers can move on to it without being daunted? Or do you want a more intuitive language like Visual Basic?
I would go with an intuitive language. Teaching programming is not about teaching C++ syntax - it''s about algorithmical design (and using words that probably aren''t real, like ''algorithmical'') and using variables and numbers to make things happen. So you would want to make a relatively simple scripting language, and you''d introduce new elements of the language as the user completes the "levels."
Hi CGameProgrammer,
Very good question... at this point I''m leaning towards teaching logic and as the programmer progressed to higher levels start showing the "script" and even further into the game the programmer would actually write the script... It seems a natural progression...
As for creating a scripting language there are a couple C++ scripting engines available - You would just have to wire up the GUI to generate the code and push it through the interpreter... Of course, I always think things are easy... *LOL*
Dave "Dak Lozar" Loeser †
When I was young I used LOGO, the thing where you give directions to draw lines to make neat patterns. It was fun and taught some very basics of programming. (I mean I was 5 or so)
Also I played a game on the Apple2 where you had these robots you had to wire to perform tasks. For example, you could wire a battery to a thruster and that thruster would fire. Then you could instead wire the batter to an OR gate and 2 thrusters, which would connect to some bumpers or something to make the robot bounce back and forth between 2 walls. (It got really complicated towards the end of the game)
It was all graphical and it was a game, as in fun, but it also provided a good foundation for programming and computer concepts.
Also I played a game on the Apple2 where you had these robots you had to wire to perform tasks. For example, you could wire a battery to a thruster and that thruster would fire. Then you could instead wire the batter to an OR gate and 2 thrusters, which would connect to some bumpers or something to make the robot bounce back and forth between 2 walls. (It got really complicated towards the end of the game)
It was all graphical and it was a game, as in fun, but it also provided a good foundation for programming and computer concepts.
...Robot Odyssey
And I think the time is soon ripe for a game like this. The difficulty is to make the experience fun and enjoyable though.
-=Lohrno
And I think the time is soon ripe for a game like this. The difficulty is to make the experience fun and enjoyable though.
-=Lohrno
Hey man, check out the ibm.com site and try to find something called robocode. This is a game that requires you to code... only it''s in Java, not C++. A C++ version would be cool as hell...
lemme try to find a link...
Ahhh, Click here
Anyway, the game simply puts tanks on the screen. You have to write the AI for the tanks. The idea is to try to write the best AI. You can load tanks with other peoples AI and add and tank with your own AI. Run it and see who''s better. There is already some interesting stuff written out there for Robocode. If anything this will also give you some insight on game AI.
- Jay
"Strictly speaking, there is no need to teach the student, because the student himself is Buddha, even though he may not be aware of it." - Shunryu Suzuki
Get Tranced!
lemme try to find a link...
Ahhh, Click here
Anyway, the game simply puts tanks on the screen. You have to write the AI for the tanks. The idea is to try to write the best AI. You can load tanks with other peoples AI and add and tank with your own AI. Run it and see who''s better. There is already some interesting stuff written out there for Robocode. If anything this will also give you some insight on game AI.
- Jay
"Strictly speaking, there is no need to teach the student, because the student himself is Buddha, even though he may not be aware of it." - Shunryu Suzuki
Get Tranced!
As someone pointed out, the problem with RoboCode or CoreWars or P-Robots or whatever is that they are for people who already KNOW how to program. They aren''t really for learning.
Robot Oddysee was cool because by the end it was basically programming, but programming wasn''t the entire point. Having FUN was the point. I would also point to Logo as a good example, it''s basically programming but the point is drawing pretty stuff.
Of course these games are meant for young audiences. For older audiences something like RoboCode might make sense if it was structured in the proper, tutorial-like way.
Robot Oddysee was cool because by the end it was basically programming, but programming wasn''t the entire point. Having FUN was the point. I would also point to Logo as a good example, it''s basically programming but the point is drawing pretty stuff.
Of course these games are meant for young audiences. For older audiences something like RoboCode might make sense if it was structured in the proper, tutorial-like way.
Author
I''ve seen all of the "ROBO coding" games... I always include what is out there in any research that I do for a game concept.
I think I stated in my original post that this was not the type of game that I envisioned... I started programming at the age of 13 - how? I really don''t remember how I learened... how I trained my mind to logically break things down into smaller problems in an effort to complete the end task... Now, after all these years my mind just does this... so, what was it that got me to the place I am?
I''m sure that it could be possible to create a "game" that could be fun and at the same time be educational... I think there was a Star Wars game a few years ago that let you build a robot to perform certain task... Given a problem you chose the best ''parts'' and assembled the robot - was the game called "Droid Works" or something like that...
Anyway, I''m going to set aside some time in the coming weeks to outline just what I do envisage.
Dave "Dak Lozar" Loeser †
I think I stated in my original post that this was not the type of game that I envisioned... I started programming at the age of 13 - how? I really don''t remember how I learened... how I trained my mind to logically break things down into smaller problems in an effort to complete the end task... Now, after all these years my mind just does this... so, what was it that got me to the place I am?
I''m sure that it could be possible to create a "game" that could be fun and at the same time be educational... I think there was a Star Wars game a few years ago that let you build a robot to perform certain task... Given a problem you chose the best ''parts'' and assembled the robot - was the game called "Droid Works" or something like that...
Anyway, I''m going to set aside some time in the coming weeks to outline just what I do envisage.
Dave "Dak Lozar" Loeser †
I remember a game many years back on some of the 8 bit micro''s (Speccy, Oric Amstrad CPC and the like). I cant remember what it was called, but the principle was similar.
In this game you had to design and program the logic of an automated tank. The tank was then left to it''s own devices to defeat an (or group of) enemies.
As you progressed, the equipment available, and the corresponding programming code available expanded. Your goal each time was to create and program the tank so as it could successfully traverse the terrain and defeat any enemies it encounted.
Stephen
In this game you had to design and program the logic of an automated tank. The tank was then left to it''s own devices to defeat an (or group of) enemies.
As you progressed, the equipment available, and the corresponding programming code available expanded. Your goal each time was to create and program the tank so as it could successfully traverse the terrain and defeat any enemies it encounted.
Stephen
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
