Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by zuhane

  1. Hello people! Thanks for taking the time to read this post. I've been using Unity for a while now and I must say that I'm very impressed with it. Definitely a jump up from XNA. However, something that I've noticed that leaves a lot to be desired is the 2D tile-based collision. Below is a little video of a game I've been working on with a friend which demonstrates my problem. Essentially, games that use huge open planes and polygons don't seem to have many problems with collisions, but when a game consists of lots of small tiles stacked alongside each other, objects tends to get stuck in-between the gaps. For example, if I have a horizontal strip of little tiles, and the player runs along the top, sometimes he'll come to a standstill and have to rebuild his momentum, However, this is much more noticeable for the ball. The ball seems to consistently bounce around randomly by hitting into edges, due to the nature of how fast and random it moves, making it very hard for players to line up shots and make meaningful choices in how they attack the ball. So after doing a little Googling, it seems like there's absolutely nothing on this topic. It baffles me, because tile-based platformers seem to be everywhere on Steam! So after some more digging, I saw that many people were using composite colliders, so that after the level is generated, the tiles all merge together into one polygonal/composite collider. However, I've found that this problem still occurs even when using this method, especially near corners. Am I possibly overlooking a simple solution here? This has been giving us grief for months now! It's also worth mentioning that composite colliders create another problem within our game world. The blocks within the levels are meant to be damaged upon contact with the ball. However, when these are nested inside an object using a composite collider, none of these collisions fire off any more, essentially making all the blocks in the level indestructible. Is there a way to cycle through all of the colliders inside of a composite collider to check them individually? Any help would be mundo appreciated.
  2. Thanks, Antonsem. I'll have a look into that. Might also try the hybrid approach that I've seen and see if that helps.
  3. Thanks for the reply! I'm thinking of creating a custom character controller from scratch. However, wouldn't that mean that I'd then have to write a whole physics system to be able to bounce multiple balls around? The whole reason I switched to Unity was because of the physics system. I'd have to learn A-level / degree-level physics, rigid body maths, collision resolution, angular velocity, etc. Could a hybrid not work?
  4. Hello forum dwellers! I've recently decided to dive into using ECS, as it looks like it solves so many issues with game development, especially with the game I am currently making (which involved many complex entities seamlessly interacting at the same time). It all seemed relatively straightforward. So far, I understand that: 1.) The entity is simply a container for components (which can also have an identifier) 2.) The components are interchangeable blocks of data which change the way the entity will behave (only containing data - no methods/functions/logic) 3.) The systems loop through all the entities and checks to see which components they contain. If it contains the appropriate components, act on them. So far, this has been easy to implement and worked for the basic design. For example, I have a player, block and a ball. The rendering component is present in all 3, colliders in all 3, physics in the player and ball, and input only in the player. I recently looked up how components interact with one another, and that also seems simple. For example, if I want a player to animate due to a button press, I would create a system which requires a rendering component AND input component. The problem I seem to be having trouble understanding is exactly how to nest more complex entities and components. For example, I want my player to be able to punch the ball around. If the player presses the "E" key, I want to create a fist which punches to the left (drawn over the player without the player animation changing). However, the fist itself punching the ball technically has a sprite that needs rendering and also a collision box, so should I create a "fist" component which contains 2 components (rendering and collision), or should I generate a new entity which contains those 2 components and let the systems act naturally on it? I feel like by nesting components within components, I end up with this spaghetti code where systems are calling other systems, removing the whole point of an ECS. It feels more "natural" to just leave the systems to wait and act on entities which contain the correct components. However, if I create a new "fist" entity, this needs to be tied to the player, so I ended up with an entity containing an entity which also seems ugly, or a weird entity with some kind of reference of linking ID to its creator. Am I missing something? On another note, is it unsafe to add multiple instances of the same component? I've heard that it's bad practice too. For example, I might have entities which all require rendering, but some might want to use animated sprites, multiple layers of sprites, shaders, etc. Is it better to have multiple rendering components which can optionally interact, or possibly use a rendering component interface which multiple rendering components can inherit from? Is this inheritance not defeating the purpose of using an ECS in the first place? Any help would be greatly appreciated! Thanks, Zuhane
  5. Thanks for all the replies. Anarcho, these certainly seem very helpful and I'm going to have a look through all of them. I started reading the Game Programming Patterns book, and it was brilliant and articulately written. The problem was that it used C++ in the examples, which I'm not too familiar with! Nevertheless, I'll have a pour through these recommendations and see if any of them help.
  6. Thanks for the reply. I like the analogy too haha! I do have to ask, though, is there a specific resource you could recommend to help with this? I'd say that at this point I have quite a lot of experience with using XNA and C#, a degree in comp science, and I'm always reading up on programming patterns and paradigms, but even after all of these years, I find it nearly impossible to make anything more complex than a very simple arcade game. As soon the the code starts to expand, it becomes too much for me to store in my brain at any given time, and the smallest changes require so much paper-trailing that by the time I find the source I've forgotten the problem. It's very frustrating, as every time I start a project I can code very quickly, then I start to lose steam and eventually grind to a halt. I can create all the individual components, but tying them all together eventually leads to this huge stressful problem where I can't even begin to modify features or fix bugs without creating more. I was hoping that ECS would help with my specific style of game (a separate one I've worked on for years), but I feel like there are so many factors involved, such as ordering, inter-dependencies, nested objects, etc. Is it commonplace to simply keep refactoring? I feel like I've got so far (and been through 2 prototypes) and that throwing it away and starting again would be a pretty big deal at this point.
  7. Thanks for the replies. I feel like they've helped, but that I still lack a strong understanding of how this works. I was under the impression that this paradigm was untouchable, but it only seems marginally more useful than inheritance, with its own laundry list of problems. I just wanted to clarify - are you saying that a complex object full of objects (a player with an inventory, for example) needs to contain a component which then tells the system to create a new entity? Does anyone know how you'd manage something which can be 0 to many? For example, a list of inventory objects attached to a player?
  8. Hello all! Thanks for taking the time to read this post. This is a bit of a strange subject, but a very important one nonetheless in my opinion. I've been programming for about 7 years now, and over this duration I've made over 10 small but complete games. Over the past few years, I started working on a bigger project, and this has been through two prototypes. I've noticed that every time one of these prototypes reaches a certain size, the code becomes more and more intertwined and interdependent to the point where productivity slows to a halt and eventually just stops. A lot of people tell me to "create small games" and "see them through to completion", but I have indeed done this, and this problem seems to persist. I'm not working on something overly ambitious or impossible to complete, but it always seems like when I try to create a game with any kind of substance or complexity, coding very quickly becomes this awful chore of backtracking, and progress slows and slows to a halt. I've done lots of research into programming patterns, and I write my code very meticulously with lots of comments and strict formatting, but I can't seem to jump this barrier. For the first time ever, recently, I decided to COMPLETELY document every single aspect of my game, so that creating content won't involve me having to over-engineer and future-proof my code in the hope of future additions. This way, I can completely design the architecture around this content and then shut the doors and agree to not add any more content, no matter how tempting it may be. However, I'm not too sure how to go about starting a new project in a way that will ensure quality control and a nice balance of readability/cohesiveness/modularity. I wondered if any of you have the same problem, and if so, how do you go about combatting it? Is there a tried and tested way create an architecture which allows the addition of code without causing a rippling echo throughout all existing code? Is there some form of diagramming or pre-planning which can help minimize this risk later down the line? I eagerly await your reply! Thank you, Zuhane
  9. Thanks for the replies peeps Is there something more that I can do from the outset? Maybe something I can refer back to, such as a generalized diagram? I feel like there's multiple forces at play within my game and don't know exactly how to display these so I can refer back. For example, the ordering needs to be taken into account - as there's collisions, animation changes, physics updates, attribute changes (HP, MP, armour, etc), deletions, additions, etc. I'd like some way to translate this to diagram form if possible. I find it difficult to visualize as there are multiple entities, copies, inheritance dependencies, etc. Another compartmentalized problem is the various screen states. Although I feel like this is easier and could probably just be doodled. There also seems to be this exponential feature creep problem I'm having where, for example, if the game has 10 weapons and 2 enemies, that results in (10 x 2 = 20) tests I have to run to make sure a new feature addition works. I'm using purely arbitrary and hypothetical measurements here, but imagine a few additions of props, passive abilities, outside influences, etc, and you end up with this (8 x 5 x 7 x 3 x 2 x 9 x 30) sort of scenario where it becomes impossible to just "wing it" every time you add a new item. So far, everything works, but I don't like the fact that it works - I don't trust it Is there a more concrete way to make sure things function? Also, when you mention modularity, would you say this seems to be the way to go? It seems that game design progressed through various iterations (object-oriented, data-driven, etc) and that this new component-system design seems to really reduce the risk of errors when features are added or removed - at the expense of more boilerplate and scaffolding at the project start (which I am totally fine with if it saves me hassle down the road) - I once heard a wise man say something about good code, and it went along the lines of "if you add or remove a feature, it should just pluck out or insert in perfectly without leaving so much as a ripple in the rest of the code" - obviously coding isn't quite that simple, but this design principle apparently creates that effect. It seems that as the project has grown, I've spent less and less time writing actual code and more time chasing chains of references, dependencies, etc. It's frustrating because I know how to create all the parts, but the problem is more complex than the sum of its parts!
  10. Sorry for the very late reply! I've been looking into a few different solutions and didn't want to rush back in without considering options etc. I think you may possibly be right with point 2, but I've noticed that even fairly small projects seem to eventually fall under this curse. I recently switched over to Unity to give it a try, as I've heard lots of good reviews, especially when it comes to modularising certain aspects of your game. However, after messing around with it, I found it much easier to make games using good old code instead of the Unity IDE. I think Unity's great in a lot of aspects, but it seems like everything is geared towards "nooby" graphical tech demos. I get that you could churn out a walking simulator or horror game rather quickly with Unity, but it doesn't seem to make life easier when it comes to make a game with complex interlinking systems. I thought about possibly adopting the component-system design for my game, as it seems to make games of my type easier to create: But anyway, working with Unity seemed to make life easier at first. I could create all these cool physics sandboxes, use fancy rendering and graphics, etc. However, when it actually comes down to making an interesting game, it seems easier to just stick with XNA. I'm still at a bit of a dilemma and aren't sure what to do.
  11. 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".
  12. 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.
  13. 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?
  14. 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.
  15. 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;
  16. 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        
  17. 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
  18. 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!
  19. 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    
  20. 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?
  21. 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?
  22. 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!
  23. 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 :)
  24. 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 :)
  25. Hello there forum dwellers!! So I recently started thinking that there don't seem to be many tutorials out there which teach tile collision in a simple manner. The ones that do seem to skip out on one of the most important aspects: handling corners/edges. So I've been working on a platform game for quite some time now, and it uses a tile collision system which seems to do the job, but it also seems to have a few problems of its own.   I'd just like to be able to have a tile engine which detects where something is in relation to a tile, then adjusts its position accordingly. Currently, the tile system I have in place seems to work fine, but every now and again, some objects seem to slip through cracks in the tile, and I honestly can't figure out why. I've had this problem for a couple of years now, and it's always just gone on the backburner, because whenever I try and fix it, it just infuriates me! I have a few theories about what could possibly be causing it, but I'd really appreciate some insight from some more experienced programmers than myself!   Here's the general gist of how it works (in order):   1.) Game receives player input 2.) All game objects on screen update accordingly 3.) All game objects check for collisions with tiles 4.) All game objects re-position   It's also worth mentioning that the tiles are given properties as the level is loaded in. So if there's a strip of horizontal tiles, for example, only the tops and bottoms will check for collision, since nothing can fall inside of them and check for left/right collisions. Tiles surrounded by tiles are actually negated, since nothing can touch them, and perform no collision checks at all. An example of this is shown in this screenshot, where only the edges that use detection have a shadowed highlight around them:     As we see here, the strip of tiles under the player only check where collisions can happen. The strips to the left and right have no top/bottom collision checks.   As far is this goes, the collision works the majority of the time. However, sometimes things can fall through, such as bullets, shown here:   http://giphy.com/gifs/xTka01Lb9WeBuchFrq       Bullets and players inherit from the same class, so they use the same collision method. Here, we see the player's collision is handled fine until he hits a booster pad, which pushes him out of the map, even though his velocity is capped:   http://giphy.com/gifs/l0OWjxILsfxsbzLa0       The interesting thing about both of these is that the bullets and player only seem to be passing through the cracks in the tiles. I've noticed that most of the bullets fall through the tiles when either (bullet.x == tile.x) or ((bullet.x + bullet.width) == (tile.x + tile.width)), with the odd ones also falling through the middle tiles. So I guess there's no x penetration to take into account there. Also, the player passes through the wall when the base of him is touching the top of the tile ((player.y + player.height) == tile.y) or also when the top of him touches the underneath of a tile (player.y == (tile.y + tile.height)). This could just be coincidence, but it's an observation I've made.   Below is the code which every game entity uses to check against collidable tiles. If anyone could offer some insight, or even a more graceful solution, I would really appreciate it! public void BoxCollision(CollisionTile currentTile) { GameSpace.collisionsWithHashing++; Vector2 penetration; Vector2 detection; detection.X = (currentTile.Rectangle.Left + currentTile.Rectangle.Width / 2) - (collisionRectangle.Left + collisionRectangle.Width / 2); detection.Y = (currentTile.Rectangle.Top + currentTile.Rectangle.Height / 2) - (collisionRectangle.Top + collisionRectangle.Height / 2); if (Math.Abs(detection.X) > (collisionRectangle.Width / 2) + (currentTile.Rectangle.Width / 2) || Math.Abs(detection.Y) > (collisionRectangle.Height / 2) + (currentTile.Rectangle.Height / 2)) { } else { //Collision has occured. penetration.X = (collisionRectangle.Width / 2) + (currentTile.Rectangle.Width / 2) - Math.Abs(detection.X); penetration.Y = (collisionRectangle.Height / 2) + (currentTile.Rectangle.Height / 2) - Math.Abs(detection.Y); if (penetration.Y < penetration.X) { //Touching top or bottom of platform if (detection.Y < 0 && currentTile.bottomCollidable) { //Hitting underneath of platform collidingWithBottom = true; if (velocity.Y < 0) { if (elasticity > 0) { velocity.Y *= -elasticity; } else { velocity.Y = 0; } position.Y = currentTile.Rectangle.Bottom; } } else if (detection.Y > 0 && currentTile.topCollidable) { //Hitting top of platform (walking and gravity bound) collidingWithTop = true; if (velocity.Y > 0) { if (elasticity > 0) { velocity.Y *= -elasticity; } else { velocity.Y = 0; } position.Y = currentTile.Rectangle.Top - collisionRectangle.Height; } } } else if (penetration.X < penetration.Y) { //Touching right or left of platform if (detection.X < 0 && currentTile.rightCollidable) { //Hitting right side of platform collidingWithRight = true; if (velocity.X <= 0) { if (elasticity > 0) { velocity.X *= -elasticity; } else { velocity.X = 0; } position.X = currentTile.Rectangle.Right; } } else if (detection.X > 0 && currentTile.leftCollidable) { //Hitting left side of platform collidingWithLeft = true; if (velocity.X >= 0) { if (elasticity > 0) { velocity.X *= -elasticity; } else { velocity.X = 0; } position.X = currentTile.Rectangle.X - collisionRectangle.Width; } } } } }
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!