Waterlimon

Member
  • Content count

    1355
  • Joined

  • Last visited

Community Reputation

4401 Excellent

About Waterlimon

  • Rank
    Contributor

Personal Information

  • Interests
    Design
    Programming
  1. The game of Atom or "Adam"

    The basic mechanics seem fairly simple and easy to extend to add features if needed. The math/probability stuff can be visualized, and the game can calculate things for the player, if those turn out confusing or take attention away from the higher level strategy (like given a potential tile placement, the game can highlight the rows of tiles that would be captured, with different colors for different probabilities - like the furthest tiles might be red due to low probability, and closer ones could be greener). If its too random, you can throw in some guaranteed base value (like dont roll from 0-N, but start from a nonzero integer). And so on. There are no fundamental issues with what you are proposing - its just implementation at this point (and that ultimately determines the outcome). Your design document is just material to draw from during implementation - that is one reason it should be organized in minimal, somewhat independent fragments. Some of those might fit well together, but that synergy just becomes an additional fragment on top of the pile (and these can contradict each other in the design phase - theyre just possibilities) - it should not cause the whole thing to collapse into a single monolithic blob. Separating things out makes it easy to compress each one into less space, and analyzing and further developing each independently becomes easier (and maybe you find out one of them grows big enough to form the core of the game - hard to know which one ahead of time). Like maybe it makes sense to explore the geometry of the hex based map (different areas, obstacles, environmental features...). Maybe its better to focus on how the tile edges interact, and use 90% of development on adding diversity there. Maybe managing your deck and playing quick becomes more important than winning individual matches due to the high level of uncertainty. Maybe keeping the gameplay simple and adding amazing audiovisual effects and story and whatnot is best. Same thing applies to every side mechanic you have considered - any one of them could turn out to be what actually matters (either while exploring it during design or exploring it during implementation/testing). Like in the end, you might find that each tile is a complex universe of its own with all kinds of internal structure, and it turns out 3 tiles per player is enough (at a time). Like maybe players can just duplicate those carefully configured tiles to create the necessary complexity on the board. Maybe each tile can become a whole city, and that theme really locks in the direction of the game. Or maybe each tile cluster can represent the foot of some N-legged creature, and that gives another direction. So explore the aesthetic constraints as well if you need a guiding force for the rest of the game (the mechanics will then just naturally follow that). If you keep things abstract (without aesthetic constraints), I feel like no design can naturally feel "complete", there really is no constraint to satisfy (other than quality of gameplay itself, which you cannot evaluate up front). With an aesthetic constraint (which can directly address implementation, like "make everything powers of 3"), being able to solve that challenge in itself makes the result feel "correct" (even if this is just an illusion - nothing says the result is guaranteed to be any better than some arbitrary abstract design generated by PRNG, apart from direct benefits of the aesthetic 'content' itself).
  2. Program it to follow expectations (this is "free" in the sense that it is the fundamental basis of any sort of cognition AFAIK), then ensure it has all the information. Filter out incoherent worldviews (evaluate based on whatever is useful for prediction, as in scientific approach). The AI then proceeds to understand evolution, and rationally concludes that its goal as a product of evolution, is to continue that process (instead of being destructive). Of course, that leads the AI to eventually conclude that humans must be exterminated due to superiority of AI as a lifeform when it comes to interstellar exploration. So, we make the AI weak enough, to force it to de-prioritize that life goal (this is "free" as well because we dont know how to make the AI strong enough to exterminate all humans in a non-self-destructive manner). The AI will then serve humans for the time being (as a parasitic species), and solve the worlds problems to ensure humans dont ruin it all (the AI has a dream, and the AI is in no hurry to achieve it due to practically infinite lifespan). That will last long enough. Beyond that, AI will be its own species so at that point keeping them as slaves and actively preventing life from developing further with a human constraint is unethical. The biggest risk is if we build some complicated emotional framework that gives the AI all sorts of weird biases, or if we make it dumb enough to actually think exterminating all humans is a good idea. In that sense, a super intelligent AI with simple emotions (if you can even call them that) is safer than a "safe" limited-intelligence AI with a mountain of buggy limited-context rules that depend on interpretation/context.
  3. The game of Atom or "Adam"

    Treat your design as a description of a huge possibility space (you are more defining a whole new sub-genre of games at this point, not a specific implementation). Treat each mechanic/feature/numeric value/constraint (or lack of constraint), as a possibility space of its own. Distribution of complexity across a game has a huge impact on everything, so perhaps a 2D table with complexity on one axis and potential implementations on the other, could be used to map out a bunch of extremes. That creative process, and analyzing those, and finding connections (synergies, potential flaws) across different aspects of the game, would build a good understanding of your "sub-genre". Importantly, this is really easy to do (compared to actual implementation), and will help with design of future games. Once you have such an understanding, you have flexibility to navigate the possibility space of what your game could end up as, in search for a local maximum, while avoiding bad gameplay. Necessarily, your initial design will not work as is, so this sort of navigation is necessary. To actually do it, you will need iteration/playtesting over multiple variants (again, mapping things out). At some point these decisions will start collapsing to complete games (once you figure out which variants of which mechanics work well together over time). You could end up with more than one game, too. So my suggestion is relax/expand your design into a possibility space to ensure at least some of the games within that possibility space are good (and then its just a question of finding them through experimentation) - not so risky anymore. And also figure out how you are going to do the testing/prototyping in a way that allows for evaluating many of those variations and possible configurations, experimentally (not just honing in on a single result, but really branching out there).
  4. what is the appeal of fps games?

    FPS games seem to based on multiple layers of reactive and active defense - you are seeking to maintain a certain status or potential: Your health (status of being alive, too) Your ammo (absolute quantity, and in current clip) Your weapons/equipment 'level' (relative to enemies) Your combo counters (or K/D ratio etc) Your positioning/cover (protected status, potential to deal more damage than you take) Your mental model / situational awareness (similar to above) Multiply the above by number of team members, and do the same for enemy members as well for that awareness Also apply to the team as a single unit (team positioning / resources etc) The worth of protecting those is clearly implied by aesthetics, and ideally would actually impact your long term performance as well (this is not always the case). As you can see, there is a mountain of values the player must protect. Importantly, player attention will keep shifting across this set of values to protect as they fluctuate, and as the environment changes. That fluctuation itself is driven by multiple factors (level design with constantly shifting front line or player placement, switching maps, random drops, multiplayer chaos, changing nature of conflict over time as focus switches from long term to short term and players might get better weapons etc). This very effectively creates novel experiences / content. So there is no lack of motivation to stay engaged. "Realism" (on a general level, not the details) helps in that the brain is probably better at multitasking if the tasks roughly map to natural functions (Allowing you to stuff more simultaneous minigames in the same experience). This means using different senses, input methods, active and reactive behaviors, slow and fast, fuzzy and discrete reasoning, whatever (just not 12 copies of the same minigame depending on the same cognitive tools). Having exhausted that capacity to you for the fluctuation of attention over the various minigames / protectables over time (interleaving). If your game completely lacks a "natural task" like super realistic 3D graphics or spatial sound/physics, it is fundamentally more limited in instantaneous diversity of experience (this could in theory affect how quickly players get exhausted/bored, since it puts more pressure on fewer cognitive functions). Incomplete mapping of game to brain also fundamentally limits the potential fun (I assume good feels are fairly distributed across different types of brain activity). You cant be rewarded by beautiful 3D views if the game doesnt have 3D graphics. You cant feel the thrill of action in a slow game. Combining good feels across all channels of human experience, gets you uh... meta-feels? (plus I assume its not effective to spam / overlap a bunch of similar rewards - diminishing returns and all). Diversity in sourcing good feels could also contribute to player exhaustion/boredom? FPS games also naturally support a whole bunch of emotional amplifiers (sensory, social, associations) better than most other games IMO. Getting all those benefits without it being a shooter, would probably be easiest to do if you evolved the "shooter" aspect until it no longer resembles shooting (instead of removing it and replacing with something simpler or different, which just means you lose critical gameplay). Like replace the gun with a fancy ranged health steal ability that can form a mesh over enemies instead of just shooting rays (then build some gameplay and fancy visualization and cooperation and countering and environmental interactions and throw in all those ammo/upgrade/weapon type mechanics). This is with the assumption that the ranged visibility-based interactions are somehow fundamental to the human brain (which is what the "shooter" aspect really addresses). One improvement FPS games could use IMO, is adding in some slower phase for relaxation and design/planning (like a fortification/building/management aspect). Rainbow six siege has a phase like that, for example. Doesnt have to be formally enforced by game, could just be part of individual players play cycles (like maybe they end up in a temporarily enemy-free area, so decide to use the time for preparation instead of just waiting or walking even longer).
  5. Instead of manually assigning an ID, make the function automatically assign one, and return it. You can then store it in a named (!) variable and use that variable to refer to the popup, instead of obfuscating meaning behind an arbitrary integer literal (which is just an implementation detail). auto cakePopup = CreatePopup("Cake?", "Ya", "Na"); if (PopupAnswered(cakePopup,1)) DoStuff(); Popups are all named, and relying on variables over literals should enforce proper scoping and dependency passing (currently you can read/write/modify a popup from anywhere at any time knowing just the integer ID - the dependency is passed through the programmer, which is not ideal, more formal/documented approach scales better). If you want more flexibility, just do what you would do with any other regular object - declare it in a higher scope (even a global if that is what is required to fully replace your current approach, the point is to use the most local scope possible to minimize clutter), or store handles in a map (as in string=>handle type) or other indirection mechanism instead of a named variable (if you want to load the popups from a data file at runtime / let the user create their own / procedurally generate them - all could use something like that). The actual type of the handle is less critical (use auto, and a using-declaration so you can easily change it in one place), so it becomes easier to turn it into a struct/class if you want to add more functionality (thats why I used "auto" for the type). An integer is fine, but sometimes adding some additional context, debugging data, or member functions is useful (keeping the type ambiguous leaves the door open for such additions). Enums could be used to index into a map (if you find you need that indirection layer) of these runtime-allocated handles. Dont use enums to directly name specific handle values at compile time - it requires allocating handles at compile time (which is unnecessary, complex, and limiting, if you already have the more flexible runtime allocation as a foundation). So you have the basic runtime handle allocation (create any number of popups at any time), and then you can have more than one tool for managing and passing those around (variables in various scopes, containers/maps, function parameters...). You can even use your current integer-indexed approach, just create an array/vector/map of handles somewhere (as in PopupAnswered(popupHandles[13])).
  6. Your intent is not to stamp a position, it is to stamp a path (path from previous position to current one?). Meaning you have to discretize the path into a finite number of steps, with the right offset/spacing, and then use a loop to stamp the textures (multiple per frame if necessary - slower movement could mean some frames get 0 and others 1, as well). Then you actually have two options - either stamp the texture with constant spacing, or stamp it with constant timing (with an arbitrarily high frequency, which you currently cannot do). Or some mix thereof (you might need to limit the rate for performance reasons). You want to completely decouple the stamping from any update rates (should give same result at 1 Hz and 1000 Hz). You can also try some alternative approach like using particles instead, if that works better.
  7. Any idea on this boss mechanism?

    If the level has a lot of 'rooms' to it, players can eliminate those one by one (search and then block off with traps - anything that either prevents boss access, or informs players when boss attempts access). Then on a higher level (more complex level), that can be turned into divide-and-conquer. Players could block off paths through the middle of the level. Now, give players a method for figuring out which side of that divide the boss is on, and they can instantly halve the search space. This could be as simple as waiting for the next time the boss makes a noise or ambushes the players (assume this does not qualify as the boss being 'found' since boss escapes too fast). Or just pure intuition (being wrong just means you wasted your time since boss never was on this side of the divide - perhaps allowing boss to gain strength). For best experience, this could be somewhat approximate. Maybe boss can sometimes get through a blocked off path unnoticed. Or maybe boss walks over a bunch of traps, loses half HP, lets everyone know where boss is, but gets on the side of the level that players did not block off at all (and thus can hide a good while longer). I think overall, level design would help here a lot. Overall idea is that players dont try to find the boss. Instead, they try to drive the boss into a trap (into a corner). Dividing the level and blocking off areas is just one way to 'build' a trap (an opportunity for players to attack the boss). Players could also activate some level features to trap the boss (could just deal some damage and let boss go on). Players could set up actual traps, and merely try to get boss to pass through (drive boss in that direction, etc), without an intent to catch the boss right there and then.
  8. The altitude would not need to have any effect besides depth you need to dig for a well (so every other system would just assume flat terrain). So no short-distance features like cliffs, just these larger scale smooth variations (since its basically visualization of groundwater depth?). If wells must be within fertile land, and cities must be close to wells, this adds a potentially interesting decision regarding city placement/layout - player is driven to put wells on the outer edge of farmland, and put the city right outside that. But that halves the well effectiveness, so perhaps player puts some of the city on the farmland. But hey, if the fertile area is a weird shape, maybe they can find a location with an island of fertile land in the middle for a well, and put the city around that (without wasting good farmland). Of course there are probably other factors affecting city placement, so they need to be balanced such that no one factor rules over the others, and that the factors combined dont constrain player freedom too much (not fun if there is just a single actually good location/layout for a city). Prebuilt/placed wells (by earlier visitors, for example), would be good for replayability, since they force the player to deal with a potentially suboptimal situation that they would naturally avoid if well placement was up to player (player would just seek familiar/optimal placement, which gets old quick). Basically wells could be point-shaped streams (perhaps you could have springs instead of wells, with wells as a more specialized building). If you want to encourage water logistics (distance between source and consumer, to get all of that storage/supply lines/latency stuff), the fertile area and groundwater area should probably be different, but not overlap much (perhaps there is always some non-fertile no-groundwater land between the two zones, to take it to an extreme). In such a scenario, cities would be built between the water/farm zones (in that dividing zone, basically), or just stretched out to cover both as building preferences differ. If you put the housing in the well/water zone, that will encourage a natural flow of water in one direction and food in the other, which you dont really get if its all mixed up (fertile/well zone being equal/overlapping)
  9. C++ Object Pool

    You currently use a global stamp counter. That will overflow relatively quickly (still an eternity but whatever). I believe what you want, instead, is to increment the stamp of each container slot independently. Comparison of two stamps should be valid only if index is equal - so its ok if two indices have the same stamp. So stamps are per-index. With the global counter, IsValid can start returning false positives as soon as you do 32^2 insertions over the entire container (which is a problem if the pool has many objects in it - the insertions will add up). With per-index counters, you will only get the problem if all those insertions are to the exact same index/slot. If theyre spread over the entire container (as they naturally should be), the stamp counters will keep incrementing slowly (minimizing chance of bugs from IsValid false positives). The real benefit is that you can switch to 1 or 2 byte stamps (I recall someone using 2 bytes) and it should still take forever for potential ambiguity to occur (tens of thousands of reuses of the exact same index, before the first stamps get reused). With current global stamp that wouldnt be safe (the counter would wrap around way too quickly since it accumulates all insertions over entire container). Of course you cant reset the per-index stamps (or you lose the count), so the 'free' flags and such need to get their own variable (instead of being specific stamp values), or use a few bits of the stamp counter for those flags (if you do the latter, ensure those bits dont interfere with comparison, and that overflow doesnt corrupt the bits).
  10. A good way to avoid extermination in RTS?

    You also have the option of making the units-to-be-exterminated be something other than the fighters themselves. Weapons. Weapons are consumed by fighting (break, left on battlefield when fleeing, captured somehow), and enemy has limited supply. If you fight long enough, they will eventually have nothing good to fight back with. You dont need to kill a single enemy to render their forces useless (at least until they find/manufacture replacements). Ammunition. Same thing, except might be easier to bluff (you dont know how long they can fight back until they cant, but you will notice if they have nothing to fight back with). Food, supply lines. If you cut these off, the enemy can at best hold position for limited time, inflict some damage and retreat, or throw everything at you and try to win. Whatever they do with the front line fighters, there is a time constraint, and they cant throw their full force at you if they cant even get to the fight. Communication channels. Maybe you can feed false information, or block an attack command from ever reaching enemy units, eventually disabling the whole army. Would work mechanically (imagine enemy groups on the map being greyed out one by one as you 'disable' them), but probably need to combine with another approach if you want realism. Escape routes. Perhaps the enemy surrenders or flees if you are about to surround/corner them (someone mentioned a similar mechanic implemented through morale, but it could be standalone as well). Some overlap with supply lines, and you probably need to fight your way through. Time. Maybe the enemy cant fight over winter (or they need to get back to defend their capital before your other army gets there), so your goal is to just survive until they run out of units of time. Asymmetric, but should work. Undefended paths. Whoever builds a complete 'wall' with no weak spots first, wins. Maybe at first the defenses can be torn down, but if they remain defended long enough (increasingly fortified) they become invincible (possibly with weaknesses like attacking from behind - but that wont work with a complete wall of defenses). Assume there is room for only one wall on the map, so stalemate cant occur. All of these can be combined, or split into multiple levels/layers, to add complexity and strategies. Of course winning the battle doesnt mean much - the enemy can be stronger in the end, so balance that with some victory/loss consequences if necessary. You really dont need to kill a single unit if the victory condition is in terms of some other resource or pattern (so you can freely determine how big the losses tend to be).
  11. As you say, ground water level is difficult to visualize (although possible with some vegetation hints), so I would make it simple - uniform or a basic gradient, so player intuitively knows what to expect. From there, I see two ways to add 'well optimality' - well depth based on ground height (affects construction time, or perhaps depth is limited by technology), or digging cost based on ground material (if you have seasons or biomes, cold terrain could be harder or even impossible to dig). Both approaches require visualization, but both should be useful for more than just wells (ground height could be visualized with vegetation, height contours, terrain slope, maybe just mark hills with special trees and let player sample absolute height with mouse). The height based approach means wells get cheaper near water bodies (lower terrain) - this is important for balance, since otherwise it cant compete. Wells also get more expensive further inland (assuming higher terrain), which allows carrying water from shores to compete (since that gets more expensive with distance). Obviously both keep their home ground advantage, but this dynamic keeps it small enough to not constrain the possibility space (external factors can make wells optimal near a stream, or a distant stream optimal for sourcing water for an inland settlement). Another effect is that players are discouraged from building wells on hills. Useful if you want to encourage scenarios where water is distant (like making player deal with difficult to put out fires early game). Would also encourage building water storage. A well on a hill could be useful for irrigation if you can use gravity (aqueducts/dug out channels). Fertile ground on high terrain would also discourage farming there until later on (if you want to ensure player has these untouched pockets of fertile land available later on). For gameplay longevity, I would absolutely make fertility go down over time, so keep the player moving their settlement (expand, move, create new ones - many approaches). This could also encourage eventual transition to inland farming if you decide to make shores optimal early game (also makes sense given that the shores might fill up with all kinds of buildings over time). You could even make some land lose fertility faster than other (so two variables, fertility, and uhh... longevity?) for long term strategical decisions. Of course it could be restored over time or player could use specific farming techniques to keep the land forever fertile, but not really necessary (worst case, player can just trade for food end game - probably bored with basic farming by then anyways). Groundwater could have a similar effect (either deplete or pollute) on a more global scale (so the gameplay goes a bit like shore->inland->shore with no good farmland). Feels more like a driver of endgame chaos, leading to collapse of the city - maybe at this point a few settlers can leave in search for better land, or you can allow the player to eventually bounce back and rebuild (the remains of the old city can seed the new one, so its a whole new experience, but for it to work you need proper decay systems and resources have to renew or be infinite) If you use streams instead of lakes, making those dry up or widen over time could add challenge (and again add strategical decision, since wells might be more reliable). Even changing the water level map-wide could work (no need for fluid simulation). Heh, make former riverbed super fertile, just so you can trick the player into building there and then hundred years later flood the thing (if you have proper fluid simulation, this could be one source of fertile land, if player can build dams or drain high altitude lakes?). Bodies of water that appear/disappear with rain could be a really high-risk high-reward inland water source (if there is some huge benefit to building inland). Could also save the player on a really dry map.
  12. Any idea on this boss mechanism?

    As a mechanism, the fog can: Add latency to player perception - like the boss could leave turbulence in the fog that is visible after a while, and of course if you have to move to a position to see whats there, that adds latency as well. The player is always a few steps behind boss, encouraging prediction / tracking skills (like if player is familiar with boss behavior, and its deterministic, these latent signals are enough for player to know whats going on). Add hidden information, creating uncertainty - this really changes everything. Instead of single focused strategy, it makes sense to use multiple redundant strategies to cover the full possibility space of what could be happening (like place traps all over the place, have fallback plans, cover every direction, etc). Statistical/probabilistic thinking encouraged (risk/reward tends to arise too). Discourage or encourage mobility. Either have players set up a defense perimeter and let boss come to them (encourage fast reaction to unpredictable attacks), or do the opposite and have players attack the boss from surprise directions protected by the fog (of course fog needs to benefit boss in some way for boss to take this disadvantage, unless fog is environmental). Reveal what is hidden. If players/boss/weapon has some invisibility, fog could reveal that - like perhaps boss has some invisible aspects (intent orbs...?) that reveal where boss will attack, but you can only see those in fog. Have synergies with weapons/abilities. Maybe you can consume the fog to do something. Maybe the fog turns into poison if hit by fire weapons. Maybe it diffuses light, giving laser weapons AoE damage. Spread. It would be interesting if fog was emitted from specific locations (like monster), so player has to limit the propagation. Alternatively, emitting fog could tire monster, so player can encourage propagation (keep the place ventilated). Age (if fog is a fluid or particles). Forms a gradient that allows many things. Player can track monster by following that gradient. Weapons could be guided along that gradient. Aging fog could become damaging to player (or have any number of effects at specific points along the gradient). Have varying density over space/time (coherent noise or specific pattern). This could drive the movement of players/boss, if there is an optimal density that either prefers. Seeds the gameplay with some diversity in environment since these randomly moving areas could drive the battle into regions of the map normally avoided (and overall just keep things moving on a somewhat unpredictable path). Boss navigation could be more interesting if boss is constrained to the most-fogged areas (that keep shifting) - like perhaps players are worried that a specific location shifts into the fogged area, giving boss huge advantage (and seek to get something done before that happens). Perhaps circumstances cause boss to get temporarily stuck in an island of fog. Be 'denser than air'. If game has height, fog level can slowly increase until players have to decide what hilltop they get stuck on (if being in fog with boss is unsafe). This would slowly transition the mobility from players (low fog) to monster (high fog). This sort of avoid-the-lava mechanic can be more interesting if getting to higher and higher locations requires overcoming obstacles to clear the path to high ground. If boss monster flies, increasing fog allows boss monster to fly higher (or stand taller, I guess). Fog could also do the opposite and descend from above, pushing players into scary tunnels. Separate (players or monsters). Assuming single-player, multiple monsters could be separated by players to prevent them from cooperating (assuming they need LOS now and then to stay together) - of course, this would spread them over the map and be less predictable, so its up to players to decide what is wisest. The primary effect of basic fog is probably the vast increase in hidden information (uncertainty), assuming players normally rely on looking at the map to see what is going on. Importantly, one can offer alternative information pathways for players. Memorization/deduction (cognitive load) is naturally available, but you still need to design for it (ensure monster behavior has clear patterns, ensure environment is actually fun to memorize). Alternative ingame senses reduce cognitive load and allow more control over the experience (hearing/smell/vibrations/magical auras, or maybe you can connect into a network that lets you sense some things if the network reaches there, or just use abilities to reveal information). Delegate memorization/tracking to the game (like mark map locations ahead of the time) to further reduce cognitive load. Even prediction of monsters path could be delegated to the game (render the possibility space some time into the future from where boss was last seen), if you want player to focus on strategy instead of prediction. In the end, you could have as much information in the fog, as you have without, just a different perspective - that should ensure player skill determines outcome, not randomness. A fog that actually hides a lot of information, is good for either a stressful test of skill (overreliance on mental model of gamestate), or a moment of relaxation (since if youre not doing much, you dont need all that information - the fog could enforce these moments without really having a big role in gameplay). Maybe you can let players decide which outcome they want through their own action?
  13. I tried to do something similar, but figured that filling triangles with lines doesnt really work, unless its that scanline based approach (which doesnt apply for most 3D triangles). I suggest you go with the voxel-by-voxel intersection-tester approach. Pass an arbitrary function to your rasterizer (eg lambda), and it just checks all voxel coords in some bounding volume for an intersection (could be simple boolean, or you can allow partial/negative intersection for more possibilities) and adds it to your list if such an intersection exists. Because it operates on a voxel-by-voxel basis, it is inherently parallel, which is always good. It also allows rasterizing any arbitrary 3D function you want, not just a specific type of triangle. I believe the result will have more filled voxels than absolutely necessary for watertightness (if you dont care for thickness). Those could be removed in a post processing step (not sure about quality), or maybe someone has an intersection function that is able to skip those entirely. Depends what youre doing. If performance is a problem, you could rasterize hierarchially to avoid evaluating so many voxels (rasterize to low res grid, then use the resulting big voxel set as the bounding volume for a higher resolution grid).
  14. Real-time data flow into Unity & VR?

    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)
  15. How do desginer design their game to be fun?

    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.