Downloads

Development Journal

F.A.Q.

Ivxscape --- Development Journal

10 - Transparent Features

It's been some time since the last dev journal entry, but these entries should start to show up a bit more often in the coming weeks as I slide out of design work and get back into coding. However, before we continue I feel I need to point something out about the way I code that is going to make updates far apart at first.

When I first announced this project I had a solid chunk of months to work on preliminary stuff and had most of the design stuff sorted out, which is a small part of the reason why it seemed like I was making lots of progress really fast. However, the larger part is that I was making the gameplay first, the mechanics second, and the UI third. This is the way most games are made as people want to ensure their core design works before making it work better and have actual progression and everything, plus it allows designers to show off what they're doing.

...I do not code this way naturally. My progression is UI first, mechanics second, gameplay third. That's right, the way I normally produce my stuff is the complete opposite of what every game design team out there typically does. This unfortunately means there's going to be a lot of updates where there's little to show, since much of the progress will be behind-the-scenes stuff like I/O routines or such.

I can at least show you a screenshot of the video configuration window which pops up when you launch the program. Since this screen is meant to configure your video settings prior to starting the game it only runs in a 640x480 window and doesn't have any fragment shader effects going, just in case you're on a low-end system and can't process such effects properly.

Now, this screenshot definitely doesn't look all too impressive, but if you saw the code going on in the background... well, your first reaction would be, "Why would you go to all that trouble just to make a video configuration screen?" But then I would go on to explain how every little thing that makes this screen work can be used again and again to make more screens in moments instead of days and suddenly all that work that went into making this one screen makes sense. :B

For instance, the buttons themselves each function on my own custom-made GUI. The buttons at the top for full screen and windowed settings have toggles on them since they retain their selection to indicate if you're going to be playing the game windowed or full screen. The buttons in the middle have animated graphics on them and a second line of text. The buttons at the bottom are in different colours. And yet, all eight of those buttons run off of the EXACT same code! All I have to do to make one of these buttons is define a variable, run a button initialization command, and feed it things like coordinates, text, colour, etc., and then the system does the rest for me! :)

Actually speaking of the coordinates, that's another thing that's transparent to the end user in this screenshot. I have to feed in coordinates manually, yet the game supports multiple display resolutions and scaling factors, so I needed to develop a method to calculate coordinates easily and effortlessly so I wouldn't have to constantly calculate these coordinates myself. As a result, I have no idea what actual coordinates those buttons and such are located at. All I did was feed my calculation routines with how many sections of space and buttons there were, what percentage of space to leave between everything, and the size of the buttons themselves, and I get back a bunch of coordinates which I can then just feed to initialization routines and boom, everything is positioned perfectly!

Which leads into more things going on transparently, such as the scaling and resolution independence. There's actually not a lot of games which do this well and in my case, since I'm dealing with very thin-lined graphics it's extremely important for me to get this right. Transparent to the end user, the game is automatically calculating the largest scaling factor it can that won't look ugly, is aligning all coordinates to match onto the scaling factor properly to give the sharpest graphics possible, and every single graphical piece has been designed at 4x the resolution necessary to look good at 640x480. (2x necessary for 1920x1080.) The game system is basically designed to look decent no matter what kind of monitor setup you throw at it! :B

And yet, all of this happens in the background. The end user doesn't know it's happening, nor should they. The sign that you're doing something technical right is that no one comments on it. All this work I'm doing now is laying out a foundation upon which I can build the rest of the game much faster than if I started with the gameplay first and went from there. It's not as showy making the game this way, but it's more comfortable for me, and given that ADG comes first and game making comes second, it's extremely important that my game design efforts feel comfortable so that I get as much work done as I can per amount of time I invest!

As a side note, I tried disabling vertical retrace syncing and ran this config screen and got over 2400 FPS. No, that's NOT a typo! XD