• Announcements

    • khawk

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

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

Leaderboard


Popular Content

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

  1. 13 points
    This is one of those 'can of worms' sorts of questions as there are just so many different problems with porting. I'll just start listing things and I'm sure others will add to it, here are some of the 'technical' difficulties: Graphics engine. The consoles all have different graphics API's, even the XBox is not 'exactly' D3D so you have to go through and port certain pieces. OS in general. Different calls to do simple things like get current working directory, creating threads, file IO, etc. Equivalency of API's. For instance if you use IOCP on Windows, expect to rewrite the entire system for each of the other platforms as they all do async work differently. TRC's, i.e. requirements you must meet to get onto the platforms. For instance, a difficult one for many games is that you can't show a static screen for more than x (6 on many if I remember correctly?) seconds. You need loading animation, progress or something to tell the user things have not crashed. Different memory configurations. Some consoles have dedicated areas of memory for different things, sometimes this is enforced, sometimes it is not. Often you need many different memory allocators in order to utilize this difference. Different compilers. While not 'as' bad as it used to be, there are still different compilers, versions of the compilers, library support, out right bugs in ports at the SDK level etc. This is just touching the surface of all the problems you can/will run into. Of course there are also game play and input changes to deal with: Often you need to revamp your UI's for the consoles, unless the game was specifically written in a console style up front. Deal with different display resolution requirements. I believe you still are required to support 480P on many of the consoles. The Switch presents some issues since when detached it's a really tiny screen, will folks be able to deal with your UI on that screen? Input, hope you didn't use mouse/keyboard in a manner that won't port well to gamepads. How folks usually deal with this is as you say, spend about a year porting things. Otherwise you have to start with the support built from day one and keep everything running on all the targets. As an indie dev, I suggest not worrying about this much as more than likely if your game does really well and has potential on a console that is the only time you'd have to worry about it. At which point you can try and do it yourself or get folks who do this sort of thing all the time.
  2. 9 points
    So, I ended up doing the "skirts" method I spoke of in the last post. And in conjunction with the default Urho3D water shader (with a few small tweaks, and more to come to eliminate artifacts on the corners of the water blocks) it actually looks pretty decent. The water animates a noise texture that ripples the ground beneath. It also uses a reflection texture (which I have set to black at the moment) if desired. I might tweak the water shader further, but for now I'm happy with it. I've also got all the small issues sorted out from the change to multi-level water. It wasn't a large change, but I was surprised at how many different parts of the code worked from the assumption that water was determined by elevation < 9. I thought I had contained it better than that, but I did get all the various spellcasting, pathfinding and object spawning oddities worked out.
  3. 7 points
    You're misunderstanding the nature of cheating - you can only do a client rollback if that client accepts that it needs to rollback (which a cheater's client typically will not), or if you know that it's cheating (which a cheater's client typically will not broadcast). The client is in the hands of the enemy and it can be tampered with or modified to do whatever the user wants. Expecting a client to self-correct cheating is like expecting prisoners to lock themselves in their cells. Practically, a game developer has 2 choices to prevent cheating: A central server maintains the authoritative state, and prevents cheating because all game state changes must be accepted by the server by definition. This is a typical client-server game. All players maintain an essentially identical state, and prevent cheating by ensuring that they all agree on what the state is, and reject players who disagree with the majority. This is sometimes called 'deterministic lockstep' or some variation. Your game type will not scale to the second solution, so you need the first.
  4. 7 points
    I find Urho3D to be fantastic. I'm using it to make my game, a turn-based, hex-based RPG hack and slash: It's a very solid engine, lots of support on various platforms and quite capable.
  5. 7 points
    So on D3D9/10/11 and OpenGL, you need a dedicated rendering thread, because only one thread can talk to the GPU at a time. D3D11 is a weird exception because other threads can also call most API functions, even preparing command buffers, but the main rendering thread still needs to submit them to the GPU (and most of the per-draw cost happens at submission time, so this is not an optimization opportunity). On D3D12/Vulkan you can start moving away from the idea of a dedicated rendering thread... The first option that you mentioned is an early attempt to make good use of multi-core CPU's -- split the game into two parts, and run those parts over two threads. If the gameplay work and the rendering work are roughly equal in CPU usage, then this will halve your frametime on a dual-core CPU. This requires that you very carefully segregate gameplay data and rendering data (to avoid threading bugs) and also likely requires that you double-buffer your gameplay state, so that for example, you can hand over a copy of every object's current position to the renderer, and then continue updating the next frame while the render thread draws stuff. However, that approach does not scale to quad/hex/octo-core CPU's... So most modern engines are built around a "job system", where the engine makes a thread pool with one thread per core (2 on dual-core, 4 on quad-core...), and then you try to write all of your code as a collection of small jobs that get automatically distributed to the thread pool. With this approach, your gameplay code can run on 4 cores, and then your rendering code (culling/etc) can run on 4 cores, and then final draw-call submission can run on one core. You can still use the hard split between gameplay work and rendering work with this modern job system architecture though, but it's optional. You can either write your code so that gameplay and rendering structures are mixed, OR, you can pretend that you've got a "game thread" and a "render thread" like in the old model, even though you don't... The downside of creating the hard split is that it takes effort. You have to be disciplined to segregate rendering structures from gameplay structures, and figure out how to create snapshots of gameplay data that's required by the renderer... The benefits are that your game code can be cleaner when responsibilities are nicely segregated into different sub-projects (it can also be messier if done badly!), and that if you decouple them fully, you can actually start processing multiple frames in parallel -- while the renderer is busy submitting draw-calls for frame #2, the rest of the thread-pool can be operating on frame #3.
  6. 6 points
    In terms of getting into the traditional industry, you need to be comfortable with object-oriented programming in C++. There's no serious debate there. The major engines are object-oriented, most in-house engines are object-oriented. There's a whole continuum of just how much inheritance you might see, but on the whole you are not likely to run into C-style data-first engines. This does not mean that you have to make a binary choice. You will need to be comfortable with object oriented programming but a good knowledge of data-oriented programming can help you if you want to optimise very low-level things, or if you end up working for a company that favours that sort of approach. A lot of data-oriented design is typically based around the reductionist view that programs are essentially just processes that transform data, and therefore you should just structure the functionality around the data, both to better represent the process and to help the computer perform this process more quickly. This view holds very true for certain low-level operations that operate on batches of similar objects, such as rendering or physics, but is barely workable for many high-level operations, such as AI or game logic. An effective engine will therefore often feature a bit of both; heavily data-oriented code at the low level for maximum performance, and heavily object-oriented code at the high level for maximum expressiveness. There's no need to throw out object-orientation entirely just because it may not be best route to top performance for certain tasks. That was 18 years ago. Probably 20 years if you are counting when development started! Ignore this particular part of your research.
  7. 6 points
    I'm on vacation in California, which means I kinda have some time to work on stuff, but it's split up by blocks of frantic activity. I'll tweak a few things, then head off to Knott's Berry Farm to burn in the sun while the kids ride on rides too small for me. Then I'll fiddle a few more things, then take the kids swimming. So while I'm getting some stuff done, it's all in a sort of disorganized tangle. I did decide to upload a new gameplay video. Once again, it's pretty poor quality. (Some day, I'll own a rig decent enough to make high-quality videos. But that day is not today.) It's about 10 minutes of random gameplay. I was kinda distracted while playing by a 5 year old who wanted my help building electronic circuits with a snap kit toy he recently got, so there are some pauses. Also, there is still stuttering in some spots, which won't be cured until I fully convert everything from Lua to C++. (That's an ongoing project, but I am getting quite a bit of progress done while here in Cali.) The stuttering is from the Lua garbage collector, which has been an ongoing problem with the Lua bindings to Urho3D. Throughout development of this game it has been at time worse and at times better. A recent change (unsure which one) made it worse again, enough that I'm finally going to just convert everything except UI stuff to C++ components.
  8. 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
  9. 6 points
    One thing you can do is try to run as much of the game logic as you can on the server side. You can't really trust the data clients give to the server, since they can mess with that data, then pass it to the server. Examples might be telling the server where they are (even if they are not really at that location), or how much health they have left, etc.
  10. 5 points
  11. 5 points
    It has to be the same mutex. Otherwise they're not interacting in any way to prevent the other thread from accessing the queue. The point of a mutex is that it is shared, like the thing it is protecting, different threads must acquire it before proceeding to use the protected resource, and only one thread can hold it at once. The other threads will block if they try to access the mutex, until the mutex is freed up by whichever thread acquired it. This means only one thread can access the resource at once - which is the intended behaviour. There are some esoteric situations where people use multiple mutexes for various functionality but that is not the usual situation.
  12. 5 points
    You can definitely improve the background image and main menu. When I clicked your link I initially thought it was a popup ad and instinctively added it to my adblock blacklist before I realised it was the game. Other than that, I would be interested in playing this game with the player speed slowed way down, such that you actually can make decisions for both snakes within 2-3 frames of time. As it stands now, the strategy is to make the top one a bit longer, then put it on autopilot and focus all of your attention on the other one, etc. My idea would be Slow down snek speed so you can focus on both Remove wrap around feature so you have to focus on both (add borders)
  13. 5 points
    Hashes, Databases, Sockets, States... These are all *completely unrelated things*. I'm worried that you're misusing terminology. Can you clarify your question by describing what you think those terms mean so that we don't misunderstand what you're trying to ask? Hashes are a lossy conversion of data. You can't get the original data back. So, no, you should not use them to store game states. You can use them to quickly FIND game states, but you should not use a hash for the state itself.
  14. 5 points
    So, I'm trying to figure out how to do water. Right now, I am doing water the "brain dead" way; any tile below a certain height is water, and water is created as a simple hexagonal plane with a partially transparent blue material applied. It works okay, but the ultimate end goal is to have water play a more involved role in the landscape. I'd like to have rivers, waterfalls, etc... and that means that I need to rethink how I do it. I'm trying to come up with ideas for the geometry of water. Here is a shot of how the current water system might look if I use it unmodified for multi-level water: Clearly, I need some sort of geometry to tie the pieces together. My first thought is to create a sort of "skirt" piece that is attached to the side of a water hex if that water hex has neighbors whose water height is lower than its own. Might end up looking something like this: The issue with that, of course, is that I have to oversize the skirts to avoid Z-fighting with the underlying ground hex, and that means that skirt pieces overlap with adjacent skirt pieces on different hexes and with the water hex of the lower water levels. In combination with the alpha-blending, this creates bands or regions of darker color where two pieces of water blend together. I could use waterfall particle systems to help obscure this overlap, I think. Alternatively, I could use a solid material instead of a partially transparent one: I dont like the look of it, though. Large areas of flat water look terrible. Granted, there will need to be improvements to the actual water material to make it look better regardless of how I handle the geometry, but for now I'm sorta stuck on how best to do this. I do have some ideas as to how I could perform the geometry stitching of the skirts to minimize overlap, but it'll take the creation of special pieces, and some special-case code. Not too difficult, I suppose, but still seems kinda messy.
  15. 5 points
    I recently decided to play through the All-Stars version of SMB 3 without using any Warp Whistles. SMB 3's playful title screen has Mario & Luigi messing around with a bunch of enemies and powerups. The sequence is fun to watch, but it also serves as a great preview of numerous game mechanics. I suspect that the majority of people who replay the game are familiar with the secret and use it to skip to the last world. This also means zooming past a plethora of well-designed levels. It’s been my habit as well, but this time I resolved to experience SMB 3 in its entirety. A lot of small, geometric stages later, here’s an overview of what I found to be the most notable points in the first world: 1) World 1-1 As with the original Super Mario Bros., the “?” Blocks are encountered as soon as the game begins. Since they utilize a fairly universal symbol for a question, they inherently invite the player to investigate. In addition to being positioned over Mario’s head, a slowly approaching Goomba encourages the player to jump up and discover that hitting the blocks from below can yield rewards (in this case, some Coins and a Super Mushroom). The red Venus Fire Trap is also introduced here and — in typical Mario fashion — doesn’t respawn if killed and only comes out if Mario isn’t standing next to its pipe (or on top of it). Although the player can’t go down this particular pipe, the fact that an enemy emerges from it hints at the possibility of Mario being able to do the same. 2) World 1-1 Immediately after collecting the mushroom powerup, the player is presented with a red Koopa Troopa, an enemy that hides in its shell after a successful jump attack. If the Koopa Troopa is touched while in this state, it quickly slides away from Mario. Although the big white block is a bit in the way, the player can still accomplish this feat fairly easily. If he does, he’ll learn that shells can be used to activate “?” blocks (which is the only way to do it in this case as the block cannot be hit from below) while discovering the game’s new powerup: the Super Leaf. Immediately to the right, a strip of flat land with three enemies — one of them a red Paragoomba — lets the player experiment with Raccoon Mario’s glide and spin-attack mechanics. 3) World 1-1 Following the three Goombas (which don’t respawn if killed, leaving the strip clean of enemies), a diagonal trail of coins leads up into the sky. The player must jump over a bottomless pit at the end of this runway and is encouraged to collect the coins, so it makes sense for him to get a running start and jump as high and far as possible. When the player starts running, a HUD meter fills up, the running animation changes, and an urgent sound effect begins looping in the background. All these events signify that something important is happening, and when the player jumps and soars into the sky, the screen — for the first time in a Mario game — begins to scroll horizontally and vertically at the same time. 4) World 1-1 As soon as Mario lands on a series of clouds, he finds an isolated Brick Block that floats in the air much like the “?” blocks. This similarity encourages the player to interact with it in much the same way, i.e., by hitting it, which yields the first 1-Up Mushroom. The clouds continue to the right creating another clear runway that ends with a trail of coins. In a dare of sorts, the coins ask the player to throw caution to the wind and make a blind leap into the unknown. The newly acquired flying ability is quite thrilling and liberating, and having just earned an extra life, it stands to reason that most players would want to pursue the extra treasure. Doing so takes Mario off-screen and gradually lowers him by a tall pipe. With no other obvious place to go, the game stresses the significance of the pipe. If the player figures out how to enter it, its path leads him to a neat little Easter Egg: a room filled with coins that are arranged to form the number 3. 5) World 1-1 If the player misses the opportunity to fly up to the cloud passage, the next two sections serve to introduce some new enemies. The first contains a green Koopa Troopa and three green Koopa Paratroopas that drop from the sky (hinting that there’s something up above). The Paratroopas demonstrate their ability to jump onto and fall down from platforms, while the two pits to the sides serve as an opening to show that enemies can also fall to their deaths. The second area contains a Piranha Plant and a green Venus Fire Trap. Their proximity makes it more likely that the player will have to stop by one of them on his route to the level’s end. If he does, he’ll have another opportunity to discover that the plants can’t come out of pipes if Mario is standing near them. The immobile version of Super Mario will also encourage the discovery of crouching in order to dodge the fireballs, and a Raccoon Mario will get a chance to dispatch the plants with his spin-attack. 6) World 1-1 Right before the level’s end, the player encounters two grounded piles of Brick Blocks. Since the player had two previous chances to pick up a Super Leaf, he’s likely to try the spin-attack on these glowing objects as there’s no way to hit them from below. In addition to this lesson, there’s also a solitary red Koopa Troopa pacing atop the second group of blocks. Since the player already had a few chances to learn that Koopa Troopa shells can take out other enemies and activate powerups, he might try to do the same here. If he does, the shell will break through a bunch of Brick Blocks and leave one of them unobstructed. If Mario hits this block from below (or spin-attacks it from the side), it will reveal a P-Switch. The P-Switch functionality immediately turns all the remaining bricks into coins and plays a jaunty countdown theme. When the countdown ends, the remaining coins turn back into Brick Blocks, teaching the player that the transformation is only temporary. The music change is important as there are no other visual cues to indicate if and when the blocks will return to their original form. 7) World 1-1 The final part of the stage is segmented by a jagged black line that spans the height of the map. This clearly denotes the end of the level while keeping with Super Mario Bros. 3’s stage motif — crossing this boundary is almost like stepping behind a curtain. The only object in this area is an animating Goal Panel that instantly draws the player’s attention and ends the stage when touched. Since the floor leading up to it is flat, it encourages the player to run in at full speed and jump into the panel. More often than not, this rewards the player with a star, the best possible Goal Panel prize. 8) World 1-2 As soon as the second level begins, the player is introduced to slopes and gets to experiment with how they affect Mario’s movement. Once Mario reaches the first peak, he can also dispatch a Goomba with the slide-attack while being pursued by more Goombas spawning out of a horizontal pipe. 9) World 1-2 The second major area in the level shows an almost unreachable series of coins, a floating pipe with a Venus Fire Trap, and some Brick Blocks located just above the ground. The player is likely to collect most of the coins and then attempt to break through the Brick Blocks, and perhaps learn the run-then-duck-to-slide maneuver. If the first block is hit, it reveals a P-Switch. Unlike the P-Switch in the first level, this one turns coins into other Brick Blocks. This results in the coins (or at least what’s left of them) being transformed into a path that leads up to the pipe. This clearly labels the pipe as a destination and allows Mario to use it to get to another bonus room. 10) World 1-2 The final new object introduced in level 2 is the Jump Block. Much like the other types of blocks, it’s uniquely (if a bit abstractly) decorated, naturally drawing the player’s attention. The first two Jump Blocks are spotted in a valley with a Paragoomba, increasing the chance that the player will bump into them while dodging/attacking the enemy. The bouncincess of the blocks is quite intuitive as it’s reminiscent of a trampoline — or a really springy bed, which most anyone will immediately understand — encouraging the player to jump off of them as they dip to their lowest point. The second block also spits out a powerup, and it’s possible to initiate this by bumping it from below or landing on top of it. In case the player misses this point, the next area contains a pit and a stairway of Jump Blocks. In order to safely traverse the pit, the player is likely to use the Jump Blocks above it (instead of risking bumping into them from below), the last of which drops a Starman. 11) World 1-2 The level end introduces a new enemy, a flying Paragoomba that bombards Mario with Micro-Goombas. Since there are no other enemies or obstacles in sight, it’s a safe place to demonstrate the mechanic of Micro-Goombas slowing down Mario if they attach themselves to him. If the player lets the Paragoomba follow Mario, he might also learn that any enemies on screen will instantly perish when Mario touches the Goal Panel. 12) World 1-3 As the third level begins, the player is greeted with a few large blocks and a Koopa Troopa. Both of these elements seem to be an aid in dispatching the Boomerang Bro. that stands behind ’em, i.e., the Koopa Troopa’s shell can be rocketed into him, while the higher vantage points makes it easier to dodge his boomerangs and squash him from above. 13) World 1-3 Following the Boomerang Bro., another Brick Block pile is presented where a red Koopa Troopa can be used to set off a chain reaction that destroys many of the bricks. This time around the pinballing turtle shell shows how Jump Blocks react to its touch (simply deflect it like other blocks) while rewarding the player with some extra coins. When the turtle shell leaves the screen, the player is encouraged to jump down into the cavity it created and investigate the leftover blocks. One of them yields a powerup , while another proves to be a Coin Block . The newly formed brick configuration leads the player to jump back out once he’s done, at which point he has a chance to encounter an invisible Jump Block. This pink block can only be hit from below, and when activated, it sends Mario into the Coin Heaven bonus section. 14) World 1-3 Although Level 3 is mostly flat, it doesn’t hold any rewards up in the sky. The Cloud Heaven, though, contains a bunch of extra coins and a 1-Up if the player uses it as a runway. 15) World 1-3 Past the pile of Brick Blocks, the player encounters a series of stacked Wooden Blocks. The reason they’re grouped this way is to encourage the player to press against them as he jumps forward, giving him a chance to discover that Wooden Blocks can yield powerups if hit from the side. 16) World 1-4 Although level 4 is not incredibly challenging, it’s much more difficult than the previous three stages. It’s almost completely devoid of solid ground, and its auto-scrolling nature makes it a much more intense experience. This is perhaps the reason why it’s skipable on the overworld map. In addition to the automatic scrolling that can push Mario to his death, the stage also introduces moving platforms. The platforms only move horizontally, and drop as soon as Mario lands on them. This is a pretty intuitive mechanic as it’s easy to imagine Mario’s weight overpowering the ethereal strings that hold up the platforms. Once the player learns this, he can use it to his advantage in an area where a vertical stack of coins is positioned next to a wall. With some quick thinking, the player can figure out that if he jumps on the incoming platform, it’ll drop and he’ll collect all the coins, and then still be able to jump off of it and through a gap in the wall. This is a great example of rewarding the player for proper environmental analysis and making him feel like he’s mastering its traversal. 17) World 1-4 Unlike the previous stages, level 4’s main area ends with a solid wall and a pipe. Since there’s nowhere else to go, the player — for the first time — must learn to travel through a pipe in order to finish the level. On the other side, he’ll be ambushed by a Boomerang Bro. and find the standard Goal Panel. Somewhat emphasizing the level’s optional-challenge nature, if the player collects all the coins in the map, Toad’s Blue House will also open up in the overworld area. 18) World 1 Fortress Podoboos and Roto-Discs are first introduced in spaces where it’s easy to avoid them. Once the player gets used to their functionality, the difficulty is ramped up: multiple Podoboos emerge from lava (with different timing), while Roto-Discs occupy platforms that Mario must jump on in order to proceed through the level. 19) World 1 Fortress The Fortress marks the first in-level appearance of the Fire Flower. This is significant as there are no regular enemies in the Fortress that can be defeated with Fire Mario’s fireballs. This is a tactic that’s used multiple times in the game, but because powerups carry over from level to level and it’s always adventagous to be in “big” Mario mode, it never feels like a handicap. 20) World 1 Fortress If the player chooses to trade in the Fire Flower for a Super Leaf, he can discover another secret in the sky. This is hinted at by the open ceiling and — if the Dry Bones is temporarily dispatched with a stomp — a runway right next to it. This particular secret leads to a Warp Whistle, and is much more intuitive than the obscure duck-on-a-white-block-for-an-extended-period-of-time maneuver required to get the first whistle. 21) World 1 Fortress The first door the player encounters leads him to a room with a spiked ceiling. The ceiling starts to descend as soon as the player enters the area, but he is also shown a gap that might keep Mario safe. With no other options in sight, it’s natural for most players to strive to reach it before the ceiling crushes them. When the ceiling drops down all the way, it begins to recede and Mario is forced to jump over a bottomless pit. There is no second hiding spot in sight, so the player has to trust the game to provide one for him. This creates tension and forces the player to perform a leap-of-faith, but he’s ultimately saved by a final tiny gap (much smaller in width and height than the first one) at the end of the area. The gap is located next to a wall so it’s fairly easy to get into it, but its small size makes the whole sequence feel like a nail-biting escape. 22) World 1 Fortress The Fotress level ends with a boss battle against Boom Boom, an enemy that needs to be stomped three times before being defeated. If the player still possesses the Fire Flower, he can also dispatch him with its fireballs. When Boom Boom perishes, he drops a “?” Ball that ends the level when touched, adding to the “specialness” of the Fortress level. 23) World 1-5 In case the player never discovered that he could slide down slopes to take out enemies back in World 1-2, this level does it for him. Unlike all the other stages, it begins with Mario on a slope already in a butt-scoop position. He then proceeds to barrel through some Buzzy Beetles that just happen to be climbing up the hill. This not only shows the mechanic, but also displays its usefulness. In addition, sliding is pretty much a universally fun activity, and its presence is another incentive for the player to experiment with the moveset. 24) World 1-5 The level contains another Fire Flower that allows the player to test out the enemies, but it’s only accessible after the section pictured above. This is notable due to the pipe that hosts a Piranha Plant located close to the ground, making it likely that the player will stop and wait for the plant to recede. During this interval, an approaching Buzzy Beetle will prevent Mario from running through the opening. When the Buzzy Bettle finally reaches Mario, the player will likely jump on top of it, learning that the beetles’ shells act much like those of the turtles. At this point, the careening shell will have a high chance of taking out the Piranha Plant as it comes out of the pipe, teaching the player another useful combat mechanic. 25) World 1-5 And in case the player missed the pink Jump Block in World 1-3, he gets another chance to discover it here. Walking up slopes is never fun so the player is encouraged to jump through the area, and in the process possibly bump into the invisible Jump Block. As usual, the pink Jump Block leads to a Coin Heaven area where — once again — he can discover extra coins and a 1-Up if he uses it as a runway. 26) World 1-6 Although this level is not autoscrolling like World 1-4, it’s similarly devoid of a floor. This creates some interesting airborne hijinks with the red Koopa Troopas that do not walk off of platforms by themselves. As shown in the above example, it’s very easy to start off the level by stomping a Koopa Troopa and sending its shell flying to the right. In turn, the shell will fall off the platform, travel through empty space, land on another platform, and eventually take out another Koopa Troopa that patrols it. 27) World 1-6 Unlike the floating platforms in World 1-4, these ones are attached to a thin path and are buffeted by end pieces. This allows the player to easily guage the platform’s movement and plan his jumps accordingly. The first platform is introduced with no enemies in sight, but the second one runs head-first into a Koopa Paratroopa. Also, its path doesn’t contain an end piece, forcing it to eventually fall off the path itself. This in turn forces the player to quickly jump to a nearby platform. 28) World 1-6 More opportunities for mid-air stunts are presented via the flying red Koopa Paratroopas. By the time the player encounters them, he’s more than familiar with the mechanic of clipping the wings of enemies and sending them plummeting to the ground. Since there’s never any solid ground below these turtles, the stomped Koopa Paratroopas simply fall to their deaths. This creates some rather satisfying scenarios where the player can kill two birds with one stone: dispatch an enemy and make a piggy-back jump onto a new platform. 29) World 1-6 The area above is a runway, but it’s punctuated by a single gap that slightly drains the run meter. If the player jumps onto it while running from a previous platform, though, he retains part of the run-charge and is able to take off into the air. A path of coins beyond the platform shadows Mario’s flight arch, and when he finally floats down, he’s safely deposited on a moving platform. 30) World 1 Airship The airship levels start off with a short cutscene of Toad pleading for help and Mario heroically leaping onto a moving airship in pursuit of Bowser’s minions. Like all “artillery” stages, the level auto-scrolls and is filled with unique enemies such as Cannonballs and Bullet Bills. This approach makes it feel almost like a shmup as the player is forced to concentrate on avoiding multiple projectiles while waiting for the end-segment to scroll into view. However, unlike most shmups, Mario has to deal with gravity, the movement of the ship, and the cramped architecture. This makes avoiding bullets much harder, but also steers the player into making another discovery: not only can Mario kill the projectiles by jumping on them, they can also perish if they touch his feet (even while he’s standing still). A single Fire Flower stresses this point as all the enemies in the level are invulnerable to its fireballs. When the end-boss is defeated, the significance of the level is further accentuated by a series of events: Mario grabs the stolen Magic Scepter , jumps down to the ground, cures the king, receives a congratulatory message, and finally reads a letter from Princess Peach that comes packaged with a powerup. Super Mario Bros. 3 contains many obvious design lessons that are also present in other games, e.g., the gradual layering of complexity that allows players to master a specific mechanic. What surprised me during my playthrough, though, was how some of these lessons were completely optional. For example, it’s possible to send a turtle shell skittering in the opposite direction of destructible bricks, or to take the cloud-route and skip certain powerups and interactive objects. Of course these same lessons are repeated multiple times, but they’re not always as heavily hinted. Personally, this hits a sweet spot for me. The game doesn’t have any forced hand-holding, and it isn’t afraid of the player simply exploring it at his own pace (even if it means circumventing chunks of the experience). This approach also serves to encourage multiple replays, and — back during SMB 3’s initial release — it probably sparked many playground discussions. Note: This article was originally published on the author's blog, and is reproduced here with kind permission. Check out his work at Incubator Games.
  16. 5 points
    All variables are just bits in memory, so using it as whatever is totally valid, because they're just stupid bits. That's a weak argument. An enumeration has by definition a restricted range of values, the compiler checks for this and makes sure you don't write buggy code by going outside of this range, which is what you were trying to do. Since you are working with flags, it makes no sense to use an enumeration type. What you want is an unsigned type and some constants. I'd simply do the following: enum { fpl_InitFlag_None = 0, fpl_InitFlag_Window = 1 << 0, fpl_InitFlag_VideoOpenGL = 1 << 1, }; typedef unsigned int fpl_InitFlag; It's clear from the naming that these are flags and there's also a hint to the user that he should use the constants starting with fpl_InitFlag_.
  17. 5 points
    Ooh good timing for this thread - Albrecht just posted some new slides! The original 2009 talk (still relevant!): http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf And the 2017 version: https://docs.google.com/presentation/d/1ST3mZgxmxqlpCFkdDhtgw116MQdCr2Fax2yjd8Az6zM/edit#slide=id.g2398a4e2af_0_118 https://docs.google.com/presentation/d/1305-i5JZ98cLqXgVwzTyB1NQUjjBJ0_0diwU2diS_TI/edit#slide=id.p tl;dr:
  18. 5 points
    Both. It's trendy for bad programmers who think that OO=inheritance to post unfortunately-influential rants against OO these days... Don't listen to them and don't throw the baby out with the bathwater. Look up SOLID - this is the modern core of OO. Those rules, along with encapsulation and invariant-enforcement let you write large scale projects that are performant but more importantly, are easy to maintain into the future. DOD and OOP can be good friends. OO doesn't really care about data layouts, but OOP languages can default to some bad layouts. C++ is flexible enough to let you apply DOD and come up with better layouts while still getting the maintainability benefits of OO. OO can also encourage bad data access patterns (thinking per object instead of thinking per batch of objects), which can be bad for performance on modern CPU's (where cycles are cheap by memory access is death). This is where you can use a hybrid of OOP and DOD. Often this manifests as creating "systems" (e.g. "particle system" class, but no "particle" class) and representing objects by some form of opaque handle. C++'s flexibility again gives endless options here. Sometimes you still have individual objects as classes as well as a "system", but move certain methods to the system from the object to force users into better data access patterns. Other times you still have traditional objects, but you just use DOD thinking to arrange them into better layouts, or restructure the algorithms that operate on them to make better use of the real hardware. C++ vs C is interesting because you can use 99% of C syntax from C++ anyway, and also no project ever uses all of C++ (almost every project coding guidelines / style guide will specify the acceptable subset of C++ that you're allowed to use). The big problem with C++ is a lack of a stable ABI -- this means that DLL's created with one compiler do not play nice with projects being created by another compiler... which means that C++ middleware is pretty much useless without source code access. If you're writing a closed-source middleware library, you should almost certainly write your public API in plain C, even if the internals are written in C++ It can also be useful to enforce these kinds of constraints within the submodules of your own project, even if you don't need to. For example, see this blog post from The Machinery (ex devs of Stingray / Bitsquid engine and, ex Grin engine team). Keeping the interfaces between the different parts of your code simple can be extremely useful for ensuring your codebase remains maintainable, which is what OO is all about.
  19. 5 points
    Since the items are referred to by their tag, then it would be easier to use an associative array, such as `dict` or `collections.OrderedDict`. Then, checking if the inventory is full is only a matter of checking the number of tags it has: items = dict() def is_full(self): return len(self.items) >= 8 You are correct in that it is misleading to add an item and not actually have an item added. This is why it is important to signal if an action succeeded and (optionally) provide other ways to determine if an action will succeed. For example: class Inventory: max_inventory_size = 8 def __init__(self): self.items = dict() @property def full(self): return len(self.items) >= self.max_inventory_size def can_accept(self, item): return item.tag in self.items or not self.full def try_add_item(self, item): if not self.can_accept(item): return False self.add_item(item) return True def add_item(self, item): target = self.items.get(item.tag, None) if target is not None: target.quantity += item.quantity else: assert not self.full, "Inventory full" self.items[item.tag] = item # and then: (1) # expect this action to succeed, otherwise crash hard inv.add_item(item) # or: (2) # lazily attempt action, not caring if it fails if inv.try_add_item(item): world.remove(item) # or: (3) # don’t attempt action, but do check if it is possible for shop_entry in shop_menu: if not inv.can_accept(shop_entry.item): shop_entry.enabled = False
  20. 5 points
    It has been quite a while since my last blog post… as always. However, development has not ceased entirely… just continued in ever so small steps. =) Here are some of the changes and additions made in the last couple of months. Exploration/event music added. Created library for handling steam achievements. More enemy types. Work on demo has begun (almost finished). Fixed a bug when shooting arrows on certain types of enemies. Implemented a game launcher which displays news and announces game updates. Launcher will not be included in the steam release, I think that would be superfluous. Added animation to an already present cutscene (this had actually been long overdue, it looked horrible). I've also created a short trailer for the game. Steam requires all games to have a trailer in order to have it published. Luckily I just found out that Photoshop is able to edit videos I didn't even have to learn any video editing software. *yay* Well, this one-man project is starting to shape up nicely I think =) Now, with these latest changes (…and a ton of tweaks and fixes made earlier, too many to mention here) I felt it was time to submit the store page and game files for review by valve/steam. They say that the review process can take up to 2-3 days for the submission to complete. It feels strange to call Medieval Story *finished* but I have to call it sometime. I hope the game gets enough response/appreciation to warrant further development. However… I know that indie games rarely becomes successful so I have set my aims pretty low in that regard. If I was doing this for commercial success alone I think I would never had gotten as far as I have. On a private note, our second daughter has been born which has led to my development time being even more limited. As always, thank you for reading and for your support!
  21. 5 points
    In my experience, these kinds of systems are done by a shitload of art creation, plus some simple morph target tech. Artists also paint which vertices belong to which 'group', so that different parts can be blended differently.
  22. 5 points
    The Gaussian blur is separable, meaning it can be done in one direction, then the other and have the same result as if you did a kernel with all surrounding points included. In other words, for a 3x3 blur, you can do an X pass with 3 taps (the middle sample and one on either side) and a Y pass with 3 taps (the middle sample and one above and below) for a total of 6 taps. If you did it in one pass, you would need to sample all nine points, i.e. the center point, the left and right, the above and below, and all four corners - those are values you get for "free" when you break it up into two passes. For a small blur width like the above example, it might be faster to use one pass, but for larger kernels, you can see that the number of samples in the single pass start to add up. For a 7x7 kernel, you would need 49 taps total for a single pass, but only 14 if you break it into separate passes.
  23. 4 points
    I'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...
  24. 4 points
    Service locators are to singletons as singletons are to globals; one step improved, but still pretty bad. I mean, I've used service locators before when hacking something together quickly, but they have almost all the same problems that a singleton does: global access to an object leading to high coupling global instances of an object meaning more shared state poorly-defined object lifetimes (usually) superfluous code enforcing that you only ever have 1 object, when there may be times you can make use of multiples Basically, I try to take a step back when thinking about code like this. If I find myself thinking "lots of bits of the code need access to object X", I know that is not really true, and so I try to find one of several strategies for resolving that. e.g. if object X is basically a resource provider (e.g. TextureManager), can we just extract what we need at initialisation time, and pass those objects in directly, instead of querying for them later? if object X is basically an event sink (e.g. SoundPlayer), or an event source (e.g. InputManager) can I just connect to it via generic events/signals/delegates/std::functions/whatever, performing the connections once and then never needing to refer to the object again? if object X is some sort of helper object which doesn't maintain any state, can I make the methods into free functions that can be composed arbitrarily (C, C++, Python, Javascript)? Or can I change the object into a static class (e.g. in C#) for similar effect? if object X is a combination of the above things, or is just accessed everywhere because it performs a lot of different roles, can I split it into separate objects X, Y, Z, each of which might be easier to handle?
  25. 4 points
    If 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.
  26. 4 points
    For an introduction to my reasons for migrating from Windows to Linux, see my previous blog post. Here I will try to stick to my experience as a Linux beginner, and hopefully inspire other developers to try it out. Installing Linux The first stage of course in migrating to Linux is to either install it on your PC, or try a 'live' version off e.g. a usb stick (or even try it on a virtual machine?). I can't say too much here, because I got my new PC with Linux Mint pre-installed, and there should be plenty of guides on google. I went for Mint because I had briefly tried Ubuntu a few years ago, and I liked the look of Mint and fancied a change. I knew it was based on Debian like Ubuntu so there should be lots of software. My first stage after unplugging my windows machine was just to take baby steps to familiarize myself with it, without running away in fright. After plugging in my network cable, I was away with Firefox browser. But after a few minutes I decided to install Chrome, as I am a fan and used that on windows (going with familiar!! safe space!!). This entailed installing software. Installing Software On windows, the process of installing software usually involves downloading an installer package from the internet and running it, and hoping it likes your machine windows version / hardware / dependencies. You can do this on Linux too (particularly for cutting edge versions of software), but there is also a far easier way to do it, via a 'package manager'. The package manager is actually the pre-cursor to all the various 'app stores' that have become popular on Android and iOS, but the idea is simple, you have a searchable database of lots of software you can install, usually simply with a click. It also has the magic advantage that it has a very good system for automatically working out the dependencies required by any software, and installing those for you too in the background, or for finding conflicts (if these do occur, when I have rarely had conflicts it has been because I've been trying to do something nonsensical!). I don't know whether it is my new machine, or linux, but the process of installation (and removal) is orders of magnitude faster than windows. It honestly only takes a couple of seconds for most of these installations. Anyway suffice to say I was very quickly running chrome, installing my favourite plugins, running my favourite websites. Accessing Windows Hard Disks The next stage was to get some of my data across from my old windows PC. This is where things get slightly interesting. Predictably enough, linux uses a different filesystem to windows, 'ext4' on my machine, whereas my windows external hard disk was formatted as NTFS. As is Microsoft's way (to discourage competitors, no doubt), NTFS is not public domain. The clever Linux devs have presumably reverse engineered much of NTFS, because you can mount and read from the NTFS disk. However, I am erring on the side of caution and not writing to NTFS for now, because from previous experience of exFAT on Android, it is possible that an incorrect write can bork the file system, and hence lose a LOT of work. My solution for now was to copy my working source code etc from the NTFS hard disk to my ext4 linux SSD. Longterm I intend to convert all my NTFS external hard drives to ext4. It would also presumably be useful if Windows could read from ext4 drives, but I don't know how easy this is as yet. Great! I had some data on my new machine. I tried some movies and they worked great in the in-built player, and VLC (which I installed). Image files loaded fine in the in-built viewer and in 'the gimp', which is sort of like the linux photoshop. I've used the gimp a little on windows, and am hoping it can do a lot of the photoshop duties. Blender For 3d models, I've been using blender on windows, and as luck would have it, this open source software is available and runs very nicely on linux. Was installed and loading my game models in no time. For development, this just left an IDE and compiler for c++ (my language of choice). Linux has a very handy standard compiler which is easy to install (g++ / gcc). This is where I might mention 'the terminal'. The Terminal Although the name windows has become synonymous with the windows GUI, it is important to realise that an operating system doesn't have to be irrevocably intertwined with a GUI system. In linux, the operating system can use several different GUIs, depending which flavour you prefer. Or none at all, if for example you are running a server. The way to talk to the operating system below the level of the GUI is a command line interface called 'the terminal'. There used to be one used commonly in windows too, the DOS prompt, but it is rarely used now. In contrast on Linux, the terminal is still very useful for a number of operations, unfortunately it can be a little scary for beginners but this is a little unjustified. To get the terminal up I just press Alt-T. You can list what is in your current directory by typing 'ls'. You can navigate up a directory with 'cd ..'. And you can navigate into a directory with 'cd MyFolder'. It will also auto-complete the folder / filename if you press tab. From the terminal you can do a lot of stuff you would also do from the graphical file manager (the excellent 'nemo' is built in to linux mint), such as copying, deleting, moving files. You can also manually tell it to install packages just like it would install from the package manager, with the command 'apt-get'. To install software, you need admin privileges (this is handy as it prevents malware from doing anything naughty without you typing in the admin password). To get admin you type 'sudo' before the command: sudo apt-get install build-essential This tells it to run as admin (sudo) to run apt-get, and install (or remove) the package called 'build-essential'. This contains the compiler and other building tools. IDE Unless you fancy yourself as a hardcore compile from the terminal from the getgo type of guy, you will also probably want to use an IDE for development. As I use C++, there are several to choose from, such as Eclipse, Code::Blocks, KDevelop, Code Lite etc. I went for QT creator, as I have used it on windows (again, familiarity!! baby steps!!). Once QT creator was installed, it was fairly easy to tell it to create a hello world app and test it, it worked great! This is where things got slightly more interesting. My current project is an Android game. I had been maintaining both a PC build on windows, and the Android build, with the platform specific stuff isolated into things like creating a windows, setting up OpenGL, input, and low level sound. OpenGL ES Where things got slightly confusing is that because I am developing for Android, I was using OpenGL ES 2.0, rather than the desktop version of OpenGL. On windows I had been using the ARM Mali OpenGL ES Emulator, which emulates OpenGL ES by outputting a bunch of normal OpenGL calls for each ES call. I was anticipating having to use something similar on linux, so I attempted to install the Mali emulator in Linux, however I had little joy. I was getting conflicts with existing OpenGL libraries used in SDL (which I intended to use for platform specific stuff). Finally after investigation I realised that my assumptions were wrong, and Linux actually directly supports OpenGL ES AS WELL as desktop OpenGL, through the open source Mesa drivers. I eventually got a 'hello world' OpenGL ES program working, and was convinced I now had the necessary libraries to start work. 64 Bit Conversion The next stumbling block was a biggie. For historical reasons, all my libraries and game code were 32 bit. I had been developing with the idea that a lot of Android devices were 32 bit, and I was hoping the 64 bit devices would run the 32 bit code (hadn't really tested this out lol). So I had been previously compiling a 32 bit windows version, and a 32 bit android version. And it soon became clear that my linux setup was compiling by default to 64 bit. No problem I thought, I should be able to cross compile. With some quick research I managed to get 32 versions of the libraries, however I had no joy with 32 bit version of OpenGL. It refused to install, and being a linux beginner I was stuck. I did some little research, but no simple path, and realised that maybe it was time to convert my code to 64 bit. Or rather, to have my code run in 32 bit and 64 bit. I had been (rather unjustifiably) dreading this, as I have a lot of library code written over quite a few years. As it happened, aside from some changes to my template library, the biggest problem was in the use of 'fixup' 32 pointers in flat binary files formats. I have been using this technique for a long time now as it greatly speeds file loading, and also helps prevent memory fragmentation. Fixup Pointers Essentially the idea with a 'fixup' pointer is you store into the file an 'offset' from a fixed point in the file to a resource, often the start, because there is no point in saving a real pointer to a file as it points to a (changeable) memory location. Then you can load the entire binary file as one big block, and on loading 'fixup' the offset pointer to a real pointer by adding e.g. the offset to the memory location of the start of the file in memory. This works great when the offsets are 32 bit and your pointers are 32 bit. But when you move to 64 bit, your offsets are fine (as long as the file is smaller than 4gb), but there is not enough room to store a 64 bit pointer. So you have a choice, you can either do some pointer arithmetic on the fly, or change your file formats to use 64 bit offsets / pointers. After a trial with the first method, I have eventually settled on going with 64 bit in the file, even if it uses a little more space. Of course the disadvantage is that it has meant I have needed to re-export all my assets. So at the same time as converting my libraries to 64 bit, the game code, I also needed to convert my exporters to 64 bit, and re-export all the assets (models, sprites, sound etc). This has been a frustrating big job, particularly because you are coding 'blind'. Normally when you program you will change a little bit, recompile, run and test. But with such a conversion, I had to convert *everything* before I could test any of it. Success! It has been demoralizing doing the conversion, I won't lie. But I have been so impressed with the operating system I was determined to make it work. And finally bit by bit I got the exporters working, re-exported, then the game, debugged. Got some crazy graphical errors, errors in the shaders that the OpenGL ES implementation didn't like (that's a whole other story!) but finally got it displaying the graphics, then did an SDL version of the sound this afternoon which is working great. One thing I will say is I should have been using SDL before, it is really simple and makes a whole lot of sense of taking out the eccentricity of setup code on different platforms (windows in particular is very messy). So to summarize I now have (nearly) everything working, compiling and running on linux. I still have to install android studio and try debugging an android hardware device through usb but I'm very hopeful that will work. Even if it doesn't it's not a show stopper as I can always use a second PC. I am gradually becoming more familiar with linux every day and even feeling I might get tempted to learn QT so I can do some nice 'native' looking apps.
  27. 4 points
    Hi, 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!
  28. 4 points
    Below 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.
  29. 4 points
    You could use them, or keep your sky dome and in the vertex shader do something like: //... some code posH = mul(inputPos, viewProjMtx); // this is your SV_Position output posH.z = posH.w; // when the divide by w occurs, this will make the depth 1.0 (far plane) //... whatever else You could also just use a full-screen triangle or quad and use the same "push it to the far plane" logic. Then in the pixel shader, color it based off the y component of a view ray (a ray from starting at the camera and extending out into the scene) - all depends on how fancy you want to get. If you stick with the dome, make sure you only transform it by the camera's position, and not rotation - otherwise the entire sky will spin as the camera spins.
  30. 4 points
    Hi everyone, I'm creating a series of tutorials about the creation of Game Effects in Unity. I hope it may help someone around here, and feel free to ask questions. Thanks & Enjoy!
  31. 4 points
    I'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.
  32. 4 points
    Trivial, 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
  33. 4 points
    A few things: 1) Yes, gd3dApp is a global. Hence the 'g' prefix. 2) The global isn't actually necessary - Windows allows you to attach a pointer of an arbitrary type to a window, either at construction time or at any point later", albeit at the cost of type-safety. Look up "SetWindowLongPtr". Mind you, the point about not assigning a member function to the window still holds, though, because of how pointers to member functions work in C++. 3) The anonymous namespace is used to prevent the global from being accessible outside the source file in which it is defined. In C we would do this using the "static" keyword, but anonymous namespaces are how modern C++ accomplishes this. 4) Classes are constructed in order of inheritance hierarchy - and destructed in the opposite order. So the base class (D3DApp) would be constructed first, assigning the "this" pointer of the class to the global. 5) If you were to have two classes deriving from D3DApp, and you would instantiate both of them, the global would be set to the address of whichever one was most recently constructed without fanfare. You can probably see why this could be dangerous...
  34. 4 points
    The main thing I'd suggest keeping in mind is that you might be artificially limiting your options by trying to find an entry-level job which also is a dedicated AI role. Entry level is hard enough to break into as it is, and AI is a specialization that typically involves some baseline experience in making games. Your best bet (IMO) is to get a good title or two shipped first as a gameplay programmer, and pick up the AI as you go. Once you have the basics of shipping code under your belt, you can start looking into the specialization. You should ideally be conversant in all of the following: Decision making systems (scripting, utility-theory, behavior trees and similar architectures, planning, state-search, machine learning [ugh], and so on) Path planning algorithms and data structures Perception modeling (sight, sound, etc.) Animation techniques at least at a high level (know what a blend tree does, how to play animations, etc.) I'm sure there are more things. Pick up a good game AI text and you should at least be comfortable talking about every subject in there. Hopefully that explains why entry level and AI specialization is a hard combo :-)
  35. 4 points
    As 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
  36. 4 points
    The compiler is just trying to save you from writing buggy code. You need to go out of your way to force your bugs into your software. Your solution does a fine job of doing that. You're implementing an operator that is not closed on the enumeration set. You're breaking the contract provided by enum. When you start getting weird errors, save yourself some debugging time and check where you use the enum first.
  37. 4 points
    Interesting read, though I feel compelled to react to a few items: First and foremost, YOU have to be capable of building the game entirely by yourself. I think that's only partially true, for self-starters. In the event of being able to throw 'some money' at the problem though, I think it is possible for someone with limited skills to lead a project to completion through hiring freelancers or team extensions, even on indie budgets, and without having to resort to the power of USD on other currencies. You absolutely positively MUST have a business plan. While I agree with the business plan, I cannot back the length. A lot of the best business decisions come from reacting or anticipating change, and the business plan is a comfortable fallback than can work against it. You should have the big picture, the product and see value where you're headed, but in the words of Elon Musk, great businesses are built on great products first and foremost. Please, please, please, for the sake of god, have everything meticulously planned out before you begin! Once again here, I can only imagine this being written by someone whose previous work did not specifically involve the same type of organization as video game development. For anyone who comes from a background similar to mine (having produced video games, some of which AAA) I'd advocate the complete opposite: don't dwell in the details, as a manager, your value already comes from being able to address that. Focus on the big picture, not which tradeshow you'll attend, but when it might get relevant. Awareness is a much better problem solver than planning, though both obviously trump over reactivity. When it comes to processes, a tried and true process is the “scientific method”. There's an extent to which experience or 'instinct' might strictly become superior to the scientific method and it happens on split-second decisions. Over the course of a project, the sub-conscious identification of patterns and best case decisions will not be 100% accurate (but the scientific method also leads to errors when certain piece of data were omitted or simply not humanly possibly to acquire) but they'll be much faster. I'm not advocating management on a global scale not built on rigorous principles, but rather a fair tradeoff between taking advantage of your experience in the field vs taking 'the time'. Obviously, for someone new to the scene, that is largely unapplicable, though you'll find that a lot of successful startups' origins are less than noble in rigor. You need money. I partially agree, though there are now new tier publishers who need to make a name for themselves. You'll still need a lot of money to get the game anywhere near a territory they might want to look at it, but as the 'smaller guy', they'll also be prone to taking more risks either because they genuinely want to, or because they seek their own break. This gives you more opportunities than, say, 5 years ago, but very few will get that call, so it shouldn't be your plan, just a nice touch to bring your MVP further along. You HAVE to believe in your experience and abilities. This one I agree fully with. Just needed to put it out there, it's probably the single most valuable item in the entire post. Having unshakable confidence balanced with humility is an art that is innate to no one. I repeat, absolutely NO ONE is born with the natural born talent for doing both. A lot of people have bloated heads, and a lot of people are too humble. Being the perfect mix of both is something that takes forever to learn, and something you can't possibly master perfectly ever. What counts is that you keep trying to reach this state as much as possible and keep it in check (too many business owners 'forget' this balance and go one way or the other and never look back post startup phase). To get an idea on what it takes to make your favorite game, open it up. Then go view the credits screen. Look at all the roles. Count the number of people involved. Then, assume everyone makes $60k a year and it took three years of full time work to produce the game (four if you want to factor out crunch time). This is the amount of time, talent, effort and money required to build your favorite game. Is your scrappy rag tag indie team going to repeat this but do a better job? No. Your scope is too large. I agree with the premise: the scope is always too big. However, I feel the example is lackluster. I've built myself a quite successful business by questioning the current 'Game Credits' standards. I've effectively delivered projects that the industry would've scoped over 1M on less than 50k budgets. The industry is plagued with problems (Logan's Run HR for starters!) that led to their unproductive over-specialization, and the very reason indies get so successful is that there's a lot of value in a holistic vision which AAA development studios are unable to capitalize on. It is frustrating to put together a 100 people team, try to keep the ship afloat and all channels open when Edmund McMillen REPEATEDLY strikes home with his games on a 2 people team. True, some people's ideas sound AAA, but not all of them NEED to be. If you focus the art of MVP, you can distill your unique experience and built something compelling and original but less than 10% of the effort the AAA world feels is mandatory to achieve and may even outsell them if you're particularly good at it and paved your way to success. A lot of people assume that because the scope is too big, the concept is, but that's generally the other way around: you've grafted too much crap to your core idea and should stick with the part that keeps you awake at night and reconsider what supports it instead of fitting a genre. In the 80s/early 90s, genres played much less of a role, and great games got made (arguably, much less forgettable ones too!). There's a reason why we're in an age of sequels and reboots: the current industry isn't fostering a climate that leads to new great IPs, but many indies do, so I feel I need to speak up regarding scope as that's one critical misunderstood step amongst new indies. Nobody knows what they’re talking about. I partially agree in that I don't believe in 'experts' particularly from a marketing standpoint (marketing is always about having that idea no one saw coming, and quite literally, that can come from anyone, at any given time, and is less likely to happen if someone sticks to SEO standard practices, adverts, etc, I mean, just look at that dig a hole campaign: pure genius!). That being said, as far as production goes, there are best practices that make sense, and having someone senior on the team who is aware of the limitations of what they know can make a huge different. Steve Jobs' Next wasn't a pure success on its own, but it was positioned at a level of quality where it was eventually feasibly for Apple to acquire that tech, so striking twice isn't a pure streak of luck. Some people see patterns, not in the sense that there's a guide to making a product, but there are 'pillars' of what should matter, what one should care about, and some people, few people (and fewer openly willing to sell their craft) are actually genuinely interested in helping other projects succeed, and have the ability to 'know what they're talking about'. Be prepared to work a lot. That's the 'all in approach' and it is not the one I would recommend. Downscale your work and get a part-time job. Get contracts if you can, split your time between what you're risking (YOUR game) and what you need to get by (work). Don't stick to a day job, you'll be already tired by the time you get started on your own stuff at the end of the way, and you will get burned by lack of sleep, etc. I know, I've been there myself (even after the 5-1-1, guess what that last 1 was for to begin with, and while we're at it, what was the first 1 for again? That's right, more work). So I can see that as a collection of lessons you're learned in your situation. Most of them are applicable to all, but some of them stem from a very personal situation. It is valuable input, but I think presenting all of it as fact is a bit misleading given not everyone floats the same boat as you did before getting started. You had some very strong suits (your background in dev) and some weaknesses (a bit more of an introvert if I'm not mistaken?) and they show through this. Still, very valuable input nonetheless, and a good reminder of the highs and lows. Given this, has your game failed? And what metric would you use to describe failure? Everything being relative, it would help to have a bit more context into what led to such a 'stop sign' type of post (while others prefer to profess unlimited motivational posts which will quite unnecessarily lead to a bunch of entrepreneurs making bad decisions while pursuing 'dreams'). Hope you're well despite the fall!
  38. 4 points
    Hi, Been a while since I took the time to write a proper entry, even more so in this journal (The Week of Awesome III was a summer 2015 gamejam entry after all). But today is different.... After building up my own freelancing business for a decade now, I'm more than happy to report than I've spent the last few months doing it fulltime, which is a lifetime achievement for me, and something I've been contemplating / building for a long time now. But this entry is not about how great life is on the 'other side', but rather, about a very specific project. A New "Death is Useful" In 2015, I made an entry in the 'Week of Awesome' GameJam hosted here at Gamedev.net titled "Death is Useful" (which was also the theme of the competition). It wasn't my best entry as far as results go (I actually managed to score 4th position on both Week of Awesome II and IV) but I felt it was the one with the most potential to scale into an interesting game. Some time ago, I even revisited the title with the intent of researching the 'new' and 'improved' WebGL exporter now bundled with Unity3D. Suffice it to say that, back then, I was anything but impressed with the results (as can be read in my previous posts). I chose to let the project to rest and resumed work on a variety of other exciting ideas (some of which you'll be hearing about soon-ish). The WebGL Exporter Strikes Back (if you're not tech-savvy, you may freely skip ahead!) By mid 2017, I was put in touch with the reps over at Unity through a client and ended up doing some R&D with the actual WebGL exporter and it had come a long way since I had last used it. So, little by little (working fulltime as a freelancer leaves very little spare time for passion projects) I ventured a bit deeper with the exporter, to see how I could polish & optimize the results. I think a word on the state of HTML5 is in order here, as one might be wondering why anyone would even bother using WebGL to begin with: I don't think there's 'one single truth', but I've been involved with a sufficient amount of projects through a relatively large client sample to know that, right now, HTML5 is 'popular', but it does not deliver. The reality is that there are few efficient engines to work from, meaning most projects end up being made up from scratch, or from a new unknown tech, making development very slow and costly. The problem is that HTML5 was meant to be the 'Flash killer', and as far as I can see and hear, it's simply not 'as fast' and 'as cheap' as making Flash games yet. I've been working with a lot of businesses that have tried and failed to make HTML5 a truly viable alternative, and so far, I'm unimpressed by everything I've seen. I would not consider WebGL a true contender here either, had it not been from the fact that it was Unity's fallback solution to having the Unity Web Player blocked on major browsers (primarily Chrome), nor would I even consider it an alternative had it still been in the state I 'found' it in a few years back, but clearly, things have changed. As developing in Unity (an established engine) is very fast, I was hoping to gauge how much time I'd need to invest in optimization and troubleshooting to make it work. Turns out that's roughly 10%, which given the alternative (HTML5 would've probably taken 2-3 times the amount of time it took to make the game in Unity, once again based on similar documented projects) is fairly cheap. Let's face it, there are a lot of people out there wanting to make their digital presence felt (I'm thinking about industry giants such as Disney, Warner, etc.) and HTML5 is making a serious dent in their marketing budget to achieve these results, so I was somehow hoping that the WebGL exporter would be an 'easy sale' but needed one or more proofs of concept. Death is Useful was going to be 'it'. The Return of Kongregate Another 'question' I've been asking myself steadily over the past few years is whether the so-called death of web games was real. With the relative decay of Flash, I felt a lot of people had assumed this meant the end of web portals, and for the most part, I think this is somewhat accurate, and the short-lived Unity Web Player didn't really endure. Players have come to expect a certain level of quality in their web games, which HTML5 couldn't really do on a budget, so in theory, that death was inevitable. On the other hand, some few key accounts from local and remote indie developers with whom I'm acquainted tested that theory. For obvious reasons, I'm not going to name names here, but the thought of turning up a profit of more than $ 8000 USD per quarter is certainly not something you'd expect from a 'dead' market. I understand a lot of developers couldn't justify a tech pipeline geared at web development for 'so little', but for the smaller teams, that's a very enticing offer. Though most of these revenue figures game exclusively from incentivized ads (ads that are tied directly with in-game rewards), I was curious about the demographics of the web games world in general and wasn't going to be very specific. Kongregate was a platform of choice for this 'test', as I've been a member since 2010 (and a lurker for much longer) and also participated to the release of a CCG that became #1 at some point (even though it was merely a port from a different platform). Suffice it to say I was well acquainted with the platform and knew the opportunities there. Kongregate was unique in that it provided a very healthy ecosystem for players with some metagame implications. All I needed was a project to test this platform, and it soon became obvious that Death is Useful was a perfect opportunity. Testing both a market and a technology at once may be risky, but I wasn't bound to any deadline, so it made sense. The Red Cell Awakens Death is Useful became 'Red Cell', rebranded after the decisively retro visuals and audio. I was born a bit too late to really experience the Atari and early Commodore days and always had a fascination for that era. I wanted to rebuild the game as something that would've fit a late 70s / early 80s arcade without limiting myself to the technology that existed then. The game concept was perfect for this, but the original perspective was fundamentally flawed as it was a 3D game. Besides, it wasn't really making great use of that 3rd dimension, so the switch was all the more valid. It took some heavylifting to reuse what had already been done (quite honestly, I should've gone full tabula rasa mode) but it helped me appreciate the kind of legacy code game-jams can generate. I wanted to give the game a 'Super-Hexagon' feel, as something that's infinitely replayable and simple to grasp, where most games take but a few minutes to play. Super Hexagon had opted for longevity through more patterns, faster game speed, etc. Given I'm an avid speedrun fan (and have some reasonable PBs on some of the retro titles) I wanted to make a game that was finite in nature, but one where you could beat your own score repeatedly. Kongregate was a great platform for this as they have a built-in score API which took some getting used to but was relatively easy to implement. Once I landed the 'best the game as quickly as possible' score idea, I felt I should also give other players an incentive to play, and added a few more score options (most mobs killed in a game, most mobs killed all time, etc.) Kongregate has something called Badges, which are achievements you can earn in games that give you a boost in the Kongregate user metagame. Unfortunately, developers can't make achievements, they can only expose scores and hope the editor picks the game up and implements 1-3 achievements based on the scores already implemented. So having more scores (some of them invisible!) was my tactic for trying to get the editor's seal of awesomeness, and the potential traffic that goes along with. I've developed the game on and off in my spare time for the past 2 months (alongside many other personal projects) and completed dev about 2 weeks ago. Given Kongregate has monthly contests, I figured I'd wait until the new month, and what better day than the one right before July 4th to release? (arguably, that release is very random, and I'm not quite sure how July 4 will play into monthly traffic). The Last Build All of this just to say the game was released today. It's not the most amazing thing on earth, but it is a fun minigame that has some potential (as far as web games go). It's also a business test I'm making on two different fronts (Platform & Technology) which, in itself, has a lot of value. As a result, I didn't see fit to make In-App Purchases, and chose to distribute the game for free (as in FREE free). I might get some minor revenues through conventional ads, which won't pay back for the time invested, and that's quite alright. I'm just glad it's finally out and people get to see it. The game is currently open to more development. I had a local 1v1 and coop 2 player game modes which I've disabled right before release. They work, but I feel they should have a few more features before being worthy of the game (chance to revive your friend when he dies in-game, etc.) I have ideas, but limited time, and quite honestly, I'm waiting to see whether the game gets any traction before investing more time into it. If you care to give it a try, here it is: - Game Link - Cheers!
  39. 4 points
    Yes. Don't understand what you are saying there, but in my opinion, you should use the GUI git tools for basic things like pushing and pulling and git shell/command line for more advanced things.
  40. 4 points
    Yes, it's realistic. If your plan is to just make games right now, you should use Unity or Unreal or any other existing technology. These will help you achieve your goal of making games and will simplify things so that you can just focus on your game logic. Of course you can always start from scratch if you want to know how things behind it work, but it's not recommended for a beginner as it can be frustrating and can burn you out.
  41. 4 points
    It depends on how you define "indie". Back in the day, we used to call the serious-hobbyist types "garage developers" -- dedicated enough to set up a work space in their garage, but not serious enough to actually be throwing enough money at their hobby to turn it into a business. Most "indies" fall into this category -- hobbyists. You should not expect to make (much) money from any hobby. You can sell your macrame and quilts at the local maker's market too, but it's not going to pay for 100% of your living expenses. IMHO that's an abuse of the word -- hobbyists are not "indies", they're hobbyists! If you define "indies" as small self-owned businesses though, then sure, plenty do succeed. I know plenty of indie studios in my town who reliably get every one of their games onto a Google Play and and iTunes "featured" slot, and into the top 10 charts, which gets them enough downloads to earn an income good enough to pay for a handful of full-time staff members. They do this by choosing to run a business professionally, not just make games as a hobby. This unfortunately requires money (capital) -- this is the way the world works for ANY business, you need seed capital to make more capital. There's also no reason to go it alone with the $132 in your bank account. Lots of cities have booming 'startup' scenes. You can go to silicon valley and come back with a million dollars (and a lot of contractual obligations) pretty easily, assuming you're taking your job seriously. Or even just getting a business loan from a bank (assuming you've got a serious business plan). Or applying for government (local/state/federal) grants and subsidies. Or just taking your business plan to friends and family and begging for startup capital... but again, this is what separates the business people from the hobbyists. If you want to make games as a hobby, accept that it's a hobby. If you want to make games as a self-owned business, accept that you're now an entrepreneur with a start-up business, not a game developer.
  42. 4 points
    Don't use strings. Use ID numbers instead. If you need to look up the string name of an item from its ID number, just index into a List<Item> using that ID, and pull the string off the Item itself - this is a constant time O(1) lookup instead of a hashmap lookup and string compare. If you want to go from string to ID, store a secondary dictionary, but be disciplined about moving to ID numbers as soon as practical in code, so you do fewer string operations. This is pretty much how the Guild Wars 2 item data works, for example.
  43. 4 points
    Learning programming typically goes a lot better if you are learning it to fulfill a secondary goal. That secondary goal may well pick your language/framework for you. Is she interested in robotics? Maybe look at something like Lego Mindstorms to start, and then move to Arduino later on. Is she interested in game development? Dive right in with Unity, so that you minimise the time-to-seeing-stuff-happen-on-screen barrier. And so on...
  44. 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;
  45. 4 points
    Virtual 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?
  46. 4 points
    That 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.
  47. 4 points
    It is absolutely true that exploits will always exist in some form. What is also true, and moderately less depressing, is that you can invest a bounded amount of effort to make the vast majority of exploits not worth it. In other words, you can ignore some exploits that just aren't a big deal, in exchange for defending against the ones that are a big deal. This is important from a cost/benefit perspective. If you get hung up on blocking every possible exploit, you'll exhaust your resources (and yourself) sooner or later. But if you let some things slide so you can focus on the important hacks, you can spare yourself a lot of work and preserve some sanity.
  48. 4 points
    The attacker fully controls the computer that the game client is running on. Just consider what someone can do with a virtual machine with full suspend/rewind/resume support, and you'll realize you cannot "lock up" the client. The attacker can decompile whatever code is being run on the client, as the client is run it, no matter how much you obfuscate or encrypt the code. Such measures simply don't matter to a determined attacker, because the code needs to be actually runnable by the CPU, and anyone with the right tools can take that instruction stream and disassemble it. Similarly, the attacker can look at all the data you send and receive on the network. It doesn't matter if you use HTTPS or some other kind of encryption, because the attacker can inject themselves in your network code before the encryption is applied. You have four options here: Decide that it doesn't matter if someone is cheating. For games that are largely puzzle games or other single-player experiences, a cheater would mainly just cheat himself. Does that matter at all? Build your system such that the interface to the server is the "game rules," and the data from the client is simply an expression of the players' desires. If the player desires to go left, send a "player goes left" command, and let the server figure it out. If the player wants to fire a weapon at 33 degrees, send that as a command. Do not use any messages that express specific state or events -- don't say "I now have 1000 gold" or "I hit player 3 for 89 damage." For fast-paced games, this will introduce latency, which you will have to manage by some time-traveling smarts in the game client and perhaps on the server. (All of the "multiplayer game models" write-ups you see online basically revolve around the different ways of doing this.) Decide that your game is not going to be particularly popular, and thus cheaters will not likely discover your game, and if they do, they will not be likely to actually want to spend a lot of effort on it. Research all the cheating tools, and keep a constant watch out on various user forums for your game, looking for exploits. Patch each of them as you find them. Study the cheating software in detail, and come up with a mitigation that works for each of them. Keep working on this, every day, for as long as your game is alive. Which one you choose is up to you.
  49. 4 points
    If you haven't measured your actual code with a profiler, now is the time to start. Blindly optimizing everything you can grab is a sure-fire recipe for spending a lot of time and being disappointed in the results. If you know what is slow about your code, you can make an informed decision about whether or not reading from an archive is going to make a significant difference in your situation. Engineering is a discipline. Don't give it short shrift by merely hacking at your load times.
  50. 4 points
    Introduction 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