Tutorial competition


Tobriand

Well-Known Member
Joined
Dec 27, 2002
Messages
4,071
Age
38
Location
Croydon (UK)
Website
Visit site
Ok... I suggested this a while back, but shortly afterwards, Craig ran the 15 day competition, so I think it was forgotten. This is an idea, and I wouldn't (I think) be able to sort out any prizes or run it or anything simply because I have big doubts as to whether the Big sites would listen to someone they've never heard of before. Anyway here goes.

The basic idea is that its a coding competition, but the prize goes not to whoever comes up with the nicest program, but to whoever comes up with the best tutorial to make whatever program they've come up with. So a columns style game could well win over a full quake port if the tutorial on how to code it was more detailed, and easier to understand for the beginner than the one for the Quake port.

The object, of course, is to provide some entry level matterial for people who want to code in principal, but aren't committed enough to buy a book and read it, or don't have the time, or read the book and then find when they take a look at GP code that it's completely different (you try finding an explanation for what a surface is in the current sets of tutorials; it's not easy!). With any luck, that'd mean some people who've never coded before would find they had a flare for it, and we'd get some more people who were passionate about porting... whatever it is they want to port. Or remaking. Or (heaven forbid) comng up with something entirely original :)

Anyway - you've probably got the idea. Code a proggy; write a no-brain tutorial that anyone can follow.

Possible Rules might be:
You're allowed to refer to other tutorials on the web, as long as you don't infringe copyright in the process and these tutorials are FREE/Public Domain/Whatever.
The tutorials are marked on how easy they are to follow to the goal, and whether a complete beginner can manage it without any external help... Then you go up step by step until you've got to needing to be a coder already to understand a word of it.
In addition, they're marked on how clear they are and WHY you're doing something; the tutorials should not be aimed at producing people who can copy out code but not understand a word of it, but rather at getting people to understand the code they're writing.
All material actually entered should be GP32, although non-GP32 material (where relevant - and I'm sure it will be, say with SDL - is of course perfectly able to be referrred to).

And prolly a few more. Bounce the idea around. Chew it over amongst yourselves. See if we can get some more coding enthusiasts as well as the group we've already got!
 
the idea is great, I guess the tutos should not so complex like covering a whole game nor that easy like "hello world" but GP32 specific....
 
Thats a really good idea IMHO. That would encourage alot more coding, and ppl could feel like they really contributed to the gp32 scene.
 
I already have a great idea of what to do a tutorial on :D

Tobriand, this is a good idea, so if you can work out the details, GP32:Zine could publicise it and sort out some prizes for it. Just let me know.
 
Brilliant - glad people think its a good idea :). I'll see if I can hammer up some rules proper that'd do the trick; I'm not *exactly* sure what we'd need in the way of them, but I'm sure some stuff is needed. What other details do we really need, btw?

Judges could be something that needs being careful about - especially if a tutorial is aimed at the complete beginner - simply because if you had complete newbies when they started on the first tutorial, they'd quite posibly *not* be complete newbies by the time they got to the last, and therefore be (perhaps) slightly less good at coming up with exactly what got them started and then gave the the boost type of thing. Not sure how that'd be sorted out - if it's open voting, perhaps just point this out as an issue and get people to make sure they're a little careful they try to avoid it (possibly by setting up a random selection script to suggest a tutorial to start with so as to get lots of people starting at different points on the list and working fown and then doing the first two? hmm...). Closed voting might be easier; just make sure there are sufficient judges that they can all start at different points; same idea, but easier to police as it were.

I'd be tempted to suggest beginner and advanced classes, but that'd imply there would be a lot of entries, which I suspect there might not - I'm sure there'll be *enough*, but I doubt quite enough to split into classes, so some other workaround is needed there (and it might also there to be a surplus of people writing intermediate ones simply because absolute beginner ones might be a little boring for those of you who are more advanced). I think the best way round that problem is to suggest a colour-convention; basically, stick beginner text in blue to make it stand out, or mark it out in some other way so that those who are not beginners but still are interested in the tut as a whole can just skip through those sections and stick with more technical bits.

Of course, there is an of avoiding very simple "Hello world" entries, which synkro mentioned. I think the best way to get round this is to suggest that there be a list of areas of programming that could be involved; a coder might be able to come up with better ones than I'm going to have a stab at on account of some sections I do might turn out to be 5-minute-ers and others might be all-inclusive and therefore impractical. Try these:
Language and conventions (intricacies of the SDK, explanations for why a particular command is used where, and similar)
Input (including input from key-presses, direction, and stuff from the various ports)
Graphical output (sub-divided into things like working with sprites, surfaces, what's actually going on with an LCD and the tricks you can do as a result and prolly some more - someone who knows about these things, suggest some stuff for this one, or it'll be too big!)
Sound (Less concerned here, since whilst there's a lot of sound, it's all fairly clean-cut; graphical stuff is harder to define. This includes MP3 work, mod, midi, and anything else you can come up with)
RF-work (Could be in input, but I've got a feeling it ought to be a sction on it's own)
SMC (saving stuff to card, reading it from it, etc.)
Memory (Exactly what does this $ sign do anyway, etc.)
Environment configuration (fairly self explanatory)
Makefiles (separate because it's such a big topic)

And probably about 4 more; preferably sub-divisions of this lot (suggest please). Then what'd happen is you choose at least 3 to work with in a tutorial to some extent - so you could have a graphical demo being coded and covering Language, Graphical output, and some work with .mods or memory or something, but you couldn't have a "Hello world" type example where all that could be used at best is graphical output and Language, or with the addition of Makefile covering and how you got to the point where hello world output was possible in the first place. Of course, by you've got to that stage, you actually have a fairly good tutorial despite only doing it on the simplest of simplenesses, so there's no point in restricting that sort. Similarly, once we'd got the sections hammered out so they aren't too small, but aren't too big either, work out an upper limit (maybe?) to limit people to writing more fully on the sections they're using. I was thinking a max of 10 (hence the need to sub-divide some more); how would that go down?

Errrm... other than that, not sure what'd need to be done. A date for entires, of course, but can't really set that until the whole thing is a fair bit further along. I'm guessing this is the sort of thing that needs about 2 months, but not sure; how'd people find that sort of time-scale for getting the lot done and not forgetting the compo existed?

Oh - and I don't see any reason not to use something that's already released as the basis for the tutorial. Its not like other compos where originality is kind of a necessity insofar as the actual code is concerned. If you coded a game a year ago and want to tell people how you did it, now is the time to do so! However, might be an idea to say no releasing of tutorials before the compo deadline, although entering them and then referring to them in other entries, should you decide to put in more than one, is fine in my mind - any other thoughts on this?

Right... is there anything else we need, apart from prizes (coz those are beyond me) and a more organised undertaking? Is it worth standardising the devving environment, or would that just be something to annoy people (I suspect the latter)? Anything else people can think of?
 
Ok... here's a provisional set of rules I've come up with. Make of them what you will. Comment on them. Scribble over them. Make them your own :)

Limitations and basic regulations
1. Entries are limited in nature only insofar as that they have to be a tutorial, and that the tutorial must cover at least 3 of the sections listed below, or others that I have neglected to mention. At least 3 areas though.
2. All tutorials must be (fairly obviously) able to be released; don?t do a tutorial for something you intend to release as a stand alone program in 6 months. That said, they do not have to be accompanied by a pre-compiled executable (the tutorial is basically the important part in this case). It?d be nice, but if for whatever reason you want to keep the results to yourself, that?s up to you.
3. All code involved must be in principal open, but any GPL or similar licenses must take a prominent place in the pre-amble/intro/whatever for the tutorial so people know they need to be careful with it and tell everyone what they do with it and such.
4. Similarly, all sprites and such shouldn?t be things you?re likely to get prosecuted for using. Copyright I don?t think we need to be too strict on in terms of sprites and graphics used, but they will be hosted at the discretion of whoever hosts the finished collection of tutorials ? if they think they?ll get in trouble for the things, be prepared to find alternative hosting for a sprite/background/mod pack, or just tell everyone where you got them from.
5. A tutorial may refer to another tutorial, as long as that tutorial is in the public domain. Referrals to not count insofar as points towards completeness is concerned (so you cannot enter a tutorial, then refer to it, and get the marks twice) but will be counted insofar as they increase the clarity of what is being said (i.e. a non-coder knows where to look before what?s in front of them will actually be readable).
6. All tutorials must be directly related to GP32 programming, although setting up the environment, and what on earth makefiles are, are both, of course, very relevant.

Guidelines/Content
1. Tutorials should consist of at least 3 of:
o Input
  i. Key input
  ii. RF-module input
  iii. The various ports available and getting info from them
o Sound
o Video
  i. Basic text out displays
  ii. Graphical manipulation (pictures and the moving thereof ? think loading screens, menus, and image viewers)
  iii. Sprites and their animation
  iv. Mode 7 and the workings thereof
  v. 3D math engines and the working thereof
  vi. Working with videos
  vii. Scrolling (including parallax)
  viii. LCD tricks (and WHY they work like they do, what the point is, etc.)
  ix. Other stuff not above
o Sound
  i. Mods
  ii. MP3s
  iii. OGG
  iv. Midi
  v. Wav
  vi. SEF
  vii. Other stuff?
o SMC manipulation
o Memory
  i. Layout
  ii. Manipulation
o Bios and firmware work
o Debugging
o Language specifics and conventions
o Physics Engines, and the making and using thereof
o AI
2. Any specifically newbie or beginner issues should be coded in blue in order to permit any more experienced coders to skip them. Any other colour conventions are at the writer?s discretion.
3. Beginners are of special concern; tutorials should aim not to simply put people in a position to copy what they see and compile, but also to understand why it does what it does.

EDIT: Physics and AI added :)
 
why has it to cover 3 of those points? Fo example: I could do a Tuto about Plasma effects and variations (itÄs pointless I know, source is already given...) and formulas... this tuto wouldn't cover 3 points but would be great... AI sounds good, there is so much you can use....
 
True... The 3-point idea was basically to prevent tutorials for things nothing more than "Hello World", at least without a lot of detail. Of course, IIRC there are built in loopholes (most notably the "language quirks" bit) which allow you to just talk a bit more about exactly what everything does (which of course, you might well be doing anyway). Perhaps I should make it so that the 3-points thing includes referrals - so you start by referring to the tutorials that'd get you started to the point of being *able* to consider doing one on plasma effects or AI, which would in themselves probably cover makefiles, and setting up. Of course, that kind of defeats the point of the system... hmm - something to think about...
 
Back
Top