At first I think my question should have been asked before, but I didn't find what I want.
One element of this iOS app I'm developing is break a 8x8 grid into Tetris pieces (every piece is made of 4 blocks). Two particular question I have are:
what is the best way to represent a Tetris piece in objective-C?
what algorithm to present the grid into random Tetris pieces (and later on how to check if two pieces fits together).
Edition on 01/28
#livingtech, I think I implemented pretty much what you say, except the point of "having a hole". My code works with no hole at simple stage when Tetris block is two blocks only (yes, two squares, connected either horizontally or vertically), but at 3-square Tetris block, I would get holes. I just tested and out of 1000 running, I would get one without a hole. So definitely I need some mechanism to check if next square will be a singleton.
I been trying to do the same thing for my game. Though I am a total beginner, and I'm using XNA and C#.
But the way I'm trying to go about it is: 4x6 grid array
--y123456
X1-000000
X2-000000
X3-000000
X4-000000
Here,
0 signifies no block
1 defines a block
Algorithm
Start by taking the very first 0 in the array ( top left corner )
and randomly pick a 0 or a 1.
Randomly choose the coordinates based on x1/x2-y1/y2, decide 1 or 0.
If it is 1, then decide coordinated based on where that 1 was put.
If it was 1 on x2 y1, then decide if a 1 should go on next touching
coordinate.
If you just have to code in what coordinates touch and which don't,
and the logic will roll through.
I have mine set up bit different. But this is the basic foundation of my random Tetris engine.
I also found that making it like that really helps to have a whiteboard and make a drawing of the grid and label with your coordinates.
since ur board is 8*8, i think u can use a int64 to represent the board. each bit of the int64 represents whether the specific grid is filled or not.
Implementing Tetris is a hobby of mine. First implemented it in Windows/C. Then in Perl/Tk! Last implementation I did in Obj-C/Cocoa (Mac). In all cases, the game logic is the same. Only the UI stuff changes. I treat every little box separately and have a two-dimensional array which contains the presence (and color) of every "set" box on the board. Standard board size I use is 10 boxes wide by 20 boxes high.
Separately I keep track of the "dropping" piece: it's location and what kind of piece it is. Based on a timer, try to make the piece drop. If any of the boxes where the "dropping" piece would drop is already set, then stop dropping the piece and add the piece boxes to the "set" part of the board. Create a new piece, and start over.
It may not be the best way to implement it, but it makes sense in my head. From a pure OO perspective, each shape of a dropping piece could be a subclass of a generic shape class. Override functions that check whether the shape can drop, the offsets of the individual boxes in the shape, etc.
I don't think anybody has taken a stab at your question #2 yet here, so I'm going to outline what I would do.
Setup:
You'll need to represent your grid as an array of some kind. At the very least, you'll want some kind of boolean values, to denote whether each coordinate in the grid is "occupied".
You'll need to keep track of the pieces on your grid. This could be another array, this time holding references to the four coordinates for each piece.
You'll need a variable or variables to keep track of a coordinate in your grid where you'll start filling in pieces, (I would probably populate these with a corner to start).
Set up a "pool" of all possible Tetris pieces and rotations. (You'll want to keep track of which ones you've already checked on every iteration outlined below.)
Iterate:
Get a random piece from your pool that will fit into your starting coordinate. (If you want to get fancy, you could be smart about which ones you choose, or you could just go totally random. As pieces don't fit, mark them checked, so you don't keep checking randomly forever. If you get to a point where you've checked all the pieces, you have a solution that doesn't work, either back up an iteration, or start over.)
Make sure the Tetris piece you selected didn't leave a "hole", or empty space with less than 4 squares. (I don't know your requirements for solving this problem, so I can't say whether you should focus on speed or ease of coding, but you may be able to skip this step if you want, and "brute force" the solution.)
"Place" the piece, by writing it to your piece array and marking the coordinates filled.
Check for "finished" condition, in which all your spaces are filled.
Pick a new coordinate in your grid and repeat #1. (I would pick an empty one next to the previous coordinate.)
If this actual yet, I wrote test tetris app on Objective-C few months ago https://github.com/SonnyBlack/Test-Demo-Tetris . I think my algorithm not very well, but it working. =)
Related
I am going to make simple 2D game in Defold game engine and I am new in this area. My question is, I have 2 game objects every object has sprites in it. A sprite in the first game object must be background for sprites of second object. I have designed it well but when I run (or render, I don't know how to call properly) it sometimes sprites of second game object are invisible and some times everything is OK.
The same issue if I set main backgruon image for the game. Please share your experiences with me. Thanks beforehand.
You posted the same question on the official Defold forum so I'm going to replicate the answer you got there here on SO as well. The solution is to make sure that the depth of two game objects that overlap isn't the same. If two objects have the same depth and overlap you might sometimes see one in front of the other and sometimes vice versa. The default render script allows a z-range of -1 to 1 (you can use fractional z-values to get fine grained control), but you can copy it from builtins and increase the range if you want to. Something like -10 to 10 is usually a good enough value.
I'm trying to develop an OpenCV-based Path of Exile inventory parser. The inventory looks like this, with items left and right. The round things on items are called "sockets", are randomized, but they can be hidden.
There are two options for this:
When you hover an item in game, and press CTRL-C, a description of the item is copied to your clipboard. A solution would be to do this on every single inventory cell, to re-create the whole inventory, bit per bit. There is an issue with this, however: the "item copy" action is probably logged somewhere, and having 12 * 5 = 60 actions like this in under 2 seconds would definitely look fishy on GGG's (the devs) end.
Using image-recognition software to decompose the inventory like a human being would. There are several methods with this, and I'm struggling to find the most effective.
Method 1: Sprite detection
This is the "obvious" method. Store the sprite of every single item in the game (I think there must be around 900-ish sprites for all the bases and unique items, so probably around 250 sprites if we exclude the unique items), and perform sprite detection for each of them, on the whole inventory. This is without a doubt extremely overkill. And it requires tons of storage. Discarded.
Method 2: Reverse sprite detection
For every single sprite in the game, calculate an associated md5, and store it in a file. Using OpenCV, cut the inventory's items one by one, calculate their md5, and match against the file to detect which item it is. It's probably faster this way, but still needs a ton of processing power.
Method 3: Same than #2 but smarter
Use OpenCV to cut the items one by one, and based on their size, optimize the search (2x2 item means that it's either a helmet, boots, gloves, or a shield. 2x1 item is always a belt. 1x1 is always a ring/amulet, and so on).
Is there another method that I'm forgetting? All of these look like they need both heavy processing, code, and before-hand work from me.
Thanks in advance.
I am taking a stab at John Conway's game of life [wiki] & [demo]. I have developed a small program in C to calculate the next state - using a 1D array (but with 2D array logic).
I am hoping to make a small iOS app out of this (to Objective-C!), and am wondering the best and fastest way to render a grid like seen in the video. Note, it would have to render every fraction of a second and would use an array of 1's and 0's to determine a "block's" respective colour.
Edit: I'm probably looking at around 10 frames/sec, but a very large grid. It'd be rendering out hundreds of thousands of squares. Of course, if this isn't physically possible with iPhone/iPad technology then I'll reduce the grid size. It is variable without issue, just looks more 'epic' on a grand scale.
Any suggestions will help out, never touched anything of this manner before.
The best way depends on your criteria. Fastest would probably be to use OpenGL. You might even be able to write a shader to do the entire simulation. However, OpenGL is hard. Really hard.
I suspect that using Core Graphics and implementing code in a view's drawRect method that renders the array of cells onto the screen would be fast enough. It depends on how many cells you have and how many frames/second you want to draw.
I wanna achieve something that looks like the wizard's ability in the game Trine.
I want to create a game where the player uses the mouse to create certain objects, so i will need to compare the shape the player drew to a predefined shape of my own and check if its close.
I have no idea how to achieve this and where to look for, I assume it has something to do with shape recognition like in image processing and computer vision but it should be much simpler and work in real time.
does anyone have a clue how this can be done or where can i look for something like that?
Is this what you're going for? http://www.youtube.com/watch?v=7Zh79q_xvZw
I would start by researching gesture recognition. I think that's the phrase you need to get good info. http://en.wikipedia.org/wiki/Gesture_recognition
Also, sketch recognition: http://en.wikipedia.org/wiki/Sketch_recognition
Have a look at this question. What you are looking for in particular is on-line handwriting recognition, meaning that you follow every move of the user from beginning to end.
Now, you might want to simplify it a whole lot, so one way is defining 9 areas, like a 3x3 grid. Then convert the user's movement into a list of how the user moved through these grids (use thresholds to make sure it was in that area for a while). Now you will have an array like this: 1-1, 1-2, 2-2, 2-3 (meaning the user went from upper-left corner, the upper-middle, etc.)
This information is now fairly easy to match to a set of gestures. If it performs poorly, you can either make it more difficult and introduce a Hidden Markov Model, that will allow some mistakes in the gesture (but still matching the most likely one you have in your gesture set), or you could simply display the grid to the user, so that the user will learn the gestures like number codes.
I've got a problem: i need to add a powerup to a racegame, using collision detection.
so i drawed the powerup, but the problem is: It has to be drawn after every 5 rounds and it needs to be placed ramdomly on the track.
Someone with any good advice?
Thanks.
Thats a bit vague. So here is my best shot at an answer.
You would want to use the c# Random class, here are the docs
For a simple game, using rectangular collision should be all you need (I assume thats what you are using) - If you want to randomly generate the power-up position, you will want to create a new Vector2 (the powerups position) with the random generator.
You can use the Next function, to pass in a low, and high variable - which you would need to configure the the bounds you wish the powerup to appear.
My advice as a game designer on the other hand, tells me that randomly located power-ups aren't always the go. It makes it harder to control the games flow and balance, and can very easily result in a flawed final product.
So my advice is a hard coded set of possible weapon spawn points - using a random generator to pick one to place.