• Content count

  • Joined

  • Last visited

Community Reputation

319 Neutral

About zuhane

  • Rank

Personal Information

  1. Shameless bump. Thanks for the replies, guys. Does Lamentation's idea seem to be the most solid? Still not exactly sure which route to take.
  2. Thank you all for the comprehensive and detailed replies. @LorenzoGatti I'm surprised that this approach (mentioned in question 3) has been adopted by Terraria. I think it surprised me because it's such an incredible and ambitious game with such talented developers that you'd except camera work to seem trivial compared to the scope of that they've created, but I suppose given the genre of game it can work. As for my game, I feel that framing is very important and this cannot be the case. @Alberth As for the art assets, I'll be creating all of the art assets once, with the exception of a few GUI assets that may need scaling differently. However, I won't be zooming the same assets at different levels at once, as I feel that different levels of pixellated zoom combined together looks horrific. As for downscaling, I don't think I could apply it in this scenario. I'm hoping to appeal to a more retro audience who might appreciate the pixellated look! I also like the ideas for obscuring areas of the level until you enter them, and I think I'll be taking that approach in level design. @Kylotan It seems silly, but being told that you can only choose one of the three options seems to have just given me absolute clarity about how I should approach this. It seemed confusing trying to fight over which elements to meld together, but now I think I'll go for the letterboxing approach. On the topic of letterboxing, I take it that developing for the most common aspect ratio will thus reduce the size of the letterboxing margins for most aspect ratios, since there's less difference between some of the more common aspect ratios, rather than hypothetically designing a game in, say, 10:1 (stupid looking) aspect ratio, for example? As for the actual view of the game, if I wanted to always show the same slice of the game on every resolution, would I be picking a uniform size to display and then working my way down by letterboxing appropriately? It's hard to explain what I mean using text, but as an example: Say I develop the game to have this arbitrary field of view. The game's tiles are 30x30, so I'd want the FoV width and height to be divisble by 30. So let's say I arbitrarily create a view of 600 x 300. If I had a monitor with a display of 600 x 300, the game would essentially display like this: this is the slice of game world I always want to display for the rest of the game. Say now I change the resolution to something bigger, like 1200 x 600, I can just double the zoom since it's exactly double the size and the aspect ratio will cause it to fit perfectly with 2x zoom. However, if I increase the screen resolution to something of a different aspect ratio, such as 1100 x 800, I get a different effect. Using the Terraria approach, I'd just end up with a larger camera boundary displaying more of the level, like so: This isn't what I want. So essentially, I'd rather have it so it maintains the same framing regardless of monitor size, like so: Given that the native FoV does not go into this new resolution perfectly, would it mean that I could not 2x the display and would essentially have to create absolutely huge letterboxing as shown above? (Given that 600 x 300 does not go into 1100 x 800 to produce a whole number) Alternatively, if had a much bigger resolution that went over 2x, could I increase the zoom and letterbox less? This is hard to explain, but say I have the native display of 600 x 300, and a monitor is 1300 x 700, I could essentially double the size (1200 x 600) and then simply letterbox a margin of the remainder, i.e. (1300 - 1200 & 700 = 600) = (100 x 100), meaning that I could essentially display the original display at 2x zoom with a margin of 50 pixels each side of the display? Producing a result more like this: As I say, it's hard to vocalise such an abstract concept without actually showing you in person what I'm talking about, but if it essentially goes into a higher resolution with leaving a remainder then you get a perfect scaling, and if not, the remainder is used as the margin?
  3. Hello forum people. So after years of being an independent developer with a degree in computer programming, I can safely say that I can't find a single resource that thoroughly scours and glosses over every single aspect of game resolution. I have loads of books on the subject, coding knowledge, and a repertoire of games I've made in the past - but these projects have always used fixed resolutions or workarounds to support other resolutions. After posting on various forums and asking around, people seem to just redirect me to resources about resolution which are still incredibly lacking and bare-bones, not teaching me more than I already know. Since resolution is such a huge and inherent part of game design, and since there is not a single game **EVER** developed that doesn't use a resolution, I am so surprised that there seems to be such a lack of material on the subject! It is a fundamental part of every single game in history. So this post will be asking a load of questions all about resolution. What I am also proposing is that if I can gain enough ground on the subject, I'd like to create my own video/page/tutorial which brushes over every single aspect of game resolution, aspect ratios, etc. **So with the introduction out of the way, here is my current project and the tasks I could use help with:** ---------- So I'm currently working solo on a 2D platformer, called DEA, which uses pixel art for the main game stage, and a mixture of raster-based (but not "pixel looking") assets for the far background. The genre/style of the game isn't important, but if you're interested, the blog link is here: DEA Game Blog Anyway, I wanted to just go through how the camera works and then what doesn't work and should work. Firstly, my camera does not scale the main stage based on resolution, so increasing or decreasing the resolution simply increases the camera size and gives a bigger or smaller view of the game world, centering on the player. Below is a hypothetical screenshot at a lower resolution: and shown here the same still of the game at a higher resolution: Now the forum formatting actually scaled the images and made them look out of proportion, but they remain the same level of zoom, and no images are scaled. I believe that the Terraria developers take the exact same approach to their game resolution, giving players with higher resolution monitors an advantage. This essentially means that at higher resolutions, a bigger slice of the game world is basically displayed on-screen, like so: However, because of the nature of Terraria's genre, it doesn't seem to be a huge problem. My game has a competitive multiplayer element, but it's couch co-op without online play, so people with better monitors won't be given a competitive edge. From my understanding, games that use vector-based graphics (or even rasterised graphics with high resolutions) don't give a larger screen view. Instead, they simply scale all of the graphics to always fit within the same proportions regardless of resolution. My understanding of this is like so: So with this, the game is displayed in the same proportion on every resolution, but a higher resolution simply gives a much crisper image, meaning more "image pixels" are displayed per "screen pixels". This is nice, because regardless of screen monitor size, everyone will get the same experience. ---------- So from my understanding, is it easy to change the zoom levels to allow for this proportioning when using vector-based graphics, because the graphics will scale accordingly, and maintain a "clean" look when stretched and transformed. Pixellated graphics or "8-bit" style graphics can't be stretched using float values because of their strict 1x1 pixel ratio, so when applying a zoom effect to games using pixel art, the zoom has to be in uniform whole numbers (i.e. 1x, 2x, 3x, 4x, etc). I've detailed this out below with examples from my game: This means that we can't recalculate sizes of pixellated sprites to accommodate every resolution, surely? It seems that the actual viewport size of the camera can be changed, and zoom can be manually changed (maybe in the options menu) in whole number intervals. However, is there no truly "smart" way of handling resolution in games that use pixel art? ---------- This brings me to my next problem. I've seen that a lot of modern "retro-style" games use other tricks to handle varying resolutions. The most common I see is the toss-up between "true" resolution and letterboxing, giving the player the option to either play the game in a distorted-looking aspect ratio, or to play at the intended aspect ratio, but to have the game "letterboxed" to look like a widescreen film. As an example, I tried loading up Owlboy (amazing game btw) and went straight to the options: The first thing that I noticed is that if I enable letterboxing or disable it, nothing actually happens. My monitor resolution is 1920x1080, and the game seems to run in that resolution, as the Steam overlay fits in the clearest and densest resolution. The graphics seem to be scaled absolutely perfectly with no distortion. My only guess as to why this is happening is that the game was developed with resources for a 16:9 aspect ratio, meaning that any resolution of the same aspect ratio will not distort the image, and any resolution of any other aspect ratio will adopt letterboxing to maintain the same ratio. My understanding of this is as follows, but I'm not sure if this is correct: Judging by all of the complications and horrors that come with managing resolution-independence, the Terraria-esque approach seems to be the easiest by far, giving players the option to choose a "zoom" level, and allowing the resolution to represent the amount of screen coverage. However, this seems to leave on huge, gaping problem in the game's design - A good rule of game design is to direct the player's attention using correct framing. You want to draw the player's attention in a certain direction using lighting, colours, movement, etc, but if the level is all displayed, this really draws this power away from the creator. In addition, if the resolution is too low, this will lead to the player maybe not having enough time to react to an upcoming trap or enemy, as their screen view doesn't encapsulate the thing ahead. Finally, on the converse, players playing on high resolutions will simply be able to see everything ahead of them, removing any element of surprise from your level design. Should resolution really be this complicated? I feel like it's melting my brain into mush. Also, I haven't even begun to start with the problems that arise with parallax scrolling... With my huge, confusing rant in mind, my questions are: Is there a smart way to handle aspect ratios with pixel art? It seems like art can only be stretched in a 1x1 ratio and zoomed in intervals of whole numbers, meaning that every resolution cannot be "truly" supported. Is it better to create art for the most common aspect ratio (such as 4:3 or 16:9)? Would this be neglecting other audiences with different aspect ratios, or would letterboxing fix this issue for different aspect ratios? Is the "Terraria" way of doing things much simpler and more accessible to all developers? If so, how would one go about "framing" a scene, so that people with lower resolutions won't miss part of the scene? Would the developer be limited to creating smaller levels that always fit within the smallest possible resolution? Is it simply better to say "f*** it" and develop the game in one resolution, and let people with large, high-resolution televisions suffer and have to deal with a pixellated mess to save buckets of time? Does this not exclude the couch-coop audience who prefer to play in a living room? ---------- Any and all advice and correction would be greatly welcomed, and hopefully this can all eventually be collaborated into the "Ultimate noob's guide to resolution and aspect ratios".
  4. Hello there!   I'm currently still working on a game project which will be heavy on music, sounds, graphics, etc.   I've also created an editor which allows you to pick the music, sounds, graphics, etc, for each level.   Currently, however, both the editor AND the game solution contain some of the exact same resources, such as tilesets and MP3 files, as the editor needs to show the creator how the level will "feel", and obviously the game project itself needs to contain these graphics and sound resources.   I wondered whether it was possible to get both of these separate solutions to reference the same folder, ie: have one single folder containing the game's soundtrack, which both of these separate solutions can access. I understand that the content pipeline in XNA is responsible for all kinds of encoding malarkey, and it saves us a monumental amount of time, so trying to subvert the content pipeline makes life more difficult. Is there a way to feed in a different directory to the content manager so that the music could be loaded from, say, my desktop, for example?   I'm constantly moving the project around, either via the internet, USB, networks, etc, and all of these resources are the slowing factor, as the solution itself is very lightweight. Any insight would be massively appreciated!     PS. It's also worth mentioning that it'd be nice to give players the freedom to be able to drag their own MP3s into a "soundtrack" folder allowing them to change the soundtrack manually if desired.
  5. All sorted! Close up the thread if you want. In case anyone's curious the solution was this: case ButtonType.TileType: var values = Enum.GetValues(typeof(Map.WorldTileType)); foreach (var enumString in values) { elementsList.Add(new DropdownElement(rectangle, enumString.ToString(), i + 1)); i++; } break; case ButtonType.BGType: var values2 = Enum.GetValues(typeof(Map.WorldBackgroundType)); foreach (var enumString in values2) { elementsList.Add(new DropdownElement(rectangle, enumString.ToString(), i + 1)); i++; } break;
  6. Thanks, Nypyren. I'll have a look into it!   EDIT:   So what I essentially have at the moment is this:     http://gph.is/2aoLpxg     It's a simple system. I have a Dropdown class which gives the dropdown its graphic and identifiers, then each dropdown contains a list of DropElements, each containing its index within the Dropdown and some string to signify exactly what it is. I have the selection, etc, all coded, and it works fine. However, when it comes to initialising each Dropdown box with its elements, I'm having to manually enter each string. What I'd like to do is create a loop which checks every value within an enumerated type. I'll show you what I mean as an example.   Here is the current hacked and ugly method for initialising: public void InitializeElements(ButtonType inType) { switch (buttonType) { case ButtonType.Gravity: DropdownElement e = new DropdownElement(rectangle, "0.3f", 1); DropdownElement e2 = new DropdownElement(rectangle, "0.4f", 2); DropdownElement e3 = new DropdownElement(rectangle, "0.5f", 3); DropdownElement e4 = new DropdownElement(rectangle, "0.6f", 4); elementsList.Add(e); elementsList.Add(e2); elementsList.Add(e3); elementsList.Add(e4); break; case ButtonType.TileType: DropdownElement e1 = new DropdownElement(rectangle, "Grassland", 1); DropdownElement e12 = new DropdownElement(rectangle, "Desert", 2); DropdownElement e13 = new DropdownElement(rectangle, "Beach", 3); DropdownElement e14 = new DropdownElement(rectangle, "Jungle", 4); elementsList.Add(e1); elementsList.Add(e12); elementsList.Add(e13); elementsList.Add(e14); break; } } I instead want to put this into a loop format, which I understand how to do, etc, but I'd to extract the string names from each element in an enumerated type within a different class. So I also have a Map class, which contains many enums, an example being: public enum WorldBackgroundEffect { Nothing = 0, LightRain = 1 } public WorldBackgroundEffect worldBackgroundEffect = WorldBackgroundEffect.Nothing; public enum WorldTrackPlaying { NoMusic = 0, Fila1 = 1 } public WorldTrackPlaying worldTrackPlaying = WorldTrackPlaying.NoMusic; public enum WorldCameraType { AutoCamera = 0, FixedOnCenter = 1, FixedOnPlayer = 2, SmashBrosWithoutZoom = 3, SmashBrosWithZoom = 4 } public WorldCameraType worldCameraType = WorldCameraType.AutoCamera; So is it possible to be able to initialise the camera dropdown, for example, by doing something like: public void InitializeElements(ButtonType inType) { index = 0; foreach (something in Map.WorldCameraType) { index++; string inString = something.MakeThisAString(); DropdownElement e = new DropdownElement(rectangle, inString, index); } } Help would be greatly appreciated!! :D
  7. Hello chums! So the editor aspect of our game we've been working on for the best part of four years is finally complete! This is a big day for us :D The next target is for us to throw in a few advanced features for the more tech-savvy players to be able to create levels that are more catered towards their needs. With this in mind, we've started working on some advanced features for the editor. Basically, if the user has created a new level, before they can get their hands on the canvas screen and start editing, they have to fill in a few basic fields about the level:   The user first enters the world name, level name, ID and author, with each field using a simple text input and converting the fields to strings.   Other basic things such as a ruler grid, etc, can be toggled on and off with single toggle buttons or sliders.   All of these fields are saved into a temporary get/set class which is used for the XML later if the map is saved, and the process is rather simple.   However, the user needs to be able to specify many other things about the maps in the level, such as the weather, type of background, gravity modifiers, soundtrack, ambience, etc. These last variables in design are basically concrete options that don't change, so having the user have to type "Grassland1" or "FilaBrazilliaTrack01" on every single map just seems silly, especially since it takes so long and also provides errors if there are typing mistakes, and that each level will consist of multiple interlinked maps.   My approach to this would be to create some kind of combobox or dropdown box from the ground up where the user can instead select from a number of predefined selections. So for background type, for example, they could choose from an enum of:   CityScape1, CityScape2, CityScape3, Forest, Canyon, Seaworld,   etc...   I'd like to design some kind of combobox that essentially accounts for how many elements are present within that enum, so that if we are to add more options in the actual code, the boxes will account for these new options, and display more or less options depending on the size and type of enum. However, it seems that within C#/XNA you are unable to pass the generic type of enum through parameters, and would have to manually implement every available option into each dropdown box.    I'd like to create some kind of cyclic format that allows the user to cycle through all the available options, and accounts for different enums, so the music dropdown would use all of the elements of the music enum, the background box for the background enum elements, etc, without having to manually create some kind of complicated system which converts the selections into strings and back again each time these fields are modified.   It's also worth noting that I'm not using forms, so everything present in the editor is created in XNA (this is purely for aesthetic purposes, as the editor is animated with little jingles and particle effects to give it a sense of accessibility and fun), so I would be created some kind of object from scratch.   Does anyone have any recommendations about a good way to go about this?   Thanks :D        
  8. Thanks so much for the help, people! This has really given me a good understanding of components. Of course I'll also need to do plenty of my own research to get a full grasp of the situation. I'll try and get some examples up of my code in the near future once I've implemented it!
  9. This is certainly very interesting! I essentially get the impression that I'm trying to remove as many dependencies as possible. I've read from quite a few sources that "good code" is basically code that, when changed, has the smallest possible impact on the rest of the code. I did wonder whether every programmer had to deal with this level of mental strain, and it's really reassuring to know that this is a common problem.   As I've developed my programming skills, I've found that the actual logic and syntax side of coding has become almost second nature, and small "hacky/hard-coded" projects are simple to develop because there is a simple and achievable end-goal. It seems to be large applications with these huge dependencies that become complicated, as they have to be designed to be "future-proofed". I also feel like once you reach a certain point with inheritance, it almost becomes impossible for the human mind to grasp, not due to lack of understanding, but simply because you have to store all of these variables in your head as you code (almost as if your brain's RAM is bottlenecking your brain's processor if that makes sense)!   I'm currently researching both component/entity systems and also the SOLID design principles and I can see that they both provide immense compartmentalisation and allow you to focus in on a single problem at hand without thinking about all the dependencies elsewhere and whether what you're writing will cause problems further down the line.   So from what I've grasped so far, a component/entity system deals with entities based on what they contain rather than what they are. Am I correct in assuming this? I'd like to apply an example if that's okay, just to make sure I'm understanding this correctly!       So, for example, say I have a base enemy class:   This base class will handle damage input (rectangle, points of damage, source of damage, etc), animation, position, and all shared behaviours. So rather than handling this behaviour within the class itself, I would be handling the logic outside of that class? So with programming conventions side, is it about operating on the upper layer rather than inside the class to an extent?   So instead of this: class BaseMonster { protected virtual void ReceiveDamage(byte damage) { this.HP -= damage; //More damage logic } } class GameSpace { byte incomingDamage = 1; foreach (BaseMonster B in monsters) { B.ReceiveDamage(incomingDamage); } } Would it be more a case of: class BaseMonster { //No damage handler method } class GameSpace { private void Main() { HandleDamage(monsters); } private void HandleDamage(List<BaseMonster> monsters) { int incomingDamage = 1; foreach (BaseMonster B in monsters) { B.CheckForDamage(incomingDamage, B); } } private void CheckForDamage(int damage, BaseMonster target) { target.HP -= damage; } } Essentially making the objects less "concrete" and giving the handling to the area containing those objects?
  10. Thanks for the swift response, guys. I've done some research and it actually seems like this approach would make much more sense than my current one. They really didn't touch up this at all when I did my degree, so it's refreshing to learn about. I do have to ask, though, what are the negatives? This approach seems better in almost every aspect? Is it more a case of inheritance still having its uses in niche situations?
  11. Hey there. Thanks for taking the time to read my post!   I've got a problem in regards to inheritance in that I'm creating a pile of variables that don't get used by a multitude of child classes, and I'd like to go about it in the best fashion possible and reduce the amount of data stored in memory. This system also uses an awful lot of inheritance. I'll explain what I have so far:     So here we have a very simplistic take on how the inheritance works for my game. Each child class has its own unique behaviour, such as input for the player, AI for enemies, hashing for projectiles, wiring for props, etc. The base entity class contains a load of behaviour which will be executed the same in every child class regardless. An example of this is containing a graphic/animation, being allocated a team, having a bounding box, position, velocity, etc!    I like to keep this hierarchy because there are future plans which could be compromised by breaking this structure. For example, enemies and players can apply forces to each other and be destroyed, but certain projectiles may also be able to be deflected or destroyed. Creatures also have passive abilities and auras that affect the stats of other surrounding entities, such as changing the speed of something in a close vicinity, for example. This is all present in the base.   However, on the converse, there will be simple projectiles created which still share lots of this behaviour (velocity, position, graphics, team, etc), but then may not contain things such as abilities. However, in the base entity class, these variables may never be used by a child class, but they still exist in the first place.   I've looked into inheritance and was wondering whether to implement a bunch of interfaces instead, such as IPhysics, IWeapons, ICircuitryInput, etc. This would give me more control, as the amount of behaviour entities will have in common differs greatly. Some entities will share lots of behaviour while others only have a slight amount in common.   I know that I could fix this problem by adding many more layers of inheritance, but is that a bad idea? I understand that by upping inheritance, I essentially cause a bigger disturbance to the code when changes have to be made, or I have to fix a problem I didn't foresee.   I like inheritance, as it allows me to essentially create a contract that enforces certain methods to be invoked, but at the same time, the base behaviour of these invoked methods might actually be the same, so manually writing these methods out for every class would be really counter-productive!   Is there an industry standard way of going about this in the most methodical way, or is it more a matter of just gauging the situation and using educated guesses? Help would be muchly appreciated! :D    
  12. Hello again. If I could get some help regarding the following, that would be awesome! I'm most familiar with C# and XNA just for the record, but a pseudo-explanation/pseudo-code example would also be really helpful.   So I'm basically working on a simple 2D platformer, but the player has a huge arsenal of poses and actions that he can perform. I've been using a workaround sprite sheet animation class at the moment which essentially cycles through different strips of the main sprite sheet. The problem is that some of the poses are different widths and heights, animation speeds, lengths, etc, and managing the whole thing is becoming a bit of a mess.   I recently switched to Aseprite studio, which is absolutely incredible btw, and it makes it unbelievably easy to generate tightly packed animation strips with the smallest margins possible, obviously resulting in less memory requirement from the game at run time. I'd essentially be like to create a simple game that prides itself on smooth animation (as I'm more of an artist/animator than a programmer), but the way they're currently managed is just this awful nest of ifs and switches.   Are there industry standard practices in approaching sprite sheet animation? I'm currently looking at using state machines to avoid nasty overlaps of animation and to also allow transitions between them.   There's also the issue of storing animations. Is it standard practice to make animations become instantiated objects in some way, so that they can be played and changed seamlessly, or would coders conventionally just alter the X and Y positions and frame numbers manually?   Help would be super appreciated!
  13. Hey forum dwellers! Just had a few questions regarding memory management in XNA and it'd be great if I could get some clarification:   1.) Why would I bother passing the content manager into every single LoadContent method? Would it not be simpler to just make a single public static ContentManager which is used at the start when all the resources are loaded in? Surely it's only ever used once?   2.) The same applies for SpriteBatch and GameTime. I understand that there are ways to apply these in mixed fashions, but in a standard game that didn't try to use various game time and drawing applications, would it not just be simpler again to declare a single SpriteBatch and GameTime in, say, Game1, and make them both public static? Would this also reduce the amount of memory required?   3.) I've been using sprite sheet animations in my current game project, and the player's animation sheet is becoming huge. This is because I've tried to animate to accommodate 60fps, and the player also has many different poses and actions. Would it be better to separate the animations into multiple smaller PNG files, or keep this format? The player is actually rather tiny, and his sprite sheet is huge in comparison.   4.) Is it a good idea to use a static LoadContent method in certain situations? For example, say I have 100 enemies all loading this sprite sheet individually, if the sprite sheet was hypothetically 1MB in size, would this cause 100MB of textures to be loaded into the RAM? Would it then be smarter to load a single static texture that all enemies share, resulting in 1MB of memory usage being accessed instead?         Any help would be greatly appreciated :)
  14. This has been the most arduous process imaginable haha! A huge problem regarding the game's development is that I started adding loads of new features and complexities in before getting the collision detection working properly. After hours of rigorous testing, I've deduced that it is indeed the speed of objects moving that is causing the clipping issue, and that smaller objects have less surface area to check for collision, so in turn have to move even slower that large objects to successfully perform a test.   The hardest part of this problem wasn't figuring out WHAT to do to fix it, but WHY they were clipping in the first place, specifically. I made a few assumptions before about my code, but it's definitely safe to say that it is the bullet-through-paper problem causing the issue! This feels like progress, finally :D   I'm also massively hyped to check out this video, adt, as Cave Story is one of my favourite games of all time :D I'll be sure to reply once I've looked into this further, and I'll most definitely post a solution once I find it myself, so that future readers may be able to fast-track some collision code :)
  15. Thanks again for the reply :D I'm not really proficient with C++, so I couldn't get much from those videos. I think I'll just have to leave this problem and maybe make it into a "glitch feature", or alternatively just shoot myself lol.   I'm amazed there's nothing simpler out there, but I suppose that's just the way it is :(