The everyday blog of Richard Bartle.

RSS feeds: v0.91; v1.0 (RDF); v2.0; Atom.

Previous entry. Next entry.

8:47am on Wednesday, 8th May, 2019:

Old Ways


It's Final-Year Project demonstrations this week. I had to mark five yesterday and have another one to do today, but when we had the open day at the start of term I got to see all the others, too.

One of the projects I proposed was the recreation of a classic arcade game. Maybe a dozen or more students picked this up. Some of them wrote their recreation from scratch in Java; some used C# for Unity. Some went by the book with a faithful reproduction; some added new features of their own to extend the original.

These were all done just fine and they did look like reacreations of classic games (although I suspect that one overseas student read "recreation" as "RECreation" rather than "recreAtion"). I don't want any students reading this to think I'm criticising them beyond what I said during their project demonstration.

The thing is, none of the students wrote their games the same way they were written in the past: tile-based. They all took full advantage of the systems offered them, but these often got in the way. The screen is not a data structure: it's how the data structure is displayed. In a tile-based system, the world is basically a 2D array. You want to check the player character has collided with something? Look in the array for the square you're about to move into: if there's something in it, you collided with it; if there isn't, you can just move. You don't have to do collision-detection every frame against every object to see if they collide.

OK, so this doesn't make a lot of difference when it comes to execution, because today's PCs are so fast that there's no perceptible run-time efficiency gain. There is an efficiency gain in coding, though, because it's actually easier to do it the old way. It's also easier in terms of design, because the mechanics are so much easier to see.

The students I asked were aware that in the past there were more efficiency and memory constraints on programming, but I don't think they quite realised just how constrained it was.

30 years from now, of course, they'll be the curmugeons complaining about how the programmers of the future don't know they've been born. I will, therefore, see some justice!

Latest entries.

Archived entries.

About this blog.

Copyright © 2019 Richard Bartle (richard@mud.co.uk).