Optimizing Large, Repeating, Sections of Code

Hi, I'm making a simple chess game to learn Lua and the Playdate SDK, and I've run into an issue where I need many individual variables for individual sprites, and it's causing a lot of visual noise in my code. Performance-wise, it hasn't been a problem, but I've only written a fraction of the code so far, and I anticipate that as I add more individual variables (I'll need to double the number I'm at right now), and begin to more actively manipulate and depend on them, performance may start to wane.

As a preface, I have the chess board as wide as possible, and you can scroll up and down using the crank. That, not letting the player scroll beyond the end of the board, and keeping everything "anchored" in place relative to the board has brought me the most trouble. Also I have every sprite's (including the board's) center set at the bottom left corner because I want the board to load in showing the bottom of the board/the starting player's pieces.

For example, for each chess piece, I'm importing the image, setting a sprite to that image, then setting the zIndex and center for each sprite(this part I already have running through a function), moving the sprite to its respective coordinate on the screen, and adding the sprite to the display list. That part I'm not super concerned about. I then get the piece's relative distance in relation to the board's coordinates and make this the "default/intended" distance. When the player moves the crank, the board and the piece is moved by the change + the accelerated change (max of 10 or -10) of the crank. I then have a section that stops the player from scrolling beyond the edge of the board. If the function ended here and we continued on with the game, when the player cranked at the top or bottom of the board, the board would not move(as intended), but the pieces would, eventually going offscreen.

My (I assume) inefficient solution to prevent this includes: getting the piece's current distance from the board to it and subtracting the "default/intended" distance from that number. Then, if the distance from the board to the piece is greater or less than the default distance, I move the piece by the subtracted distance just mentioned. I'm doing all of what I just mentioned for every single piece, resulting in a lot of variables that are meant to represent the same thing but need to be individual for each piece. If not performance-heavy, it just seems like sloppy code to me.

I suspect that there might be some way to simplify the process using either tables, for loops, functions, or some combination of them, but I think my skills just aren't at that level and I just can't wrap my mind around something of that scale yet.

If you'd like to help out, this is the source code, and keep in mind that (at least the way I've implemented it) each piece needs to have a separate, unique, variable for its various distances so that they can exist scattered around the board with various y values as the game progresses. I've already added in a movable sprite with the selector, which can be enabled by way of the system menu. I feel like it's a good example of the sprite being able to be anywhere on the board while still being "anchored" to it, and not the playdate's screen.

Thanks!

Some various things come to mind:

  1. Crank to change the drawOffset which will simplify your drawing code. You won't need to calculate distances and such. You'll set and forget the sprites.
    https://sdk.play.date/inside-playdate/#f-graphics.setDrawOffset

  2. Create an object for chess piece, extending Sprite, with properties to indicate piece type. You'll get position and other properties thanks to your object descending from Sprite. They will also be drawn automatically.
    https://sdk.play.date/inside-playdate/#_object_oriented_programming_in_lua

  3. Once you've done point 2 you can easily iterate over all sprites to cut out a lot of your repetitive code.
    https://sdk.play.date/inside-playdate/#_group_operations

  4. You'll need to draw the board as a sprite too.
    https://sdk.play.date/inside-playdate/#f-graphics.sprite.setBackgroundDrawingCallback

  5. You could go all-in on object oriented design, but I think that requires a different mindset and may be too much at this point. It would, however, result in much more readable code.
    Example:
    https://www.geeksforgeeks.org/design-a-chess-game/

1 Like