I received my TI-82 STATS programmable calculator (which is in fact more of a TI-83) about two days ago - and wanted to program a Snake game with the builtin TI-BASIC language.
Although I had to find out: TI-BASIC is extremely slow. My first implementation was so slow, that it wasn't even a challenge for the player! The main bottleneck for me lies in the management of the list (array) containing the coordinates of the snake body.
I have tried two things:
When the snake moves, update head position, then loop through the array from the tail position, and set myList[ N ] to myList[ N - 1 ], in order to make the snake appear to be moving.
This however, gets unplayable after the list gets about 4 parts long. (too slow)
Then, I tried implementing some sort of queue/deque using TI-BASIC's list manipulation features, like popping off the end and adding something at the front of the array.
This worked a bit better, but also gets too slow over time.
TL;DR / actual question:
Do you know a trick so the game doesn't slow down with the snake getting longer? I have seen that this is possible in other games made in TI-BASIC
Use a circular buffer. To elaborate:
Get an array, sufficiently big to hold the maximum snake. Establish two pointers, one for the head, one for the tail.
At the beginning, the tail would be in cell #1, the head in cell #3. As the snake moves, move the head pointer to the right and write the new coordinate. Then, if there's no food eaten, move the tail pointer to the right as well. If either of the pointers tries to go beyond the rightmost end of the array, wrap them over to the beginning.
A trick that most likely will work is instead of [ N - 1 ] do [ N - 2 ] or a higher number that way it makes up time by mathematically moving faster (you also have to adjust the size of the head to go faster
A simple trick when working with lists to improve speed is to make full use of the functions provided under the LIST menu. In particular, seq can provide significant performance benefits over a for loop that accomplishes the same goal. Other functions that I find useful are cumSum and Ξ”List.
http://tibasicdev.wikidot.com/cumsum
http://tibasicdev.wikidot.com/deltalist
http://tibasicdev.wikidot.com/seq-list
Related
I'm trying to build an array of all player pawns that are in the players FoV cone. I'd prefer to not have to loop through GetAllActorsofClass for obvious performance reasons. This will be done every tick.
GetAllActorsOfClass iterates over a hash table of things of that class. Even with 100 players it is unlikely to be very costly. I would imagine that a "get actors in frustum" would just do that under the hood.
If you are okay with using it, from there you would use ConvertWorldLocationToScreenLocation and compare that to the screen bounds coordinates with GetViewportSize.
The only method the wouldn't use GetAllActorsOfClass I can think of offhand is to calculate the size of the rectangle at the "end" of the frustum, using a giant multi box trace, and filtering based on the dot product. Traces are cheap, dot product is cheap. Whether or not it's cheaper than GetAllActorsOfClass is going to be specific to your game.
If performance is really a problem the best solution is to use code. Depending on your implementation you might be able to use Blueprint nativization to get an extra boost without digging into code.
Use MultiSphereTrace from your player to his FOV direction and loop through hit results.
Make sure you set the collision layer correctly so the trace only interact with target player.
I do this on my mobile game with around 10-20 actors per frame, and it works fine.
For now, I use a 3D array to represent my voxels in different chunks. I want to render voxels which can be visible by the player, but the way I do it is totally not efficient:
I iterate over the whole 10*10*10 chunk and check on every voxel if there is a neighbor equal to Air. Then I render separatly each faces which can be visible. So I mostly check every voxels 6 times. And I do this for all chunks.
Is there a better way to proceed or an algorithm to reduce iterating?
I basicly don't know if it is better to work with 3D Array or Octree...
Thank.
I've been thinking through this problem recently, and since nobody has answered you I thought I'd mention some of the ideas I've come across.
Firstly, it's work noting that you only need to calculate which faces to render once, since that only changes if you remove or add a voxel, and then you only need to recalculate the voxels immediately around the place where you made the change. Just use a flag to mark for rendering and cache that until something changes. If you aren't already doing this, this will give you a big performance boost over calculating every frame.
I also recommend looking into this extremely fast raycasting algorythm:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.3443&rep=rep1&type=pdf
You can use it for fast collision testing, and also for cull-testing. You can cast at grid nodes to see if any part of a face is visible.
I'm trying to make a simplified version of crazy taxi . For the first step i need to make an infinite ground . I'VE searched online but couldn't find any examples .
Can i find any example of how to do this ?
https://www.youtube.com/watch?v=rhTPxrJICVg&list=PLLH3mUGkfFCXQcNBz_FZDpqJfQlupTznd
N3K makes an infinite runner in Subway Surfers style, meaning ground coming from the back and going towards the camera.
The above link is to his tutorial series.
This is a very broad question I try to give a very simplified answer to get you going.
To create endless road you need some sort of procedural function that generates corners for your track. If you do not need to backtrack you can cook something up yourself like (in X distance turn X degrees to the right). If you do need to backtrack you need something like perlin/simplex noise that always generates the same value based on 1 or more other values. You could use total distance to get the curve in the road.
You simply keep generating the world on the fly and unload pieces of the world you don't need any more. If the player can alter the world like destroying street furniture or leaving skitmarks you need to implement a chunk system. When you backtrack and generate a cerain part of the world with your procedural function you can have permanent changes the player made in that specific part by saving and loading to the chunk. Much like Minecraft does it actually.
I'm hoping to prototype some very basic physics/statics simulations for "voxel-based" games like Minecraft and Dwarf Fortress, so that the game can detect when a player has constructed a structure that should not be able to stand up on its own.. Obviously this is a very fuzzy definition -- whether a structure is impossible depends upon multitude of material and environmental properties -- but the general idea is to motivate players to build structures that resemble the buildings we see in the real world. I'll describe what I mean in a bit more detail below, but I generally want to know if anyone could suggest either an potential approach to the problem or a resource that I could use.
Here's some examples of buildings that could be impossible if the material was not strong enough.
Here's some example situations. My understanding of this subject is not great but bear with me.
If this structure were to be made of concrete with dimensions of, say, 4m by 200m, it would probably not be able to stand up. Because the center of mass is not over its connection to the ground, I think it would either tip over or crack at the base.
The center of gravity of this arch lies between the columns holding it up, but if it was very big and made of a weak, heavy material, it would crumble under its own weight.
This tower has its center of gravity right over its base, but if it is sufficiently tall then it only takes a bit of force for the wind to topple it over.
Now, I expect that a full-scale real-time simulation of these physics isn't really possible... but there's a lot of ways that I could simplify the simulation. For example:
Tests for physics-defying structures could be infrequently and randomly performed, so a bad building doesn't crumble right as soon as it is built, but as much as a few minutes later.
Minecraft and Dwarf Fortress hardly perform rigid- or soft-body physics. For this reason, any piece of a building that is deemed to be physically impossible can simple "pop" into rubble instead of spawning a bunch of accurate physics props.
Have you considered taking an existing 3d environment physics engine and "rounding off" orientations of objects? In the case of your first object (the L-shaped thing), you could run a simulation of a continuous, non-voxelized object of similar shape behind the scenes and then monitor that object for orientation changes. In a simple case, if the object's representation of the continuous hits the ground, the object in the voxelized gameplay world could move its blocks to the ground.
I don't think there is a feasible way to do this. Minecraft has no notion of physical structure. So you will have to look at each block individually to determine if it should fall (there are other considerations but this is minimum). You would therefore need a way to distinguish between ground and "not ground". This is modeling problem first and foremost, not a programming problem (not even simulation design). I think this question is out of scope for SO.
For instance consider the following model, that may give you an indication of the complexities involved:
each block above height = 0 experiences a "down pull" = P, P may be any of the following:
0 if the box is supported by another box
m*g (where m is its mass which depends on material density * voxel volume) otherwise if it is free
F represents some "friction" or "glue" between vertical faces of boxes, it counteracts P.
This friction should have a threshold beyond which it "breaks" and the block then has a net pull downwards.
if m*g < sum F, box stays where it is. Otherwise, box falls.
F depends on the pairs of materials in contact
for n=2, so you can form a line of blocks between two towers
F is what causes the net pull of a box to be larger than m*g. For instance if you have two blocks a-b-c with c being on d, then a pulls on b, so b should be "heavier" than m*g where it contacts c. If this net is > F, then the pair a-b should fall.
You might be able to simulate the above and get interesting results, but you will find it really challenging to handle the case where there are two towsers with a line of blocks between them: the towers are coupled together by line of blocks, there is no longer a "tip" to the line of blocks. At this stage you might as well get out your physics books to create a system of boxes and springs and come up with equations that you might be able to solve numerically, but in a full 3D system you will have a 3D mesh of springs to navigate iteratively to converge to force values on each box and determine which ones move.
A professor of mine suggested that I look at this paper.
Additionally, I found the keyword for what it is I'm looking for. "Structural Analysis." I bought a textbook and I have a long road ahead of me.
I am trying to create a Pacman AI for the iPhone, not the Ghost AI, but Pacman himself. I am using A* for pathfinding and I have a very simple app up and running which calculates the shortest path between 2 tiles on the game board avoiding walls.
So running 1 function to calculate a path between 2 points is easy. Once the function reaches the goalNode I can traverse the path backwards via each tiles 'parentNode' property and create the animations needed. But in the actual game, the state is constantly changing and thus the path and animations will have to too. I am new to game programming so I'm not really sure the best way to implement this.
Should I create a NSOperation that runs in the background and constantly calculates a goalNode and the best path to it given the current state of the game? This thread will also have to notify the main thread at certain points and give it information. The question is what?
At what points should I notify the main thread?
What data should I notify the main thread with?
...or am I way off all together?
Any guidance is much appreciated.
What I would suggest for a pacman AI is that you use a flood fill algorithm to calculate the shortest path and total distance to EVERY tile on the grid. This is a much simpler algorithm than A*, and actually has a better worst case than A* anyway, meaning that if you can afford A* every frame, you can afford a flood fill.
To explain the performance comparison in a in a little bit more detail, imagine the worst case in A*: due to dead ends you end up having to explore every tile on the grid before you reach your final destination. This theoretical case is possible if you have a lot of dead ends on the board, but unlikely in most real world pacman boards. The worst case for a flood fill is the same as the best case, you visit every tile on the map exactly once. The difference is that the iterative step is simpler for a flood fill than it is for an A* iteration (no heuristic, no node heap, etc), so visiting every node is faster with flood fill than with A*.
The implementation is pretty simple. If you imagine the grid as a graph, with each tile being a node and each edge with no wall between neighboring tiles as being an edge in the graph, you simply do a breadth first traversal of the graph, keeping track of which node you came from and how many nodes you've explored to get there. You mark a node as visited when you visit it, and never visit a node twice.
Here's some pseudo code to get you started:
openlist = [ start_node ]
do
node = openlist.remove_first()
for each edge in node.edges
child = node.follow_edge(edge)
if not child.has_been_visited
child.has_been_visited = true
child.cost = node.cost + 1
child.previous = node
openlist.add(child)
while openlist is not empty
To figure out how to get pacman to move somewhere, you start with the node you want and follow the .previous pointers all the way back to the start, and then reverse the list.
The nice thing about this is that you can make constant time queries about the cost to reach any tile on the map. For example, you can loop over each of the power pellets and calculate which one is closest, and how to get there.
You can even use this for the ghosts to know the fastest way to get back to pacman when they're in "attack" mode!
You might also consider flood fills from each of the ghosts, storing in each tile how far away the nearest ghost is. You could limit the maximum distance you explore, not adding nodes to the open list if they are greater than some maximum cost (8 squares?). Then, if you DID do A* later, you could bias the costs for each tile based on how close the ghosts are. But that's getting a little beyond what you were asking in the question.
It should be fast enough that you can do it inline every frame, or multithread it if you wish. I would recommend just doing it in your main game simulation thread (note, not the UI thread) for simplicity's sake, since it really should be pretty fast when all is said and done.
One performance tip: Rather than going through and clearing the "has_been_visited" flag every frame, you can simply have a search counter that you increment each frame. Something like so:
openlist = [ start_node ]
do
node = openlist.remove_first()
for each edge in node.edges
child = node.follow_edge(edge)
if child.last_search_visit != FRAME_NUMBER
child.last_search_visit = FRAME_NUMBER
child.cost = node.cost + 1
child.previous = node
openlist.add(child)
while openlist is not empty
And then you just increment FRAME_NUMBER every frame.
Good luck!
Slightly unrelated, but have you seen the ASIPathFinder framework? Might help if you have more advanced pathfinding needs.
I would recommend just pre-computing the distance between all pairs of points in the map. This takes n^2/2 space where there are n traversable points in the map. According to this link there are 240 pellets on the board which means there are about 57k combinations of points that you could query distances between. This is pretty small, and can be compressed (see here) to take less space.
Then, at run time you don't have to do any real computation except look at your possible moves and the distance to reach that location.