2
\$\begingroup\$

So after taking some time running through a course, I believe I have enough experience with referring back to the course how to make the game I wish to all apart from one thing. How to draw the game on screen, I know how the game would work behind the screen, but don't know how to draw it. I'm looking for an experienced, informed answer based upon certain factors.

To provide some context, the game in question's interface would be very simple:

  • Grid of lines
  • Control each cell's content: (text and colour)
  • Pan and zoom

The game at the minute is based upon an excel spreadsheet as shown to show how simple it is:

Screenshot

My aim to keep this question open to others is to create a pros and cons of each.

I've narrowed down possibilities to this list. These are taken from the apple developer page under the section 'Graphics and Games':

  • Core Animation
  • Core Graphics
  • GLKit
  • Metal
  • OpenGL ES
  • cocoas 2d?
  • Other Noteworthy

I'm asking for an informed opinion as to which I should choose. This is narrowed down from research, however I assume I will have missed things that may make this task much easier. My problem thus far is that most games assumed I needed sprites but in something this simple I'm assuming I don't.

If it makes any difference, my current knowledge is only swift, high school math and hopeful abundance of learning resources. I've been stuck with this problem for a long time and I would be overjoyed if I could get some experienced advice. Thanks! :)

\$\endgroup\$
  • 1
    \$\begingroup\$ This should really be chosen by you. Questions like these are discussion oriented, so it's offtopic on this site \$\endgroup\$ – Bálint Sep 15 '17 at 17:25
  • \$\begingroup\$ This question is not discussion oriented. Any familiarity with the frameworks lead to an undeniably simple answer. Unfortunately, gamedev.SE tends to decide far, far too much is "discussion oriented" or "off-topic". Which framework is best for a type of game is exactly what gamedev.SE works best for \$\endgroup\$ – Attackfarm Sep 16 '17 at 2:09
  • \$\begingroup\$ Aaaand it was put on hold as off-topic anyhow. Because of course it was. Just because you, high-gamified-score-holders don't understand how the question could be answered objectively doesn't mean it cannot be. \$\endgroup\$ – Attackfarm Sep 16 '17 at 15:31
0
\$\begingroup\$

The options provided are unsuitable to the task you've described. Apple has created a framework that works very, very well for 2-dimensional games called SpriteKit

To be precise:

Core Animation and Core Graphics are lower level than you need. These are more suitable to a single simple task that cannot be easily reproduced by sprites, like a simple painting app.

GLKit, Metal, and OpenGL are far more complex and flexible than is needed. They require much more expertise than would ever be expected or reasonable for a game/engine of this scope. These systems allow for very complex graphical feats and would be more appropriate for detailed, resource-intensive 3D games, custom shaders, and the like.

SpriteKit, however, is designed to be a high-level, simple-to-use sprite-based framework. For the engine you described, you would not even need any "sprite" resources, as the entire engine seems to be nothing more than squares and text. The entirety would be renderable (size, color, and text) with no outside resources, yet would remain extensible should you desire to add custom sprite functionality at a later point. The "camera" controls would be simple in SpriteKit, while the squares, color, and text would be trivial.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ are you saying each square would be a sprite? To my knowledge you would 'build' your view out of objects in this case the squares, rather than drawing the lines. I would've thought in this case holding all those squares in memory would be a burden? \$\endgroup\$ – user92963 Sep 16 '17 at 12:44
  • \$\begingroup\$ Yes, each sq. is a sprite. No, they wouldn't be a burden. SpriteKit would actually only load one sprite in memory if you used a "square" sprite, but you might not even need to do that, since sprites are rendered onto square/rectangular shapes at their foundation. Simply create SpriteNodes with no set sprite, set the color, and you're done. Place text constrained in the same size of a square as a child, and you have a square with text. Place a smaller square as a child of a larger square, and you have a square with a border. The resource use would be trivial \$\endgroup\$ – Attackfarm Sep 16 '17 at 15:43
  • 1
    \$\begingroup\$ Thanks very much, I probably wouldn't have looked into it due to my preconceptions of it. After some research based on your answer, would you recommend using a 'tile map node'? \$\endgroup\$ – user92963 Sep 16 '17 at 16:10
  • \$\begingroup\$ Nevermind, that's for textured sprites. \$\endgroup\$ – user92963 Sep 16 '17 at 21:11
0
\$\begingroup\$

Given what you've provided, I would probably just do it with CoreGraphics. Learning OpenGL or Metal is a big task. (You should do it eventually, but learn simpler stuff first.) You can easily draw the board and update it when moves are made. You can make a view that's as large as you need and only draw what's been revealed as panning happens and it should be performant enough for your needs as described here.

If you keep the drawing separated from logic of the game you can always throw out the drawing and replace it with something better as you learn other technologies.

| improve this answer | |
\$\endgroup\$