hpr-knowledge-base/hpr_transcripts/hpr2256.txt

Episode: 2256
Title: HPR2256: Modular Game Scaling
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2256/hpr2256.mp3
Transcribed: 2025-10-19 00:28:00

---

This is HPR episode 2,256 entitled Modular Game Scaling.
It is hosted by Eric Newhamel and in about 5 minutes long, and Karina Cleanflag, the summer
is how I allowed more display revolution in a Modular Game Divine.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HPR15, that's HPR15.
Get your web hosting that's Honest and Fair at AnanasThost.com.
Hello again, Hacker Public Radio.
This is Eric.
I believe I introduced myself as Eric Newhamel once before, that was my cat Callie meowing
at me.
She wants attention.
This episode will be a result of me trying to stop thinking too hard about it.
Just sit down and record a show about something that's been on my mind.
I figure one of those would be of interest to hackers, so here we go.
By way of introduction to the subject, I should probably mention that I am an amateur
game programmer among other things.
I was recently confronted with a problem where I needed to adjust the display resolution
of my video game project.
I eventually decided to make it scalable by designing the game at a basic minimal resolution
and scaling up from that as needed.
For the example I'm about to describe the game design consists of three main parts,
which would be the meta game, which includes the launcher, the gameplay module, which handles
all the objects and interactions between them, and the graphics module, which handles
all the graphics that will be put on the screen.
The launcher only requires one more piece of information than normal in order to start
scaling the game, and that's the X, Y resolution, the height and width of the window that the
user wants the game to be in.
The launcher then passes this information onto the graphics module, and the only thing
the graphics module does with this is decide on the size of the window to open.
The launcher then passes this information on separately to the gameplay module.
The gameplay module now knows a little bit about the space that it has to work with, but
the design of the game itself doesn't necessarily need to do anything with this information.
It can do pretty much whatever it wants.
Assuming that there is more space now than the game was originally designed for, it could,
for instance, use the extra screen real estate to just make bigger maps and cram more sprites
onto the screen, or it could decide that the size of the window just pans around a much
bigger game area.
Or perhaps it just leaves the extra space alone and gives the meta game room to put more
information, ancillary information around the edges of the screen, or it could use the
extra space to just scale up the size of the playing field and the sprites to something
that's a multiple of its original design size.
If it does this, then it should record the new scale in an internal variable called
scale, that way you can start passing that information along to the graphics engine.
I mean the graphics module.
Now when the graphics module sees that the game has a scale that's higher than one, it
also has a lot of freedom of choice in what it can do with this information.
It could simply scale up the sprites so they're bigger.
Obviously, they'll be blockier.
You could choose to use a higher resolution version of the sprites.
Same goes for both of those choices when it comes to the tiles of a tile map or any
sort of graphics in the game.
Now, that's the end of my example.
I've implemented some ideas from this example in the design of a game and it seems to
work pretty well.
I hope to use and describe this example as a way to demonstrate how using the modularity
inherent in object-oriented programming, you can make individual parts of the program
much smaller and independent to think about, it makes it easier to wrap it easier for
me to wrap my head around it and make different bits of a program interact dynamically.
Now, before I start rambling and attempt to make some sort of coherent conclusion, I'd
like to wrap this up.
I hope my example could help somebody else with their game project.
I know it helps me to think about things this way.
Until next time, happy hacking.
Goodbye.
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out
how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the infonomicon computer club
and is part of the binary revolution at binwreff.com.
If you have comments on today's show, please email the host directly, leave a comment on
the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the creative commons, attribution,
share a like, 3.0 license.