(first post so if I violate some forum rules, sorry!)
I have an idea for a nice turn based board game that I want to develop during the winter season as a way to learn Swift(UI), iCloud Data and related tech.
As I am new (doing the 100 days thing now), I am meanwhlie trying to figure out the best choices to make on using which technology/framework for what.
It will be a square, grid style game board with 2 - 4 players, one on each side. users need to move their piece around the board according to some rules, only some moves are allowed, others not. They also need to place a limited amount of other type of pices on the board, each having a certain function in the game. Those pieces reside on the side of the board and need to be dragged onto the board. Agina, only certain positons are allowed based on game logic. Game data will be stored in iCloud and I also plan to integrate it in Apple's Game Center.
I am mostly thinking about using the new Grid view (I don't care about backward IOS version compatibility on this project). It is important though that holding your phone in different orientations should work. Also, as a future goal, it should be able to run on iPad in each orientation and on MacOS. I also learned about SprikeKit and Canvas, but am unsure if these would be the best choice. It seems if I can just drag and drop views and know which view is dragged to/dropped on which other view I should be ok.
Any hints, tips, howtos and whatnot are very welcome to me.
Thanks a miljon in advance!!
Fred is on the 100 Day Journey, and asks for advice:
First, welcome to the community. Ask questions! And code every day! It's helpful to know what day you are on when you ask questions. Perhaps you missed a key lesson in a past assignment? or perhaps the answer will be in an upcoming lesson. Hard to tell, if we don't know where you are on your journey.
Here's my first hint. Model -- View -- ViewModel aka MVVM. Read up. Watch the vids. Look for other sources to help you understand this concept.
Your game pieces, cards, dice, and your game board will all be models. That is, they will have structures that describe the pieces, dice, cards, board, and board positions. If two pieces battle for dominance, you will use the rules in your models to determine the outcome. Rules, pieces, damage, strength, options are all encoded in your model.
Your views are what your players see on screen. A view should only represent what the model contains. Piece number six is a knight, and sits at position G-6? Ask the model where it is, and this is what the view should show. The knight has 30% damage? Ask the knight for its health value and represent that in the view with cool icons, gradients, or other indicator.
The view-model is the go between. The user clicks or drags a piece in the view. The view executes a function or method that is coded in the view-model, sometimes call a intent. The intent (move piece, reduce health) updates the properties in the model. When the properties in the model are updated, this probably triggers the views to redraw themselves.
I may have oversimplified the MVVM concept. There may be BIG gaps in this explanation. But you might consider asking yourself some questions as you build your application: "What is the purpose of this code? Is it a game rule? Is this an action or event? Will I be drawing this on screen?" Your answer may determine where (View? Model? ViewModel?) you place the code.
During your journey you will find yourself writing game rules in some button on a view. Or you may find yourself determining the color of text in your model. You'll refactor many times to get the balance right! You'll find yourself moving game rules into your model. Adding an intent into your ViewModel, then calling that intent from a button in your game View.
Good luck! Keep us posted on your progress.
What a wonderful, warming, welcoming and helpful response! Thank you!
I am currently on day 27 of 100 days with SwiftUI (BetterRest, ML). I did have some interruptions in my progress due to holidays and, you know, life. I do however intend to go all 100 days.
Althought I did see mention of MVVM principles, I didn't thought much of it...yet. I now see from you simple but clear explanation how you at least should structure a game app. I hope some parts of the course will go into this. Reading about it and doing it, with the help of a course, are two different things :-)
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
You need to create an account or log in to reply.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.