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


  • Content count

  • Joined

  • Last visited

Community Reputation

4398 Excellent

About Waterlimon

  • Rank
  1. To me it seems like the only thing youll gain from this project is experience with VR development, so the future potential of having that experience available for other projects should have a big role in the reasoning for why this specific project should happen. Of course applies to any non-VR new things you have to learn or build to support it. And like you said its plain cool and thus might increase workplace happiness/motivation and so on. If this VR thing is something publicly visible, then it might improve your brand in some way I guess, and thats probably profitable (you can always use this reasoning to do cool/good things that arent directly profitable). If you are just viewing some 3D models, VR wont add much. If you are actually doing something 3D with the hand controllers, maybe VR will make it easier than using the mouse. But even if you can find that subset of functionality where VR+hand controllers are optimal, theres still additional overhead to putting the thing on. Also consider the feature/issue of hiding the real world when in VR. Does that give you increased focus on whatever youre doing inside VR (beneficial), or does it make communication or multitasking harder than necessary (bad)
  2. Its easy to think that because some gameplay you have doesnt feel fun, that its because of the high level mechanics (that you would normally think as the gameplay). But I feel that usually, 90% of the experience is determines by the 'not gameplay' things. Graphics, music, visual and sound effects, side effects of the primary action, and what purpose the gameplay serves (challenges are usually part of a bigger challenge that gives meaning to the subchallenge).   Consider that even if your gameplay doesnt even exist (the player just passively sits there), it can still be amazing. Thats how movies/music/books work, after all.   So, at the minimum, gameplay just needs to not get in the way, and that can be enough if supported by other content/effects. Maybe you do some basic actions that require zero thought and achieve progress, and repeat. Of course, if you can tie in some exciting and cognitively interesting tasks, thats great. Make the player choose or build optimal/preferred solutions. Make it rely on their understanding of the games systems. Add some time pressure / risk. Make the consequences of however they act, meaningful. Just understand that not all gameplay needs to be like that. It can even be exhausting for the player if you require constant focus on solving difficult problems.
  3. Heres more videos on game design you can watch for some insight:   [spoiler] https://www.youtube.com/watch?v=QHHg99hwQGY https://www.youtube.com/watch?v=PdCQ56UxVVE https://www.youtube.com/watch?v=qwPe3OHR04c https://www.youtube.com/watch?v=CdgQyq3hEPo https://www.youtube.com/watch?v=aXTOUnzNo64 [/spoiler] I think its most important to remember that game design is primarily about optimizing user experience (which just comes down to understanding human psychology), secondarily about doing so without excessive complexity or resources (which comes closer to designing systems / programming / content production), and thirdly about keeping the end result novel instead of a direct clone of an existing product or genre (creativity and synthesis of original solutions).   It helps to think about games youve played, and think about what theyve done to ensure good experience for the player. It could be really minor things like some shading or animation on a visual element, or it could be something deeper like letting the user relax occasionally through pacing, or some very interesting emergent gameplay that arises out of the games systems after youve played and improved your understanding of it for hours. Sometimes the interesting part is not that they did something to improve the experience, but how they did it (and games often solve similar problems in different ways, so you could do comparisons - like comparing aspects of inventory systems).
  4. The 'purpose' of play is believed to be practice for things later in life when the cost of failure or missed opportunity is bigger.   Maybe you can think about each activity/situation in your game, what core skills would be necessary, and come up with a way to practice those skills through a game where the skills are primary game mechanics (then you just need some goal and suitable environment)? Combine multiple such skills into a single game (could relate to completely different activities in the game).   It might not be realistic, but it could be a nice pattern for players to find (and maybe even educational). The games they play could even act as predictors of what is to come, if you want to add hints like that (like make them pretend everything is on fire before a really hot and dry period). Then make them play a game they call 'cannibal attack' just to disturb the player.
  5. If theres a few units, you can overlap those symbols to get more space (maybe even two interleaved rows so new tanks go like /\/\/\ which might take less space). If the rows get too long, cluster them to simplify counting. Like replace every sequence of 5 tanks, with a single symbol that stands for "5 tanks" and is more compact and readable. Mostly overlapping the similar symbols allows making them bigger so it can look like a simplified tank etc.   If theres many units, the player probably doesnt need to see exact numbers, only the total strength and the ratio of unit types. You can represent the ratio of unit types in a constant amount of space (using some bars or symbols sized according to representation or a pie chart...). Then put a single number for the total number of units. This might not work if some units are vastly more numberous than others (like 10000 infantry vs 1 boat), so might want to group the numerous units into bigger ones until the numbers are of similar magnitude. Of course you can add the detailed data in some menu.   If the numbers are big, and the player needs to do a lot of calculation/comparison, I would say its necessary to have the exact numbers there. And add some visual approximation so a force of 1 unit and 100 units are differentiated by more than just two additional digits (different icon/size for example).   You could also represent different unit types and counts using different approaches (like switching to numbers once there start to be too many, if your game changes in nature toward end-game like that). If some unit is never going to be more than 1 or 2, you can change the map icon itself (the blue thing), like add some circles around it. If some unit is always going to be numerous (like if theres always lots of supporting infrantry), just always use a number and find some special spot on the map icon to display it (so there would be a "base strength" like you have the number at the bottom, and "supporting units" individually counted like you have the tiny symbols). Making units special like this might differentiate the units more, so they dont feel all the same with just a different shape and stats (gives impression of higher complexity, and also makes it easier for you as the designer to add that complexity when theres no pressure to keep all units following the same rules).
  6. Realistically, biomes are just a simplified model that allows us to compartmentalize all the infinite possible 'environments' into a few discrete categories.   Those environments arise as a result of multiple factors that vary over space (weather, 'composition' of the area like vegetation and terrain material, terrain geometry and other large scale things that might affect things like latitude or a big mountain nearby)   So to get real biomes, you need to model those individual factors. So now you have infinitely diverse local environments.   Then, if you want, you can categorize those infinite environments into a finite number of 'biomes' for gameplay purposes.   But IMO, you should not hide the detail and only take the simplified model. It would be better to use the simplification for the player to visualize the world while keeping the underlying detail the primary representation. So there would still be those interesting cases where no biome really describes the location well, or where two places of the same biome are actually subtly different. I think thats something that is easy to get wrong when you want 'biomes' in a game. You just end up with like 5 possible locations that are all the same, with hard transitions between. If you treat biomes as the simple approximations they are and not as the foundation of your world generation, its going to be much more natural.
  7. To create an interesting experience you need variety in that experience.   Epicness is relative to the expectations of the player. If all your quests are epic, none are.   As mentioned, the focus needs to be on quality of quests. How epic they feel, is just a knob to increase the perceived quality of experience without actually changing the complexity of the content (youre just using bigger numbers and words and so on).   So you can slowly increase the epicness factor, but occasionally you need to recalibrate the players expectations so it doesnt get too crazy. I would accompany this recalibration with particularly interesting content (because obviously going from "epic" to "mundane" is not very fun, so you need to compensate). Like maybe you complete the epic quest and go back to boring life. But from that quest you got some interesting items or skills or knowledge, that keeps you interested enough to tolerate the lowered amount of stimulation for a while (epicness is just one factor of quality of experience, so you are simply switching from relying on rising epicness as a source of quality, to some other factor like new content - overall quality of experience should thus stay constant).   Consider the storytellers of rimworld. They determine how events that happen to you in the game are 'scheduled'. Rising challenge (~epicness), steady, or random. The existence of options here means that players have different preferences. So maybe you can add an explicit option, or allow players to affect this through gameplay choices. Maybe some players choose to go on a journey of increasing epicness, while others occasionally go on an epic quest and then return to normal life. And others get themselves in a situation where epic quests are forced on them without much control.
  8. Avoid using small rectangles, or overall repetitive patterns, within the objects. Doing so interferes with players ability to parse the ACTUAL boxes (which are rectangular and repetitive). Use something like the curvy shapes of SotLs design. I find those greatly improve my ability to filter/focus on a specific box type, as the pattern is unique (brain doesnt confuse it with the boxes themselves)
  9. If you get the integer position of the node in tree-space, subsequent bits (1 for each axis, 2 total for quadtree) will index into the correct child node (as if it was 2x2 array). So on nth level, read nth bit of position on each axis (first bit is most significant bit - make sure the zero pos is in middle of integer range like with signed ints)
  10. Assuming the universe is a sequence of interactions (some kind of a DAG), time is simply the fact that these interactions are (partially) ordered.   The rate at which time passes is the rate at which the interactions can happen.   Assuming interactions happen at constant rate through every branch of the DAG of interactions, then time dilation occurs because an increase in velocity 'consumes' a fraction of the interactions for moving the pattern through space, effectively slowing down the rate at which the pattern itself can evolve (while still maintaining constant rate of interactions relative to the rest of the universe).   At least thats how I like to think about it. Dont know if the latter parts are even compatible with experimental observations, but Im pretty sure that time is just another word for causality and is nothing more.   (so the universe would/could be just a static pattern of information with internal structure that respects causality and some other rules - and thus the timelines which are us humans within that giant pattern, observe time - my personal belief is that every possible such pattern exists, and the one we live in makes sense because the ones that make sense are somehow naturally favored or more frequent within the space of all possibilities)
  11. I would say that on the first go, you form a basic understanding of what you experience. And once you understand something, you ignore it (even if that understanding is wrong or incomplete).   This gets you stuck in a state where your understanding is a bit shallow, you have gained a shallow understanding and now just immerse yourself, instead of seeking further understanding. And without that further understanding, experiencing the content always feels novel.   But the second time, your brain has to refamiliarize itself with the content - this time supported by everything your learned last time (no longer content with staying ignorant because of constant exposure). And this is when the deeper patterns that before created immersion (by staying hidden from your mind), now become predictable (resulting in boredom or frustration).   This also means that if you want to figure something out in depth, you have to take long breaks. Otherwise you ignore the 'obvious' parts (never fully exploring them), and get stuck on what you decided are the 'obviously relevant' parts (which they might not be, or may only be a subset of them)
  12. My vector class has some behavior where the last component can be ignored / assumed to be 0 when converting to different number of dimension (2D <=> 3D, and yes, this should be an explicit conversion to avoid mistakes). So based on that, I would make the choice based on which dimension is the one I most often ignore (which axis is not present in the usual 2D logic).   So for most games, the up axis would be most convenient as the z axis.   Of course, its pretty trivial to change that convention, but then it doesnt scale nicely to the Nth dimension...   (this also applies to matrices - if I want to ignore z axis, its just easy to grab the 2x2 corner of a 3x3 rotation matrix, for example)
  13. Sometimes lack of options is important in giving the player the time to think about things they otherwise wouldnt (because the game doesnt force you to do so in order to make immediate progress). If you are constantly focused on the current activity, you wont think so much about what you are doing long-term in the game, or get some creative ideas, or reflect on something (like think of a new strategy for some common challenge in the game, or prepare for a potential threat).   It is important for that downtime to allow the player to focus on their thoughts (like automatically walking from A to B), instead of some repetitive grinding that takes all their attention for no reason.   Of course the game should have enough decisions you can make on your own initiative, for there to be need for time to make those decisions.
  14.   void is basically just a placeholder, when you dont want a function to return anything, for example ("the type of nothing"). struct/class (which are basically the same thing apart from minor syntax differences) describe what variables/properties and methods each object/instance of that class/type shall have.   Ignore the :: in front of names. Its just referring to a global function or such (ctrl+f it). In parameter list of a function, "&" means the parameter is by reference (if you modify the parameter, the original object that was passed by the caller, is also modified). "const" in the same context means you arent allowed to modify it (in that case, just ignore the & - we only read from the passed in data, not write)   "operator blah" is basically the function name, except its defining an operator ("a + b", where "+" is the function). The stuff before the function name is the type it returns. If a function has no body ({ *stuff* }) after the name/params, its a declaration and the body will be defined later in the code. "this->" means we are accessing member variable of the class instance the method is acting on. Likewise, "return *this" is returning the class instance.   The comments should help understand it. Just start reading through it, you will begin to understand from context once the big picture starts to form in your head. Google the rest.
  15. I use PascalCase for classes and camelCase for methods/functions/variables (with "m" prefix for member vars - not "m_"). Because variables and functions wont really be confused (because of the calling syntax), this works pretty well.   I only prefix member vars because intellisense then easily tells me my options when I press 'm', and I dont have to constantly get confused when the logical name of a parameters happens to match that of a member variable.