Jump to content
  • Advertisement

zuhane

Member
  • Content count

    58
  • Joined

  • Last visited

Community Reputation

320 Neutral

About zuhane

  • Rank
    Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. 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.
  3. 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
  4. 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.
  5. 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?
  6. 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".
  7. 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.
  8. 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;
  9. 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
  10. 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        
  11. 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!
  12. 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?
  13. 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?
  14. 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    
  15. 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!
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!