• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Angelic Ice

  • Content count

  • Joined

  • Last visited

Community Reputation

927 Good

About Angelic Ice

  • Rank
  1. Hello! I wanted to create a few interface-classes in a rather new project. Other programming languages, as C#/Java commonly agree on writing file names in a way similar to: IMyClass Personally, I use underscore within C++, just because I tend to go for long variable-names and it improves readability. Hence writing file-names with underscore seems just the native decision. Now, the I-prefix is pascal-case, which astonishes me in general, because iMyClass is more readable, but anyway: I would rather not want to use it and of course, nobody could force me to do so anyway. Nonetheless, I would like to know how you tackle interfaces in C++ in terms of naming? Currently, I'm considering: i_my_class.cpp (which looks a bit weird, never seen this before) imy_class.cpp (less readable) interface_my_class.cpp or my_class_interface.cpp I even thought about omitting the interface/prefix altogether in C++. Curious on how you deal with this! Thanks for your time!
  2. C#

    Thanks for confirming it. Because I like C# as a language but want to release on a non-windows-operating-system. Core is gaining more and more steam. Beside that, if somebody knows a common practice for "editable settings during run-time" on core, I would be all ears : )
  3. Hello everyone! Just a quick question: I would like to save some application data, similar to here: https://technet.microsoft.com/en-us/library/bb397755(v=vs.100).aspx/css But this seems to be either WinForm or .NET exclusive? At least I cannot use these methods, as properties does not exist. Furthermore, I feel like the way of serialising data in that manner is a bad sub-optimal for my liking, as I like to group multiple data-entries in a context (e.g. screen-width and screen-height in a folder/file/table/.. called window). Some pseudo-code to give an idea: Properties.Settings.Window.Width = 500; Properties.Settings.ErrorMessages.Loading.MissingFile = "File could not be found."; Is there a common practice to do this? JSON? Values should be editable during runtime! Even though an SQL-database is implemented, I do not want to scatter around key-value-tables. Thanks for your time!
  4. True, I should probably just check upon every pixel-motion, on which grids the current entity is and then check against others that are currently on that grid, too. Thanks a lot!
  5. Thanks : ) I decided to go with a complete 2d-physics-system with a "grid-interface" to access grid-slots. Thanks a lot! I decided to go with a real 2d game-field and leverage a grid-interface to guarantee accessing and placing the right grid-slots. There is only one question, I thought about assigning every moving (and static) entity's bounding box to all grid-slots on which they stand in order to simplify collision detection. I'm running a quad-tree for my GUI, not sure if that is a suitable solution for a grid-imitating field though, as I do not seek to have a maximum bucket capacity - one grid is one quad with no further quads. My grid-slots are isometric, if that matters. Are there already know data structures to handle such? I mean if there is no other solution, I would just implement my own isometric quad-tree that does not add further quad-trees : )
  6. 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? Edit: Forgot to add, that one grid should be able to identify currently "attached" objects, as in, what object stands on me? But I think that is easy to add anyway.
  7. 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 : )
  8. 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 : )
  9. 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?
  10. 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.
  11. 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 : )
  12. 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!
  13. 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.
  14. 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.
  15. 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.