Tag Info

Hot answers tagged

18

It depends on the nature of the content: Is it an asset that is loaded by the game, like a model or a texture? You want a version control system. Is it some form of data not loaded directly by the game, but used to build data directly loaded by the game, such as a localisation spreadsheet? You want a version control system. Is it a document outlining the ...


15

It's not too hard. You can store your data at arbitrary points in time (the more, the better), and you can interpolate the values of the data based on the timestamp you're looking for and the data from two closest recorded timestamps, e.g.: N | Time | Position | Rotation 1 | 0.05 | 1, 1, 1 | 0 2 | 0.15 | 1, 2, 1 | 0 3 | 0.25 | 1, 3, 2 | 30 Now imagine ...


14

The answer is always to use an array or std::vector. Types like a linked list or a std::map are usually absolutely horrendous in games, and that definitely includes cases like collections of game objects. You should store the objects themselves (not pointers to them) in the array/vector. You want contiguous memory. You really really want it. Iterating ...


11

There is no such directory; %APPDATA% is Windows-specific. You'll have to abstract it yourself: create your own GetSaveGameDirectory function that returns an appropriate path on whatever operating system you're running on. You can typically make this determination at compile time with preprocessor checks against the appropriate macros in C (and it's ilk). ...


8

Doesn't that mean that search time for records matching a certain time will increase the longer the race is? Nope :) Say you store it as an array (note the snapshots are in chronological order, but not evenly spaced): snapshots = [ {time: 0.0, position: {x,y,z}}, {time: 0.41, position: {x,y,z}}, {time: 0.57, position: {x,y,z}}, ...


7

window.localStroage is a more modern alternative to cookies. It allows you to store (semi-)persistent data in the users web browser which will survive a browser restart. The client-sided javascript can access it without having to consult a server, which makes it quite fast to access from the client. But contrary to cookies, localstorage is not directly ...


6

If you want a variable visible across multiple files, use extern: // Globals.h extern int Data[10][10]; //Globals.cpp int Data[10][10]; However, it makes a lot more sense to load them from file. Even if you don't want to use standard library containers, loading and saving is trivial, and will help you to modify and add additional levels in the future. ...


5

You have lots of choices with android. As the Luis has sated, SQLite or text files (XML, JSON). But you could also store the data in a key-value list, such as a dictionary list or storage list. Depending on how complex the data is, and what works easiest for yourself will determine what is the best option


5

What kind of questions are you going to be asking in this application? something like?: 1 + 1 = ? 6 / 2 = ? any type of storage is possible, you can use a comma delimited file such that every line would have the question and the answer like so: "1 + 1","2" "6 / 2","3" If you are going to use SQL then you can make a table with the Questions & ...


5

The parallelogram coordinates you're using are easier to work with, but they do have the drawback of being weird for rectangular maps. One approach is to store it with the offset coordinates but actually use parallelogram coordinates in your game logic. Observation: in each row of the map, the grid data is contiguous. All the wasted space is on the left ...


5

Read up on standard database design. Specifically normalized forms. An approach would be to have 3 tables: character having a character_id and other data items having an item_id and other data (names, weight etc...) inventory having character_id, item_id, quantity. A player's inventory could be expressed as "SELECT items.name FROM items, inventory ...


5

Many (especially older) cartridge-based consoles have homebrew development subcultures that have built CompactFlash-based cartridges that you can purchase, load up with your home-brew ROM, and insert into a (usually modded) system. For the NES, the most popular option seems to be the PowerPak from RetroZone. It does not appear to require a modded NES, since ...


5

I would probably start with the following schema: Slot (ID, CharacterID, SlotID, ItemID) where Slot is the name of the table ID is the table's primary key CharacterID is a foreign key that points to the character SlotID is the slot's ID going from 1 to 64 (or 0 to 63, or whatever) ItemID is a foreign key that points to the item (ID of a specific ...


4

I'm using this code on my game right now: System.getProperty("user.home"); Simple and efficient. It's a user dependent directory, which is perfectly fine for storing save files. I'm using it to download and store assets, though.


4

fixed size array (linear memory) with internal free list (O(1) alloc/free, stable indicies) with weak reference keys (reuse of slot invalidates key) zero overhead dereferences (when known-valid) struct DataArray<T> { void Init(int count); // allocs items (max 64k), then Clear() void Dispose(); // frees items void Clear(); // resets ...


4

Don't make a text file, make an image file. Now whatever pixel editor you prefer is a working tool for editing the map, and you can compress it as a png in 4, 8 or 24 bit resolution depending on how many distinct tile types you need. Edit, this will fit poorly in the comment section: Yes, editing a 8000 x 8000 image is a pain, and I have no doubt that some ...


4

Personally, I would prefer simplicity over saving memory. Don't optimize until needed! If you're still bent on saving a few bytes, here's how you can do it: Slice the parallelogram in half to form two right triangles Rearrange the two triangles to form a rectangle. (Note I added the green buffer strip so the math works out nicely.) Python code to map ...


4

There's no single "best" way to do this, it depends on the needs of your game. Here are some options: Hard Coded Both the easiest and probably least flexible approach. No reason you can't just make a static class with static fields for each of the levels. Actually, this isn't a bad way to prototype, so you can move it into some other approach later. If ...


4

The overall problem by using any text-based solution is that they are highly unreliable and naive implementations are often prone to data integrity issues. This is where david's suggestion to use a database becomes important. Databases offer you the ability to write entries to a table without worries about concurrent operations from other connections. ...


3

I would just keep the content carefully sorted into folders for what you call "tags" and subfolders by game. Maybe something like this: /assets /2d /spritesheets_tilesets (i.e. combination images) maybe even a sub folder here for humans, animals, etc. /textures (tileable images) you could have subfolders here for sizes, if they're all square ...


3

You need to ensure your game will run properly on the NES hardware. With many 8 and 16 bit consoles, there are limited times you can access the hardware registers. Accessing registers outside the allowed time often results in the program not displaying any output. One emulator to consider is no$nes, another is fceux. The no$nes will warn you if you violate ...


3

First, your concerns are definitely valid and this is not "premature optimization." The problem is, std::deque::insert invalidates all iterators and references, so deque is not actually useful for this. What I did to solve this problem is create a wrapper data structure around std::vector (I called it a perma_vector) that stores a vector of ...


2

The way I've traditionally handled it is as two arrays of lines: one n-by-(n+1) array of vertical lines (one for each row and one for each column-plus-one - there's the one to the left of each column and then the last set of vertical lines on the right), and likewise, one (n+1)-by-n array of horizontal lines, one for each row-plus-one and one for each ...


2

It's not actually a problem. What you need to do is make sure that lines are shared references, not simply variables. So if you have two boxes, A and B, sharing a line: . . . A | B . . . Then a.RightLine and b.LeftLine both point to the same reference. Or, if it's a boolean, when the user clicks on the line, make sure you update both A and B to ...


2

It depends on your game. The containers are different in how fast the access to a specific element is, how quickly a element is removed and how quickly a element is added. std::vector - Fast access and removing and adding to the end is fast. Removing from the beginning and the middle is slow. std::list - Iterating over the list is not much slower than a ...


2

There is no right answer to this. It all depends on the implementation of your algorithms. Just go with one you think is best. Don't try to optimize at this early stage. If you are often deleting objects and recreate them, I suggest you look at how object-pools are implemented. Edit: Why complicate things with slots and what not. Why not just use a stack ...


2

I would recommend using your own binary format if you want efficient storage. Creating and packaging deltas for levels should be done on the server side. The clients should be able to only read the deltas and apply them. If you are comfortable with SQL and sqlite storage is good and efficient enough for you, there is no reason why not use it. You can ...


2

Seems that your game doesn't need to store much data. I recommend that your save data can be easily converted to an NSDictionary (you can easily convert it to XML/plist). This way you won't have to worry about exporting the data elsewhere (in your case in a server). In my projects, I have a protocol where you can do these: - Get the NSDictionary ...


2

Note that "what technology to use" questions are considered non-constructive on this website, but I will still try to help you. A less over-engineered alternative to XML is JSON (Javascript Object Notations). Parser and serializer libraries are available for most common programming languages. When you have a lot of assets and you plan to manage them ...


2

If it's going to be an online game with constant communication between the server and the client, then relational database on the server side is the way to go. In SQL, for example, you can have the following tables: TRADEGOODS (id, name) //examples: (3, "Steel"), (4, "Wood") PROPERTY (id, name) //examples: (2, "Sell price"), (3, "Buy price") ...



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