Tag Info

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.


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

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).


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

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 ...


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

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 ...


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

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 ...


1

Keep an "on-screen tiles" collection that you update each time the camera moves and each tile has a reference to the objects in it. This was you only need to update the objects referenced by the tiles that are on screen (or just outside).


1

This sounds strange, and high-level, but I would consider modelling electricity through cellular automata. Practically, this means modelling electricity as a state (on/off) for each cell, and codifying a set of rules that tell you which states are on or off. The rules might go something like: For every cell that's a power source, set the state to "on" ...


1

It's a simple change to logic really, simply use a >= test instead. If Ticks is greater than or equal to your trigger amount, you should fire the trigger. Then you use the Ticks += delta; to increment it. Additionally, you can create a more generic object to hold information for a single event. class EventObject { float TimeSinceTrigger = 0; ...


1

I've +1'd @Sean Midleditch 's answer, but as some considerations: (I'm not really happy with how this is kind of a disorderly rant, but...) Video hardware varies wildly between hosts, unless you're on a Gaming Console (3DS, Wii U, PS4, Xbox1). Even "the same device" will have different GPU capabilities between generations (e.g. "iPad"), or may have ...


1

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 ...


1

This is most often done with your second option, the event system. When something happens, send out an event describing what happened. Anything the HUD cares about it will listen for. It will potentially need to keep copies of some data (like health), but this is often beneficial for a variety of reasons. One example of why the copy is useful is that you ...


1

I suggest decoupling the two and relying on an event-like (signals and slots) system. In short, make a generic base Observable class and an Observed class. The Observable class has a list of Observing object instances. When the health changes it notifies everyone who is interested about the new health status. That way health change code can be decoupled ...


1

you dont need to use another gameTime object, since its just a clock. you just have to build yourself different timer. there might be easier/better way to do it, but since I dont know them, here how i'd try 1st. What you want to update base on a different elapse time. just use different variable for when you want your update. lets set update speed for ...


1

You should add a jumpAcceleration. When the player press key(38) you should do this.velocityY -= jumpAcceleration * dt; where dt is timeDelta / 1000000000.0 . What you do in your code is, you add 6 to the velocityY at every update. So at high FPS (e.x. 300 ) you will subtract 6 * 300 = 1800 from your velocityY, but at a low FPS (e.x. 10 ) you will ...


1

No, wglMakeCurrent (NULL, NULL); will not cause you to lose any state. What it will do is make any OpenGL call in the thread where you did this an invalid operation (until you make a device + render context current again). So if you were to try to setup state during a period in which your calling thread has no current context, then you would have issues ...



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