Hot answers tagged

11

It's easiest to think of your order in a single frame, think of it as a series of dependencies. User input depends on nothing, so it goes first. Objects being updated depend on the user input, so they go second. Physics depend on the new updated objects, so it goes third. Rendering depends on the latest physics state and object updates, so it goes fourth. ...


6

The simple solution would be to just discard and recalculate the power distribution in the whole grid whenever you make a change. Considering that your grid is only 18x18, it shouldn't be too computationally intensive to do so. Inverters might be problematic, though. What do you want to happen when the player connects the output of an inverter to its input? ...


5

First, Fix Your Timestep. The component update should always have a fixed time interval. This is critical for stable physics and can avoid bugs in other systems as well. You may have cases where the time interval becomes huge, too. This can happen if you set a breakpoint while debugging. You'll want to cap the update time used for the time accumulator (...


5

Thanks for all of the help guys, but after some looking around, I found a really good updater. It's called Puchisoft Dispatcher. They have a freeware version, and it is really good for non-commercial projects.


5

Locking at 60 fps is certainly viable. From what I've seen, just as you've said, it appears fighting games typically describe timings in number of frames, even as most fighting games have transitioned to 3D (where it's rare to rely on discrete frames of animation). The drawback of doing this logic in Update() in Unity is that the game will slow down if the ...


4

Seeing as this is XNA, the simplest method is probably to use ClickOnce. This has built-in support for managing updates for you. See the tutorial on MSDN, which points out where in the ClickOnce wizard you can set up automatic updates (you can also modify these settings in the project properties later on).


4

The choice to make depends on what your multiplayer architecture is for the game. There are two major architectures for multiplayer games, the first being client based, in which each client is responsible for its own decision making and updating, and the server simply distributes these updates to other players. The other is an authoritative server, and ...


4

There is a nuance here. You asked: So I am wondering, why not just do something like: while(running){ Update(); } I believe this would call every frame. This is false. If you place your Update() method inside a simple while(true) loop, it will be called as much times as the processor can handle. If your processor can run it 123456 times a ...


4

Performance problems are tricky to diagnose remotely, but the fact that your palm trees turn almost solid green when selected is a probable clue. If you started with a nice high-resolution image, Unity probably generated PolygonCollider2D data like what you see on the left: trying to capture each frond in exacting detail. But if you're making a flappy ...


4

Rather than calling GameObject.FindGameObjectsWithTag every frame, you could just call Gunner_SpeedIncrease() within OnTriggerEnter when the trigger/collision happens. void OnTriggerEnter(Collider other) { if (other.gameObject.CompareTag ("BulletProgressionObject")) { Destroy (other.gameObject); Gunner_SpeedIncrease (); } }


3

May be overkill, but RakNet includes an autopatcher system: The autopatcher is a class that manages the copying of missing or changed files between two or more systems. It handles transferring files, compressing transferred files, security, and file operations. It does not handle basic connectivity or provide a user interface.


3

For some types of objects, you can invert the logic. Instead of every N ticks, grow by X, you can store the timestamp T1 since the last growth, and then when the player next sees that object at time T2, you can grow the plant by X * (T2 - T1) / N. That way, any plants not on screen don't take any CPU to update. Note that this only works for things that don'...


3

I read from a book (the book is "Starting android game development") that the Garbage collector is your worst enemy at the moment of making a game. That's because it takes time of it's own to recycle objects. So try to reuse your bullet instances instead of trashing them. That way you will not necessarily run out of memory. Also try to keep a static count ...


3

Create two separate applications: Your actual game and a launcher. Configure your installer to create shortcuts for the launcher, not the actual game. When the launcher is executed, it first goes online and checks if there is an update for your game. When there is, it downloads it and patches the copy of the actual game. A lightweight way to do this is to ...


3

The reasoning and processing at points 5-8 is fixed for a given pair of old version and latest version. Therefore, do it once on the update server: the protocol can be simplified to a single exchange in which the patcher says the installed game is version X and the server sends a "recipe" with a list of the appropriate incremental patches and replacement ...


3

If you publish your game through Steam you don't have to provide your own update mechanism – I'd even strongly suggest not doing so. While this gives some control away from you (i.e. you have to wait for Valve to push updates), it let's you forget about all the update handling and your players also won't hit problems in case they verify Steam's cache ...


2

One simple method is to provide a 'launcher' that checks for an update using the HTTP protocol, downloads it with HTTP, installs it and then starts the game. 1) User starts the game (which is actually the launcher). The launcher downloads and parses some kind of manifest file that details the available updates. The manifest may look something like this ...


2

The idea you describe is sound. See Replica Island for an example of a game that generates "draw lists" in one thread, and renders them from a GLSurfaceView draw callback. The only tricky part is to make sure that keep the lock held for as little time as possible, so you don't stall the renderer. Since your game state updates are expensive, you'll want to ...


2

If you game is very data orientated, it could be easy to make your own loader to verify and download data from a server, then launch the game. It shouldn't take too long in a managed language. I made one a while back where the client downloaded a map of what the game folder shoulld look like, files, md5's, etc. And then looked through local files to see ...


2

I had to address this same problem, basically you're doing it the right way, updating at a set rate of updates per second, and thus a set speed per second and rendering as fast as possible independently of that speed. That way it doesn't matter how you measure things in your update as long as you keep it consistent it'll be the same speed regardless of how ...


2

First and foremost, use a profiler and check what are the processor hogs in your game. Otherwise you are spending time augmenting and optimizing something that will not necessarily improve game performance noticeably. If you already checked and are sure you wish to optimize AI to run a few times per second then in the abstract theoretical sense, you ...


2

Your flood-fill algorithm seems to works correctly, but you are overwriting the results. You have a loop in which you update every single tile. When it is a wire, you switch it off. When you reach a power-source, you flood-fill from it. What happens in your code is: the board gets iterated in a loop from up to down switching off all wires the loop ...


2

Yes, thats called dirty blitting. The Newbie Guide to pygame touches on this. The steps they recommend to implement it are: Blit a piece of the background over the sprite’s current location, erasing it. Append the sprite’s current location rectangle to a list called dirty_rects. Move the sprite. Draw the sprite at it’s new location. Append the sprite’s ...


2

If my assumption that you want your speed to lose 2% of its value every second, then this is a perfect opportunity to use the exponential rate of decay expression, which looks like this: A=Pe^(rt) A is the final amount you want (so, after 1 second, .98(vx)) and P is the initial amount. t is just time, so since you want the velocity to only be 98% of its ...


2

Basically, what a hashmap does is store the objects in a random location in your memory. Complexity is O(1) which means that it will always take the same amount of time to retrive an object from the hashmap. The amount of time depends on various factors. This might be quite fast for few objects, but as soon as you start drawing scene with hundreds of objects,...


2

I was able to eliminate all of the GpuProgram warnings and also fix all of my animations by trial and error elimination of several shaders and additionally re-importing the models from Blender. Steps as follows. I set all of the models to use the standard shader in Unity. I then deleted and reloaded the offending shaders and did not have any errors, this ...


1

The simplest thing to do is make a copy of the Node * container before iterating over it. void Layer::update() { auto children = _children; for(auto child : children) { child->update(); } } If you want to avoid this copy, you can defer the additions and removals until after the update loop finishes. std::vector<Node *> ...


1

This button will only perform a minor update on the engine. I do not see any options to further update the installed engines so it seems the latest version needs to be downloaded separately.


1

I have tried to make an update system for my game, and this is how far I got. First, connect to my server, and download an .ini file containing the name of the newest version of the game: http_get_file("http://mywebsite.com/game/Versions.ini", working_directory + "/Versions.ini"); The first part tells Gamemaker where to find the file online, and the last ...


1

I think you have inverted the alpha in the interpolation. It should be curr*alpha + prev*(1-alpha). From Fix Your Timestep!: State state = currentState * alpha + previousState * ( 1.0 - alpha ); In fact you are rendering an interpolated status that has 1 time-step of latency, so Actual time elapsed |----------|---_______| Time simulated ...



Only top voted, non community-wiki answers of a minimum length are eligible