@2Dcube @BPOutlaws_Jeff @hdarren @atmobeat @Miradur
I think posts like yours are addressing people like me who support the OOP shift in GML, so I'll respond to the three main themes among those posts as a counter-narrative. Hopefully then you'll see the other side of the argument, and how people like me are actually fighting in your favour.
The first is the apparent accusation that I'm throwing off novices on purpose with placeholder names in the examples I used on two previous posts.
I'll clarify right now that those were NOT intended as practical examples, but synthetic examples designed to attack or question YoYo's design decisions. Someone at my level wouldn't leave variables named
foo and
bar in a production-level project, and for a practical example I'd at least give some context and use more descriptive names. But some of the forms can manifest in live code just under different names, either as intended design (e.g. mix-in inheritance) or as the result of carelessness (e.g. forgetting the
new operator), so they have to be raised in generic form.
The second is this sentiment about how introducing OOP in GML is intended to cater only to skilled hands and alienate novices.
Code in a game development setting typically falls in 2 categories:
- Action-driven code: Code that deals with overt action and has a direct presentation to a player. Examples include code dealing with graphics, audio, movement, collision and I/O.
- Data-driven code: Code that deals in background bookkeeping or abstract data and do not have a direct presentation to a player. Examples include code dealing with saving and loading, scorekeeping, stat management, relationships between agents, or abstract board states.
All games have components in both, though in different proportions and degree of interdependence. Yet mainstream GM education has a chronic bias against the latter, and students learning under it are inappropriately taught to do everything in action-driven space. The OOP additions to GML are mostly designed to address data-driven concerns, so YoYo would appear to be turning its back on novices, even though its intention is to make data-driven code easier for everyone.
Now look at all the things you claimed on this topic are "novice needs" for making a game. They are all superficial action-driven concerns that naturally come from the uninitiated. But have you ever stopped to consider data-driven concerns in a game's design, or even been taught to in the first place? You're like a handyman whose only tool is a hammer and for whom every job looks like a nail. You've been struggling with cutting 2-by-4s by beating it until it snaps, and when the hardware store announces that it's stocking better saws, you whine about how they should instead stock better hammers to serve you.
All of this community banter about how data structures, JSON and abstract modelling are "advanced" material is absurd to me. These are the most basic techniques in data-driven code, just as collision handling, drawing or keyboard/mouse input are in action-driven code. They're not difficult, just foreign to GM users who have only seen one side of the coin. If mainstream GM tutorials didn't teach you to handle action-driven code, common fare like
place_meeting(x+hsp, y, obj_wall) or
y += vsp; would be no less "difficult" to you, and you'd say that's also shibboleth intended to alienate novices. This is a 20-year-old problem with bias in GM's education system and ongoing development, and it's making you all confuse foreignness with actual difficulty.
The OOP update is for everyone regardless of skill level, and it's especially for people who have been underexposed to the other side of the action-data coin due to GML's past decision to divest from the data side. There will be incentives from now on to make GML less awkward in more contexts and usable for all.
The third is this constant insinuation that OOP is not applicable in general GM development, and won't add to what's already doable.
One of you questioned how the addition of OOP would help a beginner develop Tetris. Funny you'd mention that in particular, because Tetris is an example of a game that should be built upon an abstract data-driven foundation, and only handle I/O and presentation in action-driven space. In Chess, you don't state moves in terms of physical measurements like "pawn 1.5 inches forward", you state moves in terms of abstract square positions like "pawn to d4". The grid-centric nature of Tetris puts it in the same league as Chess. Many mainstream GM tutorials are encouraging the same absurdities as the "pawn 1.5 inches forward" anti-example, except the unit is pixels instead of inches.
Here's a rough example of what the centrepiece of the data-driven approach might look like:
Code:
function TetrisGameState() {
board = [...];
next_piece = ...;
current_piece = ...;
current_piece_offset = [..., ...];
turn = function() { ... }; // Rotate current piece
move = function(horiz_change) { ... }; // Move current piece left/right
drop = function() { ... }; // Drop current piece
tick = function() { ... }; // Make one in-game step
// Other helpers here
}
A traditional controller object would hold a single game state, call
tick() periodically and forward user input to
turn(),
move() and
drop(). Visual board element objects would be "dumb" (i.e. hold no board-specific logic) and implement
the observer pattern only to keep synchronized with its slice of the game state.
Why do it this way instead of going with the herd? I can list a whole host of features that building on a foundation of this would be straight-forward, where an equivalent mainstream action-centric implementation would struggle or needlessly duplicate code.
- Fine tuning the animation of board elements (make it observe developer keystrokes or commands instead of a live state)
- Changing sources of input (just use a different object to listen and then manipulate the state)
- Pausing (just stop calling tick() and the other input methods in one place)
- Replay (source of input is just a log of method calls)
- Resolution independence (just change the square sizes and starting coordinates)
- Automated testing of input behaviours (scripted input with expected comparison targets for board)
- Automated testing of unwanted movement in corner cases and regressions (same as above)
How many of these do current GM games do improperly? How many of these commonly get the undeserved label of being "advanced" or "complex"? Given how basic data-driven operations have been neglected for so long, can you see why YoYo's showcase is basically a collection of 2D pixel/neon-geometric action games?
The addition of OOP is highly applicable to GML development, and learning and documenting these new OOP patterns will take GML to places where the general user community used to stick "do not enter" signs in front of.