Snake is a little more complex than lander but is still aimed at the total novice. With Asteroids I’ve done more in each step with less line by line explanation, but hoping that once you have done the other two, then you should be able to cope with this third one.
As ever, comments, suggestions, improvements welcome.
I think this is the best way to present demo projects, and we have enough for a nice combined set, but it would be useful for beginners if we use the same control mechanism (for getting different tabs to run). I’ll have a look at yours, and comment here later.
@Ignatz - how it should be designed is a matter of opinion Your approach is a valid one, but not the only one.
For my purpose I wanted stand alone tabs aimed at the total beginner with zero programming experience which would lead them step by step towards getting something resembling a game up and running. It was never meant to be the blueprint for the proper way to design a game and was not my purpose. Though your approach makes it easier to see the results of each step, it does add more code on the screen which might be off putting (I remember starting off with the physics example in codea - loving the output but being confused when trying to relate it to the underlying code). I was looking for self contained tabs which could be drip fed to the student step by step highlighting only the new parts (though there is also merit of showing the final piece of code in action up front).
Ideally I would post the steps one by one to GitHub and write a blog post/book section/lesson about each one in turn, but I don’t a) have the time or b) have the students to teach so without a “run this tab only” function I think the move the tab to the end and run suits my intentions fine.
However, I appreciate your needs might be different so feel free to use some/all/none as you see fit
@West - I wasn’t being critical in posting the alternative version of the lander.
Your original version was great for beginners, and i use the same step by step approach in all the ones I have done.
What I was trying to show (a class of students) is that if you can plan in advance, you can build a more coherent structure than if you just add bits as you go.
I haven’t listed any projects yet, and I haven’t linked to it from the main wiki page. Let me know if you’d be happy to have your projects listed along with mine.
Secondly, I think some noobs may have trouble with dragging the tabs around. I set up a selector using a parameter, so they can switch tabs while it is running, and it remembers their selection. It means prefixing the setup and draw functions with a table in each tab, to identify them, but it makes it easier for new people, I think.
@nice spot on the touches error - its the last tab that introduces then new touches function but when moving e earlier tab it still gets executed. I’ll need to either add touches={} to each tab or a dummy touched function.
I’m happy for you to add my projects to the wiki.
I’ll look at the tab launchers when I get a chance - on my hols with v limited wifi
That’s because when the displayMode function is called during the progrm (ie not at the start) then Codea doesn’t update the sprcial variables until after the animation is finished, which is after the ship is initialised.
To avoid this, don’t make it so that the user specifies the step at runtime but that they do so in the code:
@Andrew_Stacey I understand the reasoning but can’t get it to work. I’m not sure where to put your invoke call and where to put displaymode fullscreen
When I start the program it starts in main setup.Screen mode is Standard with sidebar.
When I select a step and tap run this step it goes to the invoke function in localisation. This sets the functions to the local ones. It calls the setup function for the tab which contains the FULLSCREEN request, but this won’t come into effect until the current draw loop (initiated by the main tab) is complete. The x variable is set at this point based on the current (standard with sidebar) width. Once the setup is done the original draw cycle is complete then the displaymode moves to fullscreen and the next draw cycle starts. This is the draw cycle from the selected tab. The setup function has already been called and x has been set to the wrong width for the new mode.
@West One solution is to start in FULLSCREEN display mode. If you want to allow the user to select the tab when the program is running then you would have to design some sort of selection system for that, emulating the parameter stuff. But you can make it so that they select the tab before running the code by changing one line in Main. That is, if the setup function in Main is:
function setup()
invoke(2)
end
then it will start in FULLSCREEN running step 2. This replaces the setup that I originally had there.