Wednesday, May 06, 2020

Texture Design for Taskforce

This project seems as endless as the Covid-19 saga. It's a strange circumstance that just about the only way I could complete this mammoth task is in circumstances like we have now.

I awoke a 6am, determined to start work at 7am, and the plan worked. This is probably my longest ever day as a programmer, or a painter: 7:30 till 8:00, 30 minute break, 9:00 to 10:30, 30 minute break, 11:00 to 12:30, lunch. 13:30 to 15:00, break for one hour, 16:00 to 18:00, evening meal, 19:00 to 19:55.

Step one of four is now complete, I've designed new textures for all of the scenery. This job is at least as meticulous as it is artistic, probably more meticulous than artistic. I'm designing sheets like this:

These broadly mirror the existing artwork but at double the quality. I have 10 sheets to make, filled with objects from floor tiles to road signs, to book shelves, to wire fences, doors, windows. These are a bit like the 'decals' that I used to float off a sheet when making Airfix models. These shapes will cover every object in the game. This is one of the biggest of the four jobs (applying them might be bigger), but in some ways the easiest, as it involves mimicking what is already there.

Tomorrow, stage 2, which is creating the 3D models that will accept these. The models already exist, but I now need to slice them into 6 bits: one for top, and each of the four sides (if the models touch the sides, that is, if not, then I can leave them).

I thought today of potential problems. Although this is the ideal and best way to render this game, it will involve a huge amount of game sprites, each with hardly any polygons, often just 2 for the floor tiles. Most of the walls have 6 sprites, but again, just two polygons per sprite. This might lead to slowdowns... modern graphics are best with lots of polygons and minimum computer power, but this game demands the opposite because each object is printed after careful thought.

The map is 50x50x6, so there could be over 90,000 sprites active at once (lots more for weapons, soldiers and explosions). That's huge! Each sprite is capable of moving, rotating, accelerating, and all in a linked list. Parsing a 90,000 long linked list might lead to significant delays, and that is done at least every time the screen is printed - more than 50 times a second. This is worrying, but I can take heart from the fact that the game now has up to 30,000, and seems to work fine.

In an emergency I can go back and use the current, inferior looking but working, version. I always seem to be pushing limits. My music software, Prometheus, back in 2002 when I made it, I knew that computers needed 10 years to be fast enough to run it. My 2001 game The Heart of Aorkhan was similarly vast. My PC of the day had no hope of even rendering it (it was a 3D version of my Amiga game Blade, or Hilt, a huge maze)... but I knew that computers would one day. Of course, in my case now, I need this game working next week, not next decade.

I'm now exhausted and will now rest. I haven't finished before 8pm in weeks. Tomorrow will be another long day. I can't wait to see and try the finished game though. To think, I was supposed to be working on the music this week. The public demo will have no music, if it launches next week as hoped.