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


Popular Content

Showing content with the highest reputation since 06/23/17 in all areas

  1. 12 points
    This is one of those 'can of worms' sorts of questions as there are just so many different problems with porting. I'll just start listing things and I'm sure others will add to it, here are some of the 'technical' difficulties: Graphics engine. The consoles all have different graphics API's, even the XBox is not 'exactly' D3D so you have to go through and port certain pieces. OS in general. Different calls to do simple things like get current working directory, creating threads, file IO, etc. Equivalency of API's. For instance if you use IOCP on Windows, expect to rewrite the entire system for each of the other platforms as they all do async work differently. TRC's, i.e. requirements you must meet to get onto the platforms. For instance, a difficult one for many games is that you can't show a static screen for more than x (6 on many if I remember correctly?) seconds. You need loading animation, progress or something to tell the user things have not crashed. Different memory configurations. Some consoles have dedicated areas of memory for different things, sometimes this is enforced, sometimes it is not. Often you need many different memory allocators in order to utilize this difference. Different compilers. While not 'as' bad as it used to be, there are still different compilers, versions of the compilers, library support, out right bugs in ports at the SDK level etc. This is just touching the surface of all the problems you can/will run into. Of course there are also game play and input changes to deal with: Often you need to revamp your UI's for the consoles, unless the game was specifically written in a console style up front. Deal with different display resolution requirements. I believe you still are required to support 480P on many of the consoles. The Switch presents some issues since when detached it's a really tiny screen, will folks be able to deal with your UI on that screen? Input, hope you didn't use mouse/keyboard in a manner that won't port well to gamepads. How folks usually deal with this is as you say, spend about a year porting things. Otherwise you have to start with the support built from day one and keep everything running on all the targets. As an indie dev, I suggest not worrying about this much as more than likely if your game does really well and has potential on a console that is the only time you'd have to worry about it. At which point you can try and do it yourself or get folks who do this sort of thing all the time.
  2. 8 points
    So, I ended up doing the "skirts" method I spoke of in the last post. And in conjunction with the default Urho3D water shader (with a few small tweaks, and more to come to eliminate artifacts on the corners of the water blocks) it actually looks pretty decent. The water animates a noise texture that ripples the ground beneath. It also uses a reflection texture (which I have set to black at the moment) if desired. I might tweak the water shader further, but for now I'm happy with it. I've also got all the small issues sorted out from the change to multi-level water. It wasn't a large change, but I was surprised at how many different parts of the code worked from the assumption that water was determined by elevation < 9. I thought I had contained it better than that, but I did get all the various spellcasting, pathfinding and object spawning oddities worked out.
  3. 7 points
    You're misunderstanding the nature of cheating - you can only do a client rollback if that client accepts that it needs to rollback (which a cheater's client typically will not), or if you know that it's cheating (which a cheater's client typically will not broadcast). The client is in the hands of the enemy and it can be tampered with or modified to do whatever the user wants. Expecting a client to self-correct cheating is like expecting prisoners to lock themselves in their cells. Practically, a game developer has 2 choices to prevent cheating: A central server maintains the authoritative state, and prevents cheating because all game state changes must be accepted by the server by definition. This is a typical client-server game. All players maintain an essentially identical state, and prevent cheating by ensuring that they all agree on what the state is, and reject players who disagree with the majority. This is sometimes called 'deterministic lockstep' or some variation. Your game type will not scale to the second solution, so you need the first.
  4. 7 points
    I find Urho3D to be fantastic. I'm using it to make my game, a turn-based, hex-based RPG hack and slash: It's a very solid engine, lots of support on various platforms and quite capable.
  5. 7 points
    So on D3D9/10/11 and OpenGL, you need a dedicated rendering thread, because only one thread can talk to the GPU at a time. D3D11 is a weird exception because other threads can also call most API functions, even preparing command buffers, but the main rendering thread still needs to submit them to the GPU (and most of the per-draw cost happens at submission time, so this is not an optimization opportunity). On D3D12/Vulkan you can start moving away from the idea of a dedicated rendering thread... The first option that you mentioned is an early attempt to make good use of multi-core CPU's -- split the game into two parts, and run those parts over two threads. If the gameplay work and the rendering work are roughly equal in CPU usage, then this will halve your frametime on a dual-core CPU. This requires that you very carefully segregate gameplay data and rendering data (to avoid threading bugs) and also likely requires that you double-buffer your gameplay state, so that for example, you can hand over a copy of every object's current position to the renderer, and then continue updating the next frame while the render thread draws stuff. However, that approach does not scale to quad/hex/octo-core CPU's... So most modern engines are built around a "job system", where the engine makes a thread pool with one thread per core (2 on dual-core, 4 on quad-core...), and then you try to write all of your code as a collection of small jobs that get automatically distributed to the thread pool. With this approach, your gameplay code can run on 4 cores, and then your rendering code (culling/etc) can run on 4 cores, and then final draw-call submission can run on one core. You can still use the hard split between gameplay work and rendering work with this modern job system architecture though, but it's optional. You can either write your code so that gameplay and rendering structures are mixed, OR, you can pretend that you've got a "game thread" and a "render thread" like in the old model, even though you don't... The downside of creating the hard split is that it takes effort. You have to be disciplined to segregate rendering structures from gameplay structures, and figure out how to create snapshots of gameplay data that's required by the renderer... The benefits are that your game code can be cleaner when responsibilities are nicely segregated into different sub-projects (it can also be messier if done badly!), and that if you decouple them fully, you can actually start processing multiple frames in parallel -- while the renderer is busy submitting draw-calls for frame #2, the rest of the thread-pool can be operating on frame #3.
  6. 7 points
    A derived class can never renege on features provided by the base class; doing so is an violation of OO's LSP rule, so this approach is invalid. OO would force you to use composition instead of inheritance here. Make your own class from scratch which contains a vector within the private implementation details.
  7. 6 points
    I recently decided to play through the All-Stars version of SMB 3 without using any Warp Whistles. SMB 3's playful title screen has Mario & Luigi messing around with a bunch of enemies and powerups. The sequence is fun to watch, but it also serves as a great preview of numerous game mechanics. I suspect that the majority of people who replay the game are familiar with the secret and use it to skip to the last world. This also means zooming past a plethora of well-designed levels. It’s been my habit as well, but this time I resolved to experience SMB 3 in its entirety. A lot of small, geometric stages later, here’s an overview of what I found to be the most notable points in the first world: 1) World 1-1 As with the original Super Mario Bros., the “?” Blocks are encountered as soon as the game begins. Since they utilize a fairly universal symbol for a question, they inherently invite the player to investigate. In addition to being positioned over Mario’s head, a slowly approaching Goomba encourages the player to jump up and discover that hitting the blocks from below can yield rewards (in this case, some Coins and a Super Mushroom). The red Venus Fire Trap is also introduced here and — in typical Mario fashion — doesn’t respawn if killed and only comes out if Mario isn’t standing next to its pipe (or on top of it). Although the player can’t go down this particular pipe, the fact that an enemy emerges from it hints at the possibility of Mario being able to do the same. 2) World 1-1 Immediately after collecting the mushroom powerup, the player is presented with a red Koopa Troopa, an enemy that hides in its shell after a successful jump attack. If the Koopa Troopa is touched while in this state, it quickly slides away from Mario. Although the big white block is a bit in the way, the player can still accomplish this feat fairly easily. If he does, he’ll learn that shells can be used to activate “?” blocks (which is the only way to do it in this case as the block cannot be hit from below) while discovering the game’s new powerup: the Super Leaf. Immediately to the right, a strip of flat land with three enemies — one of them a red Paragoomba — lets the player experiment with Raccoon Mario’s glide and spin-attack mechanics. 3) World 1-1 Following the three Goombas (which don’t respawn if killed, leaving the strip clean of enemies), a diagonal trail of coins leads up into the sky. The player must jump over a bottomless pit at the end of this runway and is encouraged to collect the coins, so it makes sense for him to get a running start and jump as high and far as possible. When the player starts running, a HUD meter fills up, the running animation changes, and an urgent sound effect begins looping in the background. All these events signify that something important is happening, and when the player jumps and soars into the sky, the screen — for the first time in a Mario game — begins to scroll horizontally and vertically at the same time. 4) World 1-1 As soon as Mario lands on a series of clouds, he finds an isolated Brick Block that floats in the air much like the “?” blocks. This similarity encourages the player to interact with it in much the same way, i.e., by hitting it, which yields the first 1-Up Mushroom. The clouds continue to the right creating another clear runway that ends with a trail of coins. In a dare of sorts, the coins ask the player to throw caution to the wind and make a blind leap into the unknown. The newly acquired flying ability is quite thrilling and liberating, and having just earned an extra life, it stands to reason that most players would want to pursue the extra treasure. Doing so takes Mario off-screen and gradually lowers him by a tall pipe. With no other obvious place to go, the game stresses the significance of the pipe. If the player figures out how to enter it, its path leads him to a neat little Easter Egg: a room filled with coins that are arranged to form the number 3. 5) World 1-1 If the player misses the opportunity to fly up to the cloud passage, the next two sections serve to introduce some new enemies. The first contains a green Koopa Troopa and three green Koopa Paratroopas that drop from the sky (hinting that there’s something up above). The Paratroopas demonstrate their ability to jump onto and fall down from platforms, while the two pits to the sides serve as an opening to show that enemies can also fall to their deaths. The second area contains a Piranha Plant and a green Venus Fire Trap. Their proximity makes it more likely that the player will have to stop by one of them on his route to the level’s end. If he does, he’ll have another opportunity to discover that the plants can’t come out of pipes if Mario is standing near them. The immobile version of Super Mario will also encourage the discovery of crouching in order to dodge the fireballs, and a Raccoon Mario will get a chance to dispatch the plants with his spin-attack. 6) World 1-1 Right before the level’s end, the player encounters two grounded piles of Brick Blocks. Since the player had two previous chances to pick up a Super Leaf, he’s likely to try the spin-attack on these glowing objects as there’s no way to hit them from below. In addition to this lesson, there’s also a solitary red Koopa Troopa pacing atop the second group of blocks. Since the player already had a few chances to learn that Koopa Troopa shells can take out other enemies and activate powerups, he might try to do the same here. If he does, the shell will break through a bunch of Brick Blocks and leave one of them unobstructed. If Mario hits this block from below (or spin-attacks it from the side), it will reveal a P-Switch. The P-Switch functionality immediately turns all the remaining bricks into coins and plays a jaunty countdown theme. When the countdown ends, the remaining coins turn back into Brick Blocks, teaching the player that the transformation is only temporary. The music change is important as there are no other visual cues to indicate if and when the blocks will return to their original form. 7) World 1-1 The final part of the stage is segmented by a jagged black line that spans the height of the map. This clearly denotes the end of the level while keeping with Super Mario Bros. 3’s stage motif — crossing this boundary is almost like stepping behind a curtain. The only object in this area is an animating Goal Panel that instantly draws the player’s attention and ends the stage when touched. Since the floor leading up to it is flat, it encourages the player to run in at full speed and jump into the panel. More often than not, this rewards the player with a star, the best possible Goal Panel prize. 8) World 1-2 As soon as the second level begins, the player is introduced to slopes and gets to experiment with how they affect Mario’s movement. Once Mario reaches the first peak, he can also dispatch a Goomba with the slide-attack while being pursued by more Goombas spawning out of a horizontal pipe. 9) World 1-2 The second major area in the level shows an almost unreachable series of coins, a floating pipe with a Venus Fire Trap, and some Brick Blocks located just above the ground. The player is likely to collect most of the coins and then attempt to break through the Brick Blocks, and perhaps learn the run-then-duck-to-slide maneuver. If the first block is hit, it reveals a P-Switch. Unlike the P-Switch in the first level, this one turns coins into other Brick Blocks. This results in the coins (or at least what’s left of them) being transformed into a path that leads up to the pipe. This clearly labels the pipe as a destination and allows Mario to use it to get to another bonus room. 10) World 1-2 The final new object introduced in level 2 is the Jump Block. Much like the other types of blocks, it’s uniquely (if a bit abstractly) decorated, naturally drawing the player’s attention. The first two Jump Blocks are spotted in a valley with a Paragoomba, increasing the chance that the player will bump into them while dodging/attacking the enemy. The bouncincess of the blocks is quite intuitive as it’s reminiscent of a trampoline — or a really springy bed, which most anyone will immediately understand — encouraging the player to jump off of them as they dip to their lowest point. The second block also spits out a powerup, and it’s possible to initiate this by bumping it from below or landing on top of it. In case the player misses this point, the next area contains a pit and a stairway of Jump Blocks. In order to safely traverse the pit, the player is likely to use the Jump Blocks above it (instead of risking bumping into them from below), the last of which drops a Starman. 11) World 1-2 The level end introduces a new enemy, a flying Paragoomba that bombards Mario with Micro-Goombas. Since there are no other enemies or obstacles in sight, it’s a safe place to demonstrate the mechanic of Micro-Goombas slowing down Mario if they attach themselves to him. If the player lets the Paragoomba follow Mario, he might also learn that any enemies on screen will instantly perish when Mario touches the Goal Panel. 12) World 1-3 As the third level begins, the player is greeted with a few large blocks and a Koopa Troopa. Both of these elements seem to be an aid in dispatching the Boomerang Bro. that stands behind ’em, i.e., the Koopa Troopa’s shell can be rocketed into him, while the higher vantage points makes it easier to dodge his boomerangs and squash him from above. 13) World 1-3 Following the Boomerang Bro., another Brick Block pile is presented where a red Koopa Troopa can be used to set off a chain reaction that destroys many of the bricks. This time around the pinballing turtle shell shows how Jump Blocks react to its touch (simply deflect it like other blocks) while rewarding the player with some extra coins. When the turtle shell leaves the screen, the player is encouraged to jump down into the cavity it created and investigate the leftover blocks. One of them yields a powerup , while another proves to be a Coin Block . The newly formed brick configuration leads the player to jump back out once he’s done, at which point he has a chance to encounter an invisible Jump Block. This pink block can only be hit from below, and when activated, it sends Mario into the Coin Heaven bonus section. 14) World 1-3 Although Level 3 is mostly flat, it doesn’t hold any rewards up in the sky. The Cloud Heaven, though, contains a bunch of extra coins and a 1-Up if the player uses it as a runway. 15) World 1-3 Past the pile of Brick Blocks, the player encounters a series of stacked Wooden Blocks. The reason they’re grouped this way is to encourage the player to press against them as he jumps forward, giving him a chance to discover that Wooden Blocks can yield powerups if hit from the side. 16) World 1-4 Although level 4 is not incredibly challenging, it’s much more difficult than the previous three stages. It’s almost completely devoid of solid ground, and its auto-scrolling nature makes it a much more intense experience. This is perhaps the reason why it’s skipable on the overworld map. In addition to the automatic scrolling that can push Mario to his death, the stage also introduces moving platforms. The platforms only move horizontally, and drop as soon as Mario lands on them. This is a pretty intuitive mechanic as it’s easy to imagine Mario’s weight overpowering the ethereal strings that hold up the platforms. Once the player learns this, he can use it to his advantage in an area where a vertical stack of coins is positioned next to a wall. With some quick thinking, the player can figure out that if he jumps on the incoming platform, it’ll drop and he’ll collect all the coins, and then still be able to jump off of it and through a gap in the wall. This is a great example of rewarding the player for proper environmental analysis and making him feel like he’s mastering its traversal. 17) World 1-4 Unlike the previous stages, level 4’s main area ends with a solid wall and a pipe. Since there’s nowhere else to go, the player — for the first time — must learn to travel through a pipe in order to finish the level. On the other side, he’ll be ambushed by a Boomerang Bro. and find the standard Goal Panel. Somewhat emphasizing the level’s optional-challenge nature, if the player collects all the coins in the map, Toad’s Blue House will also open up in the overworld area. 18) World 1 Fortress Podoboos and Roto-Discs are first introduced in spaces where it’s easy to avoid them. Once the player gets used to their functionality, the difficulty is ramped up: multiple Podoboos emerge from lava (with different timing), while Roto-Discs occupy platforms that Mario must jump on in order to proceed through the level. 19) World 1 Fortress The Fortress marks the first in-level appearance of the Fire Flower. This is significant as there are no regular enemies in the Fortress that can be defeated with Fire Mario’s fireballs. This is a tactic that’s used multiple times in the game, but because powerups carry over from level to level and it’s always adventagous to be in “big” Mario mode, it never feels like a handicap. 20) World 1 Fortress If the player chooses to trade in the Fire Flower for a Super Leaf, he can discover another secret in the sky. This is hinted at by the open ceiling and — if the Dry Bones is temporarily dispatched with a stomp — a runway right next to it. This particular secret leads to a Warp Whistle, and is much more intuitive than the obscure duck-on-a-white-block-for-an-extended-period-of-time maneuver required to get the first whistle. 21) World 1 Fortress The first door the player encounters leads him to a room with a spiked ceiling. The ceiling starts to descend as soon as the player enters the area, but he is also shown a gap that might keep Mario safe. With no other options in sight, it’s natural for most players to strive to reach it before the ceiling crushes them. When the ceiling drops down all the way, it begins to recede and Mario is forced to jump over a bottomless pit. There is no second hiding spot in sight, so the player has to trust the game to provide one for him. This creates tension and forces the player to perform a leap-of-faith, but he’s ultimately saved by a final tiny gap (much smaller in width and height than the first one) at the end of the area. The gap is located next to a wall so it’s fairly easy to get into it, but its small size makes the whole sequence feel like a nail-biting escape. 22) World 1 Fortress The Fotress level ends with a boss battle against Boom Boom, an enemy that needs to be stomped three times before being defeated. If the player still possesses the Fire Flower, he can also dispatch him with its fireballs. When Boom Boom perishes, he drops a “?” Ball that ends the level when touched, adding to the “specialness” of the Fortress level. 23) World 1-5 In case the player never discovered that he could slide down slopes to take out enemies back in World 1-2, this level does it for him. Unlike all the other stages, it begins with Mario on a slope already in a butt-scoop position. He then proceeds to barrel through some Buzzy Beetles that just happen to be climbing up the hill. This not only shows the mechanic, but also displays its usefulness. In addition, sliding is pretty much a universally fun activity, and its presence is another incentive for the player to experiment with the moveset. 24) World 1-5 The level contains another Fire Flower that allows the player to test out the enemies, but it’s only accessible after the section pictured above. This is notable due to the pipe that hosts a Piranha Plant located close to the ground, making it likely that the player will stop and wait for the plant to recede. During this interval, an approaching Buzzy Beetle will prevent Mario from running through the opening. When the Buzzy Bettle finally reaches Mario, the player will likely jump on top of it, learning that the beetles’ shells act much like those of the turtles. At this point, the careening shell will have a high chance of taking out the Piranha Plant as it comes out of the pipe, teaching the player another useful combat mechanic. 25) World 1-5 And in case the player missed the pink Jump Block in World 1-3, he gets another chance to discover it here. Walking up slopes is never fun so the player is encouraged to jump through the area, and in the process possibly bump into the invisible Jump Block. As usual, the pink Jump Block leads to a Coin Heaven area where — once again — he can discover extra coins and a 1-Up if he uses it as a runway. 26) World 1-6 Although this level is not autoscrolling like World 1-4, it’s similarly devoid of a floor. This creates some interesting airborne hijinks with the red Koopa Troopas that do not walk off of platforms by themselves. As shown in the above example, it’s very easy to start off the level by stomping a Koopa Troopa and sending its shell flying to the right. In turn, the shell will fall off the platform, travel through empty space, land on another platform, and eventually take out another Koopa Troopa that patrols it. 27) World 1-6 Unlike the floating platforms in World 1-4, these ones are attached to a thin path and are buffeted by end pieces. This allows the player to easily guage the platform’s movement and plan his jumps accordingly. The first platform is introduced with no enemies in sight, but the second one runs head-first into a Koopa Paratroopa. Also, its path doesn’t contain an end piece, forcing it to eventually fall off the path itself. This in turn forces the player to quickly jump to a nearby platform. 28) World 1-6 More opportunities for mid-air stunts are presented via the flying red Koopa Paratroopas. By the time the player encounters them, he’s more than familiar with the mechanic of clipping the wings of enemies and sending them plummeting to the ground. Since there’s never any solid ground below these turtles, the stomped Koopa Paratroopas simply fall to their deaths. This creates some rather satisfying scenarios where the player can kill two birds with one stone: dispatch an enemy and make a piggy-back jump onto a new platform. 29) World 1-6 The area above is a runway, but it’s punctuated by a single gap that slightly drains the run meter. If the player jumps onto it while running from a previous platform, though, he retains part of the run-charge and is able to take off into the air. A path of coins beyond the platform shadows Mario’s flight arch, and when he finally floats down, he’s safely deposited on a moving platform. 30) World 1 Airship The airship levels start off with a short cutscene of Toad pleading for help and Mario heroically leaping onto a moving airship in pursuit of Bowser’s minions. Like all “artillery” stages, the level auto-scrolls and is filled with unique enemies such as Cannonballs and Bullet Bills. This approach makes it feel almost like a shmup as the player is forced to concentrate on avoiding multiple projectiles while waiting for the end-segment to scroll into view. However, unlike most shmups, Mario has to deal with gravity, the movement of the ship, and the cramped architecture. This makes avoiding bullets much harder, but also steers the player into making another discovery: not only can Mario kill the projectiles by jumping on them, they can also perish if they touch his feet (even while he’s standing still). A single Fire Flower stresses this point as all the enemies in the level are invulnerable to its fireballs. When the end-boss is defeated, the significance of the level is further accentuated by a series of events: Mario grabs the stolen Magic Scepter , jumps down to the ground, cures the king, receives a congratulatory message, and finally reads a letter from Princess Peach that comes packaged with a powerup. Super Mario Bros. 3 contains many obvious design lessons that are also present in other games, e.g., the gradual layering of complexity that allows players to master a specific mechanic. What surprised me during my playthrough, though, was how some of these lessons were completely optional. For example, it’s possible to send a turtle shell skittering in the opposite direction of destructible bricks, or to take the cloud-route and skip certain powerups and interactive objects. Of course these same lessons are repeated multiple times, but they’re not always as heavily hinted. Personally, this hits a sweet spot for me. The game doesn’t have any forced hand-holding, and it isn’t afraid of the player simply exploring it at his own pace (even if it means circumventing chunks of the experience). This approach also serves to encourage multiple replays, and — back during SMB 3’s initial release — it probably sparked many playground discussions. Note: This article was originally published on the author's blog, and is reproduced here with kind permission.
  8. 6 points
    In terms of getting into the traditional industry, you need to be comfortable with object-oriented programming in C++. There's no serious debate there. The major engines are object-oriented, most in-house engines are object-oriented. There's a whole continuum of just how much inheritance you might see, but on the whole you are not likely to run into C-style data-first engines. This does not mean that you have to make a binary choice. You will need to be comfortable with object oriented programming but a good knowledge of data-oriented programming can help you if you want to optimise very low-level things, or if you end up working for a company that favours that sort of approach. A lot of data-oriented design is typically based around the reductionist view that programs are essentially just processes that transform data, and therefore you should just structure the functionality around the data, both to better represent the process and to help the computer perform this process more quickly. This view holds very true for certain low-level operations that operate on batches of similar objects, such as rendering or physics, but is barely workable for many high-level operations, such as AI or game logic. An effective engine will therefore often feature a bit of both; heavily data-oriented code at the low level for maximum performance, and heavily object-oriented code at the high level for maximum expressiveness. There's no need to throw out object-orientation entirely just because it may not be best route to top performance for certain tasks. That was 18 years ago. Probably 20 years if you are counting when development started! Ignore this particular part of your research.
  9. 6 points
    I'm on vacation in California, which means I kinda have some time to work on stuff, but it's split up by blocks of frantic activity. I'll tweak a few things, then head off to Knott's Berry Farm to burn in the sun while the kids ride on rides too small for me. Then I'll fiddle a few more things, then take the kids swimming. So while I'm getting some stuff done, it's all in a sort of disorganized tangle. I did decide to upload a new gameplay video. Once again, it's pretty poor quality. (Some day, I'll own a rig decent enough to make high-quality videos. But that day is not today.) It's about 10 minutes of random gameplay. I was kinda distracted while playing by a 5 year old who wanted my help building electronic circuits with a snap kit toy he recently got, so there are some pauses. Also, there is still stuttering in some spots, which won't be cured until I fully convert everything from Lua to C++. (That's an ongoing project, but I am getting quite a bit of progress done while here in Cali.) The stuttering is from the Lua garbage collector, which has been an ongoing problem with the Lua bindings to Urho3D. Throughout development of this game it has been at time worse and at times better. A recent change (unsure which one) made it worse again, enough that I'm finally going to just convert everything except UI stuff to C++ components.
  10. 6 points
    (since shadertoy doesn't allow more than a couple of lines in the description and I don't want to put all the stuff into the comment section there, I abuse the blog here) For everybody new - or not so new - to shaders, hear this: Browse and use ShaderToy ! Not only is it just bloody amazing what you find there, it's veeeeeery educational. And easy to use. No hassle with setting up the GPU pipeline yourself - you only need a WebGL capable browser (most are). The interactive compiler displays errors right after the faulty code lines. Minor nuisance for me was the sometimes "restrictive" behaviour of GLSL (coming from HLSL), but that's not deal breaking. After experimenting with signed distance functions in 3D with my SlimDX/HLSL stuff I was curious about 2D. So I found this (thank you Marteen): https://www.shadertoy.com/view/4dfXDn Very nice. Basic shapes with contours and the usual combiners. Improved with lighting and shadows. Expanding on this, experimenting with polygons and stars, I wanted to put it to the test with something less abstract. Anybody remember Spirograph ? The math around this (pun intended) is already endless. I didn't even know about roulettes before. But let's start simple. There's a very old discovery from a Persian astronomer: Tusi-Couple. Here a short protocol of the progress: Needed individual colouring for the shapes (Marteen's sample combines all shapes to one SDF). Experimenting with arbitrary blending, too (blend function). Animate the inner circle/wheel within the the outer. Just basic trigonometry. To make it more clear I colored both circles "Wheel of Fortune"-style (see radial function). Choose some point on the inner wheel, mark it with a point. I chose a star shape for this. Track the ellipse path. Since I got no clue how to derive that yet, I simply trial-and-errored. Only got a filled ellipse (or rather: used a transformed circle). Found a real ellipse and used that to generate an outline (ellipse and ellipseLine functions) The ellipse line produced some artifacts at the main axis. Needed some tweaking. Still not perfect, goes havoc in the degenerate case. Now use lineDist in that case. Hmmmm, cogs would be nice. Splitting the polygon function into circleMod (to get normalized angle part) and using polyShape for laying cyclic functions around a circle. The current implementation using a simple sinus is actually NOT a clean SDF. It works well enough though - and I expect a correct implementation to be quite challenging. Added spokes and bars to give even more of a mechanical/gear feeling. Steampunk rules. Challenge: Derive ellipse path automatically. I feared the worst. Ellipses are usually a bitch - algebraically. But in this case I found that one can exploit the simplicity of the Tusi-couple and derive the major/minor axis directly (see final if-clause within sceneDist function. Not yet commented) Add some light and make the thing scale with the viewport correctly (shadertoy has fullscreen capability). TODO: Choose 2nd point with mouse. This should be possible with additional input/buffer logic of the shadertoy setup. Haven't dug into it just yet. For now one can change the point at the start of the shader code, though (relativePos constant). ENJOY! If you're interested in SDFs I recommend this as a starting point: Distance functions. Quílez has more to offer, of course. He is also quite active on shadertoy. Rewriting classic games for instance. Wow. PS: Oh my, there are even sound shaders : https://www.shadertoy.com/view/MtGSWc
  11. 6 points
    One thing you can do is try to run as much of the game logic as you can on the server side. You can't really trust the data clients give to the server, since they can mess with that data, then pass it to the server. Examples might be telling the server where they are (even if they are not really at that location), or how much health they have left, etc.
  12. 5 points
    It has to be the same mutex. Otherwise they're not interacting in any way to prevent the other thread from accessing the queue. The point of a mutex is that it is shared, like the thing it is protecting, different threads must acquire it before proceeding to use the protected resource, and only one thread can hold it at once. The other threads will block if they try to access the mutex, until the mutex is freed up by whichever thread acquired it. This means only one thread can access the resource at once - which is the intended behaviour. There are some esoteric situations where people use multiple mutexes for various functionality but that is not the usual situation.
  13. 5 points
    You can definitely improve the background image and main menu. When I clicked your link I initially thought it was a popup ad and instinctively added it to my adblock blacklist before I realised it was the game. Other than that, I would be interested in playing this game with the player speed slowed way down, such that you actually can make decisions for both snakes within 2-3 frames of time. As it stands now, the strategy is to make the top one a bit longer, then put it on autopilot and focus all of your attention on the other one, etc. My idea would be Slow down snek speed so you can focus on both Remove wrap around feature so you have to focus on both (add borders)
  14. 5 points
    Hashes, Databases, Sockets, States... These are all *completely unrelated things*. I'm worried that you're misusing terminology. Can you clarify your question by describing what you think those terms mean so that we don't misunderstand what you're trying to ask? Hashes are a lossy conversion of data. You can't get the original data back. So, no, you should not use them to store game states. You can use them to quickly FIND game states, but you should not use a hash for the state itself.
  15. 5 points
    So, I'm trying to figure out how to do water. Right now, I am doing water the "brain dead" way; any tile below a certain height is water, and water is created as a simple hexagonal plane with a partially transparent blue material applied. It works okay, but the ultimate end goal is to have water play a more involved role in the landscape. I'd like to have rivers, waterfalls, etc... and that means that I need to rethink how I do it. I'm trying to come up with ideas for the geometry of water. Here is a shot of how the current water system might look if I use it unmodified for multi-level water: Clearly, I need some sort of geometry to tie the pieces together. My first thought is to create a sort of "skirt" piece that is attached to the side of a water hex if that water hex has neighbors whose water height is lower than its own. Might end up looking something like this: The issue with that, of course, is that I have to oversize the skirts to avoid Z-fighting with the underlying ground hex, and that means that skirt pieces overlap with adjacent skirt pieces on different hexes and with the water hex of the lower water levels. In combination with the alpha-blending, this creates bands or regions of darker color where two pieces of water blend together. I could use waterfall particle systems to help obscure this overlap, I think. Alternatively, I could use a solid material instead of a partially transparent one: I dont like the look of it, though. Large areas of flat water look terrible. Granted, there will need to be improvements to the actual water material to make it look better regardless of how I handle the geometry, but for now I'm sorta stuck on how best to do this. I do have some ideas as to how I could perform the geometry stitching of the skirts to minimize overlap, but it'll take the creation of special pieces, and some special-case code. Not too difficult, I suppose, but still seems kinda messy.
  16. 5 points
    All variables are just bits in memory, so using it as whatever is totally valid, because they're just stupid bits. That's a weak argument. An enumeration has by definition a restricted range of values, the compiler checks for this and makes sure you don't write buggy code by going outside of this range, which is what you were trying to do. Since you are working with flags, it makes no sense to use an enumeration type. What you want is an unsigned type and some constants. I'd simply do the following: enum { fpl_InitFlag_None = 0, fpl_InitFlag_Window = 1 << 0, fpl_InitFlag_VideoOpenGL = 1 << 1, }; typedef unsigned int fpl_InitFlag; It's clear from the naming that these are flags and there's also a hint to the user that he should use the constants starting with fpl_InitFlag_.
  17. 5 points
    Ooh good timing for this thread - Albrecht just posted some new slides! The original 2009 talk (still relevant!): http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf And the 2017 version: https://docs.google.com/presentation/d/1ST3mZgxmxqlpCFkdDhtgw116MQdCr2Fax2yjd8Az6zM/edit#slide=id.g2398a4e2af_0_118 https://docs.google.com/presentation/d/1305-i5JZ98cLqXgVwzTyB1NQUjjBJ0_0diwU2diS_TI/edit#slide=id.p tl;dr:
  18. 5 points
    Both. It's trendy for bad programmers who think that OO=inheritance to post unfortunately-influential rants against OO these days... Don't listen to them and don't throw the baby out with the bathwater. Look up SOLID - this is the modern core of OO. Those rules, along with encapsulation and invariant-enforcement let you write large scale projects that are performant but more importantly, are easy to maintain into the future. DOD and OOP can be good friends. OO doesn't really care about data layouts, but OOP languages can default to some bad layouts. C++ is flexible enough to let you apply DOD and come up with better layouts while still getting the maintainability benefits of OO. OO can also encourage bad data access patterns (thinking per object instead of thinking per batch of objects), which can be bad for performance on modern CPU's (where cycles are cheap by memory access is death). This is where you can use a hybrid of OOP and DOD. Often this manifests as creating "systems" (e.g. "particle system" class, but no "particle" class) and representing objects by some form of opaque handle. C++'s flexibility again gives endless options here. Sometimes you still have individual objects as classes as well as a "system", but move certain methods to the system from the object to force users into better data access patterns. Other times you still have traditional objects, but you just use DOD thinking to arrange them into better layouts, or restructure the algorithms that operate on them to make better use of the real hardware. C++ vs C is interesting because you can use 99% of C syntax from C++ anyway, and also no project ever uses all of C++ (almost every project coding guidelines / style guide will specify the acceptable subset of C++ that you're allowed to use). The big problem with C++ is a lack of a stable ABI -- this means that DLL's created with one compiler do not play nice with projects being created by another compiler... which means that C++ middleware is pretty much useless without source code access. If you're writing a closed-source middleware library, you should almost certainly write your public API in plain C, even if the internals are written in C++ It can also be useful to enforce these kinds of constraints within the submodules of your own project, even if you don't need to. For example, see this blog post from The Machinery (ex devs of Stingray / Bitsquid engine and, ex Grin engine team). Keeping the interfaces between the different parts of your code simple can be extremely useful for ensuring your codebase remains maintainable, which is what OO is all about.
  19. 5 points
    Since the items are referred to by their tag, then it would be easier to use an associative array, such as `dict` or `collections.OrderedDict`. Then, checking if the inventory is full is only a matter of checking the number of tags it has: items = dict() def is_full(self): return len(self.items) >= 8 You are correct in that it is misleading to add an item and not actually have an item added. This is why it is important to signal if an action succeeded and (optionally) provide other ways to determine if an action will succeed. For example: class Inventory: max_inventory_size = 8 def __init__(self): self.items = dict() @property def full(self): return len(self.items) >= self.max_inventory_size def can_accept(self, item): return item.tag in self.items or not self.full def try_add_item(self, item): if not self.can_accept(item): return False self.add_item(item) return True def add_item(self, item): target = self.items.get(item.tag, None) if target is not None: target.quantity += item.quantity else: assert not self.full, "Inventory full" self.items[item.tag] = item # and then: (1) # expect this action to succeed, otherwise crash hard inv.add_item(item) # or: (2) # lazily attempt action, not caring if it fails if inv.try_add_item(item): world.remove(item) # or: (3) # don’t attempt action, but do check if it is possible for shop_entry in shop_menu: if not inv.can_accept(shop_entry.item): shop_entry.enabled = False
  20. 5 points
    I've long grown out of playing games. Coding games and tools is a different thing all together, I remain fully interested and stuck with coding mobile games and wouldn't choose a different hobby/career (well apart from the fact that I long to improve my coding skills, and my maths and physics knowledge) But playing games, these days (unlike over a decade ago) genuinely bores me to death. I guess I always feel I am coding for the younger generation, similar to enjoying making toys for kids but not enjoying playing with the toys yourself I'm coding mobile games at the moment and I look at and play some few just for gameplay analysis and checking current standards and features but not because I enjoy playing them I know this certainly makes me an odd-ball here, but just wondering how far an odd-ball I am. Is there a few... maybe just one more person like me here OR just me? (if the latter then I have to make sadder clown face )
  21. 5 points
    It has been quite a while since my last blog post… as always. However, development has not ceased entirely… just continued in ever so small steps. =) Here are some of the changes and additions made in the last couple of months. Exploration/event music added. Created library for handling steam achievements. More enemy types. Work on demo has begun (almost finished). Fixed a bug when shooting arrows on certain types of enemies. Implemented a game launcher which displays news and announces game updates. Launcher will not be included in the steam release, I think that would be superfluous. Added animation to an already present cutscene (this had actually been long overdue, it looked horrible). I've also created a short trailer for the game. Steam requires all games to have a trailer in order to have it published. Luckily I just found out that Photoshop is able to edit videos I didn't even have to learn any video editing software. *yay* Well, this one-man project is starting to shape up nicely I think =) Now, with these latest changes (…and a ton of tweaks and fixes made earlier, too many to mention here) I felt it was time to submit the store page and game files for review by valve/steam. They say that the review process can take up to 2-3 days for the submission to complete. It feels strange to call Medieval Story *finished* but I have to call it sometime. I hope the game gets enough response/appreciation to warrant further development. However… I know that indie games rarely becomes successful so I have set my aims pretty low in that regard. If I was doing this for commercial success alone I think I would never had gotten as far as I have. On a private note, our second daughter has been born which has led to my development time being even more limited. As always, thank you for reading and for your support!
  22. 5 points
    In my experience, these kinds of systems are done by a shitload of art creation, plus some simple morph target tech. Artists also paint which vertices belong to which 'group', so that different parts can be blended differently.
  23. 5 points
    The Gaussian blur is separable, meaning it can be done in one direction, then the other and have the same result as if you did a kernel with all surrounding points included. In other words, for a 3x3 blur, you can do an X pass with 3 taps (the middle sample and one on either side) and a Y pass with 3 taps (the middle sample and one above and below) for a total of 6 taps. If you did it in one pass, you would need to sample all nine points, i.e. the center point, the left and right, the above and below, and all four corners - those are values you get for "free" when you break it up into two passes. For a small blur width like the above example, it might be faster to use one pass, but for larger kernels, you can see that the number of samples in the single pass start to add up. For a 7x7 kernel, you would need 49 taps total for a single pass, but only 14 if you break it into separate passes.
  24. 5 points
    Long-time GameDev.net member and indie developer @cliffski32 of Positech Games has posted in his latest blog a very direct message to aspiring indie developers: you will flop and lose money. While not the message most aspiring developers want to hear, @cliffski32 discusses the challenges for an indie from a financial perspective with all the costs and revenue losses that developers incur when you factor in staff, legal, and investors. Using data from player unknown: battlegrounds as an example of the high end and assessing the mean game in 348 pages of "Top Sellers" of Indie games on Steam, @cliffski32 makes the point that game development is a tough business. Read the full blog post at http://positech.co.uk/cliffsblog/2017/06/23/your-indie-game-will-flop-and-you-will-lose-money/.
  25. 5 points
    What it looks like you're trying to do is draw the first sprite, and then "wait" (is this why you were asking about Sleep()?) and then draw the second. This won't work. The "wait" call you are attempting to make here will just halt everything for the duration of the call, giving the program the appearance of freezing for a second or however long you are waiting. The correct way to handle this kind of thing is, unfortunately, more complicated. What you can do is keep track of how much time has elapsed between the last time you called drawScene() and this current call to drawScene(). There are various ways to do this, using various platform-specific or platform-agnostic timing APIs that can give you the "current time" in some fashion. std::chrono::high_resolution_clock is probably a reasonable place for you to look at (specifically, the now() function). void drawScene() { auto timeStampNow = std::chrono::high_resolution_clock::now(); auto elapsed = timeStampNow - timeStampPrevious; // ... timeStampPrevious = timeStampNow; } Here, you get the current time, subtract it from the previous time (which you are storing elsewhere, in a member variable perhaps) and compute the elapsed time since the last call. At the end of the function, you set the "previous time" to the current time, so it's correctly set up for the next time drawScene() is called. Once you have this elapsed time, you can use it to "count down" until the next time you are supposed to do something. If you have another member variable that is, say, "timeUntilSecondSprite" initially set to some value corresponding to how many seconds until the next sprite show up, you might do timeUntilSecondSprite -= elapsed; if (timeUntilSecondSprite <= 0.0f) { // Counter has run out, draw the sprite now. } You can implement as many time-based effects as you want with this approach, optionally resetting the counters when they hit zero if you want them to occur (for example) every N seconds.
  26. 4 points
    Hi everyone, I'm creating a series of tutorials about the creation of Game Effects in Unity. I hope it may help someone around here, and feel free to ask questions. Thanks & Enjoy!
  27. 4 points
    A few things: 1) Yes, gd3dApp is a global. Hence the 'g' prefix. 2) The global isn't actually necessary - Windows allows you to attach a pointer of an arbitrary type to a window, either at construction time or at any point later", albeit at the cost of type-safety. Look up "SetWindowLongPtr". Mind you, the point about not assigning a member function to the window still holds, though, because of how pointers to member functions work in C++. 3) The anonymous namespace is used to prevent the global from being accessible outside the source file in which it is defined. In C we would do this using the "static" keyword, but anonymous namespaces are how modern C++ accomplishes this. 4) Classes are constructed in order of inheritance hierarchy - and destructed in the opposite order. So the base class (D3DApp) would be constructed first, assigning the "this" pointer of the class to the global. 5) If you were to have two classes deriving from D3DApp, and you would instantiate both of them, the global would be set to the address of whichever one was most recently constructed without fanfare. You can probably see why this could be dangerous...
  28. 4 points
    The main thing I'd suggest keeping in mind is that you might be artificially limiting your options by trying to find an entry-level job which also is a dedicated AI role. Entry level is hard enough to break into as it is, and AI is a specialization that typically involves some baseline experience in making games. Your best bet (IMO) is to get a good title or two shipped first as a gameplay programmer, and pick up the AI as you go. Once you have the basics of shipping code under your belt, you can start looking into the specialization. You should ideally be conversant in all of the following: Decision making systems (scripting, utility-theory, behavior trees and similar architectures, planning, state-search, machine learning [ugh], and so on) Path planning algorithms and data structures Perception modeling (sight, sound, etc.) Animation techniques at least at a high level (know what a blend tree does, how to play animations, etc.) I'm sure there are more things. Pick up a good game AI text and you should at least be comfortable talking about every subject in there. Hopefully that explains why entry level and AI specialization is a hard combo :-)
  29. 4 points
    This article was first published on https://medium.com/@ricardo.valerio/make-it-difficult-not-punishing-7198334573b8 Difficulty plays a big role in keeping players motivated, engaged and, unintuitively, in marketing. Some games have it better designed than others. Some design it even to make it satisfyingly hard, like Dark Souls. But others have it poorly designed, with a very high difficult bar set from the very start, or none to little difficulty altogether, combined with too steep or too shallow difficulty increase. So how do we go about designing good difficulty? The first thing that we need to do is to define difficulty. What is difficulty? Difficulty is the amount of skill required by the player to accomplish a goal or progress through the game experience. It can be as simple as jumping from one platform to another, killing a character, defeat a boss fight — which could be designed respectively to be easy, medium or hard to accomplish. Difficulty goes hand in hand with the challenge presented and the skill of the player related to that challenge and the game. Present a too high challenge for a less skilled player, and it becomes a hard barrier from which players can turn away from; present too little challenge for high skilled players, and it won't be interesting for them. The optimal difficulty is one in which the challenge presented is always slightly greater than the skill of the player when he first encounters it, so defeating the challenge provides a climax, small or big, and satisfaction. This provides for an optimal flow state, where the player knows accomplishing the goal is possible, and investing energy will provide for a satisfying resolution. Mihaly Csikszentmihalyi, a Hungarian psychologist, proposed the following graph that defines flow as the channel where there is an optimal level of skill vs. challenge. Difficulty is the amount of skill required by the player to accomplish a goal or progress through the game. Later on, he proposes a more detailed mental map, matching certain areas of skill and challenge to specific mental states. Image from https://en.wikipedia.org/wiki/Flow_(psychology) As we can see here, a difficult challenge for an average skilled player will at first provoke arousal — the player knows it’s hard right now, but it is within his grasp, and he only needs to become a little more skilled, or perhaps acquire an ability that is key for the challenge, and become skilled at it. But eventually, a player will be in full control of the challenge, as riding a bike. And over time, it will become a somewhat relaxing, or boring, activity. So it’s important that to keep players engaged, more difficult challenges must be presented, or alternatively, different ways of accomplishing goals and avoiding having a single solution for resolving them. So if the player does defeat a challenge, it is always possible to increase their mastery by going back and trying to make it better. And this leads us to motivation. Motivation So what drives someone to perform an activity? We can separate motivations into two categories: intrinsic and extrinsic . When someone is intrinsically motivated, he performs the activity because he likes it, it is satisfying, regardless. An extrinsically motivated person, however, will perform for an external reward — praise, fame, an item, an achievement. Because of this, an extrinsically motivated player needs external factors, but on the other hand, an intrinsically motivated player has his own flame of desire to perform a task. This is important to understand because whenever possible, the primary motivations that should be focused on are the intrinsic ones. This leads us to Self-Determination Theory. The theory states that humans have three fundamental needs, as described in its Wikipedia page: Autonomy, or “to be causal agents of one’s own life and act in harmony with one’s integrated self” Competence, or “seek to control the outcome and experience mastery” Relatedness, or “ the universal want to interact, be connected to, and experience caring for others” Directly connected to skill is competence. It is important for the player to feel he can use his mastery and feel he can control the outcome. Designing good difficulty We know that difficulty will derive from the challenge presented and the player’s skill. Skill is a combination of mental and physical effort and capabilities, which culminate in mastery. And players can vary heavily in skill, depending on their previous experiences, motor skills, cognitive capabilities in the game context, etc. But on the other hand, challenge is easier to define and can be designed to require an increasing amount of mastery. What is a good challenge? The problem mostly lays in defining good challenges. Consider these two boss fights: The boss will randomly kill a player every 5 to 10 seconds without any kind of warning The boss will every 10 seconds place a deadly void zone on the player’s feet, that will explode after 3 seconds and kill anyone on top of it The first one is very punishing, and there is nothing the player can do about it, no matter how much skill he has and earns. But if we look at the second boss, we have many elements that provide a great challenge and promote learning: There are cues The player can react to it There is feedback The player can, therefore, increase his skill in dealing with it Consider riding a bicycle. First times, we are clumsy, lose balance, go slowly. Over time, we focus rather more on the environment than the process of riding the bike itself, because we already are familiar with it, we learned the required techniques for each activity, such as pedalling, balancing, braking, turning, and our skill is high. Same with video games. A good activity should be learnable, to such an extent that it can become mostly automatic, so we can focus on reacting to the environment. A good challenge should present cues, allow a reaction and provide feedback, so when the player fails, he will feel that he could have done better. This will foster learning and increase of skill. If we look at any boss fight in World of Warcraft, we can see they are carefully designed to always provide cues, feedback and allow the player to react. All the mechanics are carefully set in the fight to make it possible to accomplish without it being overly frustrating. The goal is always within reach, and practice takes the player closer to defeating it. Difficult raid bosses have a set of abilities, and sometimes phases in the fight, that as they are defeated get the raiding team steps closer to defeating the challenge. This has a potent effect because as players get closer to their goal, tension rises and builds towards a climax. And after hitting the climax, it provides a great deal of satisfaction — even euphoria and shouting, I have witnessed it first hand with my own guild. A challenge doesn’t need to be solved in the first attempts. But there should be a sense of progress. Even in games as difficult as Super Meat Boy, where a player dies multiple times before clearing a level, players remain engaged. There are clear visual cues of the threats, there is a great deal of feedback, and after death, the player character respawns quickly. With each attempt, the player learns what works better. Perhaps timing, or jumping closer or farther from an edge, etc. When Flappy Bird went viral in 2014, players were raging with the difficulty of the game. A quick search reveals a plethora of videos with raging players. And yet, it went viral, and people were relentlessly trying to get better at it. The fact that cues were presented and the player could react means that there is a chance to become skilled. And it is in fact so hard, that just passing a few pipes can be a reason for bragging and a great sense of one’s growing mastery. Artificial vs Designed difficulty We can add difficulty in two ways: artificial or designed. Designed difficulty is when you design a boss with a certain set of abilities, perhaps adding or removing depending if you are doing a raid with 10 or 25 players, or a hard mode. It is difficulty which requires learning new skills or using them in a certain way, as opposed to just performing better with existing ones. Generally speaking, artificial difficulty is about changing stats. Designed difficulty is about introducing or combining different mechanics, which force the player to learn and master specific skills. Examples of artificial difficulty are increasing health, defences, attacks, number of enemy characters or reduce the time limit if it exists. Examples of designed difficulty are the boss getting a new ability, different kinds of enemies joining the fight or requiring coordination with other players. Artificial difficulty is cheap. It’s easier to tweak than designed difficulty. But at the same time, it might feel cheap for the player. If by going hard mode only changes stats, then the player won't get anything new out of it — unless it challenges his assumptions and forces him to be creative or rethink his strategy. For example, a boss that beats much harder and for longer periods might force the players to rotate their survival abilities carefully; and in team efforts, it might even lead them to coordinate survival abilities. To make a point, imagine a game where you have only one single enemy character that appears with increasing amounts of health and attack. Now imagine one where the enemy characters vary in abilities. The first would become boring faster, and the second one has more chances for using skills differently. As with everything, moderation is key. Use both and combine them to present the best challenge for the player. But it’s not just boss fights While boss fights are in many games a point of climax, and therefore usually are taken more seriously when it comes to difficulty, it doesn’t stop there — in fact, it doesn’t even start there. Setting the difficulty starts right from the beginning of the game. As simple as learning movements, learning to jump, use a skill. The initial game experience of the player is crucial to sparking the desire to play and keep playing. In Super Mario Bros, the player starts with an empty scenario and is left with the only option which is to move. Then he is presented with a cube with an interrogation mark, which will likely trigger curiosity and try to interact with it. Soon after, the first NPC appears, he looks angry and moves towards the player — there are signs he is a threat, and the player needs to react to it. If he touches it, Mario will die — feedback — and the player learned he can’t touch them by walking to them — he has to try something else. The most likely step afterwards will be to try to avoid or jump on top of it, as to smash it, and there will be feedback that the player successfully defeated the challenge presented — his skill level now allows him to deal with these type of NPCs successfully. From the start, the player feels he is learning. Wrapping it up When designing good challenges, it is important that the player is able to learn from it and increase his mastery. In order to do that, we should present cues, visual, audio, vibration, etc, that signal the player something is about to happen. This creates an opportunity to react, and eventually prove one’s mastery. And finally, there should be feedback. With each attempt, the player will become more skilled, defeat the challenge and become satisfied. If the player fails, you want to have him feel there was something better he could have done, and not leave him frustrated and helpless. Avoid having single solutions to defeating a challenge and let play sessions vary — this allows the player to get better, as opposed to a static solution. Make it a difficult challenge but within reach. And avoid making it punishing. Conclusion We went through a definition of difficulty, what drives players, and what is an optimal difficulty level that promotes flow. Allowing the player to learn is fundamental, which ultimately drives progress, and gives a sense of competence and autonomy. And in the end, players will want to seek more challenges. So when it comes to difficulty, make it hard, but not punishing. Stay tuned Stay tuned for follow-ups on this series on game design, where I will explore other aspects that help to deliver a great experience to players and create great games. Follow me on Medium If you liked this article, please upvote or leave review or comment to let me and others know you found this useful, I would be very happy and greatly appreciate it. Thanks!
  30. 4 points
    I'm sure this question has been asked before, but in grumpyOldDude's post about growing out of games I kinda felt like talking about the time I've been the most obsessive about a game and am curious to know what you all consider to be the most obsessive you've been about a game. So, what' the most obsessive you've been over a game? for me that title easily goes to counter-strike ~1.3 to 1.6. I bought my first computer to... that's right, play counter-strike. I bought surround sound speakers and built a little hole in my basement to immerse myself in counter-strike. I've lost more hours to counter-strike than probably any other game. And it was hard, I remember when I first started playing I would just die endlessly and maybe get a kill every now and then. I so badly wanted to be like the guys at #1 in a match. Then slowly I got better and better and have my own domination stories I'm still fond of to this day. I lived and breathed cs_italy, that was my map. hahaha
  31. 4 points
    The compiler is just trying to save you from writing buggy code. You need to go out of your way to force your bugs into your software. Your solution does a fine job of doing that. You're implementing an operator that is not closed on the enumeration set. You're breaking the contract provided by enum. When you start getting weird errors, save yourself some debugging time and check where you use the enum first.
  32. 4 points
    Interesting read, though I feel compelled to react to a few items: First and foremost, YOU have to be capable of building the game entirely by yourself. I think that's only partially true, for self-starters. In the event of being able to throw 'some money' at the problem though, I think it is possible for someone with limited skills to lead a project to completion through hiring freelancers or team extensions, even on indie budgets, and without having to resort to the power of USD on other currencies. You absolutely positively MUST have a business plan. While I agree with the business plan, I cannot back the length. A lot of the best business decisions come from reacting or anticipating change, and the business plan is a comfortable fallback than can work against it. You should have the big picture, the product and see value where you're headed, but in the words of Elon Musk, great businesses are built on great products first and foremost. Please, please, please, for the sake of god, have everything meticulously planned out before you begin! Once again here, I can only imagine this being written by someone whose previous work did not specifically involve the same type of organization as video game development. For anyone who comes from a background similar to mine (having produced video games, some of which AAA) I'd advocate the complete opposite: don't dwell in the details, as a manager, your value already comes from being able to address that. Focus on the big picture, not which tradeshow you'll attend, but when it might get relevant. Awareness is a much better problem solver than planning, though both obviously trump over reactivity. When it comes to processes, a tried and true process is the “scientific method”. There's an extent to which experience or 'instinct' might strictly become superior to the scientific method and it happens on split-second decisions. Over the course of a project, the sub-conscious identification of patterns and best case decisions will not be 100% accurate (but the scientific method also leads to errors when certain piece of data were omitted or simply not humanly possibly to acquire) but they'll be much faster. I'm not advocating management on a global scale not built on rigorous principles, but rather a fair tradeoff between taking advantage of your experience in the field vs taking 'the time'. Obviously, for someone new to the scene, that is largely unapplicable, though you'll find that a lot of successful startups' origins are less than noble in rigor. You need money. I partially agree, though there are now new tier publishers who need to make a name for themselves. You'll still need a lot of money to get the game anywhere near a territory they might want to look at it, but as the 'smaller guy', they'll also be prone to taking more risks either because they genuinely want to, or because they seek their own break. This gives you more opportunities than, say, 5 years ago, but very few will get that call, so it shouldn't be your plan, just a nice touch to bring your MVP further along. You HAVE to believe in your experience and abilities. This one I agree fully with. Just needed to put it out there, it's probably the single most valuable item in the entire post. Having unshakable confidence balanced with humility is an art that is innate to no one. I repeat, absolutely NO ONE is born with the natural born talent for doing both. A lot of people have bloated heads, and a lot of people are too humble. Being the perfect mix of both is something that takes forever to learn, and something you can't possibly master perfectly ever. What counts is that you keep trying to reach this state as much as possible and keep it in check (too many business owners 'forget' this balance and go one way or the other and never look back post startup phase). To get an idea on what it takes to make your favorite game, open it up. Then go view the credits screen. Look at all the roles. Count the number of people involved. Then, assume everyone makes $60k a year and it took three years of full time work to produce the game (four if you want to factor out crunch time). This is the amount of time, talent, effort and money required to build your favorite game. Is your scrappy rag tag indie team going to repeat this but do a better job? No. Your scope is too large. I agree with the premise: the scope is always too big. However, I feel the example is lackluster. I've built myself a quite successful business by questioning the current 'Game Credits' standards. I've effectively delivered projects that the industry would've scoped over 1M on less than 50k budgets. The industry is plagued with problems (Logan's Run HR for starters!) that led to their unproductive over-specialization, and the very reason indies get so successful is that there's a lot of value in a holistic vision which AAA development studios are unable to capitalize on. It is frustrating to put together a 100 people team, try to keep the ship afloat and all channels open when Edmund McMillen REPEATEDLY strikes home with his games on a 2 people team. True, some people's ideas sound AAA, but not all of them NEED to be. If you focus the art of MVP, you can distill your unique experience and built something compelling and original but less than 10% of the effort the AAA world feels is mandatory to achieve and may even outsell them if you're particularly good at it and paved your way to success. A lot of people assume that because the scope is too big, the concept is, but that's generally the other way around: you've grafted too much crap to your core idea and should stick with the part that keeps you awake at night and reconsider what supports it instead of fitting a genre. In the 80s/early 90s, genres played much less of a role, and great games got made (arguably, much less forgettable ones too!). There's a reason why we're in an age of sequels and reboots: the current industry isn't fostering a climate that leads to new great IPs, but many indies do, so I feel I need to speak up regarding scope as that's one critical misunderstood step amongst new indies. Nobody knows what they’re talking about. I partially agree in that I don't believe in 'experts' particularly from a marketing standpoint (marketing is always about having that idea no one saw coming, and quite literally, that can come from anyone, at any given time, and is less likely to happen if someone sticks to SEO standard practices, adverts, etc, I mean, just look at that dig a hole campaign: pure genius!). That being said, as far as production goes, there are best practices that make sense, and having someone senior on the team who is aware of the limitations of what they know can make a huge different. Steve Jobs' Next wasn't a pure success on its own, but it was positioned at a level of quality where it was eventually feasibly for Apple to acquire that tech, so striking twice isn't a pure streak of luck. Some people see patterns, not in the sense that there's a guide to making a product, but there are 'pillars' of what should matter, what one should care about, and some people, few people (and fewer openly willing to sell their craft) are actually genuinely interested in helping other projects succeed, and have the ability to 'know what they're talking about'. Be prepared to work a lot. That's the 'all in approach' and it is not the one I would recommend. Downscale your work and get a part-time job. Get contracts if you can, split your time between what you're risking (YOUR game) and what you need to get by (work). Don't stick to a day job, you'll be already tired by the time you get started on your own stuff at the end of the way, and you will get burned by lack of sleep, etc. I know, I've been there myself (even after the 5-1-1, guess what that last 1 was for to begin with, and while we're at it, what was the first 1 for again? That's right, more work). So I can see that as a collection of lessons you're learned in your situation. Most of them are applicable to all, but some of them stem from a very personal situation. It is valuable input, but I think presenting all of it as fact is a bit misleading given not everyone floats the same boat as you did before getting started. You had some very strong suits (your background in dev) and some weaknesses (a bit more of an introvert if I'm not mistaken?) and they show through this. Still, very valuable input nonetheless, and a good reminder of the highs and lows. Given this, has your game failed? And what metric would you use to describe failure? Everything being relative, it would help to have a bit more context into what led to such a 'stop sign' type of post (while others prefer to profess unlimited motivational posts which will quite unnecessarily lead to a bunch of entrepreneurs making bad decisions while pursuing 'dreams'). Hope you're well despite the fall!
  33. 4 points
    Inheritance is hardly important as a linguistic construct. The Epoch language for example has no notion of inheritance, and deliberately so. If you can do composition and polymorphism, you can eliminate inheritance as a feature entirely. I don't know the specifics of your language implementation, obviously, but I'd venture to guess that getting those two things working is either already done or easy to do.
  34. 4 points
    Hi, Been a while since I took the time to write a proper entry, even more so in this journal (The Week of Awesome III was a summer 2015 gamejam entry after all). But today is different.... After building up my own freelancing business for a decade now, I'm more than happy to report than I've spent the last few months doing it fulltime, which is a lifetime achievement for me, and something I've been contemplating / building for a long time now. But this entry is not about how great life is on the 'other side', but rather, about a very specific project. A New "Death is Useful" In 2015, I made an entry in the 'Week of Awesome' GameJam hosted here at Gamedev.net titled "Death is Useful" (which was also the theme of the competition). It wasn't my best entry as far as results go (I actually managed to score 4th position on both Week of Awesome II and IV) but I felt it was the one with the most potential to scale into an interesting game. Some time ago, I even revisited the title with the intent of researching the 'new' and 'improved' WebGL exporter now bundled with Unity3D. Suffice it to say that, back then, I was anything but impressed with the results (as can be read in my previous posts). I chose to let the project to rest and resumed work on a variety of other exciting ideas (some of which you'll be hearing about soon-ish). The WebGL Exporter Strikes Back (if you're not tech-savvy, you may freely skip ahead!) By mid 2017, I was put in touch with the reps over at Unity through a client and ended up doing some R&D with the actual WebGL exporter and it had come a long way since I had last used it. So, little by little (working fulltime as a freelancer leaves very little spare time for passion projects) I ventured a bit deeper with the exporter, to see how I could polish & optimize the results. I think a word on the state of HTML5 is in order here, as one might be wondering why anyone would even bother using WebGL to begin with: I don't think there's 'one single truth', but I've been involved with a sufficient amount of projects through a relatively large client sample to know that, right now, HTML5 is 'popular', but it does not deliver. The reality is that there are few efficient engines to work from, meaning most projects end up being made up from scratch, or from a new unknown tech, making development very slow and costly. The problem is that HTML5 was meant to be the 'Flash killer', and as far as I can see and hear, it's simply not 'as fast' and 'as cheap' as making Flash games yet. I've been working with a lot of businesses that have tried and failed to make HTML5 a truly viable alternative, and so far, I'm unimpressed by everything I've seen. I would not consider WebGL a true contender here either, had it not been from the fact that it was Unity's fallback solution to having the Unity Web Player blocked on major browsers (primarily Chrome), nor would I even consider it an alternative had it still been in the state I 'found' it in a few years back, but clearly, things have changed. As developing in Unity (an established engine) is very fast, I was hoping to gauge how much time I'd need to invest in optimization and troubleshooting to make it work. Turns out that's roughly 10%, which given the alternative (HTML5 would've probably taken 2-3 times the amount of time it took to make the game in Unity, once again based on similar documented projects) is fairly cheap. Let's face it, there are a lot of people out there wanting to make their digital presence felt (I'm thinking about industry giants such as Disney, Warner, etc.) and HTML5 is making a serious dent in their marketing budget to achieve these results, so I was somehow hoping that the WebGL exporter would be an 'easy sale' but needed one or more proofs of concept. Death is Useful was going to be 'it'. The Return of Kongregate Another 'question' I've been asking myself steadily over the past few years is whether the so-called death of web games was real. With the relative decay of Flash, I felt a lot of people had assumed this meant the end of web portals, and for the most part, I think this is somewhat accurate, and the short-lived Unity Web Player didn't really endure. Players have come to expect a certain level of quality in their web games, which HTML5 couldn't really do on a budget, so in theory, that death was inevitable. On the other hand, some few key accounts from local and remote indie developers with whom I'm acquainted tested that theory. For obvious reasons, I'm not going to name names here, but the thought of turning up a profit of more than $ 8000 USD per quarter is certainly not something you'd expect from a 'dead' market. I understand a lot of developers couldn't justify a tech pipeline geared at web development for 'so little', but for the smaller teams, that's a very enticing offer. Though most of these revenue figures game exclusively from incentivized ads (ads that are tied directly with in-game rewards), I was curious about the demographics of the web games world in general and wasn't going to be very specific. Kongregate was a platform of choice for this 'test', as I've been a member since 2010 (and a lurker for much longer) and also participated to the release of a CCG that became #1 at some point (even though it was merely a port from a different platform). Suffice it to say I was well acquainted with the platform and knew the opportunities there. Kongregate was unique in that it provided a very healthy ecosystem for players with some metagame implications. All I needed was a project to test this platform, and it soon became obvious that Death is Useful was a perfect opportunity. Testing both a market and a technology at once may be risky, but I wasn't bound to any deadline, so it made sense. The Red Cell Awakens Death is Useful became 'Red Cell', rebranded after the decisively retro visuals and audio. I was born a bit too late to really experience the Atari and early Commodore days and always had a fascination for that era. I wanted to rebuild the game as something that would've fit a late 70s / early 80s arcade without limiting myself to the technology that existed then. The game concept was perfect for this, but the original perspective was fundamentally flawed as it was a 3D game. Besides, it wasn't really making great use of that 3rd dimension, so the switch was all the more valid. It took some heavylifting to reuse what had already been done (quite honestly, I should've gone full tabula rasa mode) but it helped me appreciate the kind of legacy code game-jams can generate. I wanted to give the game a 'Super-Hexagon' feel, as something that's infinitely replayable and simple to grasp, where most games take but a few minutes to play. Super Hexagon had opted for longevity through more patterns, faster game speed, etc. Given I'm an avid speedrun fan (and have some reasonable PBs on some of the retro titles) I wanted to make a game that was finite in nature, but one where you could beat your own score repeatedly. Kongregate was a great platform for this as they have a built-in score API which took some getting used to but was relatively easy to implement. Once I landed the 'best the game as quickly as possible' score idea, I felt I should also give other players an incentive to play, and added a few more score options (most mobs killed in a game, most mobs killed all time, etc.) Kongregate has something called Badges, which are achievements you can earn in games that give you a boost in the Kongregate user metagame. Unfortunately, developers can't make achievements, they can only expose scores and hope the editor picks the game up and implements 1-3 achievements based on the scores already implemented. So having more scores (some of them invisible!) was my tactic for trying to get the editor's seal of awesomeness, and the potential traffic that goes along with. I've developed the game on and off in my spare time for the past 2 months (alongside many other personal projects) and completed dev about 2 weeks ago. Given Kongregate has monthly contests, I figured I'd wait until the new month, and what better day than the one right before July 4th to release? (arguably, that release is very random, and I'm not quite sure how July 4 will play into monthly traffic). The Last Build All of this just to say the game was released today. It's not the most amazing thing on earth, but it is a fun minigame that has some potential (as far as web games go). It's also a business test I'm making on two different fronts (Platform & Technology) which, in itself, has a lot of value. As a result, I didn't see fit to make In-App Purchases, and chose to distribute the game for free (as in FREE free). I might get some minor revenues through conventional ads, which won't pay back for the time invested, and that's quite alright. I'm just glad it's finally out and people get to see it. The game is currently open to more development. I had a local 1v1 and coop 2 player game modes which I've disabled right before release. They work, but I feel they should have a few more features before being worthy of the game (chance to revive your friend when he dies in-game, etc.) I have ideas, but limited time, and quite honestly, I'm waiting to see whether the game gets any traction before investing more time into it. If you care to give it a try, here it is: - Game Link - Cheers!
  35. 4 points
    Yes. Don't understand what you are saying there, but in my opinion, you should use the GUI git tools for basic things like pushing and pulling and git shell/command line for more advanced things.
  36. 4 points
    Yes, it's realistic. If your plan is to just make games right now, you should use Unity or Unreal or any other existing technology. These will help you achieve your goal of making games and will simplify things so that you can just focus on your game logic. Of course you can always start from scratch if you want to know how things behind it work, but it's not recommended for a beginner as it can be frustrating and can burn you out.
  37. 4 points
    It depends on how you define "indie". Back in the day, we used to call the serious-hobbyist types "garage developers" -- dedicated enough to set up a work space in their garage, but not serious enough to actually be throwing enough money at their hobby to turn it into a business. Most "indies" fall into this category -- hobbyists. You should not expect to make (much) money from any hobby. You can sell your macrame and quilts at the local maker's market too, but it's not going to pay for 100% of your living expenses. IMHO that's an abuse of the word -- hobbyists are not "indies", they're hobbyists! If you define "indies" as small self-owned businesses though, then sure, plenty do succeed. I know plenty of indie studios in my town who reliably get every one of their games onto a Google Play and and iTunes "featured" slot, and into the top 10 charts, which gets them enough downloads to earn an income good enough to pay for a handful of full-time staff members. They do this by choosing to run a business professionally, not just make games as a hobby. This unfortunately requires money (capital) -- this is the way the world works for ANY business, you need seed capital to make more capital. There's also no reason to go it alone with the $132 in your bank account. Lots of cities have booming 'startup' scenes. You can go to silicon valley and come back with a million dollars (and a lot of contractual obligations) pretty easily, assuming you're taking your job seriously. Or even just getting a business loan from a bank (assuming you've got a serious business plan). Or applying for government (local/state/federal) grants and subsidies. Or just taking your business plan to friends and family and begging for startup capital... but again, this is what separates the business people from the hobbyists. If you want to make games as a hobby, accept that it's a hobby. If you want to make games as a self-owned business, accept that you're now an entrepreneur with a start-up business, not a game developer.
  38. 4 points
    Don't use strings. Use ID numbers instead. If you need to look up the string name of an item from its ID number, just index into a List<Item> using that ID, and pull the string off the Item itself - this is a constant time O(1) lookup instead of a hashmap lookup and string compare. If you want to go from string to ID, store a secondary dictionary, but be disciplined about moving to ID numbers as soon as practical in code, so you do fewer string operations. This is pretty much how the Guild Wars 2 item data works, for example.
  39. 4 points
    https://sitavriend.wordpress.com/2017/05/22/players-emotions/ This topic will probably be one of the more ambitious topics I will write about for a number of reasons. First of all emotions are not a just about feeling excited about playing that new game you bought today or feeling sad because your favorite character in game of thrones just got killed. It’s very closely related to longer lasting moods. Secondly, psychologists aren’t completely sure on how to explain human emotions. There are a number of different theories that explains what happens when we experience an emotion and many of them are support by scientific studies. I’m not going into those theories because I don’t think they are relevant to this article. There is a link to a crash course video in the references below just in case you’d like to know about emotions in general. So what is an emotion? And more importantly, why should you take them into account when you design and develop games? Emotions are a bit ambiguous, even psychologists can’t agree on a unified definition. One of the definitions I found: an emotion is an internal response to an event. Something within your body might change when you experience an emotion, for example, your heart rate can increase or decrease. Some other psychologists might say an emotion is more like a feeling or mood. From these definitions it feels as if emotions aren’t very tangible and difficult to study. However, specific emotions and moods can be very useful when designing games. Taking emotions into account when designing games can definitely help you to enhance the player’s experience. And although emotion is an ambitious and broad topic, it also means there are countless ways you can apply it in your game design. Russel’s dimensional model of affect Just like there are multiple theories of emotions, there are several models to classify them. I will keep to one: the picture below is Russell’s model of affect (Russell, 1980). This is a two dimensional model in which emotions are classified based on how active (level of arousal) and pleasant (positive or negative) an emotion is. Many action games use the model to some extent. You feel your heart pounding in your chest, your arousal is up, feel stressed and tense as you approach the enemy camp. On Russell’s model this would be high arousal and a sort of negative emotion. Now the important question: Why should you apply all this to your game? Here are a number of reasons: Emotions can help form memories so players remember your game in more detail (LeDoux & Doyere, 2011). This enhances the player’s experience, making it richer and feel more personal. Allowing your players to experience a positive mood can help them solve the puzzles and riddles in your game (Isesn & Daubman, 1987). Arousal in general can be quite useful as well. When you want something important to be noticed by the player, make it more arousing to grab their attention (Buodo & Sarlo, 2002). Arousal can also boost the player’s performance. According to the Yerkes-Dodson law (Yerkes & Dodson, 1908) easy tasks can benefit from high arousal while difficult tasks are handled best when the player’s arousal level is low. You can use this law to adjust the difficulty curve of your game accordingly. Keeping your player in a positive mood will motivate them and make them try harder (Nadler, 2010). Basically you can keep increasing the difficulty curve of your game as long as the player is in a good mood. More specific emotions can also be beneficial as well. Anger, for example, motivates players for confront a problem or pursue a goal. On the other hand, players who feel guilty about an action they did can be motivated by their guilt to do good and counteract what they have done (Parrott, 2004). Even negative emotion, such frustration can improve your game. It can motivate your player when done right. Remember when you fought an end-boss in a game but lost? What did you do? Did you quit the game or did you go back to the last save and try again? Most games have a difficulty curve of some form to keep players challenged and when the curve is just right, you will occasionally loose and have to try again. This trial-and-error will come with a bit of frustration but quickly changes to excitement and motivates to try again. Frustration in these situations only become a problem when the difficulty curve is too steep and the player gets stuck somewhere in your game. It that case they might even quit all together which is not very good for your retention. Of course there should also be a moment of joy when the player finally overcomes an obstacle to make all the effort feel rewarding. Be careful with too much frustration and confusion though. It’s never good when your players become frustrated because they can’t figure out how the controls work, how to read the UI of your game or don’t know what to do. Obviously you need to address this kind of frustration and figure out how to minimize it. Unfortunately, it’s not always possible to get rid of the bad kind of frustration in your game for all players. Not all players are the same and for some the difficulty curve might be a little on the steep side. While others will always be a bit frustrated about your UI. In those cases you can benefit from the Halo effect (Nisbett & Wilson, 1977): certain salient characteristics bias the perception of other less salient characteristics. It’s not about getting rid of frustration all together, make desired emotions stand out more and the player will focus on them more. You can apply the knowledge about emotions in your game design regardless of the genre, however, I’d like to show you some examples for narrative and puzzle games. Puzzle games are all about frustration, confusion and joy. The halo effect is at work here: the joy of the eureka moment when the player completes a puzzle is much more salient than the frustration and confusion from the trail-and-error. Puzzle games are a great example of the good kind of frustration as I talked about before. A great example of a puzzle game that uses the good kind of confusion and frustration is Anti-chamber. The player is told very little when they start the game, basically it’s the game to figure out the game (game-ception!). it’s can be great example if you want to make a puzzle game without a tutorial that takes the player by the hand each step of the way. Antichamber: all you need to know Narrative games probably are the best type of games to evoke emotions in players. When done right, your player will have a memorable experience of an emotional journey. As I talked about before emotions help form memories. There is nothing better than remembering the joy you felt when you helped your character do something amazing. Narrative games can allow players to really empathize with characters when something truly sad happens. My favorite example for such a game is Thomas was alone, one of my favorite games of all time. The emotional narration makes it such a memorable journey. The designers did a great job expressing a full range of passive emotions such as sadness, happiness and serenity. Everything within the design of the game supports these emotions: the choice of the abstract art style, music and the way it is narrated. I’ve never felt so much empathy towards any video game character as I did for Thomas and his friends (and they are just colored squares!). Thomas was alone: squares with a personality! Some tips and examples for you Now how could you implement all this knowledge into your game or narrative design? It seems like a lot of stuff to take into account but it all depends on your game. A good place to start is to identify the overall feeling or mood you want the player to get when they play your game. Ask yourself: how should the player feel after each session? And what about when they finish your game? Maybe your game has some key-events where you want the player to feel a certain way. Of course your game design document describes how players should interact with your game but why not add a section on how they should feel when they do it? PANAS example Playtesting is where you find out if players experience your intended emotions. Set your playtests up in such a way that you can either see or film the play-tester’s face directly. The decode all the different emotions you can use the coding system for facial emotions (FACS) developed by Ekman and Friesen (1978). Even better would be to use software to decode even the subtlest emotions for you. There is a huge range of apps, software and even APIs and SDKs to use such as EmoVu (http://emovu.com/e/). When you don’t have the money for these tools, time to get familiar with FACS or you want to be more thorough with your playtests, you can use PANAS (Watson, Clark, Tellegen, 1988). PANAS is a questionnaire where your play-testers answer questions on how much they experience a certain emotion. The picture at the right is a good example of what a PANAS questionnaire can look like. With PANAS you can find out what overall emotions the player experienced during the game or during key-events in your game. It will be a bit time-consuming to set up but once you’ve created one you can use it for all future games. There is a link to a PANAS worksheet in the references below to help you get started. Some useful links and references Crash Course Psychology: https://www.youtube.com/watch?v=4KbSRXP0wik&list=PL8dPuuaLjXtOPRKzVLY0jJY-uHOH9KVU6&index=26 Worksheet PANAS questionnaire: http://booksite.elsevier.com/9780123745170/Chapter%203/Chapter_3_Worksheet_3.1.pdf LeDoux, J.E. & Doyere, V (2011). Emotional memory processing: Synaptic connectivity. In S. Nalantian, P.M. Matthews, & J.L. McClelland (eds), The Memory Process: Neuroscientific and humanistic perspectives (pp. 153-171). Cambridge, MA: MIT Press. Yerkes R. M. & Dodson, J. D. (1908). The Relation of strength of a stimulus to rapidity of habit-formation. Journal of Comparative Neurology and Psychology, 18, 459-482. Parrott, W. G. (2004). The nature of emotion. In M. B. Brewer & M. Hewstone (eds), Emotion and Motivation (pp. 5-20). Malden, MA: Blackwell Publishing. Posner, J., Russell, J. A., & Peterson, B. S. (2005). The circumplex model of affect: An integrative approach to affective neuroscience, cognitive development, and psychopathology.Development and Psychopathology, 17(3), 715–734. http://doi.org/10.1017/S0954579405050340 Isen, A. M., Daubman, K. A., & Nowicki, G. P. (1987). Positive affect facilitates creative problem solving.Journal of personality and social psychology, 52(6), 1122. Buodo, G., Sarlo, M., & Palomba, D. (2002). Attentional resources measured by reaction times highlight differences within pleasant and unpleasant, high arousing stimuli.Motivation and Emotion, 26(2), 123-138. Nisbett, R. E., & Wilson, T. D. (1977). The halo effect: Evidence for unconscious alteration of judgments.Journal of personality and social psychology, 35(4), 250. Nadler, R. T., Rabi, R., & Minda, J. P. (2010). Better mood and better performance learning rule-described categories is enhanced by positive mood.Psychological Science, 21(12), 1770-1776.
  40. 4 points
    Learning programming typically goes a lot better if you are learning it to fulfill a secondary goal. That secondary goal may well pick your language/framework for you. Is she interested in robotics? Maybe look at something like Lego Mindstorms to start, and then move to Arduino later on. Is she interested in game development? Dive right in with Unity, so that you minimise the time-to-seeing-stuff-happen-on-screen barrier. And so on...
  41. 4 points
    I gave this talk yesterday evening at a VR meetup in Bellevue, Washington. It starts at about 3:00 min and runs for about 50 minutes. I've also included my powerpoint slide deck in case anyone is interested in downloading it and following along. Virtual_Reality_Design_Secrets.pptx
  42. 4 points
    https://sitavriend.wordpress.com/2017/05/15/reactance-theory/ You can make something more desirable by forbidding it. That something can be anything: an item, an action, an idea. Well this is possible and known as the reactance theory. Reactance is the feeling you get when someone limits your freedom or option. Basically when you’re not allowed to do something or when you are told you have to do something. This feeling results in you: 1. Wanting forbidden option even more. 2. Trying to reclaim your lost option. 3. Experiencing aggressive and angry feelings towards the person (this person may be fictional as well, or and AI) who limited your options or freedom in the first place. (These feelings can be very subtle and barely noticeable but motivate you to do the opposite from what you have been told to do.) The first scientist to talk about the idea reactance was Brehm in a theory of psychological reactance. He was the first to research the reactance theory and explains reactance as a motivational state people experience when their freedom is removed or threatened (1966). But you probably already know the reactance theory as reverse psychology. And that’s what reactance basically comes down to: Getting people to do something by telling them they are not allowed to do that something or the other way around. Unfortunately, it doesn’t always work. Some people are just not as sensitive to experience reactance as others and circumstances matter too. For instance: reactance breaks down when people can rationalize why they shouldn’t do something. If someone told you not to buy the bag you really wanted, you’d probably buy the bag anyway. But if that someone explained that he bought the same bag and it broke after 2 days, you’d probably think twice before buying the bag. Portal 2 applies the idea of reactance brilliantly in their level design when the player enters Aperture’s dungeons. Along the way back up, the player encounters several warning messages as you can see in the picture below: “warning”, “do not enter”. Of course these warnings are not to discourage the player, they are meant to lore the player closer. Reactance helps the storyline feel less linear than it actually is. Player is more attracted to this option and goes on to explore it. It also guides the player through the level more naturally because they want to explore this forbidden option rather than going somewhere else. You probably want to know what’s behind those walls The Stanley parable applied the reactance theory to their gameplay using narrative. The player is encouraged to try all storylines since the end is never the end in the game. In fact, the game is all about discovering new endings and alternative storylines and that means you don’t want listen to the narrator most of the time. The blue door ending is a great example of this: The narrator tells Stanley to walk through the red door when the player approaches a room with a red and blue door. When you ignore the narrator and walk through the blue door, he’ll send the player back and tells Stanley to walk through the red door again. The blue door becomes a more attractive option now, so the player choices the blue door again. The player will be send back to choose the red door again but this time the blue door is moved behind the player and the narrator stresses Stanley he has to walk through the red door. The blue door has never been a more attractive option. Such an attractive blue door! Look at those curves! The reactance theory can easily be applied to your own games. It can help you design interesting levels or create interesting narrative for games that rely on (branching) narration. When you want to implement the idea of reactance into your own game you can make something more desirable by forbidding it or you can make something less attractive by forcing it. This something can be anything: an item, a choice you want the player to make, a path the player should walk, an action you want the player to perform. Be creative! Keep in mind that not everybody is equally sensitive to reactance and that the effect breaks down when the player can rationalize why they shouldn’t do something. Here are some ideas for you. Level design: – Use some art! Show something is dangerous or advise the player not to go there with signs or writing on the walls. Doesn’t have to be art-heavy, just tell them a certain area is closed off and that they are not allowed to enter. Narration games: – Somewhere in the narrative you can tell the player they are not allowed to make a certain choice (remember: don’t explain why). You can also “force” players to make a certain decision like the red door in the Stanley parable. – Empower the player by telling them they aren’t good enough to do something, they will do it. – Tell the player that he/she has to do something a certain way, they will do the opposite. Items: – Tell your player is a forbidden item and they shouldn’t take it. Want to read more (scientific) stuff on the reactance theory? Brehm, J. W. (1966). A theory of psychological reactance. London: Academic Press. Jack W. Brehm (1989) ,”Psychological Reactance: Theory and Applications”, in NA – Advances in Consumer Research Volume 16, eds. Thomas K. Srull, Provo, UT : Association for Consumer Research, Pages: 72-75. https://books.google.nl/books?hl=nl&lr=&id=gd4iAQAAQBAJ&oi=fnd&pg=PT317&dq=reactance+proneness&ots=RSjeInAUj2&sig=xBekeKqXAkdk5JPYckJvlgZkDdQ#v=onepage&q&f=false
  43. 4 points
    'What' qualifies as an expression vs a statement actually varies across different languages. In some languages the distinction is that expressions evaluate to a value while statements do not. In some languages expressions are just a certain type of statement which happen to return values. In some languages everything is an expression because everything has some kind of a value. For what it's worth you can go a long, long way without ever needing to know the difference between statements and expressions. This is not something most programmers need to think about day-to-day. It's more a concern for compiler authors and language designers and not really something programmers are required to know in order to actually 'use' the language. You mentioned C# though so the rest of my answer is more towards the C# way of thinking... An expression is one or more 'operands' strung together with 'operators'. Operands include things like literal values, variables and function calls and operators are things like +, -, /, *, &&, ||, etc. An expression can consequently be evaluated to a value. E.g. 1 + x * y - func(10) Meanwhile a statement is like an "action" or "instruction" to the computer. E.g. "Declare a variable", "Call this function", "compare this value", "loop over an array", etc. Statements include things like declaring a variable, control-flow statements (if/for/do/while/return/continue/break/etc), declarations of types and methods, etc. Statements as a whole are very often constructed out of expressions. Such as when you declare a variable and initialize it with the value of some expression all one one line: int x = 10 + 2;
  44. 4 points
    It is absolutely true that exploits will always exist in some form. What is also true, and moderately less depressing, is that you can invest a bounded amount of effort to make the vast majority of exploits not worth it. In other words, you can ignore some exploits that just aren't a big deal, in exchange for defending against the ones that are a big deal. This is important from a cost/benefit perspective. If you get hung up on blocking every possible exploit, you'll exhaust your resources (and yourself) sooner or later. But if you let some things slide so you can focus on the important hacks, you can spare yourself a lot of work and preserve some sanity.
  45. 4 points
    The attacker fully controls the computer that the game client is running on. Just consider what someone can do with a virtual machine with full suspend/rewind/resume support, and you'll realize you cannot "lock up" the client. The attacker can decompile whatever code is being run on the client, as the client is run it, no matter how much you obfuscate or encrypt the code. Such measures simply don't matter to a determined attacker, because the code needs to be actually runnable by the CPU, and anyone with the right tools can take that instruction stream and disassemble it. Similarly, the attacker can look at all the data you send and receive on the network. It doesn't matter if you use HTTPS or some other kind of encryption, because the attacker can inject themselves in your network code before the encryption is applied. You have four options here: Decide that it doesn't matter if someone is cheating. For games that are largely puzzle games or other single-player experiences, a cheater would mainly just cheat himself. Does that matter at all? Build your system such that the interface to the server is the "game rules," and the data from the client is simply an expression of the players' desires. If the player desires to go left, send a "player goes left" command, and let the server figure it out. If the player wants to fire a weapon at 33 degrees, send that as a command. Do not use any messages that express specific state or events -- don't say "I now have 1000 gold" or "I hit player 3 for 89 damage." For fast-paced games, this will introduce latency, which you will have to manage by some time-traveling smarts in the game client and perhaps on the server. (All of the "multiplayer game models" write-ups you see online basically revolve around the different ways of doing this.) Decide that your game is not going to be particularly popular, and thus cheaters will not likely discover your game, and if they do, they will not be likely to actually want to spend a lot of effort on it. Research all the cheating tools, and keep a constant watch out on various user forums for your game, looking for exploits. Patch each of them as you find them. Study the cheating software in detail, and come up with a mitigation that works for each of them. Keep working on this, every day, for as long as your game is alive. Which one you choose is up to you.
  46. 4 points
    If you haven't measured your actual code with a profiler, now is the time to start. Blindly optimizing everything you can grab is a sure-fire recipe for spending a lot of time and being disappointed in the results. If you know what is slow about your code, you can make an informed decision about whether or not reading from an archive is going to make a significant difference in your situation. Engineering is a discipline. Don't give it short shrift by merely hacking at your load times.
  47. 4 points
    Ideally shaders would always be precompiled. Shaders are pre-compiled for a particular target / shader model -- e.g. SM5 shaders for FEATURE_LEVEL_11. If you try to load these on FEATURE_LEVEL_10, they won't work... So, you have to precompile your shaders once for each target that you wish to support. e.g. if you want to support D3D10, D3D10.1 and D3D11 hardware, then compile your shaders for SM4, SM4.1 and SM5, and then load the correct set of precompiled shaders at runtime.
  48. 4 points
    Maybe you're just playing wrong games
  49. 4 points
    Extending a standard library container class is almost always the wrong approach. There are very few things in the standard library designed for extension, and those are clearly indicated. It is possible to extend some of them, but it usually comes with unexpected ramifications. Your desire to mix smart pointers and raw pointers, as well as trying to describe what can be copied all reek of a common problem. Controlling the lifetime of objects is a critical aspect of software, especially true in games. What you describe sounds like a symptom of not understanding what code owns the lifetime. What is the REAL problem you are trying to solve here? You came up with a solution of trying to do complex things with a vector, but what problem drove you to that solution?
  50. 4 points
    Ellipses catch is very useful when you want to do some cleanup and rethrow.