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


13

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


10

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

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

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

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

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


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

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


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


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

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


2

You most definitely want to use something like XML or JSON if a plist if what you're familiar with. Take a look at some of the available libraries you can use to parse either and store your data like that. A simple XML file might look like this: <Data> <NumberOfEnemies>20</NumberOfEnemies> <SpawnSpeed>60</SpawnSpeed> ...


2

you can say on pond tiles that they are part of a multi-tile object with a reference to where the actual data is stored if there is no data then you can create a type for each sub tile of the large object and just store those, so you can find the orientation and bounds by just looking at the type in game you can have it act as one object. edit: let say ...


2

Having username in userstats is redundant. You probably would want to key userstats.id_user and users.id_users. userstats.id_stats as auto incremented would be ok to reference from an npc interaction. Remove Coords from userstats. table: playerLocation id_user | playerX | playerY | levelName 1 | 211 | 105 | myMap2 Remove experience from ...


2

This is a pretty big question and I think you might be better served by asking each part separately. That said, two of your points (viewport and collision) are essentially about accessing "nearby" objects efficiently. The way to do this is to use some kind of spatial data structure (aka spatial index). The simplest one is to have a two-dimensional array ...



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