Which is best for Android?
I have 30 3D models but there is only ever one drawn on the screen at any time.
Do I:
create the model and destroy the previous model every time the displayed one changes.
or
create all 30, store them and just reference them when I want to draw them.
Note that when one model is removed another model appears and the transition must be smooth.
In what context would one be better than the other?
Have you tried loading all of them at once? Start with that, and if it doesn't work, then look at memory management. You should be able to keep at least three or four models in memory on an older device. If you do have issues with ram, try to predict which models are going to be used next, and pre-load them in.
Keeping them all loaded is normally preferable, because it means your app will appear fluid and responsive.
I would like to implement undo/redo in a small paint application. It seems the Command Pattern fits the use nicely, but I am unsure how to best implement it.
As I understand the pattern, it is necessary to include in each command:
The details of the paint operation for purposes of redo (e.g. Line -> start & end points, free form line -> GeneralPath)
The state of the component prior to the change for undo. In this case, that will be a small snapshot image of the area affected by the command.
My understanding based on that is that each command needs to be 'atomic' or self contained, with all the information needed for undo/redo that operation.
Unfortunately that would require storing more information than I'd first anticipated. For a line we must also account for things like the Color, Stroke and RenderingHints used to draw it initially. This turns my 'simple little commands' into something ..more bulky in memory, and with more boiler-plate code to churn out (each will be a serializable bean1).
For reasons of memory conservation (mostly) I was wanting to 'cheat' on the specification of the commands. Perhaps take a backup of the entire drawing area every 100th update, but otherwise store no part of the changed image, and simply rebuild the last (up to) 100 commands for each new paint operation. But that seems problematic to ensure that the state of the Graphics object is right before painting each part - this part might require a line, but the RenderingHints were changed 4 commands ago, the Color was changed 98 commands ago, while the Stroke has remained the same for the last 227 commands.
Pursuing a more memory efficient command seems to throw the pattern right out the window in terms of being 'atomic'. That in turn leads to difficulties in determining the earliest command that might affect the rendering.
Should I:
Look for a new pattern?
Attempt to implement my peculiar needs by tweaking the pattern?
Toss all this in the waste bin as premature optimization and code it in the simplest (and most memory consuming) way that sticks to the command pattern as defined?
Update
"each will be a serializable bean" On 2nd thoughts, no. I did dome checks to find that a Graphics2D (which neatly encapsulates many parameters used when drawing) is not serializable. Further, a BasicStroke is serializable, but the thickness of the stroke is not stored. I could create serializable versions of many of the attributes but it seems to make for a lot more code, so I'm going to abandon that spec. as well. I will only attempt to store a reference to a BufferedImage at run-time.
I would stick with command pattern and first try a naive solution (=the most memory-hungry). For some graphical operations it may be even necessary to keep a copy of the entire image in the command object (eg. think of filters). This is a common problem also in professional image editing applications, they often have a memory or step limit of last commands that are remembered. And if the memory consumption is really large you may think of swapping the oldest entries in command-history to file system. I think user will not mind waiting a second until the change is undone.
Maybe, it would be better not to store copy of entire image in command, but store only copy of area, which is changing by command. Of course, this is not a panacea
I have a game where I draw and move bitmaps over a SurfaceView. The user can interact (drag and drop) these bitmaps. When the player hits the home button then goes back into the game, I want to be able to pause the game, then restore it to where it was before he left it. What is the best way to store my custom objects?
Should I implement onSaveInstanceState(Bundle) and have all of the classes whose objects I want to save implement the Parcelable interface? This would be quite a bit of work, and I'm still not sure how I would save things like bitmaps. I suppose I wouldn't and I would just reload those from disk.
I am also confused about what kind of storage a bundle offers: disk storage that never goes away unless you clear it yourself, or memory storage that goes away if the OS decides to remove your program from memory while it's in the background. According to the comments in this question, it is disk storage. The documentation implies that it is memory storage, saying Note that it is important to save persistent data in onPause(), however I don't find it very clear. This page also implies that it is not persistent: it only lasts as long as the application remains in memory. So which one is it?
The last link above suggests using onRetainNonConfigurationInstance() to keep objects in memory while the application is in the background. This would imply that if the program is taken out of memory by the OS while in the background, everything would be lost. This seems to be what most (all I tested on) games do: if you hit home while playing then go back in, the level resumes. If you hit home, open a lot of stuff (sufficient to make Android remove the game from memory), then go back in, nothing is resumed, the game starts from the main menu. Does that mean this is what they use, and if so, is that a good practice?
Note that the question about a Bundle's persistency is just a secondary curiosity. I don't really care if the state of this game is not permanently saved and can be lost after the game being in the background for a while (as described in 2 above). I'm interested in the best practice for this case.
The basic idea is, IMO, identify the smallest collection of values that will enable you to recreate the state of your game. Save those in shared preferences.
I have written a few 2D games in the past using libraries such as LWJGL (with a Slick2D wrapper) and the XNA framework, but one thing i have never been able to grasp (or have the need to) is how the user input is kept constant, eq not dependent on FPS.
I'm looking for a more generic answer rather than framework specific. I understand it has something to do with time measured between frame updates ?
Thank you
I can't speak for some of those other frameworks, but I know that XNA basically lets you poll the current input state (are the buttons up or down?) whenever you like. You usually do it each frame.
What this means is, if your player happens to be a ninja and can hit keys faster than 60FPS, it is possible that they may hit a key (or mouse button) between pollings and you miss it. In practice it is almost never an issue.
If it does bother you, the solution to this problem is to hook the Windows message pump and receive keyboard up/down events.
For general gameplay it is really not worth the effort. Usually the only time where you really must capture every keystroke is when the user is typing text. So rather than capture key up/down events, you capture character events (WM_CHAR). This means you won't miss a keypress. But the more important problem that this solves is that it offloads key-to-character translation to Windows - allowing it to handle key-repeat, keyboard layout, shifted characters, etc, for you - allowing your game to behave like any other Windows application.
(Of course, if you can get away with just using the polling-based framework input stuff - go with that - it's much easier to implement and less platform-specific.)
The above only matters when you are detecting distinct key presses (eg: tap to fire this gun), as opposed to holding keys down (eg: accelerate this vehicle).
The alternate interpretation of your question is you are suggesting that a key may come up half way through a frame - how do you account for that, in a game with a discrete time-step?
Generally you don't worry about it. Just as 60 frames per second is fast enough to discretely calculate your game state and appear smooth and continuous to a human, it's fast enough to accept input.
But what happens if you're not running at 60FPS? If you're running at 30FPS (as you might on a mobile platform), then it can make your inputs - particularly analogue inputs - feel much smoother if you poll them at 60FPS. The easiest way to do this is to simply do two Updates for each Draw - if your Update is not too taxing on the CPU.
I'm creating a grid based game in Java and I want to implement game recording and playback. I'm not sure how to do this, although I've considered 2 ideas:
Several times every second, I'd record the entire game state. To play it back, I write a renderer to read the states and try to create a visual representation. With this, however, I'd likely have a large save file, and any playback attempts would likely have noticeable lag.
I could also write every key press and mouse click into the save file. This would give me a smaller file, and could play back with less lag. However, the slightest error at the start of the game (For example, shooting 1 millisecond later) would result in a vastly different game state several minutes into the game.
What, then, is the best way to implement game playback?
Edit- I'm not sure exactly how deterministic my game is, so I'm not sure the entire game can be pieced together exactly by recording only keystrokes and mouse clicks.
A good playback mechanism is not something that can be simply added to a game without major difiiculties. The best would be do design the game infrastructure with it in mind. The command pattern can be used to achieve such a game infrastructure.
For example:
public interface Command{
void execute();
}
public class MoveRightCommand implements Command {
private Grid theGrid;
private Player thePlayer;
public MoveRightCommand(Player player, Grid grid){
this.theGrid = grid;
this.thePlayer = player;
}
public void execute(){
player.modifyPosition(0, 1, 0, 0);
}
}
And then the command can be pushed in an execution queue both when the user presses a keyboard button, moves the mouse or without a trigger with the playback mechanism. The command object can have a time-stamp value (relative to the beginning of the playback) for precise playback...
Shawn Hargreaves had a recent post on his blog about how they implemented replay in MotoGP. Goes over several different approaches and their pros and cons.
http://blogs.msdn.com/shawnhar/archive/2009/03/20/motogp-replays.aspx
Assuming that your game is deterministic, it might be sufficient if you recorded the inputs of the users (option 2). However, you would need to make sure that you are recognizing the correct and consistent times for these events, such as when it was recognized by the server. I'm not sure how you handle events in the grid.
My worry is that if you don't have a mechanism that can uniformly reference timed events, there might be a problem with the way your code handles distributed users.
Consider a game like Halo 3 on the XBOX 360 for example - each client records his view of the game, including server-based corrections.
Why not record several times a second and then compress your output, or perhaps do this:
recordInitialState();
...
runs 30 times a second:
recordChangeInState(previousState, currentState);
...
If you only record the change in state with a timestamp(and each change is small, and if there is no change, then record nothing), you should end up with reasonable file sizes.
There is no need to save everything in the scene for every frame. Save changes incrementally and use some good interpolation techniques. I would not really use a command pattern based approach, but rather make checks at a fixed rate for every game object and see if it has changed any attribute. If there is a change that change is recorded in some good encoding and the replay won't even become that big.
How you approach this will depend greatly on the language you are using for your game, but in general terms there are many approaches, depending on if you want to use a lot of storage or want some delay. It would be helpful if you could give some thoughts as to what sacrifices you are willing to make.
But, it would seem the best approach may be to just save the input from the user, as was mentioned, and either store the positions of all the actors/sprites in the game at the same time, which is as simple as just saving direction, velocity and tile x,y, or, if everything can be deterministic then ignore the actors/sprites as you can get their information.
How non-deterministic your game is would also be useful to give a better suggestion.
If there is a great deal of dynamic motion, such as a crash derby, then you may want to save information each frame, as you should be updating the players/actors at a certain framerate.
I would simply say that the best way to record a replay of a game depends entirely on the nature of the game. Being grid based isn't the issue; the issue is how predictable behaviour is following a state change, how often there are new inputs to the system, whether there is random data being injected at any point, etc, You can store an entire chess game just by recording each move in turn, but that wouldn't work for a first person shooter where there are no clear turns. You could store a first person shooter by noting the exact time of each input, but that won't work for an RPG where the result of an input might be modified by the result of a random dice roll. Even the seemingly foolproof idea of taking a snapshot as often as possible isn't good enough if important information appears instantaneously and doesn't persist in any capturable form.
Interestingly this is very similar to the problem you get with networking. How does one computer ensure that another computer is made aware of the game state, without having to send that entire game state at an impractically high frequency? The typical approach ends up being a bespoke mixture of event notifications and state updates, which is probably what you'll need here.
I did this once by borrowing an idea from video compression: keyframes and intermediate frames. Basically, every few seconds you save the complete state of the world. Then, once per game update, you save all the changes to the world state that have happened since the last game update. The details (how often do you save keyframes? What exactly counts as a 'change to the world state'?) will depend on what sort of game information you need to preserve.
In our case, the world consisted of many, many game objects, most of which were holding still at any given time, so this approach saved us a lot of time and memory in recording the positions of objects that weren't moving. In yours the tradeoffs might be different.