text:
Download the Game Design and Indie Game Marketing Freebook 07/19/17GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game's design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Content count
Content count
Content count
Content count
Popular Content
Showing content with the highest reputation since 06/28/17 in all areas
13 pointsThis 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.
9 pointsSo, 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.
7 pointsYou'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.
7 pointsI 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.
7 pointsSo 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 pointsI 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. Check out his work at Incubator Games.
6 pointsIn 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.
6 pointsI'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.
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
6 pointsOne 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.
5 pointsIt 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.
5 pointsYou 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)
5 pointsHashes, 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.
5 pointsSo, 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.
5 pointsAll 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_.
5 pointsOoh 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:
5 pointsBoth. 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.
5 pointsSince 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
5 pointsIt 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!
5 pointsIn 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.
5 pointsThe 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.
4 pointsI've been developing on Microsoft Windows for a long time, since around 1992/93, when I got my first PC. Various other platforms before that, but I've pretty much stayed with it, not because it is a technical marvel (it's not), but based on the idea that it was the most popular OS so it should be easy to get programs running on other people's machines. Coupled with this (and no doubt because of this) there is also loads of good software for development, which had made it the 'default' choice for me. Don't get me wrong, I have certainly admired certain aspects of the various Apple OSes over the years (especially when they embraced BSD), but been put off by having to relearn the 'backwards' way of doing everything, and rightly or wrongly the suspicion of a 'control freak' walled garden approach, where you are not in control of the computer, Apple are. And don't get me started on my experiences of having to use iTunes to do something as simple as transfer a file over usb from a Mac to an i-something. And the obvious bias towards monetizing every aspect of the experience. In contrast I sometimes feel that Windows is *overly* open, exposing too much to developers, allowing them to too easily 'hijack' your PC and take over its resources for their own purposes at startup, as well as a series of insecure 'technologies' that seem more appropriate for malware authors than legit developers. It seems to be designed so that the OS will run slower and slower the more apps you install, until you give up and re-install windows. Along this line comes the other unpleasant thing I found with windows, that a lot of the software would rely on some other flavour of the month technology being installed as a dependency. Want to use a text editor? No, first you needed to spend half a day installing the latest huge bloated .NET runtime, to find it probably breaks some other app. And for something that is meant to be backward compatible, certain software companies (particularly Microsoft themself) seem to go above and beyond the call of duty in making their software incompatible with anything but the latest builds of the OS. And so we come to my personal last straw .. I spent some time last year evaluating different IDEs, and preparing projects, converting code etc, until I finally settled on using Visual Studio 2017, which was in the final release candidate stages at the time. The first version worked great until it expired. Then I tried the updater, which failed miserably at installing the next version, so I had to manually tweak things until it installed. Finally I came back from holiday 3 weeks ago to find that the 'final final' RC candidate had expired, and I was required to install the release version. Unfortunately I found the installer refused to work on my system. During the time between the RC and the release, they managed to screw up the installer (of all things??). So I was left unable to do any work until I had it resolved. I spent several days backing up my PC and trying to update it, but even with the windows updates no joy with the installer. I resigned myself that I had a choice of either buying a new hard disk and installing windows 10, or buying a new PC. Given I didn't want to risk losing my old work, I went for a new PC, even though my old one was perfectly adequate. £650 or so later I had ordered a fanless kaby lake system. During the order I had the choice of OS to put on it. I had originally planned to put Windows on it, but thought what the hell, I should have another play with Linux, as one of the options was Linux Mint, and I could be sure the hardware would all work, so it should be easy. While I waited a few days for the build, I did some research into Windows 10. Unfortunately I became more and more disillusioned the more I read. While I'm sure technically the OS has got better over the years, I've heard only disturbing things (from 'the register' etc) about the roadmap Microsoft is taking with Windows. One of the things I hate about Windows is the need for updates, and the way you are left to pray during the process that they don't break some other bit of software. So usually I turn automatic updates off, and carefully manually select any if they are really required. Not so with Windows 10! As (allegedly) the 'last' version of windows, it will now automatically update itself, forever, whether you like it or not. That's nice to know that if you are a business, you have the very real possibility of waking up one morning to find Microsoft have borked your work and there's absolutely nothing you can do about it. This is clearly a showstopper for many people, for instance having a meeting to show clients the next day and finding your PC has been remotely broken by some well meaning folks who I'm sure have your best interests at heart and not theirs. But it doesn't end there, no now the operating system is designed to take your personal info, searches, work etc etc and send it (without your permission) to Microsoft central command mothership. Simple, you turn it off, you would think, except that, apparently, it seems you can't turn it off. So you think you will block the MS servers in your firewall etc. No dice, as the OS apparently ignores these rules because slurping your private data is too important. And even if you think you've worked a way round this, you only have to leave the PC till the next morning, for the next AUTOMATIC update to circumvent your attempt to circumvent the data slurping. Honestly, there must be laws against this kind of thing. All this made me realise I had to seriously think about moving off windows as a development platform in the longterm, and that time may just be NOW! Several of my old dev colleagues had by now moved to other platforms, notably a lot have moved to Apple. I admit I have an irrational phobia of all Apple products, so the only choice for me was to investigate Linux. I only had some *very* basic grounding in unix (having done some pascal on unix machines at Uni), and having played with linux on my Asus EEE netbook many moons ago. So my experiences, in the next blog post, should be useful for anyone who is an absolute beginner like me. Suffice to say, it has been a very difficult slog learning the basics and converting my code, but I have *finally* got my libraries and game code working, and I am now a convert. The whole Linux experience seems light years ahead of windows. I may still end up having to install windows in a VirtualBox machine, but I haven't had a need as yet. Next blog post will be my migration experience...
4 pointsIf an object needs a reference to the TextureManager to do its job, then give the object a reference to the texture manager. You can pass it in when the object is created. Better still, have the object grab these textures ahead of time, so that when the collision happens, it already has them ready for the change, without needing access to the TextureManager.
4 pointshttp://www.tinker-entertainment.com/sitavriend/psychology-and-games/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
4 pointshttp://www.tinker-entertainment.com/sitavriend/psychology-and-games/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.
4 pointsHi, community. I am writing a series of articles about Lighting related with real-time computer graphics. The purpose is to get information from a lot of great resources like computer graphics books, blogs, and forums, and try to explain them as easy and clear as I can. I am going to update the list periodically. Lighting Series The first post in the list is the following Lighting Series Part 1 - Light and Radiometry Update (2017.07.05) Lighting Series Part 2 - Radiant Energy and Radiant Power Update (2017.07.16) Lighting Series Part 3 - Radiance Update (2017.07.25) Lighting Series Part 4 - Irradiance All suggestions for improvements, corrections, and new topics, are very welcome because in this way I am going to learn a lot and, and why not, maybe this helps anybody with the same doubts than me. Hope you find this useful!
4 pointsBelow is my preliminary draft design for the AI system within Spellbound. I'm slowly migrating away from scripted expert systems towards a more dynamic and fluid AI system based on machine learning and neural networks. I may be crazy to attempt this, but I find this topic fascinating. I ended up having a mild existential crisis as a result of this. Let me know what you think or if I'm missing something. Artificial Intelligence: Objectives: Spellbound is going to be a large open world with many different types of characters, each with different motives and behaviors. We want this open world to feel alive, as if the characters within the world are inhabitants. If we went with pre-scripted behavioral patterns, the characters would be unable to learn and adapt to changes in their environment. It would also be very labor intensive to write specific AI routines for each character. Ideally, we just give every character a self-adapting brain and let them loose to figure out the rest for themselves. Core Premise: (very dense, take a minute to soak this in) Intelligence is not a fixed intrinsic property of creatures. Intelligence is an emergent property which results directly from the neural topology of a biological brain. True sentience can be created if the neural topology of an intelligent being is replicated with data structures and the correct intelligence model. If intelligence is an emergent property, and emergent properties are simple rule sets working together, then creating intelligence is a matter of discovering the simple rule sets. Design: Each character has its own individual Artificial Neural Network (ANN). This is a weighted graph which uses reinforcement learning. Throughout the character's lifespan, the graph will become more weighted towards rewarding actions and away from displeasurable ones. Any time an action causes a displeasure to go away or brings a pleasure, that neural pathway will be reinforced. If a neural pathway has not been used in a long time, we reduce its weight. Over time, the creature will learn. A SIMPLE ANN is just a single cluster of connected neurons. Each neuron is a "node" which is connected to nearby neurons. Each neuron receives inputs and generates outputs. The neural outputs always fire and activate a connected neuron. When a neuron receives enough inputs, it itself fires and activates downstream neurons. So, a SIMPLE ANN receives input and generates outputs which are a reaction to the inputs. At the end of neural cycle, we have to give response feedback to the ANN. If the neural response was positive, we strengthen the neural pathway by increasing the neural connection weights. If the response was negative, we decrease the weights of the pathway. With enough trial runs, we will find the neural pathway for the given inputs which creates the most positive outcome. The SIMPLE ANN can be considered a single cluster. It can be abstracted into a single node for the purposes of creating a higher layer of connected node networks. When we have multiple source inputs feeding into our neural network cluster and each node is running its most optimal neural pathway depending on the input, we get complex unscripted behavior. A brain is just a very large collection of layered neural nodes connected to each other. We'll call this our "Artificial Brain" (AB) Motivation, motivators (rule sets): -All creatures have a "desired state" they want to achieve and maintain. Think about food. When you have eaten and are full, your state is at an optimally desired state. When time passes, you become increasingly hungry. Being just a teensy bit hungry may not be enough to compel you to change your current behavior, but as time goes on and your hunger increases, your motivation to eat increases until it supersedes the motives for all other actions. We can create a few very simple rules to create complex, emergent behavior. Rule 1: Every creature has a desired state they are trying to achieve and maintain. Some desired states may be unachievable (ie, infinite wealth) Rule 2: States are changed by performing actions. Actions may change one or more states at once (one to many relationship). Rule 3: "Motive" is created by a delta between current state (CS) and desired state (DS). The greater the delta between CS and DS, the more powerful the motive is. (Is this a linear graph or an exponential graph?) Rule 4: "relief" is the sum of all deltas between CS and DS provided by an action. Rule 5: A creature can have multiple competing motives. The creature will choose the action which provides the greatest amount of relief. Rule 6: Some actions are a means to an end and can be chained together (action chains). If you're hungry and the food is 50 feet away from you, you can't just start eating. You first must move to the food to get within interaction radius, then eat it. Q: How do we create an action chain? Q: How do we know that the action chain will result in relief? A: We generally know what desired result we want, so we work backwards. What action causes desired result (DR)? Action G does (learned from experience). How do we perform Action G? We have to perform Action D, which causes Action G. How do we cause Action D? We perform Action A, which causes Action D. Therefore, G<-D<-A; So we should do A->D->G->DR. Back propagation may be the contemporary approach to changing graph weights, but it's backwards. Q: How does long term planning work? Q: What is a conceptual idea? How can it be represented? A: A conceptual idea is a set of nodes which is abstracted to become a single node? Motivators: (Why we do the things we do) Hunger Body Temperature Wealth Knowledge Power Social Validation Sex Love/Compassion Anger/Hatred Pain Relief Fear Virtues, Vices & Ethics Notice that all of these motivators are actually psychological motivators. That means they happen in the head of the agent rather than being a physical motivator. You can be physically hungry, but psychologically, you can ignore the pains of hunger. The psychological thresholds would be different per agent. Therefore, all of these motivators belong in the "brain" of the character rather than all being attributes of an agents physical body. Hunger and body temperature would be physical attributes, but they would also be "psychological tolerances". Psychological Tolerances: {motivator} => 0 [------------|-----------o----|----] 100 A B C D E A - This is the lowest possible bound for the motivator. B - This is the lower threshold point for the motivator. If the current state falls below this value, the desired state begins to affect actions. C - This is the current state of the motivator. D - This is the upper threshold point for the motivator. If the current state exceeds this value, the desired state begins to affect actions. E - This is the highest bounds for the motivator. The A & E bounds values are fixed and universal. The B and D threshold values vary by creature. Where you place them can make huge differences in behavior. Psychological Profiles: We can assign a class of creatures a list of psychological tolerances and assign their current state to some preset values. The behavioral decisions and subsequent actions will be driven by the psychological profile based upon the actions which create the sum of most psychological relief. The psychological profile will be the inputs into an artificial neural network, and the outputs will be the range of actions which can be performed by the agent. Ideally, the psychological profile state will drive the ANN, which drives actions, which changes the state of the psychological profile, which creates a feedback loop of reinforcement learning. Final Result: We do not program scripted behaviors, we assign psychological profiles and lists of actions. Characters will have psychological states which drive their behavioral patterns. Simply by tweaking the psychological desires of a creature, we can create emergent behavior resembling intelligence. A zombie would always be hungry, feasting on flesh would provide temporary relief. A goblin would have a strong compulsion for wealth, so they'd be very motivated to perform actions which ultimately result in gold. Rather than spending lots of time writing expert systems styled AI, we create a machine learning type of AI. Challenges: I have never created a working artificial neural network type of AI. Experimental research and development: The following notes are crazy talk which may or may not be feasible. They may need more investigation to measure their merit as viable approaches to AI. Learning by Observation: Our intelligent character doesn't necessarily have to perform an action themselves to learn about its consequences (reward vs regret). If they watch another character perform an action and receive a reward, the intelligent character creates a connection between an action and consequence. Exploration Learning: A very important component to getting an simple ANN to work most efficiently is to get the neurons to find and establish new connections with other neurons. If we have a neural connection topology which always results in a negative response, we'll want to generate a new connection at random to a nearby neuron. Exploration Scheduling: When all other paths are terrible, the new path becomes better and we "try it out" because there's nothing better. If the new pathway happens to result in a positive outcome, suddenly it gets much stronger. This is how our simple ANN discovers new unscripted behaviors. The danger is that we will have a sub-optimal behavior pattern which generates some results, but they're not the best results. We'd use the same neural pathway over and over again because it is a well travelled path. Exploration Rewards: In order to encourage exploring different untravelled paths, we gradually increase the "novelty" reward value for taking that pathway. If traveling this pathway results in a large reward, the pathway is highly rewarded and may become the most travelled path. Dynamic Deep Learning: On occasion, we'll also want to create new neurons at random and connect them to at least one other nearby downstream neuron. If a neuron is not connected to any other neurons, it becomes an "island" and must die. When we follow a neural pathway, we are looking at two costs: The connection weight and the path weight. We always choose the shortest path with the least weight. Rarely used pathways will have their weight decrease over a long period of time. If a path weight reaches zero, we break the connection and our brain "forgets" the neural connection. Evolutionary & Inherited Learning: It takes a lot of effort for a neural pathway to become developed. We will want to speed up the development. If a child is born to two parents, those parents will rapidly increase the neural pathways of the child by sharing their own pathways. This is one way to "teach". Thus, children will think very much like their parents do. Other characters will also share their knowledge with other characters. In order for knowledge to spread, it must be interesting enough to be spread. So, a character will generally share the most interesting knowledge they have. Network Training & Evolutionary Inheritance: An untrained ANN results in an uninteresting character. So, we have to have at least a trained base preset for a brain. This is consistent with biological brains because our brains have been pre-configured through evolutionary processes and come pre-wired with certain regions of the brain being universally responsible for processing certain input types. The training method will be rudimentary at first, to get something at least passable, and it can be done as a part of the development process. When we release the game to the public, the creatures are still going to be training. The creatures which had the most "success" will become a part of the next generation. These brain configurations can be stored on a central database somewhere in the cloud. When a player begins a new game, we download the most recent generation of brain configurations. Each newly instanced character may have a chance to have a random mutation. When the game completes, if there were any particular brains which were more successful than the current strain, we select it for "breeding" with other successful strains so that the next generation is an amalgamation of the most successful previous generations. We'll probably begin to see some divergence and brain species over time? Predisposition towards Behavior Patterns via bias: Characters will also have slight predispositions which are assigned at birth. 50% of their predisposition is innate to their creature class. 25% is genetically passed down by parents. 25% is randomly chosen. A predisposition causes some pleasures and displeasures to be more or less intense. This will skew the weightings of a developing ANN a bit more heavily to favor particular actions. This is what will create a variety in interests between characters, and will ultimately lead to a variety in personalities. We can create very different behavior patterns in our AB's by tweaking the amount of pleasure and displeasure various outputs generate for our creature. The brain of a goblin could derive much more pleasure from getting gold, so it will have strong neural pathways which result in getting gold. AI will be able to interact with interactable objects. An interactable object has a list of ways it can be interacted with. Interactable objects can be used to interact with other interactable objects. Characters are considered to be interactable objects. The AI has a sense of ownership for various objects. When it loses an object, it is a displeasurable feeling. When they gain an object, it is a pleasurable feeling. Stealing from an AI will cause it to be unhappy and it will learn about theft and begin trying to avoid it. Giving a gift to an AI makes it very happy. Trading one object for another will transfer ownership of objects. There is no "intrinsic value" to an object. The value of an object is based on how much the AI wants it compared to how much it wants the other object in question. Learning through Socialization: AI's will socialize with each other. This is the primary mechanism for knowledge transfer. They will generally tell each other about recent events or interests, choosing to talk about the most interesting events first. If an AI doesn't find a conversation very interesting, they will stop the conversation and leave (terminating condition). If a threat is nearby, the AI will be very interested in it and will share with nearby AI. If a player has hurt or killed a townsfolk, all of the nearby townsfolk will be very upset and may attack the player on sight. If enough players attack the townsfolk, the townsfolk AI will start to associate all players with negative feelings and may attack a player on sight even if they didn't do anything to aggravate the townsfolk AI.
4 pointsHi 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!
4 pointsI'm locking this thread for now. Neither GDNet nor its moderators, administrators or members are qualified to offer advice or support with regard to mental health concerns and suicide. Ghonchi-- I urge you to seek counseling and support online or through whatever channels available in your area for your personal mental health risks. You can message me directly if you need help finding available treatment programs or online counseling services. GDNet can provide technical and creative support and input for game development, but as many other members may suffer from similar mental health issues, this thread may pose a threat to the well-being of the rest of the community. Concerning PC procurement, you can start a new thread provided you stay on subject.
4 pointsTrivial, just position the camera correctly, and the 3D renderer will do the rest. Don't remember the angles exactly, but wikipedia does: https://en.wikipedia.org/wiki/Isometric_graphics_in_video_games_and_pixel_art
4 pointsA 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...
4 pointsThe 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 :-)
4 pointsAs the old saying goes, we have good news and bad news. The good news is that we're already half way through summer. The bad news is that the revenue of a mobile application, game or any other product often drops during the hot months, which has a perfectly reasonable explanation. In this article, we'll talk about such a phenomenon as seasonality in the values of key project indicators, discuss how to find it and use it for your own good. WHAT IS SEASONALITY? Any recurrent fluctuation of the time series is usually called seasonality. Supposedly, you have data on product sales for each day for three years. Our experience in application analytics shows that seasonality is likely to exist in your time series, i.e. you may note some cyclicity in the behavior of the indicators. Most often, seasonality is the most pronounced by the days of the week and by the months. Let's take a look at each of them separately. Weekly seasonality consists of growths or falls that correspond to different days of the week. It can be explained quite logically: there are weekdays, and there are weekends. From weekdays, it is possible to allocate Monday (usually with a minus sign) - a day of calmness after a noisy weekend, and Friday (usually with a plus sign) - a day when you can afford a little bit more than usual. On the weekend, unlike weekdays, the online graph behaves differently (because you can play from the very morning instead of going to school or work), as well as the other metrics (for example, ARPDAU - the average revenue per daily active user). Here are some examples: in many games, the audience on weekends is more active than on weekdays; on the other hand, the revenue indicators are averagely higher on weekdays with a peak on Friday (which is why Friday is an excellent day for promotional campaigns); especially interesting is the fact that the retention of users registered on Friday is slightly higher on average than that of users registered on other days. Probably, this can be explained purely psychologically: by installing application on Friday, you increase your chance to open it the next day as it's a day off. By the way, the last example shows an important thought. Seasonality applies not only to quantitative product metrics (audience or gross), but also to qualitative indicators (retention, ARPU). That is, users even behave differently on different days. Monthly seasonality. If you aggregate the indicators by month (from DAU to MAU, and from ARPDAU to ARPU), you may also notice some seasonal changes: as we said above, in many products hot months are on the contrary the "coldest" in terms of the number of the audience, its interest, and revenue from it; but cold months, on the contrary, attract more users (when it's cold outside, you may spend time at home playing games); especially seasonality is expressed in December - this is usually a month of general upswing: both in terms of the audience and the money received from it. However, seasonality is not limited to weekly or monthly. A little later we will talk about how to find the optimal cycle duration, and for now - a few non-trivial examples: in one of the games we saw that the optimal cycle duration in ARPDAU performance is not 7 days, but 14; we explained this by the fact that people receive the payroll once a fortnight; in some products, by the way, peaks are especially noticeable on those dates of the month, which could be divided by five (and these are the payroll days also); we also found products in which the optimal cycles were 3, 9, 11 days - and in all cases, this was related to the internal events in the product (e.g. tournaments). There is one more way to classify seasonality. It might be additive (when seasonal coefficients are constant in time) and multiplicative (when seasonal fluctuations grow or fall with time). In this article, we reviewed the additive seasonality, as it's more common basing on devtodev's experience with multiple projects. HOW TO FIND SEASONALITY? Below you can find a detailed description of the algorithm for calculating seasonality (by the example of finding seasonality by the days of the week). To make it easier for you to understand the process of calculating seasonality, we have prepared a file, in which all the following actions have already been performed. However, if you use this file to substitute your data into it, calculate seasonality and make forecasts, we also won't mind. CLEARING DATA FROM OUTLIERS Preliminary the source data must be cleared from outliers - atypically high or low values of the indicator that are outside the expected range. Often on the graph, such data looks like significant peaks or, conversely, drops almost to zero, which exceed the usual values by several times. The cause for such outliers might be peak sales on a holiday, the failure in the tracking system, or any of the other one-time factors that somehow influenced the metric. Why do we need to clear data from these outliers? Such values distort the results of calculations and can lead to errors in the forecast. Some statistical indicators, such as standard deviation and arithmetic mean, are dependent on the outliers and, by including them into the calculation, you may draw the incorrect conclusions. So, to clean up the data, there are a number of approaches that allow you to assess which suspiciously high or low value can be considered an outlier, and which cannot. We will not go into more detail on clearing data from outliers, because our main task now is to calculate the seasonality, but nevertheless, we must always remember it when analyzing the data. CALCULATION OF AUTOCORRELATION So, the second stage of calculations, which is applied to the already cleared data, is the calculation of the autocorrelation lag. Autocorrelation is a relationship between the values of a time series taken with a shift. It is used to identify trends and cyclical fluctuations of data in a time series. For its calculation, Excel uses a standard function CORREL, which calculates the coefficient of autocorrelation between two ranges of data. These ranges are arguments of the function and are shifted relative to each other: if we are looking for the first-order autocorrelation coefficient, the first range includes the time series values from the first to the last but one, the second range contains all values starting with the second one. We get two ranges offset from each other for one day. To search for the coefficient of the second order, the ranges should be shifted by 2 days - the first does not include the last two values of the time series, the second does not include the first two. This way, we calculate the autocorrelation coefficients for 7 orders and find the maximum among them. It will be an indicator of the day with the highest autocorrelation. If the maximum coefficient is obtained for autocorrelation of the first order, then this series does not contain any trends and dependencies. And if this coefficient is maximal for the 7th order, it means that series contains cyclic fluctuations with a periodicity of 7 days. CALCULATION OF LINEAR TREND COEFFICIENTS Next, we will build a trend for our series to subsequently make a forecast on it and determine how the chosen indicator will behave further. There are several types of trends, which can describe the metric (linear, exponential, logarithmic, polynomial, etc.). We will use a linear method as it's most simple to build and perceive, and at the same time it shows well the dynamics of the metric. The linear trend is built from an equation of the form y = ax + b, where a and b are coefficients, and x is the ordinal of the day (column D in the given example). So to calculate the equation, we need to calculate two coefficients. This can also be done with the standard Excel function LINEST, the arguments of which are two data sets - the metric that's being examined and the ordinal numbers of the days. Using this formula as an array function (Ctrl + Shift + Enter), we get two coefficients, which we then substitute into the equation. BUILDING A TREND LINE To build a trend line, use the previously calculated coefficients - a and b. The only variable parameter of the equation is x - the ordinal number of the day. Due to this, the trend line can be extended for several days ahead, in our example it's 7 days (column I). Thus, we obtain a further dynamics of the change in the metric. CALCULATION OF SEASONALITY COEFFICIENTS The next step for building a linear trend forecast is to calculate the seasonality coefficients. To do this, determine the deviation of the metric values from the trend line (column K), and then find the average value of these deviations, depending on the day of the cycle. These average values are the desired coefficients. IMPOSITION OF SEASONALITY ON THE TREND LINE AND BUILDING A FORECAST To complete the forecast, you need to "overlap" the trend with the seasonality. To do this, multiply each value of the trend line by the coefficient of seasonality of the corresponding day (column L). This will lead the trend line chart to the familiar form - with regular fluctuations depending on the day of the week. And since before we extended the trend for 7 days beyond the available data, the seasonality will spread to the forecasted part of the trend line, thus providing a forecast for the metric for the next 7 days. WHY YOU NEED TO KNOW THE SEASONALITY First of all, to predict your revenue more accurately and to make correct decisions based on these forecasts. For instance, do not plan a massive traffic purchase in August, but wait till September to do it. The question of revenue planning in general is very important, and every company is probably working on it. Seasonality is one of the ways to make your forecasts much more accurate. Secondly, seasonality can be used for your own benefit. If you know that in December you will have many users and the average revenue per user will be high, then it's worth to increase it even more by offering these "hot" users of the cold month more favorable discounts. There is an interesting question: is it possible to fight seasonality? Let's say you know that in July ARPDAU will be the lowest for you in a year. Should you try to increase it and bomb users with tempting July discounts? Our experience tells us that it's useless to fight seasonality: if your users left for a summer vacation, then they would remain on their vacation, no matter what you do. It is better to focus on multiplying seasonality of the high months and increasing your revenue even more, rather than trying to resurrect the revenue of the low months. A FEW IMPORTANT THESES And again, let's mention outliers. Before calculating seasonality, make sure that your data is cleaned from them. Any leap in the source data (and leaps are often caused by a simple technical error) can significantly distort your data. Let's say that on one of the days in July the revenue was a hundred times better than the usual average. If you do not clear the series from outliers, then you can get that July is the most profitable month, and incorrectly plan a general discount based on this data. And only later you may find out that the table probably lost the bit capacity on that day, and in fact the number is quite average. By the way, in our file, outliers purification, of course, is envisaged. Seasonality depends on many factors: application genre (imagine how surprised the representatives of tourist services would be when reading about the summer revenue decrease); country, language, religion (for example, in Iceland almost everyone goes on vacation in summer, and it's even almost impossible to schedule a doctor's appointment); weather (the hot May might be better than the cold June); any other factors. That is why the conclusions mentioned by us (about the good Friday, or unsuccessful summer) cannot be applied to all the products at once - this is only our experience that's based on the games' analysis. It is better to calculate the seasonality of your project by yourself and draw conclusions based only on your calculations. So download the file, calculate seasonality and make more effective decisions! This article was first published on devtodev's Education Center: SEASONALITY OF THE PROJECT: DO NOT BE AFRAID OF SUMMER RECESSION
4 pointsThis article was first published on https://email@example.com/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!
4 pointsThe 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.
4 pointsInteresting 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!
4 pointsInheritance 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.
4 pointsHi, 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!
4 pointsYes. 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.
4 pointsYes, 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.
4 pointsIt 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.
4 pointsDon'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.
4 pointsLearning 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...
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;
4 pointsVirtual memory, the general computing concept, is about providing a mapping to actual physical memory addresses from a (potentially larger) virtual (that is, "pretend") address space. This is a core OS feature in just about every modern operating system, and cannot be disabled. It is the thing that lets you (a) have an object at "address X" while another process also thinks it has a wholly different object at "address X," or allow both processes to think they're loading at the same address in memory when obviously they cannot be and (b) address the entire range of the address space even though you don't actually have that address space physically, assuming you don't address it all at once. It also provides other benefits, like memory protection via isolation. You can't turn this feature off. Colloquially, "virtual memory" is sometimes used in the context of Windows to refer to the page file and its size. This is a bit of a misnomer, as the use of a page file in the implementation of virtual memory is an optional implementation detail. However, since the Windows control panel for controlling the page file puts it under the "virtual memory" heading, and there are no other controls in that section, it's a term that kinda sticks. The page file is a mechanism to allow the OS to set aside memory that is in-use (but not immediately in use right now) on the disk in order to make room in physical memory and thus preserve the illusion of a larger virtual memory space. So what you seem to be asking for is detecting the size of the page file. You probably cannot do this exactly the way you want, but if you call GetPerformanceInfo, you can read the CommitLimit member of the PERFORMANCE_INFO structure it fills out. This will tell you the global limit on pages that can be committed by the system without causing the page file to grow. You can multiply this by the size of a page file ("PageSize") to get a value in bytes. This will include physical RAM, which you'd need to subtract out potentially, depending on what you're doing. It's also not going to report what the page file is allowed to grow to. There's a good chance they didn't, since they used the term "virtual memory." Now, perhaps they picked that term because of the reason I outlined above, where it's fallen into colloquial use among Windows users as a synonym of the page file, and they wanted to make sure users understood what exactly was "enabled." But my bet would be that they just made some calls into GetPerformanceInfo or GlobalMemoryStatusEx, read some numbers from it, maybe did some subtraction or other potentially-fuzzy math, and determined based on that whether or not the page file was enabled. I would not by default trust that the wording of that dialog means you can perform precisely the check you're thinking about performing. Why do you only want your program to run if the page file is disabled, exactly?
4 pointsThat should alleviate your other concern. As long as all the OS/platform dependent code is isolated into its own CPP files, so that the game code can never include any OS/platform specific details, then you're in a good situation.
4 pointsThe 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.
4 pointsIf 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.
4 pointsLong-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/.
4 pointsIntroduction This article attempts to answer one of the most asked questions on GameDev.net. "I am a beginner. What game should I make?" If you are a beginner at game development, you should definitely read this article. Your First Step to Game Development Starts Here You've learned a language. Skills are at the ready. Now it's time to finally create that game! After years of playing games and discussing graphics, design, and mechanics, the time to put the game that has been dreamt about on the big screen is now. That Final Fantasy 7 remake is the first game that needs to be made. The idea of making it an online multiplayer is also a priority. Why? It would make the game better of course. Plus, everyone wants that feature anyway. Now the googling begins. What engine was it made from? What graphics does it need? Did it use DirectX or OpenGL or even Unity? Every new question produces two more questions. It gets to the point that the tasks and goal can be overwhelming. But with ambition the goal can be met! Right? Unfortunately as many beginners come to find out, the complexity of a game can tamper ambition and in some cases completely put out the flame. However, this article will help you prevent that and also build up your game programming skills. But first let's address some issues that a vast majority of beginners run into. Many beginners ask what language they should be using. The answer is this: any language. Yes, that's right: C, C++, D, Java, Python, Lua, Scheme, or F#. And that's the short list. The language is just a tool. Using one language or the other does not matter. Don't worry about what the professionals are using. As a beginner, the only priority and goal is having the tools to create and complete the game. The second priority is to improve your code and skill. We'll get into that a bit later. Remember there is no "which language is better?" or "which language is best?". The only question anyone with experience will ask is: "How much experience do you have with the language?". At this stage in the game development journey, familiarity and skill with whatever language you are using is more important than the language itself. This is an universal truth. With your language of choice in hand, now is the time to choose how you will make the game. The choice normally is among a game development library, game engine, or a game maker. Which should you choose? If you are prototyping or are not a programmer, then a game maker would probably be the best choice. Game makers (ex: Game Maker, RPG Maker, ENIGMA) are able to create games (which I list later on) similar to the games of the 8-bit and 16-bit era. Game makers do some of the heavy lifting for you (ex: loading/handling image formats, input handling, integrating physics) and allow you to focus on the game itself. Most, if not all, game makers have a language specific to them to handle more advanced techniques and situations. The language more often than not is similar to C/C++/Javascript. Game engines such as Unreal, Crysis, and Unity handle all manner of games (ex: 2D, 3D, offline, online) and therefore are far more complex and in some cases complete overkill for the type of games a beginner should be making. Game engines should be used when you as a game developer have several games under your belt and fully understand the mechanics of making a game. For most beginner game developers, especially those who are programmers, choosing a game development library is a good choice. It puts those programming skills to the test and allows discovery of more things about the language. Like the language, the library doesn't matter. Whether it's SDL, SFML, PyGame (for Python only), or Allegro, the library is just another tool to create and complete the game. Game dev libraries have more or less the same features. So whichever you pick will be fine to get the job done. Finally after gathering our tools: language and game dev library or game maker software, we are ready to answer the most important question of all. "What game should I make?" For this question, the answer has to be approachable, doable, and for the most part understood. This is why the game that should be made should be 2D. Everyone understands 2D games. 2D games can be fancy but at its core they are basic with very few "moving parts". Believe it or not, the previous question has a definitive answer. And that answer is Pong. Now you may wonder, "why?". Well, Pong is one of the simplest games known. The graphics are simple and the mechanics are simple. There's no guesswork on how Pong should work. Therefore it's the best candidate for the first game to be made. Each new game that is presented in this article is meant to show something new and/or build upon what the last game taught you. The skills that are learned from each game become cumulative and not specific to just one game. So each game is a step up in terms of difficulty, but nothing a little brainpower and some brute force can't solve. Now I'll list some well-known games that will definitely help your game development skills and allow you to have actual complete games under your belt. I'll quickly point out some things that will be learned for each game. These games are: Pong = Simple: input, physics, collision detection, sound; scoring Worm = Placement of random powerups, handling of screen boundaries, worm data structure Breakout = Lessons of pong, powerups, maps (brick arrangements) Missile Command = targeting; simple enemy ai, movement, and sound Space Invaders = simple movement for player and enemy, very similar to breakout with the exception that the enemy constantly moves downward, simple sound Asteroids = asteroids (enemies) and player can move in all directions, asteroids appear and move randomly, simple sound Tetris = block design, clearing the lines, scoring, simple animation Pac Man = simple animation, input, collision detection, maps (level design), ai Ikari Warriors = top down view, enemy ai, powerups, scoring, collision detection, maps (level design), input, sound, boss ai Super Mario Bros = lessons of Ikari Warriors (except with side-view instead of top-down view), acceleration, jumping, platforms The list shows games in terms of difficulty from least to greatest as far as programming them goes. There are games that others may suggest but these 10 games will definitely round out what you need to know in 2D game development. If you can make and complete these games, then games like Sonic, Metroid, or even Zelda become that much easier. Those games are just variations or extensions of what you have already learned. Before I end this article, I would like to say something about completing the games. As I said above, your primary goal is making and completing the game. However, your secondary, and arguably just as important, goal is to refine your game. It's safe to say that 99% of programmers do not code Pong perfectly. Most likely your first or even second go around with Pong or Worm will not be a software architecture masterpiece. And it's not supposed to be. However, to improve your code and therefore your skill, you'll have to submit code for a code review. As all will attest to, this is A Good Thing TM. Allowing others to proofread your code will give you insights on better structure, better practices, and dangerous code that may work now, but may crash in the near or far future. Being introduced to good advice early in your game dev journey will save you from sudden and unnecessary meetings between your head and the keyboard. As you complete one game and move on to the next, do not kick that completed game to the corner. Go back (sooner rather than later) and refactor and improve the code. Doing so is proof that you understand the advice that others are giving you and shows that your skills have indeed become better. So in short, the process of making a game should be: create > complete > code review > refactor. Again, once you submit your code for review go on to the next game on the list, but remember to go back and improve that code after you get some feedback. If you've made it to the end of this article, you now have a path to start your game development journey. This article is meant to be a guide and not a be-all, end-all to game development. Hopefully the advice given here helps others start to become better game developers. NOTE: You can post code reviews in the For Beginners forum. Also, it is easier on the people checking your code if you post all the code in your post. Article Update Log 26 Mar 2013: Grammar edits, code review clarification 19 Mar 2013: Initial release