Don't know, what I don't know.

So I’m new to programming and game developing. So far I’ve created pong and break out and now want to try something a little harder with a chess/checkers hybrid. While planning things I’ve come to a point where I don’t know if what I’m doing is going down the right path or there’s something I don’t know that would make this cleaner. I haven’t started any coding yet just planning stuff. So here goes. Tldr; noob has no idea if what he’s doing is correct.

First I have my players select a map. The map class reads a delimeted text file that holds parameters to create tile objects and throws the objects into a map [ , ]. Then I have a grid class that takes the map [ , ] and creates a (x,y) grid the size of the array and makes the tiles draw their image onto the grid. When player1 and player2 are created they create pieces and get places into a playerTeam [ ]. I have a gamestate class that creates a selecter object that has property locationX and locationY which i pass to grid to draw the selector ontop of the tile at map [locationX, locationY] which the player is able to move around. If selector locationX && locationY == the locationX and locationY of one of the players pieces they are able to do actions with that piece object based on the pieces rulset. Say it can move like a king in chess, 1 square in any direction, once the king is selected i want to higlight all tiles in map [ , ] by ±1x and ±1y. Then move selector to one of those points and select that tile and update that pieces locationX and locationY to the selected tiles locationX and locstionY and redraw it there.

Sorry if formating/spelling is awful I’m on mobile right now. Basically does this seem like a decent plan to deal with this or is there a better way that I do not know of?

Thanks for reading all!

It’s a bit hard to form a picture from this block of text, if you’d draw a diagram that would be a lot easier to digest. It sounds alright though :slight_smile:

If you want to compare your intuitive design to something more formal check out GRASP. Most rules are intuitive but reading it over might give some insights that you wouldn’t think of otherwise.

EDIT: fixed the link, thanks @lozzajp

Sounds like you are understanding programming design a bit better than the average new guy. Sounds good so far as well if you want some really neat ideas check out game programming patterns. I just read the entire thing and it seems to be a staple book in learning game dev.

@Jjagg You are missing the last “)” in your link.(Also seems to link to mobile site even from my PC).

An old boss of mine once told me that I suffer from “over-abstraction-itis” really badly. It’s true, and for years, I’d sit down with a game idea, start designing it and get to a point where you are - where I’d have a workable algorithm/game mechanic/whatever but worry that it was “messy” or “there must be a more elegant way to do this” or on and on.

I’d then spend quite a bit of time googling things, reading gamedev articles, etc and eventually be in so over my head that I simply gave up. Or I’d start abstracting things into class libraries, etc and end up working on writing an engine, not a game.

So, from my experience, let me share a few things with you

  1. Functional code > pretty code. Code that works is WAY better than some mythic “perfect” code. We programmers are obsessed and have dreams about “the perfect code” - something elegant, easy to use and consistent, but it doesn’t exist because…

  2. Everybody’s code sucks. You may think the pros “do it differently” - and in certain cases that is true just by experience, but by in large, EVERYONE’s code is a pile of boolean spaghetti, full of bugs and ad-hoc solutions that “I’ll refactor later” but then are ignored or become so crucial they can’t be refactored. Hell, even Einstein had an ad-hoc hack in relativity…if it’s good enough for him, it’s good enough for you.

  3. “The simplest thing that could possibly work” is the best design paradigm EVER. Over-design and over-abstraction are your enemies! Keep it as simple as you can and only worry about redesigning stuff IF IT NEEDS IT.

  4. Don’t quit! Don’t give up or stop…finish your game! But even more importantly:

  5. DON’T RESTART! As you program, you’ll learn things - and at some point you’ll probably think “Hey, if I restarted this project with everything I’ve learned it’d be SO much better.” But guess what? If you restart, you’ll also learn things and end up at the exact same point. Save it for the next game!

Anyway, from what I can deduce from what you’ve wrote, it looks like you’ve got a totally workable solution that will do what you want it to - that’s the hard part! Don’t worry about “doing it better”, just do it! Hope what I’ve written helps!

Thank you @jjagg and @lozzajp, Those are definitely things I need to learn. What I’ve learned so far is mainly from R.B. Whitakers C# course as well as the Microsoft Visual Academy. I don’t really have much design theory or how to handle large scale things. The main thing question really is having the map[ , ] that holds the tiles and the grid that displays them in their proper place. Getting that to actually work will be quite annoying i’m sure.

@archnem Thank you for your tips. Those are definitely things I feel as well. My main thing is I’ve never dealt with something this large so far. It’s probably something easy for most of the people here however. This is the first step towards my “dream game” a 2d hero based ctf game, basically a 2d strategy version of Team Fortress Classic/Overwatch. I’ve been trying to plot this basic chess game out and every time I think I have a solution to what I need 2 issues arise, it feels like a hydra. Though i’m guessing that’s something i’m going to need to learn to deal with in programming. I’ve only been doing this for a few weeks and lack most theoretical application of programming.

Again thank all of you for reading!