Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 26 Feb 2007
Offline Last Active Today, 02:24 AM

#5230129 tile objects in 2D RPG

Posted by Ravyne on 20 May 2015 - 04:21 PM

In general, you would just store an index, UID, handle, pointer or other 'name' in each tilemap cell, which refers to data that describes that tile. That's the easy part -- you have one unique thing (the tile) that reappears in many places, so you tag each place with a way to find the thing, then look it up; this pattern appears all over the place, not just in maps, not just in games.


A more interesting question is how you want to store the map cells. The easiest way is using a 2D or 3D array, dynamically allocated so that you can load maps of different sizes. This can be a bit wasteful of memory (e.g. if you have 'overhead' map layers with lots of empty space, you'll store a lot of 'empty' tiles in those cells, but this is not a problem on modern systems, though it can be a large annoyance if you have just one or few very tall layers (you spend an entire layer to represent just a few overhead tiles, multiplied by the number of layers needed). You can have a 2D array where each cell is a linked-list, which saves that unused memory, but can be more costly to iterate over. Or you can store in smaller chunks (say 8x8 tiles) and stream in only the chunks you need. Lots of options with different properties and tradeoffs.

#5228427 Can I do MIMD on SIMD architecture?

Posted by Ravyne on 11 May 2015 - 02:10 PM

I think there was never hardware that executes real MIMD. Some stream processors support that kind of, they use VLIW and execute different operations on every register lane, but the instruction streams are always interleaved in one real stream, hence there can be no diverging branching.


The latest PowerVR Rogue architecture might be close -- given applicability to OP, this is a bit of a non-sequiter -- but its real silicon, and a non-SIMD GPU that can actually do divergent branching as I understand it.


For what its worth, I suspect that when we see real implementations, low-power applications will be where we do (the Rogue GPU is a mobile-focused part). From a power-savings perspective, avoiding power-waste due to executing both sides of a divergent branch and then reconciling results is wasteful of battery and generates heat needlessly.

#5228018 Back Face Culling idea

Posted by Ravyne on 08 May 2015 - 04:06 PM

A camera view vector in the world multiplied by an objects orientation matrix in the world, gives you a view vector in the model/mesh space.


...and then you need to transform the model into that space in order to do the backface culling -- the fact that you get to seemingly skip this step normally is because in camera-space you're always implicitly looking down the depth axis. I'm certain you could compensate by incorporating the view vector back in, but its probably not any less math in the end -- you have to do this for each vertex in the mesh, and then afterwards you have to do a real transform on the ones you keep (half, on average) -- whereas with the traditional order of things do the proper transform on all things and then throw out half (on average) -- not to mention you'd have to repack (e.g. copy) your vertex and index buffers new each frame.


There's just no win here.

#5227565 Average games length databse?

Posted by Ravyne on 06 May 2015 - 01:06 PM

I would echo that firstly it doesn't really matter what other games do, and state secondly that you're not going to get a statistically-accurate number of average playtimes anywhere I'm aware of, as very few (if any) games are actually instrumented to measure length of play; the only one's I can think of off the top of my head are Open-World games like fallout 3 or RPGs (both japanese and western-style). Any self-reporting is going to be skewed, firstly because people want to look better, and secondly because my intuition leads me to think that speed-runs are going to be statistically out-sized (so, you might get something closer to the average length of a speed-run instead of the average length and average player takes to complete the game as intended).


Since you don't have statistical accuracy, your own educated guess about game length are probably as good a basis. For example, I'd say that the average length of a traditional FPS single-player campaign is around 15-20 hours, but could be as few as 8-10. Keep in mind that those figures are the length of the critical path, and discounts failed attempts and false-starts.


Perhaps a better way to approach the question is to name the genre(s) that interest you and poll the community for their own gut-estimates, and then averaging those answers to benefit from a larger sample size than your own experiences.

#5227549 How 3D engines manage so many textures without running out of VRAM?

Posted by Ravyne on 06 May 2015 - 11:52 AM

So you would have a pool of, say, 20 textures at a given resolution (let's pick 512x512 for the purposes of this example).  If one of those textures is no longer needed at runtime, rather than destroy it, you would just reuse the texture and replace it's content.  In OpenGL this means a glTexSubImage call, in D3D a LockRect or Map.


Right, and in the new APIs like Direct3D 12 it takes things even further, as I understand. You just have reserved pools of memory which are only typed by the context you use to describe them, so you don't have to re-use a texture of the same size, just another resource that fits within that space, and you can join adjacent vacated memory areas together. The API adds fences to notify you when a resource is no longer in active use so that you can track what you might be able to over-write if you need. Then, there's also support builtin for large virtual textures that are paged in as needed.


Another trick to optimize texture occupancy is that when a particular model is far away, you don't need the full-resolution texture, and so you don't need the largest mip-maps -- every top-level mip-map you can get rid of reduces the amount of memory occupied by 75% -- so a compressed 2k texture occupying, say, 10.6MB (8MB 2k + ~2.6MP mip-maps) would be reduced to just that 2.6MB (now 2MB 1k + 0.6MB mip-maps), and if you reduce it again it occupies just around 600KB (512KB 512p + ~88KB mip-maps). 

#5227451 "True" MVC-Concept in games

Posted by Ravyne on 06 May 2015 - 12:55 AM

Servant summed up what seem to be the three most-common approaches to leveraging design patterns, and of the three I agree his third is the most correct usage.

But I think there's a subtle distinction that's really important, and its so subtle, in fact, that I think I neglected it myself, today, in a response to an earlier thread.

We don't call patters 'formulas' or 'recipes' because we can't just reproduce them for wrote, but at the same time, we call them patterns because they outline a robust solution to a recurrent problem -- so patterns are something more than just language applied after the fact (though often you might find that you've inadvertently applied something that looks like pattern without realizing it), and can be used to help reason about design and architecture.

Crucially, a pattern in a design-phase (prior to or during code production) should serve as inspiration for a solution to a problem or requirement that you have, or will probably have, but it should not inspire you to create problems or requirements that you would never have had in the first place.

#5227415 "True" MVC-Concept in games

Posted by Ravyne on 05 May 2015 - 07:39 PM

The MVC pattern (or MVVM, or Presentation Model patterns), even when not using them to create different views, can be useful in as much as it tends to enforce a separation of game logic from presentation, which can make it easier, for instance, to create a headless server for your game.


In a game scenario:

  • The Model in MVC is the simulation and game logic layer -- all the data and processing that represents the state of the world and the actions you can take on it. If we were to look at the pattern from a client-server perspective, this is the server.
  • The View in MVC is the presentation layer -- it observes the model (which, remember, is the 'state of the world') and 'renders' it. The view might also have some strictly-presentational state of its own -- for example, your presentation layer might know whether or not it is displaying a debugging overlay, and conditionally observe relevant debugging information based on whether it is or isn't, rather than always observing but rendering it conditionally. If we were to look at the pattern from a client-server perspective, there can be 'views' on both the client and server; on the client, the view graphically renders what the client sees within the world; on the server, you might have a 'view' that presents only the information that's relevant to a particular player and sends it over the network. In a game, a View might be fairly rich if it has to support features like dead-reckoning or other temporal displacements, or if it supports any physics on its own (say, for example, that usually particle systems aren't and don't need to be 100% replicated across player views for visual purposes, just its placement and characteristics).
  • The Controller in MVC is the input layer -- This includes "raw" input from keyboards, mice, or joysticks that, after being baked into high-level commands, is usually sent to the Model (but could *also* be sent to the View for e.g. dead-reckoning to hide network latency in a client-server game), but also UI commands such as those generated when you click an icon in the GUI (these inputs are generally filtered through the View, or otherwise work in conjunction with the View). Controllers can also be used in other interesting ways, such as for implementing AI baddies or pre-recorded demo play (if your game is deterministic and begins in a known state, then you can record a game session just by recording input commands and playing them back). If we were to look at the patternf rom a client-server perspective, there can be controllers on both the client and the server; on the client the controller is responsible for letting the player send game commands; on the server, a 'controller' (paired with a suitable View) could be an AI player, or could represent the last-known input state from a remote player (or could be the local player who is hosting a network game).

All that said, be sure that the pattern is worthwhile for what your needs are, and weight the costs vs its benefit. It does introduce some additional layers of indirection, and it can make debugging somewhat more difficult (though, you can build logging or other facilities into your layers to help out). It can be a relatively high cost to do correctly (and you really have to do it correctly to reap all the rewards) and the payoff for simple scenarios can be slight, especially if there's little churn in the presentation layers. On the other hand, the potential payoff is worthwhile if you're going to make use of what it makes available.

#5227394 Agile methodolog

Posted by Ravyne on 05 May 2015 - 04:04 PM

A PM in my experience is generally one part facilitator, one part representative, and one part vision.


Their job is basically to help work get done, ensure that the work produced is a valuable contribution towards the vision, and to develop and/or communicate that vision with other stakeholders who might come from diverse perspectives (e.g. even non-technical ones like marketing or legal) -- they're the driver of aspirations and single authority for the ground-truth of the product, project, or feature.


I don't think Agile conflicts with that particular definition, but the particulars of the job description change from place to place -- even from team to team within larger organizations. That said, if adopting Agile methods changes what you used to call PMs so much that they're made redundant or nigh unrecognizable, then perhaps you never really had 'PMs' to begin with, but something else entirely.


Keep in mind also, that Agile methodologies are a a kind of management pattern -- just like software patterns (e.g. Observer, MVVM, and such), they're a somewhat loosely-defined and amorphous body of features who's purpose is to address a recurring challenge flixible application, rather than to demand that the challenge bend its shape to suit the solution. Even though there are books such as Design Patterns by the Gang of Four that enumerate and detail such patterns, there is still no One-True-Visitor pattern, just features of a solution that looks enough like other solutions to similar problems that we collectively call the Visitor pattern, with each solution learning from those before it and shaping the particulars to their precise needs. Likewise, Agile, or any other pattern of management should be applied in the same flexible way, learning from predecessors, taking what works, cutting what doesn't, and inventing new things to fill the gaps. Over time, as enough people have gone through that process, there begins to be an outline of a shape that tends to define a greatest-common-denominator, and what people are generally referring to when they say "Agile" is this core + modifications that are appropriate to your organization or project. No extant project fits perfectly with Agile methods as described by any one source, nor should any new project strive to. At the end of the day its about shipping a product or a feature with consistent quality, on a schedule that doesn't surprise anyone, and without overworking the labor.

#5226569 Interested in creating new game engine for a space adventure game; questions...

Posted by Ravyne on 30 April 2015 - 02:46 PM

Microsoft and sony might not like me to release a game wth that type of loophole, hut keeping it hidden in the developers console and through some code masquerading to obfuscate the intention on the platform relase could get me by


No it won't. And if your intent is to subvert the platform sandboxing you'll be at least exposing yourself to a permanent ban from their platforms (an friend once tried to sneak something past Apple by hiding it and removing the feature announcement from the changelog. He got found out anyways within a week, and the stunt earned him a two-year ban from the appstore, and was not something so serious as a security hole) -- and you might even expose yourself to liabilities.


Assuming that there's actual gameplay intent -- what does running a real linux kernel buy you, exactly? Device drivers -- nope. Hardware support -- nope. Useful applications -- unlikely.


Something that felt more or less like Bash, supported any of the usual command-line apps that might be useful in a game environment (grep and friends), and python scripting or something would probably feel sufficiently "linuxy" and be far easier to integrate.


Embedding a VM into an app is an interesting question on its own, I just don't see what advantages it brings to gameplay.

#5225705 Screen resolution & map size

Posted by Ravyne on 26 April 2015 - 02:46 PM

Since you've mentioned Tiled, I'm assuming you are making a raster-style 2D game (retro perhaps), rather than a 2D game with traditional cell-style animation (more like a cartoon). 


A concept that you'll eventually come to borrow when trying to make this kind of game work is the action-safe zone, which comes from the film industry. Basically, in film and television you won't see important things or text at the very edges of the display, because it might not be visible on some displays due to how they're manufactured or calibrated. In a 2D raster-style game you have the same thing only the motivation is that your game might be run on platforms with rather different resolutions and aspect ratios. So what you want to do is collect all the resolutions and aspect ratios you want to target, layer them on top of one another, and see what the common area that they all share is -- you have to design with this minimal area in mind, because its what you can guarantee the player will see. Likewise, you have to then look at each platform separately and consider how much larger that platform's screen is than this common area -- if you're going to fill that area with more view, you now have to consider how that impacts the gameplay experience. For example, in a competitive game, does it give an unfair advantage to a player with a certain screen size? In a single-player game, does it make a secret that's hard to spot on some platforms super-easy to spot on others, and do you care?


How you deal with that can vary, but usually its a combination of scaling and letterboxing (instead of black bars, you can add or rearrange HUD elements if you like, or add decorative borders). All of this is just to deal with different aspect ratios.


In a raster-based game, after you've decided how to deal with aspect ratios, then you can think about how that impacts your art production parameters, like the sizes of tiles, characters, UI, and maps. If you need pixel-perfect art, then you need to make identical art at several resolutions, picking the one that's most appropriate for that platform -- it sounds like a lot of work, and it is, but its the only way to get pixel-perfect results. You can reduce this work somewhat by scaling-up smaller assets, and by playing with your action-safe zone to allow for reasonable compromises between platforms who's needs are close. (You'll also want to weight the importance of particular platforms based on how much of the market they have (e.g. its probably a good idea to cater to flagship devices like iPads, GalaxyTabs, Kindle, and HDTV resolutions). If you scale up, but want the classic sprite-style look, you can apply the family of Scale2X algorithms to avoid the blurriness associated with up-scaling graphics using things like box-filters.


In a tile-based game, I like to think of dimensions in two fundamental units, tile-size and screen-size. The screen-size is defined in terms of how many tiles high and wide I want it to be, which gives me the tile-size. Then, going the other direction, I think about how large I want my map to be in terms of how many screens tall and wide it is. Its the basis for other relationships too -- I tend to think of how fast I want my characters to move in terms of how quickly I want them to be able to traverse a screen.



I'll give you an example from my most-recent project, which is a retro-styled, sci-fi action RPG -- think Legend of Zelda in Space.


Starting with target resolution, I want to treat HDTV resolutions as the primary target -- this is a console-style game, and consoles mean televisions. So we have 1280x720 and 1920x1080 accounting for 99% of modern televisions, plus the most popular PC monitor sizes (1080p is popular on desktops and laptops, 2560x1440 (2x 720p) is popular, 1366x768 (nearly 720p) is popular, 4K (3840x2160, 2x 1080p) is going to be popular). I decided that I wasn't going to care about different aspect rations, and that I'll just letterbox if I have to. In fact, I decided to keep a retro 3:4 aspect ratio for the playable area, and use the extra space for decoration and UI.


Since I want that retro, chunky-pixel look I had to select a resolution that's a good common denominator between 1080p and 720p. It turns out that the greatest common denominator of the two is 640x360 -- multiplying by two is 720p, multiplying by 3 is 1080p. It also means I can give users a choice between square pixels, or using scale2x and scale3x if they prefer. Because I want the 4:3 aspect for the playable area, this means its 480x360, with 160x360 left over for UI.


Next, I need to determine tile size -- usually you want a power of two, so 16x16 or 32x32 would be a go-to size, but I didn't like the scale they gave me -- ~20 tiles high would make things things feel smaller than I wanted, and ~10 tiles high was too constricting for the level design. I looked at the old consoles, and using 16x16 pixels, they all had around 15 tiles high to work with -- translating to 480x360, that gives tile dimensions of 24x24. Not a power-of-two in size, but a nice number of pixels to work with, and the technical reasons for power-of-two's benefits aren't really much of a thing these days.


So there I had it, I settled on a resolution of 640x360 (16:9 aspect), with a 480x360 playable area (4:3), with each playable screen consisting of a retro-inspired 20x15 tiles, giving a retro-appropriate tilesize of 24x24 pixels. It scales directly to the most popular screen sizes, and with minimal letter-boxing to others; but the 4:3 aspect ratio of the playable area gives me some wiggle-room to play with too -- for example, there are some tablet devices with 3:2 aspect ratios, which is just a hair wider than 4:3 and doesn't leave enough room for extra area dedicated to UI, so on those devices I can letterbox (or maybe draw ~1 more tile to either side), and lay the UI over the playable area with transparency.


For me, my game, and the devices and experience I'm targetting, I'm super happy with how this all works out. If I were to do an iPad version (given its market penetration, I'd tweak the rendering to draw an extra half-tile around the parimiter, and maybe redo the UI at high-resolution (I might even redo the art with 48x48 tiles and possibly even sell it as an add-on). On super-wide devices like an iPhone6, I'd go the other direction -- I'd redo the art at 20x20 pixels, and layout the UI differently, and have the virtual controls in the letterbox area to either side of the screen, such that the player's thumbs don't obscure the playable area.

#5225688 Why Does Everyone Tell Newbies To Make Games?

Posted by Ravyne on 26 April 2015 - 12:42 PM

There tend to be two types of newbies -- the humble ones, and the ones who have delusions of grandeur and immediate gratification.


For the former group, they can usually met the challenge and they're willing to take things one step at a time. They know what their skill level is, and realize they can't learn everything at once. They might fail, they might bite off more than they're ready for, but they'll learn from the experience regardless.


For the latter group, they have no grasp of the realities of game development and its probably best to knock them off their cloud as soon as possible. Often times, they only way to humble them is to utterly fail at that thing they think will be so easy. They need to attempt and fail at making a game before they're really ready to learn.


But you're right that everyone needs a grounding in programming before they can take on a game. And I don't just mean syntax or basic code engineering skills, I also mean problem-solving and math skills, and most importantly they need a baseline skill-set, domain knowledge and self-confidence to recognize and reject the poor advice they'll innevitably find (AKA -- they need a good bullshit detector). Real-time games have lots of moving parts -- parts that move all at once, no less -- and that's a lot different than turn-based games (most text games, many puzzle-style games), the complexity of orchestrating that is a lot to get your head around -- and that's to say nothing of the plumbing that lets any of it happen. Those skills necessary to wrangle this kind of complexity build up upon one another, I'm not aware of any way to skip right to the end.

#5225325 I'm trying to make a GBA game in C

Posted by Ravyne on 24 April 2015 - 02:51 PM

The best way to develop GBA roms is using an emulator, both for the greater turn-around time, and the availability of easy debugging.


No one ever really produced "blank carts" for the GBA -- not as in "I can load my program on here and sell them". There were flash-carts, which are developer tools for people like yourself to be able to test, carry, and show off your work (and which could also be abused for piracy) though. Today, no one I'm aware of is still manufacturing or retailing any GBA flash-carts. The best you can do is probably Ebay -- see what turns up when you search for "GBA flashcart" and do your research on what turns up because plenty of flashcarts have limitations and bugs that you might be happy with. If you can find and EZFlash 4, though, that one seems to have the best reputation -- I picked one up on Ebay a couple months back for like $70.

#5224896 GPU Ternary Operator

Posted by Ravyne on 22 April 2015 - 12:51 PM

I don't know for certain, but detecting a "complex" (with an inline expression) or "simple" (a < register-sized value) ternary expression is trivial -- CPU compilers have detected this (and equivalents, expressed as if-else form) for ages and transformed between the two instruction sequences as needed, regardless of ternary or if-else form.


I also would presume that if even one of the operands is "complex", then something more interesting will happen -- either it devolves into a branch, or possibly it would pre-compute the result of the complex expression and then do a CMOV-type operation substituting that result for the expression. For simple computations, the latter might be faster as it avoids a branch, but it might not be so for a non-trivial expression.


Now, be aware that as soon as there's a possibility of a branch there's also a possibility of a divergence if even one thread in the warp/wavefront goes the other way, which is what will really kill your GPU perf. If you have a mixed case -- that is, one simple and one complex operand to the ternary expression -- then you might want to consider doing that pre-computation of the complex operand yourself to help ensure you avoid branches.

#5224594 software contract (good or bad)

Posted by Ravyne on 20 April 2015 - 07:32 PM

Yes, it sounds like a bad deal -- particularly if that "you cover the costs of what you can't develop yourself clause" is worded or interpretted broadly -- as in "You're on the hook to deliver the software you promised us, and if that means you have to farm out the whole thing, that's on you, even if it puts you in the hole." I wouldn't assume any risk that is not my own on behalf of another entity -- not for a 15% stake -- If I'm assuming equal risk, I would want a commensurate portion of the company/project.


Accepting a percent of earnings (by the way, net or gross? There are horrible loopholes here that can screw you -- just see how the movie industry uses shell companies to make it look like they didn't turn any profit at all.) can be a savvy move, but I would not take that as sole payment. Your costs and your dev time don't work on a percentage basis, they have real, nominal costs. I would seek up-front, milestone-based payment for my costs at least (plus either a fixed profit or a percentage).

#5224592 do float operations give different results in different GPUs?

Posted by Ravyne on 20 April 2015 - 07:21 PM

Its probably just a bad idea to rely on exact, bitwise equality for any floating point number on any real (digital) floating-point machine, unless you are absolutely sure that you can gain and maintain complete control of that environment. I would imagine that even a super-scalar floating-point unit must have potential to make things go haywire, given non-deterministic scheduling, and how floating point error naturally and inevitably accrues. Such super-scaler systems are invisible to the programmer (I suppose there might be ways (settings, fences) to explicitly control execution order, but not sure what real systems provide, if any) and what they do can be affected by what other external processes are in flight (or maybe have just ended).


If you have a fixed platform with fixed input and a known starting state, you can probably rely on bitwise identical results, but it all goes out the window if any of those variables change.