Angelic Ice

  • Content count

  • Joined

  • Last visited

Community Reputation

927 Good

About Angelic Ice

  • Rank
  1. Thanks a lot for the delighting input! One important operations with the grid-system would be clicking on one grid-slot and being able to find neighbours in a reliable and quick manner of course. That means, every grid-field, as a grass-tile or stone one, is capable of knowing their neighbours. I think, in a real 2d-field, I would have to keep grid-coordinates as well and then simply convert them to possible grid-neighbour-tiles?
  2. Hello everyone! In my last thread, I was all about serialising a grid-map and its running animation-processes. Now, the thread made think: Is the grid-format really the right way to go? The overall game is based on clicking-on-grids (every grid-slot contains a field, e.g. stone-field, to walk on etc.). Clicking a grid-slot may alter neighbours of the grid, too. That is why I decided to have an list/vector/.. to represent my grid. The issue is, that characters continuously move on the grid. If one clicks on a grid with a character on it, the interaction will be different. Additionally, if a character starts to move from grid 1 to 2, the consequences shall only apply once the character is actually in near of cause (stepping on a nail on grid 2). What consequences? Imagine, the character starts walking, as every grid is larger than the character, it will take a while until the character crosses the border to grid 2. Multiple cases can occur: The earth-field in grid-slot 2 might fall down into the void. The consequence would be: The character falls down once they cross the border to grid-slot 2. Another consequence could be an obstacle that hurts the character upon collision. It would look weird, if the obstacle is very small and the character gets damaged just after crossing the border. E.g. a nail. The damage to the character should be applied, once the character actually steps on it. Nonetheless, every obstacle might disappear just a few centimetres before colliding. Vanished fields might reappear, nails dis/appear. Now, what options do I have? I would like to be able to build the level in a grid-logic. Selecting a field-type (e.g. stone) and inserting them into a grid-slot, then placing an object (character, enemy, ...) onto them. At the moment I handle this by having a z-axis, representing the height, e.g. ground being 1, things on a grid being 2. Simply: I want to keep the grid-feeling (especially for editing/creating levels in a grid), but interactions (collision etc.) shall be bound to hit-boxes, to provide a kind of real-time-feeling. I saw grid-games, that simply decide the logic/consequences just before transitioning to the next grid-slot, but that is too early for my needs. Doing a full 3d world feels overkill, as the presented logic is still provided in grids. Hopefully my explanation of my issue was understandable enough, I'm not really sure myself, haha. Anyway, thanks for your time : )
  3. Ah, so you suggest to serialise A as well, if X is continuously transformed towards the final state of Y. So, X could resemble a tuple of coordinates and A the player-input (e.g. a click on the grid), which translates into a move-order. I should attach this instruction-set to the owner of X and upon saving, serialise both? So coordinates slowly transform... Start is x = 10 then x = 11, x = 12, ... goal could be 20. And the instruction-set would be continued, being some script. Probably should read into how other games tackle this, as I want to keep high customisability. Serialising a spin-animation, followed by a teleport/blink to a grid-field during action, might be difficult. Thanks for all the inputs : )
  4. Hm, yes. I would totally fine by not saving the actual movement. As you said, either A1 or A8. There are still some problems for me though. When the movement happens, the coordinates are being transformed already, saving during an action would resolve in saving those coordinates. That might lead to errors: Maybe the character moves over field 3 and 4. But field 4 is a hole hence the character falls into the hole. If the game would be saved during the walking and then opened again, the character might stand on top of field 4, bypassing its fall-script. In either case, it sounds as if games contain two kinds of values. One set, that can be serialised and another one that is live and can be transformed?
  5. Maybe this is a part of my problem. I cannot really think of a smart way to serialise actions (player-inputs and resulting game reactions), as my game is mainly done round-based. An input, as a mouse-click to a grid-slot, will run a walk-script, triggering an animation-script and so on, the player has to wait until this has been finished. If the game suddenly needs to be saved, serialising this momentum becomes quite a problem for me. I barely ever saw a game saving currently processed actions (as jumping, attacking, ..), as to what I experienced, saving is a limited to only certain spots in a level (e.g. save-points) and usually serialises map-data and flags only. I totally understand the reasoning behind this, players usually opt-in -out of a game's session and probably do not want to save mid-action. An example for a mid-action: When the player moves from grid-slot 1 to 3, and the user suddenly shuts the phone hence the game tries to save automatically mid-motion/action. How would a move-to-new-slot-task be serialised? One idea would be having a action-task-scheduler (not meant in a multithread-context), that owns currently executing instructions, as player_moves_to_new_grid_slot, owning values as: running_script and the script's required arguments as goal_slot. entity_attacks, owning values as: running_script and again the script's required arugments target. If I would not serialise these task, the transformed player-coordinates would just be loaded in-between grid 1 and 3 but not complete the action. I mean, I could also have live-coordinates and old-coordinates and simply ignore live-values, therefore dismiss incomplete tasks.
  6. Oh, interesting! Well, the issue is, if the player-object wants to move from field 2 to field 3, there will be an animation that transforms the position of the player-object. If a serialisation occurs during this progress, the player will be saved in-between. Even worse: Imagine the playing stopping the game just briefly after saving has been successful, what would happen if the player wants to load this later? I could of course say, once an object's centre passes the border to a new grid-slot, it will automatically moved to that slot within the vector/list/.. . Therefore, when adding objects from file to field, I would have to calculate, where each centre-point fits in. This avoids having empty slots in the file, which is ideal, as the average simple calculation is, as you already said, faster than any read/writes. Especially, since empty-objects have to be written to the file and read from it. While calculating allows me to simply map coordinates to slots only during loading, while saving only has to write the actual coordinates. I really like this approach, thanks a lot for helping me out : )
  7. I decided to go with a vector/list, because I do not need any physics-calculation but "give left/right/... neighbour of grid-slot"-logic. Oh, I worry about size and speed because this application should run on phones, too. Just trying to provide rather light-weight level-files and keep loading/saving times low, as multiple levels could be downloaded. Overall, I just got curious if there is already a similar way of handling this case : ) Thanks for your input!
  8. Yes, not storing empty grids is actually a problem for me. Let's say we have one row of this grid, slot 1 2 3 and 4. Now, 1, 2 and 4 are filled, therefore not empty. Only 1, 2 and 4 are being serialised, because why store empty spots? Sadly, when we deserialise the file, these contents lack their original grid-position as e.g. x = 32 and y = 0 mean nothing in a grid-world. The first object would go in grid-slot 1, 2nd in 2, but the original 4th positioned object would go in grid-slot 3, because there is nothing left. First read first placed, kind of sorting behaviour. Because the level-loader cannot know, whether a grid will be used, the serialised-file contains no information about what grid-slots to avoid. I define empty as, no object has been inserted at a given grid-slot. A user could create a 20x20 grid, but use only a few slots within this 20x20 grid. Hence not used grid-slots are empty. At the moment, the game cannot know if a grid will be empty. It would be just a NULL'd element within a list/vector. That is the actual problem for me. Should I just serialise empty grid-slots? Sounds like an immense waste of space, but that would allow me to serialise in order (grid-slot 1 to last) and deserialise in the same pattern. obj_1 = { .. some values ..} obj_2 = { .. some values ..} obj_3 = { empty } obj_4 = { .. some values ..} To re-interpret coordinates to grid-slots just sounded odd to me, but that technique would help me to avoid serialising empty grid-slots. And math is probably faster than meddling with disk-speed, haha.
  9. Oh, but how would you identify where to place an entity within the grid-datastructure? Would you simply calculate that? E.g. coordinates are x = 64 and y = 64, one grid is 32x32. Simply doing x/32 and y/32 would give me the grid-slots. But that sounds so awkward to do, haha. Sadly, I cannot rely on the order within the serialised file, as there might be empty grids and these are of course not part of the savegame.
  10. The game logic evaluates the grid/slot-position : ) But instead of accessing the actual entities, it uses the datastructure-vector/list/... storing them. Coordinates-values pursue two use-cases at the moment: 1) To help the loader to insert them into the grid-datastructure. 2) To be displayed on the screen, because at some point, the painter-class will iterate over them and render them, wherever they are at the moment. One entity would be the player, in order to allow smooth transition between two tiles, I require the actual coordinates that can be transformed/synced with their animation.
  11. Hello forum! I have a grid, let's say 20x20. Every object (but GUI and alike) are part of this grid. Since every grid-slot has a fixed size, I can easily determine whether a mouse-click interacts with a grid-slot. But there is one problem with this: Do I serialise the grid-slot or the actual-position? Actual position: + Easy to deserialise, since no further conversion is required, coordinates are pretty much done. - It is unclear on where to insert this onto the grid, would require calculation. Position in the grid: + Easy to place on the grid. - Requires calculation to find the true coordinates. Serialise grid as well and keep coordinates as values per entity: + Contains everything needed. - Data redundancy, because both values could be converted anyway during runtime. - Slower serialising and slower deserialising.   I assume serialising the grid-position for grid-elements is better? Not really sure how to progress or what class should be responsible for interpreting/converting/changing grid-positions to real coordinates.   Thanks for your time : )
  12. Hello forum! Disclaimer: I just marked this as C# but this issue might very well apply to every other language. I wanted to implement a SQL-component with following goal: The component shall be able to switch between database-implementations: SQL, PostgreSQL, ... and hide SQL's specific syntax. Therefore I thought going with an interface or aggregation would probably work. But there is one problem, that is constructing a proper query without the caller needing to know the specific database-software implemented by the callee. E.g. a caller should be able to run something as this: Select(string name); From(string tableName) instead of actually  building the query itself :"SELECT 'name' FROM 'table'". There are multiple ways that came up to my mind, the SQL-component would carry a string that is being build up via calls. As shown in my example, Select(string name) would set the beginning of the build, From(string tableName) the next part of it. Finally, the Query() method would return true or false depending on whether the build query-message was successful. The downside to this approach are surely possible limitations and a very sensible integrity (wrong order of calling destroys the built query). I thought about the SQL-component owning string-fragments that represent nothing but sole parts of the actual query. One string representing the SELECT column, the next string representing the scheme and table. A bit as in the Model View Controller pattern, where the string is the model being altered via the caller. On the one hand, this would be more stable, order stops mattering, as these strings will be automatically merged together in the right order upon calling Query(). The only issue is, what if someone calls Select("test") but also Update("test")? One string should probably be rather saving the initial operation. Select() would change it to "SELECT 'test'" and Update() overwrite this to "UPDATE 'test'. Nonetheless, I assume this problem has been solved many ways and I would be really curious on the common practice. If there is a name to the pattern, hearing that instead would be enough as well : )
  13. Hello community! Disclaimer: This is not primarily about game-developer-jobs. Lately, I wanted to update my CV and came across a small problem: I created quite some products, but they are not available to the public. Nearly all of them are commercial products. To most, I own the right to share code excerpts. Now, the question is, how can I still present these to potential employers? I would be fine by sharing excerpts of my code, but definitely not the entire code-base/project. In the end, I'm creating software for what makes me happy, while I totally understand that employers want to see/judge the quality of my code. How devastating is this? What kind of code would you, as an employer like to see? I assume, this is heavily job related? Where is the difference between expectations of code by juniors and seniors? I doubt seeing another implementation of a generic algorithm or data-structure would not be really interesting to see code-examples of. I considered to break a few things from my commercial products into libraries and publish the code for everyone too. Is that of any worth or would one rather see completed projects as a whole? Finally, what would you recommend me? Should I just keep going and work on closed source projects (my current ones are too) or actually force myself to publish something that I can show to an employer as well? I'm just a bit anxious about "not having that kind of code up, that employers are looking for". Thanks for your time, would be really glad if you could advise me : )
  14. Thank you, Kylotan, I understand what you meant now! You helped a lot, I got a way firmer grasp on this Windows-mess now : )
  15. Reply to frob: Oh, misunderstanding and my mistake, I wrote C:\Users\User\Saved Games because I know no other shortcut for it but FOLDERID_SavedGames. And that is probably more programming related, while %APPDATA% works via search etc. too. I totally am convinced that absolute paths are not advisable for this, simply for every reason you mentioned. FOLDERID_SavedGames isn't secure? As far as I know, if the path does not exist (somebody deleted it), Windows creates it either way. If the user changed the configuration (to whatever drive), it should point to that as well, right? Hm, yes, I witnessed this too, more and more application using Application data. Some still clutter my documents folder, though, haha. So I should give up on FOLDERID_SavedGames? I really wonder why nobody uses it, as it seems to be natively made for that, haha. Reply to Kylotan: I still do not understand the issue. If they use the same user-account, well, then they will have no benefit from either way, since it will use the same user-path in %APPDATA%. If they use two different user-accounts, the game is probably installed on either user's paths, or am I overseeing something? So, if it is installed on user A's account, user B won't even see the game? Unless user B can, I would see no advantage. If user B can see user A's game, that is the point where could I see reason to actually not save within the executable. Nobody said "high amounts", but "reduce" sounded like reducing it to a lower amount of writes not completely forbidding writes, haha.