Gotcha. So probably a good set of tutorials/simple examples of Arrays wouldn't go amiss. Creating a highscore, creating a menu system, creating an inventory: But the paradigm is now 'Learning and working with Arrays to do xxx'.
Does the forum not have these types of tutorials? Things just covering fundamentals? (If there are, do these need to get better visibility?)
Both YouTube and the GMC have these kinds of tutorials, and the paradigm simply isn't working. These tutorials put those design-level items in the limelight, leaving arrays, data structures and other technical-level basics a negligible afterthought. An unguided novice won't notice the key technical points that are reusable in other contexts and enable true independence. "Someone who has genuinely learned to implement X should have known Y in the process" is something I've been saying a lot on the Q&A, and the rookies give me nothing but blank stares most of the time. The paradigm isnt "learning and working with arrays to do X", the paradigm is "monkey sees X, monkey does X". It's watch-and-paste tutorial dependence.
All GML books published to date that I know of also have this problem. They pick several games and genres that are popular with novices, then does the same watch-and-paste process in written form. I've served as the technical reviewer for several of these books, and most of them have been poorly received by readers. These customer reviews talk about not learning anything, low technical content and value, and the material being too similar to stuff already available on YouTube. As a technical reviewer, I don't have the agency to change the method of teaching or even setting a bar for technical correctness. I can only point out the bad spots and hope the author changes it. But with designers writing these books instead of genuine coders (Overmars and Habgood are the only 2 exceptions I know of), I can't do much about it.
I have several articles covering fundamentals at a level just above syntax and events, e.g. with block recipe cards. All but one are sunk well past first page now, though I repeatedly link to them.
What I'd like to see more are teaching material of ANY stripe that instead presents a well-defined technical item in the limelight (e.g. arrays, data structures, basic syntax, etc.), then crafts examples around it. It emphasizes genuinely reusable content (basic elements instead of usually non-reusable concrete examples), gives more time to cover the item's finer points, and encourages rookies to think beyond the obvious. Right now it's the other way around, and all it does is encouraging novices to stop their analysis at the superficial design level (e.g. "cool platformer game with RPG elements") and hand everything over to YouTube. That we already know isn't working.
True, true. But the environment itself (GM) doesn't support a data-driven development, as opposed to graphical. Hence why I asked if we can run scripts as standalone in GM now: Or rather, set up some kind of Unit Test so you can run a script and set the data in, see data out.
Because if it's still 'Run the game and see your Room and Objects drawn', then the environment itself is encouraging the graphical mindset. (As it always has: And this has mostly been seen as a positive feature[rightly or wrongly!])
It'll support more sensible data-driven development once the GML 2020 updates come out. But even now, it's perfectly possible to run single scripts as standalone in GM, as long as it's free of drawn graphics and asynchronous delays. One is the classic Room Creation Code in the first room. The more recent approach is gml_pragma("global"):
Code:
///@func run_me()
gml_pragma("global", "run_me();");
/* Insert code here */
I don't have a problem with the "run the game and see your room and objects drawn" approach. This is a valid first step, and a graphical mindset is needed for practical projects. The goal of a responsible curriculum is to make sure that the less obvious algorithm-/data-driven mindset is also covered, as are less obvious aspects of action-driven competency. Most of the incompetent rookies on the Q&A section stay that way not only because they suck with data organization and basic algorithms, but also because they suck at events and plane geometry.
The thing is, if we were talking about a uni course, (or a professional environment) you're right. People cannot skip the basics, they've got to build that foundation to be useful in the future (or be able to face more challenges). As aforementioned, this is why many level 1 courses don't let their students create GUI's, or even data types.
I've been through this whole process myself, and aside from basics being non-negotiable, the rest of your statement just doesn't reflect my experience.
My university used Python for its level 1 computer science course, and class data types came at the 1-month mark. Data structures and trees came at level 2, 4 months downstream from the start of level 1 course. No GUI yet, but most learned it as a side hustle or as part of later courses (e.g. web development).
My high school was the kind that put all of its money into its football team and left Windows 98 machines running Turbo Pascal 7 for the computer science department --- as late as 2010. Even then, its level 1 computer science course had drawn graphics on day 1, class data types at the 5-month mark, and the most competent students were improvising GUIs by the 6-month mark.
On the educational front, I think the biggest problem by far are the so-called "game design" courses that demand playable deliverables, but don't stand their ground in demanding prior coding experience. You basically have a game designer teaching the course, then they dole out an assignment requiring a playable product and leave students in the hands of YouTube. They call it a test for learning on the spot. That's where you end up with a lot of panicking non-coder students who should have seen it coming, but didn't. This kind of curriculum design is to post-secondary education as payday loans are to personal finance.
