So, I was playing some genny games from 1993 or 1994 and up, and some 16bit arcade machines from the 90s. I noticed a pattern, which is hardly applied these days (exceptions still exist), now by indie developers more. And frankly, to this day I have found almost no recognition nor mention to any of that, not in my college's videogame design course before quitting, not in Programming sites, not in Game Programming sites, nor in Graphic Design sites either!
The game has to be appealing, and needs a style. But the visual artist's power is limited to drawing sprites/planes, while it's programmer's task to make stuff actually move, on the screen.
However, in the 90s, devs seem to have turned more ambitious than that, until it almost became a requisite for the newer games.
From the games I played (In the Hunt, Sonic 3 Complete, Alien Soldier, Contra HardCorps or Ristar to name a few), I noticed there's a deliberate intent on applying what I call "complicated movement patterns", in the name of "pushing hardware limits". "Worms" and/or other misc "chains", "particles", X/Y speed add/sub (though a basic one, this time now apply for almost everything), circles, arithmetical progressions ideology (to position the particles between two points, or move an object to a given place in a given frame amount), HBlank (scanline repositioning (race fields, "vertical resizing", etc), changing colors), and many more.
In some cases, I THINK it could be a game style done "by force" though, as some effects in Ristar do look quite "messy" in lazy ways sometimes (even though they have seemingly contracted someone to exclusively work in the game's effects).
HardCorps' programmer said in an interview that, after the game had been planned to look this way beforehand, "As a result, the entire game is something of a programming exhibition of skill."
But what happens with the last statement? Well, as a hobbyist programmer, I don't think good visual programming equals to good technical and/or logical programming. My boyfriend does very good on writing game cores, hardware drivers/libraries, and the like. While writing objects, their final code also gets very light & clean, and works very well. But at runtime, they look some rigid or "simple" moving.
I'm exactly the other way: for game cores/drivers/libraries, my code isn't exactly the most optimized as friends say, sometimes "thoughtless". This supossedly gets worse when writing in-game objects and similar stuffs (gimmicks, enemies, bosses, screens (score tally(ies), title screen), etc). It unconsciously happens the most when the spritesheets to use have been drawn by myself, because, as I'm writing the object, straight from vfx mindset: I have this tendency to focus on how it "looks" more than how it "works".
This tendency, however, isn't really "new" to me: I seen the disassembly of a well sold, "professional" genny game, and the objects written have lots of weird stuffs. Self-patching, duplicate codes, dead codes from previous "attempts", memory re-hacking, and generally weirdly arbitrary operations from time to time. I could be wrong, but sometimes it really looks like they were given the spritesheets to work with, then manually experimented around until coming up with a good movement pattern that plays good. Especially with the particle-based explosions!
The final ROM plays very good, it COULD be tagged as a "programming exhibition of skill" too, but would it deserve such a title?
So, what's your take on this? Should Visual Programming be more taken into account? Is exclusvely visual-oriented program an acceptable skill?
I think what does best is, why of course, the proper balance. It's just that it requires much more human skill and/or patience to apply.
Talk about anything else you want
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest