Leaderboard


Popular Content

Showing content with the highest reputation since 07/22/17 in all areas

  1. 8 points
    Nope. If you are a good software developer or a good artist, you can go a long way without really caring about games. Knowing more about games will help, certainly. And you can't get away without knowing about games technology. And I'd certainly argue that it's important for designers to have a broader understanding of the field. But they are only one part of the development process. You don't. You have to choose. It's a sad fact, but there are just not enough hours in the day. If you want to spend 8hours a day or more on MMO raids or whatever then that is a fun hobby to have, but throw in a day job as well and you simply do not have enough time to teach yourself enough to get good at making games. Play fewer games, play shorter game sessions, and prioritise what is important to you.
  2. 8 points
    Take the following post as coming in semi-moderator capacity; I hope there is something useful in it, but this is not going to be the start of a lengthy debate over something that we have been over time and time again. First, this is not the place to complain about what other people are interested in or not. The forum is called "game design and theory", and you're welcome to discuss those topics. It's also not the place for blatant hyperbole - you say "not a single person has said a single word too me about any of it" and yet there are over 70 comments on your blog. Most likely you are just not willing to hear what people have said to you. What I don't think you appreciate is that you have spent thousands of words talking around your concept, but hardly any time talking about what it actually is. Not 'what it means for games', not 'how important it is', not 'how everything could change if this existed'. You keep asserting that it's important, but you have not proven or demonstrated it in any way. You don't need a degree from Devry. You don't need to write 500 pages about it. You just need to communicate your idea clearly in such a way that you can demonstrate that it will do what you need it to do. Stop talking down to people and saying they are "so far behind actual simulation design" - learn to communicate better. You don't build interest by repeatedly insisting that people should be interested and insulting them when this doesn't change. When a startup wants to get interest from investors, they will create very short and very effective descriptions of what exactly their product or service is, and how it will deliver benefits to users/players/the market/whatever. It should be possible to communicate all the benefits in about 10 pages of Powerpoint at most, and about one sentence at best. They don't expect people to read 500 pages of blogs and neither should you. Alternatively, you can do what most other game designers with a 'big' idea do; make a prototype yourself. If the idea is as good as you say it is, the prototype will prove that, and you'll get interest and funding. If it's not, you won't.
  3. 7 points
    >>What do I have to do to finally be seen as at least the equal of someone with almost no experience, and even less knowledge? Build a portfolio, apply for jobs and go to interviews, like all the rest of the people do. Btw, I again remind you that, when you were talking about your sports mod and how good you are at designing those kind of games, I offered you my services as a programmer in order to make a prototype together(I was interested in making a sports game myself back then). Sure, we weren't going to make an AAA sports game, but we would have an awesome(if your word was true) playable prototype that we both could showcase. You declined, because your grand designs can only be made with multi-million teams and anything else is beneath you. So I went on my way, worked on my indie game, now have a job at EA DICE. Not as a designer, as a programmer, but I work with designers every day, making the tools they use to make AAA multi-million games. See, you *could* have a connection there today, but you don't accept anything less than people bowing down to you and handing you 100 million. So there's that too.
  4. 7 points
    I advise you to not aim to learn "everything" (in Unreal or other technologies), as it can be a futile endeavor and lead to frustration because of the huge ammount of content. Instead, aim to learn what you need to build your ideas (and most of the time it's much less than "everything"). Unreal has a steep learning curve, so it's good to break the learning in manageable chunks. Anyway, Unreal site has a ton of learning resources, so it's a good starting point. They also have a Youtube channel, so check it out and see if it helps. Other than that, you could check online courses such as this on Udemy . I'm doing it, and liking so far.
  5. 6 points
    You're approaching this way too pragmatically and from the wrong direction. If you want to be a level designer, start designing levels. When you gain experience you might discover that in order to add this cool new feature to your levels you need some coding. Then learn coding. It is never the correct approach to mathematically define what you think they want to see. The correct approach is to make what you enjoy making and get a job based off the things you enjoyed creating. If you can't get hired based off what you enjoyed making then you are in the wrong field and you saved yourself from a life of hell. If you aren't motivated enough to create lots of things for a portfolio then you are in the wrong field and you saved yourself from a life of hell. This is just a more direct way of saying what jpetrie said. We can't give you direct answers because the only correct answer is whatever you want to do. How are we supposed to answer your last question? If you are interested in making beautiful levels, and functional levels, why do you need to be told which one to do? You're just going to do them both anyway because you enjoy doing them both, right? If you don't like one or the other, why should we tell you to do what you might not enjoy doing? Careers must always be based off doing what you love. If you want to make pretty backgrounds, do it and apply at companies that want pretty backgrounds (fighting games, racing games, RTS games, RPG's, etc.) If you want to make functional backgrounds, do it and apply at companies that want functional backgrounds (FPS games, 3D action games, RPG's, etc.) Or you can do both, whatever. It's entirely your choice. L. Spiro
  6. 6 points
    The component system outlined on the T-Machine blog is a mish-mash of hating object-oriented programming, love for relational databases, and then an attempt to wedge in cache-coherency - don't expect to follow those articles and get anything elegant out of them. If you want to worry about having contiguous data then the data access pattern cannot be waved away or ignored. Whether you benefit or suffer from interleaving different component types will depend entirely on how you intend to access them. Data locality is about read patterns, not semantics; know your read pattern, then you can decide. The names we assign to that data like 'position' or 'physics' are entirely arbitrary and the cache doesn't care. 30000 entities is going to stress any system if they are non-trivial, anyway. In my opinion, the real benefits from component-based approaches are in modularity and in providing a composition-based approach to implementing functionality. Much of the recent emphasis on being data-oriented and cache-coherent is missing the point and overcomplicating software for little real benefit. Note that the Randy Gaul article you linked stresses modularity first and only mentions cache coherence as an optimisation. That is exactly the method I would use; first implement components to suit my gameplay, then attempt to find ways to locate them in memory to reduce cache misses.
  7. 6 points
    Medieval Story has finally been released on Steam (wohooo!). Many late nights and evenings have been put into making Medieval Story. All graphics, sounds, maps, programming, scripting, GUI, music, AI, dialogue writing, modelling and what not has finally come together into this small game with about 8-15 hours of gameplay time. It feels quite bizarre thinking of all the hours that have been put into the game over the years and then reading reviews about it. Sadly some people seem to have had quite high expectations, pointing out infantile (?) dialogue, horrible controls and bad characters. I don’t know… Never fun to read criticism when it is sort of rude. If you consider buying the game I hope you enjoy it for what it is; a one man game project developed in spare time. http://store.steampowered.com/app/543740/Medieval_Story/ Thanks for reading!
  8. 6 points
    Ok, so I didn't really want to engage with this, as I feel it's likely to be a waste of time... My prediction is that you're just going to dismiss the following as us not having the frame of reference to understand your brilliance or something, but here goes... I played Armageddon Chess. I was curious when you published something that actually looked like a playable game, so I arranged to take it to our local gaming store, and a group of 7 of us made up 3 sets and gave it a few tries. All are avid tabletop and board game players. Four like video games as well, three almost never touch them. Two have actually tried SFB, although admittedly one wasn't a fan and only ever tried one introductory game. It's actually playable, and the rules weren't too badly described, although as we were making our sets before play and piecing it together as we go it was a bit cumbersome to figure out. Not one of us enjoyed it. You took the elegance of chess and added tedious combat rules and book keeping, and the we justc didn't find it fun. You shared a massive "design document" for Pirate Dawn" 10 years ago, and several people here actually tried to read it, but it was an unstructured and disorganosed typo-riddled mess; unfortunately you wouldn't accept that that was your problem, declaring that 'our industry just don't understand proper detailed design documents'. You actually have one video game design credit for Sinistar Unleashed. It wasn't received very well, and the reviews I can find almost universally claim that it was aesthetically beautiful but that the gameplay was terrible. Apparently you worked on a football mod that was popular, but noone remembers it, and in all my searching all I can find about it other than an old discussion here where you claim it was great (noone else remembered it then either) is two dead links You keep talking about being in the SFB staff, but according to your own earlier posts you didn't actually design the game, you were just an avid core player with a deep understanding of the rules who was asked to contribute to the strategy manual. That doesn't have no value, but nor is it particularly compelling design experience. Your writing is verbose, poorly structured, and seems to talk around a point you never actually make. It's filled with boasting about your design and old table top games and scorn for 'the industry' but startlingly devoid of actual meaning, although you claim that's because we just couldn't possibly have a frame of reference to understand it. So no, you simply haven't actually done anything to demonstrate your supposedly amazing skills.
  9. 6 points
    http://www.psa.es/sdg/sunpos.htm The function will take your time of day as well as location on earth (specified as a latitude/longitude coordinate pair), and give you the direction of the sun in spherical coordinates.
  10. 6 points
    I would not advise learning C++ in the context of Unreal. The way you write C++ for Unreal is different enough from the way one writes "pure" C++ that learning it first may warp your understanding of what is something you do in C++ versus something you do in Unreal; for example, Unreal has a garbage collector implementation and an invasive macro-and-preparsing-based reflection system. I'd recommend you focus your Unreal learning on Blueprints. If you want and feel capable of also learning C++ at the same time, spend some time working with it outside of Unreal, by writing some simple text-mode games in Visual Studio or whatever IDE you prefer. Guess-the-number games, Hangman or Blackjack are good basic games to try building in that fashion.
  11. 6 points
    Bytes are well documented. Do a Google/Wikipedia search for definitions before you ask, so that your questions can be more specific. A byte is an amount of storage 8 bits of data (at least in every situation you will ever encounter). Therefore it is broadly equivalent to the 'u8' type you're working with. All data transmitted or stored is essentially sending bytes back and forth. The computer programs at each end then decide how to interpret those bytes - for example, 1 byte on its own might be a 'u8', 4 bytes in a row might be considered an 'int', 8 bytes might be a 64 bit pointer, and so on. When understanding what is meant by "high byte first" you need to understand how numbers are encoded in binary. (Read this paragraph, then read this - https://en.wikipedia.org/wiki/Binary_number#Counting_in_binary) When we write a number in decimal, we write the 'high digit first', so 145 is one hundred, four tens, and five ones. A hundred is the 'high' amount, and the ones are the low amount. Binary doesn't use digits from 0 to 9 like decimal does - it uses digits from 0 to 1. (Binary digits are "bits".) This means that instead of each column signifying ones, tens, hundreds, thousands, etc, each column signifies ones, twos, fours, eights, sixteens, etc. Each byte has 8 'columns' of binary digits, i.e. 8 bits, and when we send the 'high byte' first, we're sending the byte with the largest column values first in the list. Because a byte is just 8 bits, it tells us nothing about what sort of information it is meant to carry. This is why 2 networked programs need to know what to expect - so if you're sending an int, you need to know to expect 4 bytes and what order they're going to arrive in. If you want to send a string, you need to know what format it takes - some systems send an int to mark the length followed by each byte in the text, and some systems send each byte in the text and a delimiter (i.e. what you call "a line break or something"). Both ways exist and are used. And a 'short' is usually a 16-bit value of 2 bytes. Scan this list - https://en.wikipedia.org/wiki/C_data_types - but be aware that type names can vary from language to language, and sometimes from platform to platform. e.g. an 'int' is usually 32 bits on a 32-bit operating system and 64 bits on a 64-bit operating system. I would warn you that if you're not yet familiar with 90% of this stuff then trying to do low level networking between 2 different languages is going to be very tricky. You might want to keep practising with just 1 language first.
  12. 5 points
    If you interpolate the RGB values of two complementary colours you will go through a neutral region of the RGB space. The middle of your gradient will be "grey". There are other ways of interpolating colours, like interpolating the parameters of your two colours while in the L*a*b* or HSL space. Use this tool for some previews: http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker
  13. 5 points
    If Z-fighting is an issue, then yeah I'd definitely recommend doing this. Make sure you're using a 32_FLOAT depth format. Swap the near/far params of your projection matrix creation code (e.g. instead of Projection(fov, aspect, near, far), use Projection(fov, aspect, far, near)). Swap your depth comparison function (e.g. replace LESS_EQUAL with GREATER_EQUAL). If you have any shaders that read the depth buffer (e.g. deferred lighting reconstructing positions from depth), then fix the bugs that this has introduced to that code). [edit] Clear your depth buffer to 0.0f instead of 1.0f. [/edit] The link I posted earlier explains why this is magic. But quickly -- z-buffers store z/w, which is a hyperbolic curve that focuses most precision on values that are close to the near plane (something like 50% of your depth buffer values cover the range of (near, 2*near]!!), and floating point formats do a similar thing -- they're a logarithmic format that focuses most precision on values that are close to zero. If you simply use floating point format to store z/w, you make the problem twice as bad -- you've got two different encodings that both focus on making sure that values next to the near plane are perfect, and do a bad job of values next to the far plane... So if you invert one of the encodings (by mapping the far plane to zero), then you've now go two encodings that are fighting against each other -- the z/w hyperbolic curve is fighting to focus precision towards the near plane, and the floating point logarithmic curve is fighting to focus precision towards 0.0f (which we've mapped to the far plane). The result is that you end up with an almost linear distribution of values between near and far, and great precision at every distance.
  14. 5 points
    It is an expected behaviour, with VSM (and any other related techniques) you have to render both the occluders and the receivers into the shadow map. If you think about it, when you blur the VSM without the receivers in it (or even if you just sample that map with proper texture filtering), you blur between the occluder depths, and the maximum z value, meaning that the blurred values will strongly tend towards the max z. Tending towards max z also means that the blurred values will be "behind" the receiver pretty quickly, and that messes up the whole thing. (This explanation is exactly mathematically precise, but hopefully it's enough to illustrate the problem.)
  15. 5 points
    I said I was done, but since you're addressing me directly, I'll do you the courtesy of responding. "Rube doesn't qualify me as a game designer in your eyes". Correct. Because it's not a game, it's a long series of vague blog posts. There may be other things you've made which qualify you as a game designer, but I've not seen them. "40 years of experience doesn't either" Experience of what? And for what? 40 years of board game design experience, if you have it, is useful, but it wouldn't qualify you to come to my company and tell us what game to start making. That's not how the process works. It might qualify you to come in at mid-level providing you were able to show some capability with digital design tools, and a willingness to engage with our existing processes. "you'll hire a 22-year-old in a heartbeat". If they have relevant skills for the role we need, sure. They, too, would not be coming in to the company telling us what game to make. They'd probably be given a copy of the Unreal Engine and asked to start blocking out greybox levels for whatever game we're already working on, or asked to tweak vehicle handling parameters, or told to design some low-level kill-10-rat style quests. "I just want to make games." So make them. Unity. Unreal. GameMaker. Stencyl. Godot. There are tons of cheap or free tools out there and you can get started today. "What do I have to do to finally be seen as at least the equal of someone with almost no experience, and even less knowledge?" You have to do the same that anyone else would have to do - make something to prove your capabilities. Nobody hires on the basis of blog posts or repeated insistence. The burden of proof is on you. You also have to learn to communicate better and to be more of a team player. Nobody hires someone who comes to them and says, "your industry is full of idiots who don't understand that I am the top person in this field". Who'd want to work with someone that sounds so arrogant? If you truly are at the top of your field, you wouldn't need to state it; it would be obvious from your work.
  16. 5 points
    I didn't ask whether you had any private notes, I asked whether you had anything concrete that you were willing to share with others. I'm an engineer, I use tools to build things. If you don't give me a tool to use, then I can't use it... If I can't use it, why would I care about it? In your first post in this thread you ask why no one wants your magic technology. I answered that -- if you are keeping it a secret, then it's not possible for us to even begin to care. As for turns vs impulses, etc, we talked about this in one of your previous threads. Event-based simulation using timelines instead of turns was covered in my 1st year data structures class at University. The other part of your problem is that you don't know what everyone else has been doing for the past 70 years, so you're not qualified to tell us what we do and don't know. Maybe there's practical reasons why people choose to use one over the other? Big projects involve hundreds or thousands of trade-offs between different technology choices, often based on mundane practical reasons. The structures used by your secret magical tech may well have been considered by a lot of games over the years, may have been used, may have been discounted for practical reasons. You simply don't know. And you'll never know if you insist on just rambling about what some secret magical system does for you, instead of actually sitting down to do the work to tell us what it is. If you have nothing to share with us, then it doesn't matter what you have. To us, it doesn't exist. So for all practical purposes, your tech does not exist right now. Stop being lazy. Do the work required to make it exist to us, or you'll die alone without ever having left behind a legacy that anyone cares about.
  17. 5 points
    CS degrees have remarkably little to do with working as a software developer. Provided you have strong programming skills, and pick up the CS basics on your own (the various containers, algorithms, big-O complexity analysis), the CS degree is just a way to make sure your resume stays in the stack (rather than ending up in the shredder). Personal contacts, a strong portfolio... those should accomplish the same end (and possibly considerably more).
  18. 5 points
    C++ has the potential for better performance. You can try to write perfect code or you can write code that is good enough to get the job done. I would suggest the latter. My point is...choose whatever language you are comfortable with that will result in a finished product. I would submit that focusing on readability of code and a well thought out, well executed, and extensible design is more important than performance. About writing a GUI...nothing says you can't write the GUI in one language which is well suited to high level GUI stuff and the logic in a different language well suited to performance. In the example of a web application...you can write the back-end code (where speed matters) in C++, the web app code in Python and the GUI in JavaScript/XHTML markup.
  19. 5 points
    There's been a solution for this exact use case built into Windows since it was a 16-bit cooperatively scheduled layer on top of MS-DOS. The relevant starting point is the SetCapture API.
  20. 5 points
  21. 5 points
    This article will introduce you to basic art concepts to give you a head start in making your own 2D game art. This is not a Tutorial! This article is for those with some vague familiarity with 2D art for games, primarily people who are programming games but would like to create quality assets, or those just getting started with creating art for games. By 2D assets, I'm referring to 2-dimensional images used for games - anything from character sprites to large backdrops. This article focuses on giving a brief introduction to good old-fashioned art skills and the ways they can make your game better. It's meant to give you a brief introduction to some principles and ideas so you don't have to waste your time discovering them the hard way or develop any bad habits you will then have to break. I won't be covering things like file formats, raster art vs vector art or what software to use in this article. What I will be covering: Form and Shape Anatomy and Proportions Perspective Breaking Down Color Lighting and Shading Practice Makes Perfect If those bullet points don't grip your heart and tear at your soul, here's this handy before-and-after demonstrated what you will learn: An internet fact! Okay, that's actually what my programmer friend made and my, uh vast improvement, but I think it's a pretty good example of what happens when you apply a little artistic know-how to a design. We're all used to looking at 2D images in everyday life, but knowing what things look good isn't the same as understanding exactly why they look good. Any 2D image can be broken down into basic elements, and you can think about creating 2D art as combining those elements in a way that 1) Looks like what you meant it to be, and 2) Is not super ugly. For example, we all know what a square and a sphere look like, but how do they fit into the process of making an identifiable character? To answer that, we're going to start with our first section: Form and Shape Knowing that shapes matter, you can apply them to make environments seem more or less friendly, or match (or intentionally mismatch) characters and objects to those environments. Start designs with only very basic shapes- I'm talking about circles, squares, and rectangles. Try a character made of squares, or one made out of just triangles, and then see who looks more like the hero and who looks more like the villain. Keeping your initial design thoughts to shapes only also lets you generate a lot of ideas without getting carried away trying to figure out the detail right away (more on that later with the "Practice Makes Perfect" section). Generally, sharp edges imply artificiality or evil while curves and roundness imply organic and good. Traditionally it's thought of as a spectrum, with roundness on one end with jaggedness on the other, with squares somewhere in the middle. For a great example, think about the landscape of Mordor in the Lord of the Rings films, versus the rolling hills of the Shire. A round, friendly looking character wandering through an angular environment seems more unsettling than the same character in a predominantly round environment. In the same vein, you can easily make stylistic choices to influence how a player thinks of an area. Let's take a look at another particularly good example... Let's break down two characters that have a lot, but also pretty much nothing in common: Godzilla and Barney the Dinosaur. What kinds of shapes make one look like a fearless killing machine and the other look like a friendly hugging, uh... machine? Also, Godzilla has three fingers.(Barney image source, Godzilla image source.) Think about it, both characters are T-rex-like monsters designed around the fact that a guy had to fit inside... but they're on the opposite sides of the appeal spectrum. Why? It has a lot to do with one having smooth curves while the other is more angular with parts that are downright sharp (there are other reasons, which we'll get into later). At a fundamental level, this has to do with our general comfortableness with round organic shapes versus our discomfort with sharp angularity. It's no coincidence that "bad guys" tend to have spikes coming out of every conceivable surface (Bowser in Super Mario Bros being the archetype), while "good guys" like Mario himself, tend to be, well, soft around the edges. When Sonic the Hedgehog was conceived as a cooler, more mature version of Mario, it's no coincidence he designed to be significantly sleeker and spikier than Mario. Let's take a look at Barney and Godzilla again, this time in silhouette: Evilness of a character is correlated with how painful the action figure is to step on. Silhouettes are very closely tied to the shape of an object and are a great way to break down the shape of a character. Apart from any connotations of the shapes used, if a character does not have a distinct silhouette compared to other characters, it's not a very good design. Some artists even go so far as to start with the silhouette and move inward to flesh out their subject. Reducing an object to just the silhouette can also be a great double check after it's already started to make sure it's looking right. In summary, when thinking up designs for your games, make sure you account for shape and form and connotations those shapes often have to get a design that conveys what you want it to. Also, keep in mind that things are largely recognized by shape, so objects in your game should have distinct shapes in order for the player to identify them easily. Spikey the Sea Urchin as a protagonist, outside ironic appreciation, probably wouldn't have a lot of appeal among Facebook gamers. TL;DR: Everything is made of shapes and forms, and different kinds have different subconscious connotations. Anatomy and Proportions Figure drawing is often considered to be the most difficult field of drawing since people are structurally complicated masses of interconnected cartilage, muscles, bone, and skin. I'm not going to go into super detail since I don't personally have a ton of experience, but there are hundreds of books and websites dedicated to figure drawing. The essential idea is that there are certain rules and relationships in terms of length, size, and position of anatomical features, which is important because anatomical errors stick out. The more stylized a figure, like Mickey Mouse, the less important strict adherence to anatomy becomes, but it's a good idea to study realistic figures since by knowing the rules, you'll be able to bend them better. You can think of human proportions as essentially shortcuts to get close to ideal anatomy by comparing the size of different parts of the body to each other. There are specific proportions to measure pretty much every part of the human figure, but the usual starting point is the head. Humans in real-life are around 7.5 heads tall, though often this is rounded to 8 to make a slightly more idealized figure: There are many, many examples of available of this kind of diagram. Google is your friend! Changing the size of the head of a character compared to his/her/its body can have a pretty big impact on how that character feels. Big heads are more child-like, and so are more associated with friendly characters, while small headed characters feel more adult or even grandiose. Yet again, Godzilla and Barney help us out: Godzilla might seem more mature, but Barney is waaaaaay creepier like this. TL;DR: For people to look right, they have to follow certain rules regarding proportions, and messing with different proportions can change the "feel" of a character. Pages to get you started: Proportions Guide by FOERVRAENGD, idrawdigital Tutorial: Anatomy and Proportion Perspective Perspective is all about creating the illusion of depth on a 2D surface by altering the appearance of shapes and forms and is a pretty big subject so forgive me if I split it into sub-headings. Geometric Perspective Most 2D games simply avoid dealing with what I like to call "Geometric" perspective for the simple reason that implementing true-to-life perspective would be insanely time-consuming for creating 2D art for games. Games like to cheat their way out of that problem by adopting unrealistic viewpoints, such as assuming everything is seen perfectly form the side (like a 2D Platformer), or from an isometric viewpoint which is no less realistic although more subtle in its unreality. I want to go over it because it's probably the hardest overall principle to truly understand, and even a very basic understanding will get you vastly better results. The Vanishing Point forms the basis for most formal perspective and is based around the idea that parallel lines appear to converge onto a single point as they recede from the viewer. LOLwut you ask? Like this: This would be a more dramatic example if there was an oncoming train.Image from Wikimedia Commons Notice how the parallel lines (real and implied) converge? Maybe this will help: So I could have added more red lines, what of it? Red lines converge on the vanishing point. Got it. What you also see dividing the earth and sky is the Horizon Line, which happens on infinite (from the viewer's perspective) planes. Vanishing points and horizon lines at their core enforce a really a simple idea: Things that are far away appear smaller than things close up, and the closer side of an object will appear bigger than the farther side. The above example uses one vanishing point, but there are really as many vanishing points in a scene as there are sets of parallel lines, with each set having its own vanishing point. Sound complicated? It definitely is, which why scenes are generally simplified down to one-, two-, or three-point perspective. What normally happens with one-point and two-point perspective is that one or the more sets of parallel lines are assumed to stay parallel forever and never converge. Here's an example of a cube and a cuboid in one point perspective: That's right... pencil and paper, sucka. Note how the horizontal and vertical sets of edges are perfectly parallel. Now, here's two-point perspective: It's traditional when you're starting out with perspective to lightly draw the other side of the objects as well to get a better feel for the 3D-ness. Here, the set of edges that were previously perfectly horizontal now get their own vanishing point. The vertical edges stay perfectly parallel. Finally, here's three-point perspective: Three-point perspective pretty much entails epic-ness, at least in terms of height. Now all edges get their own vanishing point. Good for them, right? It should be noted that vanishing points deal parallel lines the best, but by drawing guide lines or even full boxes you can get a better idea of how to approximate depth for complicated shapes. One, Two, and Three-point perspectives are by far the most common and useful, but there's at least one artist who has used six-point perspective to create crazy spherical scenes. There's an important trick to drawing tubes or any circular object in proper perspective, since circles in perspective deform in special ways. Circles look like ellipses when they're viewed obliquely, the more oblique, the more squashed the ellipse: I cannot tell you how many people don't get this, so seriously and for real, circles turn into ellipses. A simple rule is that when you're looking up at a cylinder edge (like the roof of a round building), the curve bulges up. When you're looking down, like at the base of telephone pole, the circle bulges down. The line through the middle of this image is the horizon line: This would have been a perfect candidate for shading to add depth, but we'll get there. However, you should remember than many 2D games avoid geometric perspective problems by picking viewpoints (from the side, perfectly top-down) that minimize the need for it. Foreshortening A common perspective art concept in figure drawing is called foreshortening, which comes up often with how parts of the body appear in perspective. A fist held out at the viewer will not only appear bigger than it would be held at character's side, but it eclipses a huge part of the arm, too. I'm terrible at figure drawing so this won't be the most professional-looking example ever: Seriously, I suck. Often, artists eyeball foreshortening for characters simply because laying out all the vanishing points would take too long. But for your edification, here's forshortening with vanishing points and cylinders, which are often used as proxy forms for limbs: At least I can draw cylinders good...er, I mean "well". Keep in mind that characters, human characters especially, can be thought of as a series of simpler objects which are easier to comprehend. Sketching out characters as a series of tubes connected by joints before filling in the detail isn't uncommon. Page to get you started: idrawdigital Tutorial: Forshortening Tricks Overlap and Parallax Overlap is very simple: closer objects will overlap and mask farther objects. It's very important for 2D games since it's a very simple way to show the player their relationship to objects. Let's take a quick look at an extremely simple example: Also known as the weird hills in the background of every Super Mario game. From this set of lines you perceive the circular thing (a bush?) on the right is in front of the others, while the tallest one is behind. This effect is sometimes called the "T-rule" since the line of the object in front forms the top of a T compared to the object behind. It's simple, but pretty powerful. In this example, all the T's are updside-down: More like ASCII Code 193 rule, amirite? Parallax is another important perspective effect having to do with the relationships of overlapping objects. Parallax essentially is that objects that are far away appear to move less when the viewer moves, compared to closer objects. Parallax is great for 2D games because it's pretty easy to implement, and you have no doubt come across it. Wikipedia actually has a pretty decent article on using parallax in games, and I'd hate to waste your time regurgitating it. Atmospheric Perspective Since 2D games often intentionally violate regular perspective rules for the simple reason that it's easier to draw stuff for them, they have to rely on other means to get the idea of depth across. By making objects that are supposed to be far away from the viewer appear more washed out and less detailed, you can easily make the brighter, sharper looking things in the foreground appear more distinct. Here's an example from real life, in a picture I took while visiting the gloriously smoggy People's Republic of China: For real, it's pretty smoggy over there. You can also see the parallel line perspective effect, although in this case the main vanishing point would be off to the left of the frame. The game applications are pretty staggering. Almost every 2D platformer ever made uses atmospheric perspective. Take this screenshot from Super Mario World: Also, overlap and parallax! Booya! Super Mario World Image Source Notice that the farther in the background an object is, the more washed out it looks. In particular, looking at how dark the outlines are tell you how close they are to the plane of the player. This also folds directly into the idea of contrast. Contrast can tell the player what's important and what's not. Take a look at that Super Mario World screenshot again. Blue hills that are lightly shaded? Not important. Pipe with a white highlight fading to total black? Important. The only bright red thing on the screen? Super important. Remember, interactive parts of a game should always stand out from non-interactive parts unless there's a specific reason to obscure something from the player. Pages to get you started: ArtyFactory.com Linear and Aerial Perspective, perspective-book.com Tutorial Breaking Down Color Color is a tricky thing, and one of the more subjective parts of art in general. Some colors look better to some people than others, and color combinations and connotations do not transcend cultures. White might be the color of purity in the west, but in Japan white often stands for death. However, there are a few basic ideas regarding color that will help you out in understanding what's going on in your art. Let's start with thinking about what makes up a particular color. Hue, Saturation, Brightness There are many ways to break down color, but this one I think is the most helpful for beginning digital artists. Let's start by comparing two colors: Red vs Blue, get it? It seemed pretty clever at the time. Red and Blue. They aren't the same color? Pretty simple, right? Well there's actually a more precise term called Hue. The left square has a red hue and the right one has a blue hue. Other hues include green, orange, purple, and so on. While hue may seem just a redundant term for color, it's not because the amount of any given hue in a color can change: Red vs Less Red. So they are both red, but how are they different? The one on the right is just kinda... washed out. The term we're looking for is saturation. Saturation is basically the term for how colorful, um, a color is, or how much hue it contains. I like to think of saturation as a measure of how much gray there is in a color. No gray = saturated. Lots of gray = unsaturated. So in this case, the square on the left is a fully saturated while the one on the right is desaturated. Pure gray is simply a color with no saturation. Saturation is the most devious of color attributes for beginners to get the hang of in my opinion. Just be aware that saturation has a big impact on the "tone" of your art. Highly saturated colors tend to look more, well, friendly when used in large amounts, where desaturated colors are associated with grittier style. The last attribute is Brightness. It's much more straightforward - it's just how bright the color is (sometimes the term "value" is used instead, no biggy). Here's the same red as above, but with a darker version: Same red, but darker (not desaturated). The relationship between brightness and saturation takes a little getting used to, since they can appear to overlap: I like drawing spaceships and explosions, but I also secretly like magenta. Here's an example of how color can affect the tone of a game, with Castlevania: Lords of Shadow set against New Super Mario. Also note the lack of gibs and bloodsplatter you'd expect a Mario that size would generate stepping on a goomba. Image Source Nothing clever, just wanted to point out how well those bright status bars stand out from the background. Image Source You know what also relates back to color... Barney and Godzilla! Whooo! So anyway, think about the ways color makes them so different in terms of hue, brightness, and saturation, and what would happen if one or more of those attributes changed. What would happen if you left one attribute alone but traded them between the characters? Would a gray Barney still seem huggable? There is no escape from the Godzilla-Barney comparison! RGB in Brief Congratulations! You now understand HSB (Hue Saturation Brightness) color (sometimes the "B" is swapped out with the a "V" for value, but the meaning is the same). Pretty much any image software can use that definition along with Red, Green, and Blue (RGB), and Cyan, Magenta, Yellow, and Key /Black (CMYK). I think HSB is a much more straightforward way of understanding what's happing with colors, especially regarding how bright and how saturated a color is, which is what you need when you're working on shading. You will have to work with RGB color in different applications however, so let's review that briefly. RGB simply describes colors in terms of Red, Green, and Blue, since all colors can be described as a combination of those three, which has to do with how your eyes process color information. Take some time and monkey around with color values to see what both the HSB and RGB values change, and how they related to each other. Here's the standard RGB overlap diagram (notice what happens when the colors overlap): Also known as an additive color model, since colors are creating by adding light, rather than absorbing light (subtractive model) Also note how when all three are combined, it makes white. You can think of all the colors playing in a tug-of-war, so when they all have the same value, the hues cancel each other out and make gray. But the colors different combinations yield can be kind of confusing, so for working on artwork, I would lean towards HSB. The Color Wheel Now that we have defined what a color is, let's start looking at color combinations. Color theory is complicated and pretty subjective, so what follows isn't meant to be an ironclad explanation, but a guide of what to think about. The color wheel forms the basis of most color theory. It's basically an arrangement of hues by their perceived relationship, with Red, Yellow, and Blue at the thirds of the wheel (the so-called primary colors), with Green, Orange, and Purple (secondary colors) between them. Wheel of Color would be a really stupid game show. Hues are also commonly split into Warm and Cool categories, termed color temperature, with red-yellow colors being described as warm and blue colors being described as cool, as below: Spike Lee's film Do the Right Thing was oranger than normal to make it seem "hotter." I learned that in a film class, and it seemed relevant to bring up. I added a zone of iffiness, since those colors are kind of borderline but I've seen the yellow-green as cool and the magenta color as warm. The important thing to remember is that cooler colors are associated more with darker shades, so a cool shadow will be perceived as darker than a warmer one that is technically the same value (brightness). Other relationships between colors can be explained using the wheel, too. Analogous colors are simply hues next to each other on the color wheel, like green, yellow, and the colors between. Complementary colors are colors (hues) 180 degrees from each other that appear more vibrant when used together. You've probably seen them in action, even if you didn't know why; blue and orange has even become a trope. If you're using Firefox, look at the icon. Complementary colors strike again! When working on game art, think about associating colors with specific factions or enemies and environments or levels. Color-coding isn't mandatory, but you can use it as a way to bend player perception. Think of a set of colors for bad guys, but use unique shades of those colors for specific enemies, for example. But with using colors, don't be afraid to experiment and try lesser-used colors. Using any reasonably-advanced art program, like GIMP, it's actually easier to change color than any other attribute. It's one of the few things you can change after completion relatively easily. TL;DR: Colors can be divided and related to one another in different ways, and different combinations of colors can make their individual component colors look different, for better or worse. Page to get you started: Color Theory for Designers Lighting and Shading I'm going to be using lots of pixel art examples, but they basic concepts are just as applicable to any other type of 2D art. Light Sources The most common issue I see with beginning artists is that they don't understand lighting. Shading a drawing generally means to apply different shades to create the illusion of light in a drawing, just like perspective is the illusion of depth. And just like in perspective, you have to create some 2D stand-ins for mimicking real-world effects. There's really only one rule: Light has to come from somewhere. It doesn't just appear, which means that laying down colors in a drawing will always look wrong. What happens pretty often with beginners is that they try to "shade" their art, but don't understand lighting, which results in objects that look like this: Seriously, don't do this. Compared to the unshaded version: You might even be better of with this version than the one above. It's called pillow shading, and it can be easy to do without thinking about it. It can seem natural to just color from the outside in with darker shades... but it looks completely fake. In order for lighting to look right, it has to be directional, with light/dark shades being chosen depending on the whether or not a side of the subject faces the light source(s). A light source could be the sun, a lamp, a boiling hot lake of molten lava, etc, but doesn't have to be something that specific. For example, you can just assume almost all light is coming in at 45 degrees from infinity, and your subject will be shaded well enough for most applications. For animated sprites that are going to be used in a variety of environments, a little vagueness helps keep the sprite from looking too out of place on any background. Here's an example using a light source coming from the top left somewhere: This also requires you to think about if there's a part casting a shadow over another. Parts facing the light source are lighter and parts facing away are darker, couldn't be simpler, right? Of course, it's not always that simple... Flat vs Round Keep in mind that flat surfaces generally have almost the same shade across their entire surface, where curved surfaces will have a gradient of shades. Here's a neat real world example (with fighter jets!) of how this works: An F-117. I actually grew up with these flying over my house. Notice how all the panels have the same shade unless they're actually in the shadow of a different part of the airplane? Now, let's look at a more normal jet (an F-15): Whooo America! Except this one is actually Saudi Arabian - Gotcha! Relate back to the Shape and Form section. Which one of these bad boys would you cast as the good guy and which as the bad guy going on looks alone? Here, you can see an actual gradient transition between light and dark. Check out the left wing, it's an almost perfect gradient. Now let's go back to that pillow shaded mess from earlier: The light source for the cube and sphere aren't quite the same. What's different? Note the cube only really needs one value per side at this scale, while the sphere requires many more values to mimic the gradiated nature of shadows on curved surfaces. Bounced Light The kind of shading above is simplified since light can also bounce off surfaces and light up shadows. This often means that the part of the shadow that is farthest away from the main light source is actually lighter than the other parts of the shadow. This is most noticeable when an object is extremely close to a reflective surface, or is just plain big. This is the classical example of how this looks: Also note how the shadow it casts also gives you a better sense of depth. Here's a couple digital examples of the same thing. If these spheres were sitting on a blue surface, the reflected light on the cube would also be blue. The left is an example of bounced light located off the edge, which happens with highly reflective surfaces. The shinier the object, the more obvious and distinct this bounced light appears. Speaking of shininess, lighting and shading can not only reveal an object's form, but also its texture. Hue Shifting Hue shifting relates somewhat to bounced light, and comes up with pixel art a lot. It basically refers to how the hue of a shadow or highlight isn't necessarily just a darker or lighter version of the base color. The most common usage is for objects that are supposed to be in the sun. The direct sunlight tends to be a little yellow, but the blue sky reflects blue light into the shadows, so you have yellowish highlights and blue-ish shadows. This also relates back to warm colors and cool colors, with cool shadows and warm highlights. This idea becomes more important when you have multiple light sources (like underlighting from lava or whatever) that's a different color from other light sources. Remember, colored light affects the color of the object. But hue shifting can also be simply a stylistic choice, and by exaggerating the effect or substituting complementary colors you can get some pretty neat effects: Doing this too much will make your game look like it's trapped inside Instagram. Keep in mind that shadows can also appear to be less saturated, and that less-saturated colors can appear darker than they really are. There's not a total consensus on hue shifting in the art world, so find a way that you like, but keep in mind the more you shift, the more surreal your art will seem. Shading and Texture The texture of an object affects how light bounces off of it, so naturally changing how you shade something can also change what its texture looks like. There are specific terms for certain types of textures that will help you in thinking about different types of texture, too: Knowing this will let you buy paint without having to ask the forlorn-looking old guy working in the home improvement department for help. A Gloss surface is just a shiny surface, where the light bounces off a particular angle of the surface almost all in the same direction with very little scattering. What that means is the brightest part is very bright (since you're getting lots of light from that one place at once) and the darkest part is very dark (since the light is sticking together and going somewhere else). A good example of a gloss surface is the body of a freshly waxed car. A Flat texture is the opposite, where light scatters off the surface at many different angles. That means the brightness is more even, since no part of the object is directing all of its light in a particular direction. Old car tires are a pretty good example of a flat surface, as is modeling clay. A Matte surface is somewhere in-between. It reflects light in chunks, but scatters a lot too. A lot of plastic has a matte finish, like most keyboards. So when you're drawing, think about what kind of material that you're shading is supposed to be. Is it shiny metal, or flat cloth? You don't want your medieval characters wearing plastic-looking garb, and you probably don't want your sleek sci-fi armor to look silky soft. TL;DR: Light has to come from somewhere, or look like it does, for 2D images to look right. Page to get you started: Android Arts Tutorial by Niklas Jansson Practice Makes Perfect So now that all those concepts are laid out, what are you supposed to do? Well, start trying stuff out! Don't be afraid to jump right in. It really is true that anyone can draw. Sure, some people have a particular knack, but the biggest separator between a bad artist and a good one is how much they've practiced. You gotta do it a lot to get good at it. Practice, but practice smart. Game projects also provide a lot of opportunity for practice, so if you have a project in mind, start creating art for it if you haven't already (after reading this article all the way through, though). If you don't have one in mind, find one! Even the smallest game project has enough art that you'll get enough practical experience that by the next one you'll be noticeably better. And fortunately for non-artists, game art doesn't have to be Italian renaissance level quality to be functional. Three P's: Pencil, Paper, Practice The only way to get better at drawing is to practice, and the cheapest and easiest way is to do it with good ol' fashioned pencil and paper. It might be tempting to simply stick with digital-only for all steps in the design process since that's where your final product will be, but resist! Drawing by hand gets you more involved in the process and will help you avoid some of the more dangerous habits that relying on software tools will get you. Those tools can be great and it might seem easier at first to make sprites using the square tool, but trust me when I say that you would do ridiculous and ugly things that would be impossible to do with a pencil sketch. There will be plenty of time later to mercilessly exploit tools, tricks, and shortcuts when you're conscious of the basic principles. It might seem awkward at first if you've gotten used to doing things digitally only, but pencil and paper are the starting point for artists the world over for a reason. With that in mind, I recommend buying a sketchbook, some pencils (I like mechanical pencils, but it doesn't really matter at this level), and a separate eraser like a Magic Rub since you'll be erasing way more often than the #2 pencil designer gods intended. You don't absolutely need a sketchbook - the real key is that you need to practice, and to that end the margins of your class notebook or a sticky note at work aren't worlds apart. A sketchbook does let you keep all your work in one place, though, so you don't have to hunt down that one really sweet design for an enemy that you put on the corner of your homework or a memo at work. Sketching The key to pencil sketching is to think of all the lines as temporary suggestions rather than permanent representations. What? Don't get attached to your lines! Sketch over them, erase them, make new ones without regard for old ones. Of course, make all your lines fairly light when doing this. Start with the basic shape of your subject, and add detail incrementally. Most things can be approximated by basic forms, namely the sphere, the cylinder, and the box, which is especially useful for drawing objects in perspective. For example, don't draw a more or less finished head, then move to the chest, then arms, then legs, etc. because focusing on detail will make you lose sight of how those parts fit together. Start with a big rough sketch of everything together and add detail on top of that. Don't get attached to any lines in the beginning - don't be afraid to ignore lines and draw other lines on top until you get an overall shape that looks good, and don't be afraid to simply restart if things aren't going your way. This video illustrates this perfectly, as the artist builds the basic framework of the character, puts some rough shapes on top, the proceeds adding more and more detail - and erasing and re-doing parts that look bad. Here's a little image out of one of my old sketchbooks, complete with funky-looking man: Another figure - Don't look! Um, I guess he has a huge zit on his face? What was I thinking? Draft, Draft, Draft It might sound crazy at first, but you should sketch at least three versions of any character/object/setting before committing to a digital version to use in a game. Major studios often create literally dozens of concepts for a single character before even thinking about picking one. Even for background assets like trees or bushes that aren't interactive, sketching three versions to get one final asset is not an unusual ratio. Just like turning in the first draft of a term paper, making the first version the only and therefore final version is a huge risk and not one worth taking. By trying three different ways, you can also then take the best parts of each version and combine them to make a stronger final version. Here's a simple example of a couple cool space helmets, both of which are different than the final design below (and based on even rougher earlier sketches): Shout out to Anatomy and Proportions section since it's hard to make a helmet without knowing how skulls are shaped. The top part should really be casting a shadow on the visor... oh well. This might seem burdensome, so it's important to keep in mind that these sketches are rough, rough, rr-rrr-rooouuugh drafts. Don't spend time on them. In fact, the less the better many times, since the longer you dwell on a piece, the less flexible you become about revising it or making the next version different. Leave the detail out at first, just get the general idea down and move on. If you feel like it, you can then go back and add more detail to your first contender. Be prepared to draw, a lot, and be prepared to get a little frustrated sometimes. If your art looks iffy at best to you, congratulations, you are a human being. Your next drawings will probably be better, and the ones after that better still. Remember, getting frustrated is standard - if drawing was as easy as it looked, there wouldn't be this article. In fact, if you aren't getting at least a little frustrated drawing for a while, you either aren't pushing yourself or your contacts fell out and you've convinced yourself that blurry mess was totally your intention all along. TL;DR: Draft all your game art by sketching out several versions first with pencil and paper, without worrying about being perfect. Related Page: Sketching: The Visual Thinking Power Tool Conclusion Hopefully now that you are familiar with these concepts, you can go forth and create with the knowledge you need to not suck. I mean, be incredible! Seriously though, creating art isn't easy and it takes a lot of practice, but just having some idea of these concepts is fantastic. As I said in the introduction, most of the information here is in the context of creating 2D art for games, and doesn't necessarily reflect what you would get in an Art 101 class. Further Reading I've included links within the text, usually at the end of relevant sections, but if you're interested at all in any further information about game art, particularly character creation, I have to highly reccomend Chris Solarski's book Drawing Basics and Video Game Art. This article owes a lot to him and his book, and you can read some of his writing on Gamasutra.
  22. 4 points
    https://stackoverflow.com/questions/5574914/srandtimenull-doesnt-change-seed-value-quick-enough
  23. 4 points
    https://www.twitch.tv/videos/168126246 Link to the full review of all the submissions. I did go through them in order of games in the rar file.
  24. 4 points
    Making your formatting consistent is good. Just understand that everyone is going to do things differently, so it doesn't actually matter what you choose to do, so long as you are disciplined about doing it the same way throughout your code. There is no such thing as a universal formatting standard for code. If you want to format your code to be consistent, which is again a good thing, you should use a formatting tool like clang-format or Visual Studio's Format Document command (found under Edit menu -> Advanced). There's no need to do it by hand.
  25. 4 points
    There is a great book, "What Color Is Your Parachute?" that covers that in depth. I strongly recommend everyone reads it, it has been a best-seller for many decades so you can find many copies at your local library or used book store. Yes, you can do a job you don't enjoy. You can grow to love a job that you initially dislike. You don't need to be passionate about something to do it. For example, I spent some of my early years doing custodial work; I hate vacuuming and cleaning toilets. I also spent several summers earning money doing yard care even though I have severe allergies and needed to be heavily drugged to get through the days. However, I love software development and I can talk with people for hours about good practices, about algorithms and tradeoffs and software bugs. I also enjoy games and developing products that people enjoy. I also love several other fields, and I've turned them in to hobbies. Even though I love software development, there are still tasks I dislike. There are still software assignments I don't want to do, but I do them anyway because I'm a professional, just like I cleaned toilets and breathed pollen clouds while disliking the job. All jobs will have elements you dislike. In an ideal world you do stuff you love all day, every day. In the real world you can get occasional periods of bliss but most of the time you get boring real life. Sometimes you get difficult troubles, and in that case you can (and should) take any job you can honorably do. If that means doing a job you dislike that pays the bills, then for a time that may be a job you've got to do as you work to improve your situation. Anyway, go get a copy of "What Color Is Your Parachute?" which has several soul-searching exercises to help you figure out details of the things that you most enjoy in an effort to bring you closer to your own personal bliss, the things you enjoy most. I heard the quote years ago: "Life is to be enjoyed, not just endured." Endure when you must, but find joy wherever you can.
  26. 4 points
    Day 7! What a wonderful week! Today we tried to finish the game. We haven't implemented anything special, just bug fixes and gameplay enhancements. Here's the game: https://mega.nz/#!K40gGKyC!k-nuSvEdhKluAhznQvr3RFEC70ErwcXyjoxHF7QvNiU After I write this entry, I'll post the package on the site. Hope you enjoy! Thanks for reading and following the development of our game during this week!
  27. 4 points
    Competition is over, judging thread: The competition has begun, this years themes are: Chain Reaction | Assassination | Alien Invasion | Castles You must choose 2 themes to receive full theme scores. This year their is no stipulation on gameplay or graphical, You are free to interpret the themes anyway you wish, but remember it should be fairly easy to know which theme you chose. To submit a game this year, you need to sign in to this site: https://neonlightgames.com/woa/Submit with your gd.net credentials. If there is an issue submitting to the site, then you can upload elsewhere and link to this thread and i will manually add it to the site. Remember you can submit a game even if you did not tell us you were participating! Remember to receive participation points you must either post updates in this thread, or drop a link to your blog updates in this thread!! you can also get points by commenting on other people's updates as well! This year, our resident artist and judge riuthamus has graciously created a number of art assets for the themes of this year's contest. they are free to take for this week, and are free to use afterwards, but will be only available as free to obtain for this week before they will be placed in the unity store, so if you are seeking some assets to use in your games, you can find them here: https://dl.dropboxusercontent.com/u/41065/WoA_modelPack_v1.zip (note: check back tomorrow as riu says it's not 100% finished.) some images of the pack: Lastly i'd like to once again recommend gd.net'scord chat can be found here: ttps://discord.gg/Njc96xM where we have a dedicated channel for WoA. Good luck to everyone! remember to post your updates in this thread! Administration Thread:
  28. 4 points
    Addressing a few points in no particular order: Pure design positions are indeed a role in the industry, although they're comparatively rare and generally require a proven skill set. Most people in these roles got their chance by making their own projects, by being given a chance on some low-risk project, or by having experience in tabletop game design. Steve Cole is a good example of someone who could qualify for such a position. There are actually entry level pure design roles as well, but they're significantly more limited in scope and don't match what you with to do - you would probably consider them more akin to a design assistant, working on small bits of a project as part of a more senior designer's team. The reason noone is really considering this as a viable option for you, is as I covered earlier in the topic: you simply do not have a verifiable track record of relevant experience. You may well have designed hundreds of games and be very good at it, but as far as you've made us aware you only have verifiable credits on two released products: as a contributor to the SFB Tactics Manual (along with 25 other people credited for design), a design credit for Sinistar Unleashed (which had very unpopular design), and perhaps if you're lucky and someone remembers it your IKNFL mod. You haven't claimed to have any relevant formal education. You may well be a fantastic designer with a wealth of experience, but you have nothing to prove it, so it's exceedingly unlikely a business would risk money on the chance that you'll be as good as or better than someone with verifiable qualifications - noting again that the sort of pure design role you're interested in is generally not entry level and isn't going to fresh-faced Devry graduates either. So, if pure design roles are a thing, why do people keep telling you to learn how to program? They're actually giving you different advice, not aimed at getting you in to a pure design role. For the reasons above, people have trouble believing you would be able to get into a pure design role, so they're offering you an alternative: learn to make things yourself so you don't have to be held back by the industry, or so that you can produce something suitably convincing to get into a position you want in the industry. Remember above how I said pure design roles generally only go to people with a proven track record? Sometimes those people get that proven track record by learning another discipline such as programming or art so they can work in other roles until they prove themselves. In short, the suggestions to learn programming do not actually contradict the suggestions that pure design roles exist. In sales, they say that it doesn't really matter what's true - it matters what is believable. You're essentially trying to sell yourself to us, and you're constantly making some pretty huge claims about your abilities and about what 'rube' can do. Maybe the things you're saying are really true, they're certainly not impossible. They're certainly not believable though. You tell us you're a founding father of our industry, but none of us have heard of you and you aren't credited on the published products to prove it. Maybe it's true. But it's not believable. You tell us rube is 'a functioning simulation of god', but you won't share anything but the smallest details (and you make us wade through the most amazing amounts of text to get those small glimpses), and you even claim the full potential of rube can't be realised with current day computing limitations. It may well be true. But it isn't believable. Stop trying to sell us your truth, and sell us what is believable - once we believe, maybe people will start to see your truth. It's not believable that you're a founding father of the industry with years decades of design experience on hundreds of games, because the games aren't there for us to look at, so instead show us something we can believe: polish up some smaller, simpler designs and just show us that you're a good designer. It's not believable that rube is 'a functioning simulation of god' (whatever that means), so stop talking about the unprovable possibilities that current computing can't even handle, and stop talking about things you aren't willing to share details of. Talk about something we can believe, and show us what these lesser forms of rube can actually do in an implemented design. Don't talk about the history, and don't talk about future possibilities: stick to what you can actually show us right now (or in 6 months or in a year if you need time to work) in full detail, so that we will have no choice but to believe. That is how you can get some actual interest in the other stuff. Star Fleet Battles is one of the most (if not the most) complex and detailed game rule sets in existence, and you keep discussing how other games (such as Master of Orion) pale in comparison. You keep saying this shows how much more skilled the designers such as Steve Cole are. I don't think anyone disputes the skill of Steve Cole and other table top designers. They're work is fantastic, and many of their games have a very loyal following and have made plenty of money, often for years. But you don't seem to allow for the fact that taste in games is subjective. You love how complex and amazingly detailed the rules of SFB are, but many people hate it for exactly the same reason. When a designer produces a simpler game, it doesn't necessarily mean they are less skillful, it just means they had a different objective in mind. Often, these designers have been very skillful in designing a less complex game that appeals to the great number of people who prefer simpler games. You've mentioned a few times that the industry has no respect for table top and board game designers. I'm sure there are some people who don't, but I can assure you this isn't some all-encompassing attitude shared by the whole industry. I don't think I've ever spoken to anyone about it who didn't have a huge respect for those designers. Many people in the industry play and love table top and board games. Many study them to learn. Many design them as prototypes, or as full products to develop their skills. Many table top designers have made successful transitions to our industry and are now well respected designers. You're having trouble finding anyone who respects you, because (at least in my experience of you) you're all outrageously rude talk with no demonstrable credits or released product to show that you're actually worthy of respect, but in general I'd say our industry has a huge respect for table top gaming. It isn't laughable to defend Devry graduates getting positions while you can't get one, because you aren't after the same entry level roles that they get, and they are more demonstrably qualified than you for the roles they are able to get. You may well be a great designer, but you can't really prove it right now, whereas a fresh graduate can be assumes to at least have a baseline level of skill in the field taught by their course. Noone wants to make the same assumption about you when all you're giving is your word that it's true. You say the Pirate Dawn design document was actually quite well organised. It wasn't. I'm one of the people who tried to read it, and at least when I looked it was a disorganised unapproachable mess riddled with typos. Maybe that's because 'the industry wanted you to add a bunch of stuff', but that doesn't change what you presented. It just was not. If you'd like to fix it up (or have already done so in the past 10 years) I'm sure some people would actually try to read it again, but there's no point just telling us we're wrong about it - multiple people tried to read it, and we all have the same assessment. For whatever reason, it was a mess. If you have the time to write 500 pages, you probably have the time to go back and fix it up as well. Don't excuse it or explain it, just fix it. Lastly, you seem to think this offensive, overly wordy cult-of-personality you have going on is helping you, and have even suggested a few times that you "have to put it on to get attention". It isn't helping you to get any valuable attention. It just makes you look like an insane rambling crank who doesn't know what he's talking about, to the point that a great many people think you're trolling. If you're genuinely pretending to have this abrasive personality, knock it off. It's not serving you well. You've got plenty of people reading your posts and engaging in conversation, so stop screwing around and do something useful with the attention. Stop driving away attention you've got with paragraphs of irrelevant or unbelievable nonsense. Put your money where your mouth is, and show us you can walk the walk and not just talk the talk. If you're a brilliant designer, show us some actual, playable, brilliant designs. Feedback on Armageddon Chess will be coming in a day or so, we were pleasantly surprised that you claim to actually want to hear it, so some of the others are getting their thoughts together for me to pass on too. Good luck, shut up, and for the love of all that is good and holy show us some actual games! Hope some of that helps in some way.
  29. 4 points
    Dedicated R&D positions in the games industry are comparatively rare. You'll likely only see them at very, very large studios, if at all. Most development positions will involve some varying amount of R&D (usually during the early phases of a project) into varying subject matter. Most of the time, you'll see positions related to graphics and AI doing the most of it. Often this "R&D" won't be so much developing entirely new methods of accomplishing things (although sometimes it does), but researching how to adapt other people's entirely new methods of accomplishing things to the project at hand.
  30. 4 points
    Hi All, I'm taking part in the Week Of Awesome again. Third time. This year I don't have as much time available, a new job and newborn have left me with precious little vacation time left for the year and less personal time when I'm at home. With that said, I was in my day job today and will be tomorrow so I have only had time enough to think of an idea. The themes are interesting this year, I couldn't think of much for assassination but the castle theme and alien invasion is making me think Sci Fi/Fantasy crossover Tower Defence game. The genre is bursting at the seams but it should keep the scope small and well defined. With all of my jobs for the evening out of the way, I have only had enough time for pulling together a fresh project and the basics of my framework. So no pictures Hopefully I will make some progress tomorrow.
  31. 4 points
    As you can see, now buildings built in one screen sync to the other. I have a system where it takes a few seconds to build something, and I send the completion time over TCP, then build another work in progress object on the other computer, set to complete at the exact same time. This way, even half a second lag will still not hurt the experience. (On the screenshot, you can see the raw data stream in the console.) I also have a system where the players choose what sides they will play on. The basic system is that the first player to click wins. If both players click the same team at the same time, the both programs will generate a random number and the highest number wins. I haven't been able to test this system, and it will probably not actually work. Aliens and Knights have different types of buildings. They will behave the exact same way as each other, but have different names and images. I am thinking I can get some humor from a rock wall being exactly as strong as a force field, or a laser gun doing equal damage as a bow and arrow. If I get as far as having flying enemies, the knights will have some kind of Davinci winged wooden contraption, with equal speed as the aliens flying saucer. My next step is to give each team a fort. The game ends when the fort is destroyed. When I have a fort, I will not have anything to guard me from actually building the AI for the attackers. I don't think making complicated path finding will be worth my time. When encountering a obstacle, the NPCs will determine if going around left or right is the fastest. If neither is possible, it will go straight on ahead. (As all obstacles are breakable). Shouldn't be to much trouble...
  32. 4 points
    I'm happy to say that I've successfully added one of the two themes I chose to my game. The aliens! They are created at specific points in the map and run towards the player until they collide. At that point the screen will fade out (no battle swirl yet) and a battle will start. It's interesting to note that, just like Earthbound, other aliens can still continue to run towards the player while the screen is fading out. And if they make contact, then they too will be added to the battle. The battle itself isn't anything special yet though. It just displays the in-battle sprites of the aliens and you can attack by pressing the V button. Also the aliens won't attack back yet, which might be a bit disappointing. You can also change the selected alien by pressing left or right, but which alien is selected isn't displayed in any way yet. So that's not particularly useful. By the way I drew the in-battle sprite for the alien completely by myself. It won't win any awards, but I like to think it's pretty decent. Another thing to note is that I recently started using co-routines for animations in Python. Effectively they are just generators that use the yield-statement to give control back to the rest of the update-tick. They are quite effective in preventing the need for stateful member variables (fadeTimer, coolDown, etc.). I might write an article about it later if there doesn't exist any yet that already does a proper job at explaining them. Download link: http://www.mediafire.com/file/ciwguyrx82844l4/main_v0.0.2.zip (Reminder: press V to attack!)
  33. 4 points
    A day has passed since the competition began (at least in my country)., and now I'm going to show you the progress our team made so far. Here's a little video with the current stage of the game: The game we are about to make is about saving a castle from an alien invasion. We want to make a little bit Angry Birds style with aliens landing on the earth. Today we were able just to do the basic mechanics of the game, but we hope that in the following days we'll have the gameplay of the game. The models in this video are just placeholder content. (Tomorrow some of the models will be ready) All right, that's about it, thank you for your attention.
  34. 4 points
    Strawberry Alert: Day 1 Today I have started working on the Week of Awesome V challenge. The working title for the project is Strawberry Alert. I generated it randomly and it is very unlikely to change due to time constraints. The Project The themes I want to try are Alien invasion and Castles. My intention is to create a side scroller where the hero must defend her castle from an alien invasion. With this project I want to explore whether functional reactive programming can be successfully used in games. I intend to capture the user input and time effects into streams, apply map-reduce to these streams to generate the game state, and finally render that game state to the screen. I will be happy if I can deliver something playable by the end of the week. Unfortunately, this week I'm back to work after vacation and I've got a few social commitments that I must honour, so I expect to be able to dedicate only about twelve hours more to the project. So far, I have managed to put together a parallax background and the walking animation for the hero sprite. The Art I am using a hero sprite and castle tiles created by Jetrel. I still need to find sprites for the alien enemies. The Tools I will target the browser and create my game using JavaScript. My weapons of choice are: pixi.js: a rendering library for WebGL and Canvas. cyclejs: a functional reactive framework. xstream: a stream library designed to work well with cyclejs. The Links The code is available on GitHub and, since it is a browser game, I will deploy my daily progress so that you guys can try it out. GitHub Game
  35. 4 points
    Someone on my team had the genius idea of making our game multiplayer. I would hate that person if I wasn't on a one-man team. The basic idea of my game is it's a 2 player tower defense style game, where both teams have to build troops and defenses, and the first to kill the others home base wins. One side will be the alien invasionists, the other side will have castles. The attackers will have some kind of path-finding system, like clash of clans. It is my general strategy to get something playable on the first day, and work the rest of the week on polish. This time, sockets get in the way. Instead of the general client-server architecture, I need a symmetric system where both sides sent data to each other in the same way, and a third party can not join. At first, I tried using the python socketserver library. Both clients would start a server on startup, and prompt for a IP address. If you typed a address and pressed enter, the client would shut down the server and connect to the other server. The whole system was encapsulated and exposed only send, receive, and connect methods. The rest of the program did not care if it was client or server. There was one problem, however: Socketserver could not keep open connections. I could send messages from the client to the server anytime, but I could only send a message back as a reply. This was of course, unusable as no message might be passed for a few seconds, so a signal could come way late. I had found a answer earlier on stack overflow that used the sockets module directly as a server. At first, this seemed overly complicated, but having exhausted the earlier approach, and realized that using the same module for both client and server might save effort in the long run, I decided to go for that idea. I deleted all references to socketserver, and replaced them with copy-pasted code blocks from the answer, some of which I barely understood. The code I copied returned a new socket for every client. Since I need only one client, I decided to just delete the server and use this client object as soon as the connection was established. I then spent some hours figuring out why messages where being passed from one direction but not from the other, untill I suddently found that my recv() call was inside a if (self.mode==CLIENT) block. So much wasted time. Finally, I got both clients to sync state, as seen on the screenshot: Hopefully, tomorrow I will actually get some game mechanics done. Hopefully my system will not break outside a local computer. Hopefully, I can fix those ghastly castle sprites.
  36. 4 points
    This year I didn't have any preparation post because I was busy getting Tiled maps to works with my engine. This is because I want to make an Earthbound-like RPG for the Week of Awesome. So you can imagine I'm quite happy with one of the themes being "alien invasion" since that's literally what happens in Earthbound. The other theme I've chosen is "chain reaction", which will apply to the gameplay although I won't say yet in what way. It's better to keep it a surprise. Also for this year I wanted to use existing art rather than having to make it myself. Originally I wanted to team up with an artist but since that didn't happen I had to look elsewhere. So it's a good thing I know about opengameart where I found this pixel-art pack in a style very close to that of Earthbound. I did have to tweak the textures here and there though. https://opengameart.org/content/isaiah658s-pixel-pack-1 The game I'm going to make will take place in the woods so I needed to place a lot of trees in the Tiled map. Unfortunately drawing multiple tress over each other proofed to rather difficult. Initially I just tried making multiple layers in Tiled with different depth values, but the problem is you have to keep creating layers if you have a lot of trees in a line from top to bottom. So that gets messy really quickly. The current solution I've come up with is to create a patch of forest in the tile sheet so that I have tilable pieces of forest that I can copy over the map. It's a lot better but very error prone, it's very easy to place a tile in a way that makes it look like part of a tree is missing. Maybe I'll find a better way though. As for the main character, he can only walk around a simpel map right now. Also the game doesn't have any name yet so the exe is just called "main". I'll come up with the actual game name later. Download link: http://www.mediafire.com/file/ciizr3ubrizid7d/main_v0.0.1.zip Tomorrow I hope to get started on the most important part of the game: the turn-based battles with the aliens.
  37. 4 points
    Yes. This is because Pygame is based on ancient technology that is embarrassingly out of date. Pygame is one of the only systems that expects to draw to the screen using old technology. Pygame uses SDL 1.2. SDL.1.2 uses DirectX 5, specifically DirectDraw for graphics. DirectX 5 is literally 20 years old, written for a time when a typical screen was 640x480 and graphics cards were esoteric add-on units.
  38. 4 points
    Hey! Never ever give up on that I haven't played the game but it seems polished and captivating by looking at the images on steam and your blog posts. Good job on coming this far already. This is not bullshit talk but a really honest opinion. Congratulations! A small detail: I would consider lowering the price on steam. I am not saying that it doesn't deserve the price (I can't tell how it should be valued at since I didn't play it) but people rarely trust "new games" so they are probably not willing to spend 13 dollars on them. I am not saying it is not a fair price but for now it might be high. If I were you I would lower the price by a little or even promote the game by offering it to some people (as competition prizes is a great idea too) and only then increase it. All the hours you spent were not wasted for real. Keep up the good work!
  39. 4 points
    Pretty awesome that you released it, man. I wouldn't let a couple bad reviews get you down. Of course, it's easy enough to say that, but fear of exactly that kind of criticism is what has kept me from releasing stuff in the past. People can be dicks.
  40. 4 points
    Kavik, if you want people to take you seriously, don't tell them that they're stupid. Nobody will listen to you after you do that. They don't care about your decades of struggle. They don't care that you think you intellectually tower over them. They also don't care about the cosmic significance you think your idea has. If you can explain it, do so. If you can't, then work on your communication skills. Don't blame your audience for your own failings. Your writing has all the qualities of a classic crank. GEORGE HAMMOND claimed to have a SCIENTIFIC PROOF OF GOD. Gene Ray (Cubic) claimed to have proven he was above God, because he knew that, uh, something about there being four days at once in every day, because the Earth is a cube, or something, and that everyone else was stupid and evil. When other people read your writing, they don't think "boy this guy really seems to know what he's talking about", they think "Oh, another crank who thinks he's decoded all of the secrets of the universe." The #1 sign of a crank is that they say they're so smart nobody else can even understand how smart they are, and that their ideas are so good, nobody else is qualified to judge them. The truth is, a lot of a time nobody can understand a crank because the crank spouts of a bunch of hyperbolic jabber about how great they are, but never actually explains their idea in sufficient detail to tell whether or not it's worth anything. Your writing fits this pattern. They often use the excuse that their invention or discovery is so revolutionary, they won't publish it, for fear that THE ESTABLISHMENT will steal it from them. Your writing also fits this pattern. If you don't want your idea out there, why are you telling people about it? Cranks tend to make claims that are rejected out of hand because they're enormously overstated. If someone else told you their work was then you would probably ignore them because that sounds impossible. It seems very, very, very unlikely that you have actually arrived at the ultimate goal of simulation design. If you had, wouldn't you be out there making the best simulations anyone has ever seen? Clearly, you're not, if your best hope of finding funding is posting angry rants on game development websites. What response are you actually looking for? What would you consider a successful interaction? Someone simply giving you a million dollars to make your game, sight unseen? That will never happen, because people with "revolutionary" ideas are everywhere, and very few of them have the chops to realize those ideas. If you can, make something with your idea. Make it a phone app and put it on the Android app store. Make it a board game and put it on Kickstarter. If it actually works, people will come calling. If not, well, maybe your idea isn't as good as you think it is. Finally, "Rube" is a terrible name. It invites unflattering comparisons between the name of your product and your online persona. Edit: Claiming to be the inheritor of hundreds of years of knowledge, but you're the only one who actually understands it all, is another classic crank behavior. Again, if your idea is as good as you say it is, put out a proof-of-concept, just enough to demonstrate its superiority, or else everyone will conclude you talk a good game but have nothing to back it up. Second edit: Plenty of people have released free versions of games, then gotten funding to produce the real version. If you say your idea is so magical you can't show it to anyone for fear of being copied, then the natural conclusion is that it's not that good, but by never showing it to anyone, you avoid being found out as a fraud. https://en.wikipedia.org/wiki/History_of_perpetual_motion_machines
  41. 4 points
    WARP uses CPU so floats should behave IEEE compliant. Don't rely on this for GPU. At least assume they can behave differently. Probably the debugger emulates the instructions on CPU, too. You can check for NaNs in HLSL though: if(isnan(whatever)) return float4(1.0, 0.0, 0.0, 1.0); // Red alert, this is not a drill Final note: Instrumenting your HLSL code can of course rearrange the instructions and give different results. And then hide the bug
  42. 4 points
    Work is how a lot of people value there lives, yet it isn't the only way. The idea of people not working is alien to us now, yet the same can be said about our lives. Think of explaining banks and money to your caveman ancestors. There should be something after money, yet even if we where shown what it was, chances are that we wouldn't be able to understand why people of that time value it.
  43. 4 points
    Capitalism will never die, just change form. As long as humans can value something, there will always exist a need to have more of that value. So if AI did provide for humanity then we would find things worth more than basic necessities. For example when we entered the industrial age, the farmers didn't all just stop farming because food output increased a thousand fold. They didn't hangup there farm hats and just laze around all day, setting up some kind of slave system. People just expanded there view and moved on, the same thing should happen if AI do all the basics for us, we will just focus on the advanced an beyond.
  44. 4 points
    I've been developing on Microsoft Windows for a long time, since around 1992/93, when I got my first PC. Various other platforms before that, but I've pretty much stayed with it, not because it is a technical marvel (it's not), but based on the idea that it was the most popular OS so it should be easy to get programs running on other people's machines. Coupled with this (and no doubt because of this) there is also loads of good software for development, which had made it the 'default' choice for me. Don't get me wrong, I have certainly admired certain aspects of the various Apple OSes over the years (especially when they embraced BSD), but been put off by having to relearn the 'backwards' way of doing everything, and rightly or wrongly the suspicion of a 'control freak' walled garden approach, where you are not in control of the computer, Apple are. And don't get me started on my experiences of having to use iTunes to do something as simple as transfer a file over usb from a Mac to an i-something. And the obvious bias towards monetizing every aspect of the experience. In contrast I sometimes feel that Windows is *overly* open, exposing too much to developers, allowing them to too easily 'hijack' your PC and take over its resources for their own purposes at startup, as well as a series of insecure 'technologies' that seem more appropriate for malware authors than legit developers. It seems to be designed so that the OS will run slower and slower the more apps you install, until you give up and re-install windows. Along this line comes the other unpleasant thing I found with windows, that a lot of the software would rely on some other flavour of the month technology being installed as a dependency. Want to use a text editor? No, first you needed to spend half a day installing the latest huge bloated .NET runtime, to find it probably breaks some other app. And for something that is meant to be backward compatible, certain software companies (particularly Microsoft themself) seem to go above and beyond the call of duty in making their software incompatible with anything but the latest builds of the OS. And so we come to my personal last straw .. I spent some time last year evaluating different IDEs, and preparing projects, converting code etc, until I finally settled on using Visual Studio 2017, which was in the final release candidate stages at the time. The first version worked great until it expired. Then I tried the updater, which failed miserably at installing the next version, so I had to manually tweak things until it installed. Finally I came back from holiday 3 weeks ago to find that the 'final final' RC candidate had expired, and I was required to install the release version. Unfortunately I found the installer refused to work on my system. During the time between the RC and the release, they managed to screw up the installer (of all things??). So I was left unable to do any work until I had it resolved. I spent several days backing up my PC and trying to update it, but even with the windows updates no joy with the installer. I resigned myself that I had a choice of either buying a new hard disk and installing windows 10, or buying a new PC. Given I didn't want to risk losing my old work, I went for a new PC, even though my old one was perfectly adequate. £650 or so later I had ordered a fanless kaby lake system. During the order I had the choice of OS to put on it. I had originally planned to put Windows on it, but thought what the hell, I should have another play with Linux, as one of the options was Linux Mint, and I could be sure the hardware would all work, so it should be easy. While I waited a few days for the build, I did some research into Windows 10. Unfortunately I became more and more disillusioned the more I read. While I'm sure technically the OS has got better over the years, I've heard only disturbing things (from 'the register' etc) about the roadmap Microsoft is taking with Windows. One of the things I hate about Windows is the need for updates, and the way you are left to pray during the process that they don't break some other bit of software. So usually I turn automatic updates off, and carefully manually select any if they are really required. Not so with Windows 10! As (allegedly) the 'last' version of windows, it will now automatically update itself, forever, whether you like it or not. That's nice to know that if you are a business, you have the very real possibility of waking up one morning to find Microsoft have borked your work and there's absolutely nothing you can do about it. This is clearly a showstopper for many people, for instance having a meeting to show clients the next day and finding your PC has been remotely broken by some well meaning folks who I'm sure have your best interests at heart and not theirs. But it doesn't end there, no now the operating system is designed to take your personal info, searches, work etc etc and send it (without your permission) to Microsoft central command mothership. Simple, you turn it off, you would think, except that, apparently, it seems you can't turn it off. So you think you will block the MS servers in your firewall etc. No dice, as the OS apparently ignores these rules because slurping your private data is too important. And even if you think you've worked a way round this, you only have to leave the PC till the next morning, for the next AUTOMATIC update to circumvent your attempt to circumvent the data slurping. Honestly, there must be laws against this kind of thing. All this made me realise I had to seriously think about moving off windows as a development platform in the longterm, and that time may just be NOW! Several of my old dev colleagues had by now moved to other platforms, notably a lot have moved to Apple. I admit I have an irrational phobia of all Apple products, so the only choice for me was to investigate Linux. I only had some *very* basic grounding in unix (having done some pascal on unix machines at Uni), and having played with linux on my Asus EEE netbook many moons ago. So my experiences, in the next blog post, should be useful for anyone who is an absolute beginner like me. Suffice to say, it has been a very difficult slog learning the basics and converting my code, but I have *finally* got my libraries and game code working, and I am now a convert. The whole Linux experience seems light years ahead of windows. I may still end up having to install windows in a VirtualBox machine, but I haven't had a need as yet. Next blog post will be my migration experience...
  45. 4 points
    I'm not sure what you're on about. This seems unnecessary. They're undefined if you have a negative number of bits or if the shift is larger than the number of bits. But you should never be in either situation. That is a bug in the code, a bug in the logic. Writing code that solves a bug by wrapping it inside a function that hides the bug is nonsense. That is a "Don't Do That" bug, the problem is that the programmer did something they shouldn't. It also gets into trouble if you attempt to shift a signed negative value. Since the language does not specify exactly how numbers are encoded it would be nonsensical to enforce what happens on those situations. That's another case of "Don't Do That'. None of those are particularly problematic. Programmers shouldn't be doing that in the first place, and if they do, that's a bug that should be caught through testing. As for your performance concerns, every CPU that matters implements a bit shift opcode. Every compiler I'm aware of either simplifies the expression to something even faster, or it generates the CPU-specific opcode. It is hard to get much faster, especially compared to all your branching code.
  46. 4 points
    Can you? Yes. Should you? It is a STRONGLY discouraged practice. Generally in programming you want to minimize the amount of coupling with other systems. You've got your collision system coupled with a texture system, which doesn't seem to make any sense to me. What does physics collision have to do with object texturing? You're suggesting increasing the coupling even more. Not only is the physics coupled to rendering, but now the object is coupled with the entire Application entity. Far better for systems to work independently, and there are many great patterns that work with this. One is forwarding commands to be handled by the appropriate level. Your collision system might pass an event or call a function on the object when the collision takes place, now the collision system knows nothing about textures; the object itself may not know about the details, but may have a component that is interested in the response so it calls the component's function on collision; the component already knows the texture and it also knows to change in response to a collision.
  47. 4 points
    Service locators are to singletons as singletons are to globals; one step improved, but still pretty bad. I mean, I've used service locators before when hacking something together quickly, but they have almost all the same problems that a singleton does: global access to an object leading to high coupling global instances of an object meaning more shared state poorly-defined object lifetimes (usually) superfluous code enforcing that you only ever have 1 object, when there may be times you can make use of multiples Basically, I try to take a step back when thinking about code like this. If I find myself thinking "lots of bits of the code need access to object X", I know that is not really true, and so I try to find one of several strategies for resolving that. e.g. if object X is basically a resource provider (e.g. TextureManager), can we just extract what we need at initialisation time, and pass those objects in directly, instead of querying for them later? if object X is basically an event sink (e.g. SoundPlayer), or an event source (e.g. InputManager) can I just connect to it via generic events/signals/delegates/std::functions/whatever, performing the connections once and then never needing to refer to the object again? if object X is some sort of helper object which doesn't maintain any state, can I make the methods into free functions that can be composed arbitrarily (C, C++, Python, Javascript)? Or can I change the object into a static class (e.g. in C#) for similar effect? if object X is a combination of the above things, or is just accessed everywhere because it performs a lot of different roles, can I split it into separate objects X, Y, Z, each of which might be easier to handle?
  48. 4 points
    For an introduction to my reasons for migrating from Windows to Linux, see my previous blog post. Here I will try to stick to my experience as a Linux beginner, and hopefully inspire other developers to try it out. Installing Linux The first stage of course in migrating to Linux is to either install it on your PC, or try a 'live' version off e.g. a usb stick (or even try it on a virtual machine?). I can't say too much here, because I got my new PC with Linux Mint pre-installed, and there should be plenty of guides on google. I went for Mint because I had briefly tried Ubuntu a few years ago, and I liked the look of Mint and fancied a change. I knew it was based on Debian like Ubuntu so there should be lots of software. My first stage after unplugging my windows machine was just to take baby steps to familiarize myself with it, without running away in fright. After plugging in my network cable, I was away with Firefox browser. But after a few minutes I decided to install Chrome, as I am a fan and used that on windows (going with familiar!! safe space!!). This entailed installing software. Installing Software On windows, the process of installing software usually involves downloading an installer package from the internet and running it, and hoping it likes your machine windows version / hardware / dependencies. You can do this on Linux too (particularly for cutting edge versions of software), but there is also a far easier way to do it, via a 'package manager'. The package manager is actually the pre-cursor to all the various 'app stores' that have become popular on Android and iOS, but the idea is simple, you have a searchable database of lots of software you can install, usually simply with a click. It also has the magic advantage that it has a very good system for automatically working out the dependencies required by any software, and installing those for you too in the background, or for finding conflicts (if these do occur, when I have rarely had conflicts it has been because I've been trying to do something nonsensical!). I don't know whether it is my new machine, or linux, but the process of installation (and removal) is orders of magnitude faster than windows. It honestly only takes a couple of seconds for most of these installations. Anyway suffice to say I was very quickly running chrome, installing my favourite plugins, running my favourite websites. Accessing Windows Hard Disks The next stage was to get some of my data across from my old windows PC. This is where things get slightly interesting. Predictably enough, linux uses a different filesystem to windows, 'ext4' on my machine, whereas my windows external hard disk was formatted as NTFS. As is Microsoft's way (to discourage competitors, no doubt), NTFS is not public domain. The clever Linux devs have presumably reverse engineered much of NTFS, because you can mount and read from the NTFS disk. However, I am erring on the side of caution and not writing to NTFS for now, because from previous experience of exFAT on Android, it is possible that an incorrect write can bork the file system, and hence lose a LOT of work. My solution for now was to copy my working source code etc from the NTFS hard disk to my ext4 linux SSD. Longterm I intend to convert all my NTFS external hard drives to ext4. It would also presumably be useful if Windows could read from ext4 drives, but I don't know how easy this is as yet. Great! I had some data on my new machine. I tried some movies and they worked great in the in-built player, and VLC (which I installed). Image files loaded fine in the in-built viewer and in 'the gimp', which is sort of like the linux photoshop. I've used the gimp a little on windows, and am hoping it can do a lot of the photoshop duties. Blender For 3d models, I've been using blender on windows, and as luck would have it, this open source software is available and runs very nicely on linux. Was installed and loading my game models in no time. For development, this just left an IDE and compiler for c++ (my language of choice). Linux has a very handy standard compiler which is easy to install (g++ / gcc). This is where I might mention 'the terminal'. The Terminal Although the name windows has become synonymous with the windows GUI, it is important to realise that an operating system doesn't have to be irrevocably intertwined with a GUI system. In linux, the operating system can use several different GUIs, depending which flavour you prefer. Or none at all, if for example you are running a server. The way to talk to the operating system below the level of the GUI is a command line interface called 'the terminal'. There used to be one used commonly in windows too, the DOS prompt, but it is rarely used now. In contrast on Linux, the terminal is still very useful for a number of operations, unfortunately it can be a little scary for beginners but this is a little unjustified. To get the terminal up I just press Alt-T. You can list what is in your current directory by typing 'ls'. You can navigate up a directory with 'cd ..'. And you can navigate into a directory with 'cd MyFolder'. It will also auto-complete the folder / filename if you press tab. From the terminal you can do a lot of stuff you would also do from the graphical file manager (the excellent 'nemo' is built in to linux mint), such as copying, deleting, moving files. You can also manually tell it to install packages just like it would install from the package manager, with the command 'apt-get'. To install software, you need admin privileges (this is handy as it prevents malware from doing anything naughty without you typing in the admin password). To get admin you type 'sudo' before the command: sudo apt-get install build-essential This tells it to run as admin (sudo) to run apt-get, and install (or remove) the package called 'build-essential'. This contains the compiler and other building tools. IDE Unless you fancy yourself as a hardcore compile from the terminal from the getgo type of guy, you will also probably want to use an IDE for development. As I use C++, there are several to choose from, such as Eclipse, Code::Blocks, KDevelop, Code Lite etc. I went for QT creator, as I have used it on windows (again, familiarity!! baby steps!!). Once QT creator was installed, it was fairly easy to tell it to create a hello world app and test it, it worked great! This is where things got slightly more interesting. My current project is an Android game. I had been maintaining both a PC build on windows, and the Android build, with the platform specific stuff isolated into things like creating a windows, setting up OpenGL, input, and low level sound. OpenGL ES Where things got slightly confusing is that because I am developing for Android, I was using OpenGL ES 2.0, rather than the desktop version of OpenGL. On windows I had been using the ARM Mali OpenGL ES Emulator, which emulates OpenGL ES by outputting a bunch of normal OpenGL calls for each ES call. I was anticipating having to use something similar on linux, so I attempted to install the Mali emulator in Linux, however I had little joy. I was getting conflicts with existing OpenGL libraries used in SDL (which I intended to use for platform specific stuff). Finally after investigation I realised that my assumptions were wrong, and Linux actually directly supports OpenGL ES AS WELL as desktop OpenGL, through the open source Mesa drivers. I eventually got a 'hello world' OpenGL ES program working, and was convinced I now had the necessary libraries to start work. 64 Bit Conversion The next stumbling block was a biggie. For historical reasons, all my libraries and game code were 32 bit. I had been developing with the idea that a lot of Android devices were 32 bit, and I was hoping the 64 bit devices would run the 32 bit code (hadn't really tested this out lol). So I had been previously compiling a 32 bit windows version, and a 32 bit android version. And it soon became clear that my linux setup was compiling by default to 64 bit. No problem I thought, I should be able to cross compile. With some quick research I managed to get 32 versions of the libraries, however I had no joy with 32 bit version of OpenGL. It refused to install, and being a linux beginner I was stuck. I did some little research, but no simple path, and realised that maybe it was time to convert my code to 64 bit. Or rather, to have my code run in 32 bit and 64 bit. I had been (rather unjustifiably) dreading this, as I have a lot of library code written over quite a few years. As it happened, aside from some changes to my template library, the biggest problem was in the use of 'fixup' 32 pointers in flat binary files formats. I have been using this technique for a long time now as it greatly speeds file loading, and also helps prevent memory fragmentation. Fixup Pointers Essentially the idea with a 'fixup' pointer is you store into the file an 'offset' from a fixed point in the file to a resource, often the start, because there is no point in saving a real pointer to a file as it points to a (changeable) memory location. Then you can load the entire binary file as one big block, and on loading 'fixup' the offset pointer to a real pointer by adding e.g. the offset to the memory location of the start of the file in memory. This works great when the offsets are 32 bit and your pointers are 32 bit. But when you move to 64 bit, your offsets are fine (as long as the file is smaller than 4gb), but there is not enough room to store a 64 bit pointer. So you have a choice, you can either do some pointer arithmetic on the fly, or change your file formats to use 64 bit offsets / pointers. After a trial with the first method, I have eventually settled on going with 64 bit in the file, even if it uses a little more space. Of course the disadvantage is that it has meant I have needed to re-export all my assets. So at the same time as converting my libraries to 64 bit, the game code, I also needed to convert my exporters to 64 bit, and re-export all the assets (models, sprites, sound etc). This has been a frustrating big job, particularly because you are coding 'blind'. Normally when you program you will change a little bit, recompile, run and test. But with such a conversion, I had to convert *everything* before I could test any of it. Success! It has been demoralizing doing the conversion, I won't lie. But I have been so impressed with the operating system I was determined to make it work. And finally bit by bit I got the exporters working, re-exported, then the game, debugged. Got some crazy graphical errors, errors in the shaders that the OpenGL ES implementation didn't like (that's a whole other story!) but finally got it displaying the graphics, then did an SDL version of the sound this afternoon which is working great. One thing I will say is I should have been using SDL before, it is really simple and makes a whole lot of sense of taking out the eccentricity of setup code on different platforms (windows in particular is very messy). So to summarize I now have (nearly) everything working, compiling and running on linux. I still have to install android studio and try debugging an android hardware device through usb but I'm very hopeful that will work. Even if it doesn't it's not a show stopper as I can always use a second PC. I am gradually becoming more familiar with linux every day and even feeling I might get tempted to learn QT so I can do some nice 'native' looking apps.
  49. 4 points
    You could use them, or keep your sky dome and in the vertex shader do something like: //... some code posH = mul(inputPos, viewProjMtx); // this is your SV_Position output posH.z = posH.w; // when the divide by w occurs, this will make the depth 1.0 (far plane) //... whatever else You could also just use a full-screen triangle or quad and use the same "push it to the far plane" logic. Then in the pixel shader, color it based off the y component of a view ray (a ray from starting at the camera and extending out into the scene) - all depends on how fancy you want to get. If you stick with the dome, make sure you only transform it by the camera's position, and not rotation - otherwise the entire sky will spin as the camera spins.
  50. 4 points
    Welcome to GDNet’s For Beginners discussion forum! If you’re new to game development and are looking for some help navigating the many choices and challenges of the field, this is the place for you. If you’re a seasoned pro and are looking to pass on some of your wisdom to the next generation, this is a great place to do it. Additionally, please consider joining our Discord server to engage in real time with other game developers from our community. There are some simple ground rules the moderation team enforces in this forum, in addition to GDNet’s general community guidelines: For Beginners is a forum for all disciplines: programmers, artists, designers, composers, and everyone else. In other words, it’s not just programming questions that are acceptable here. Any questions from anyone who is just getting started in any aspect of game development are fair game. The primary exception to the above are questions dealing with career advice: how to break into the industry professionally, what choices to make regarding school choices, and so on. Those belong in our Career Development forum. This is place for beginners to ask questions and get answers. It’s not a place to post tutorials or articles, or links to tutorials or articles, that you think might be helpful to beginners. For that, you should use the Your Announcements forum. If you’re a beginner posting a question in this forum, please try to include as much information about your problem as you can. Be very specific. Include the exact text of any error messages you are getting. If you’re a programmer including code, include the exact code. You are much more likely to get a good answer quickly this way. If you are a grizzled veteran answering questions, please remember that even you were a neophyte once, and be particularly cognizant of the fact that the audience here may not have the years of experience you do. Try to be as precise, clear and forgiving in your responses as possible. Please avoid derailing topics into tangential discussions of technical minutiae and subtle pros and cons. Topics that drift too far afield of the original poster’s query may be reigned in. Please do not attempt to mark threads as “solved” or otherwise “closed” because you think the question has been answered. Sometimes there’s more than one side to a problem or solution, and we encourage discussion so long as it stays relevant to the original topic and to the experience level of the asker. “Solved” edits will be rolled back. Be nice, respect your fellow members, and remember that we can usually all learn something from somebody else.