Popular Content

Showing content with the highest reputation since 07/18/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
    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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 5 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
  11. 5 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!
  12. 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.)
  13. 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.
  14. 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.
  15. 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).
  16. 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.
  17. 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.
  18. 5 points
  19. 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.
  20. 5 points
    It has to be the same mutex. Otherwise they're not interacting in any way to prevent the other thread from accessing the queue. The point of a mutex is that it is shared, like the thing it is protecting, different threads must acquire it before proceeding to use the protected resource, and only one thread can hold it at once. The other threads will block if they try to access the mutex, until the mutex is freed up by whichever thread acquired it. This means only one thread can access the resource at once - which is the intended behaviour. There are some esoteric situations where people use multiple mutexes for various functionality but that is not the usual situation.
  21. 5 points
    You can definitely improve the background image and main menu. When I clicked your link I initially thought it was a popup ad and instinctively added it to my adblock blacklist before I realised it was the game. Other than that, I would be interested in playing this game with the player speed slowed way down, such that you actually can make decisions for both snakes within 2-3 frames of time. As it stands now, the strategy is to make the top one a bit longer, then put it on autopilot and focus all of your attention on the other one, etc. My idea would be Slow down snek speed so you can focus on both Remove wrap around feature so you have to focus on both (add borders)
  22. 5 points
    The main thing I'd suggest keeping in mind is that you might be artificially limiting your options by trying to find an entry-level job which also is a dedicated AI role. Entry level is hard enough to break into as it is, and AI is a specialization that typically involves some baseline experience in making games. Your best bet (IMO) is to get a good title or two shipped first as a gameplay programmer, and pick up the AI as you go. Once you have the basics of shipping code under your belt, you can start looking into the specialization. You should ideally be conversant in all of the following: Decision making systems (scripting, utility-theory, behavior trees and similar architectures, planning, state-search, machine learning [ugh], and so on) Path planning algorithms and data structures Perception modeling (sight, sound, etc.) Animation techniques at least at a high level (know what a blend tree does, how to play animations, etc.) I'm sure there are more things. Pick up a good game AI text and you should at least be comfortable talking about every subject in there. Hopefully that explains why entry level and AI specialization is a hard combo :-)
  23. 5 points
    So, I ended up doing the "skirts" method I spoke of in the last post. And in conjunction with the default Urho3D water shader (with a few small tweaks, and more to come to eliminate artifacts on the corners of the water blocks) it actually looks pretty decent. The water animates a noise texture that ripples the ground beneath. It also uses a reflection texture (which I have set to black at the moment) if desired. I might tweak the water shader further, but for now I'm happy with it. I've also got all the small issues sorted out from the change to multi-level water. It wasn't a large change, but I was surprised at how many different parts of the code worked from the assumption that water was determined by elevation < 9. I thought I had contained it better than that, but I did get all the various spellcasting, pathfinding and object spawning oddities worked out.
  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
    Greetings and Salutations. I can't think of anything that justifies the risk to add at this stage, So end of day seven for me. I spent the day mostly adding polish, Which includes: Laser pointers for the turrets, No ammo sound, Low health sound, Changed the colour on each alternative entry in the credits. I thought I solved the performance issue (which was some kinda base static light pass, Which I could find no info on ), It runs faster in the editor tho. The AI(FrogMen) is a bit iffy, They should shoot or melee you on sight. Yet they don't most of the time, But the work well when they do. There is a text field in the options menu you can use to execute any UE4 console command, I have included a file "CVars.txt" with some graphics related commands. You may want to drop the quality setting down to medium, I had to for the game to hit 60 FPS. This has been fun, I look forward to playing the other entries. I may even do a review of them. Dang, I forgot to credit @riuthamusfor his asset pack (Sorry @riuthamus). Link to my entry: Here Title: Invasion of Planet Frog And the picture: Thats all for now, Thanks for reading.
  26. 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:
  27. 4 points
    Today I've implemented the chain-reaction part of the game. In the battles, if you defeat one of the aliens, then it will generate shockwaves that damage the aliens that were standing on the left and right. Even better, if a shockwave manages to defeat an alien it will create a stronger shockwave. And, you guessed it, this can happen one more time, creating the strongest shockwave. I intent this to be the only way to defeat certain enemies later in the game. I've also added an experience system to the game. So if you defeat enough aliens Harris will level-up and gain extra hitpoints and attack power. Although I'm not sure increasing the attack power this way is a good idea. It seems like you become overpowered really quickly this way. There are also objects in the game now that can be interacted with. Simply walk up to them and press V. Lastly the game-over screen now displays "GAME OVER" (surprising, I know) and asks if you want to continue. Tomorrow I plan to implement the boss for this game and change the level to roughly how it should look like in the end. That way I'll have something to submit already. Download link: http://www.mediafire.com/file/2mvbb3r0bcjkrcn/ThunderStruck_v0.0.4.zip Controls: Arrow keys for movement, V for confirm, C for cancel.
  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
    I disagree with at least parts of the above replies. The PayScale source is talking about general software R&D, not what it means for games, and while dedicated positions are comparatively rare, part of the reason they are more common than you might think is because they aren’t just for the very large companies. That some companies have created their own fancy terms for it (“Advanced Technology Division” for Square Enix for example or “Core Tech” at Deep Silver Dambuster Studios) may add to the illusion that it is rarer than it is. Perhaps the best way to answer is to show actual R&D recruiting pages from companies, and for the ones where I actually worked I can give more details. tri-Ace (~130 employees) http://www.tri-ace.co.jp/en/recruit/category/programer.html#programer_02 tri-Ace has its own game engine called ASKA Engine. The R&D team works on the engine, which was built by them from scratch. Since the engine is fairly fully fledged now, current tasks are mostly related to maintenance and optimizations, but new features are still constantly being added, from various types of editors, network code, new graphics API support, tool-chain improvements, etc. The team is led by tri-Ace CEO/CTO Yoshiharu Gotanda, who is responsible for helping advance the state of real-time physically based rendering. A mathematical prodigy, he creates new rendering equations himself and gives presentations at Siggraph. http://research.tri-ace.com/ Interesting reads are his physically based Blinn-Phong, layered models, and his cheaper and more accurate Oren-Nayar approximation (http://research.tri-ace.com/Data/s2012_beyond_CourseNotes.pdf), and his film tonemapping (http://research.tri-ace.com/Data/course_note_film_simulation_for_videogames.pdf), among others. The engine is released to the game teams on its own time, and game teams are not allowed to know when it will be released. Schedules are usually not tied to any specific project, so you typically do not have crunch and long hours. But there may be critical bug patches that need to be made or critical feature support here-and-there. Square Enix (~3,924 employees) http://www.jp.square-enix.com/tech/index.html# While a majority of their R&D department was dedicated to the Luminous Studio game engine and Final Fantasy XV, members in this department are actually more free-floating between all the projects as needed. There are distinct teams within it dedicated to graphics, effects, sound, animation/physics, etc. But team members don’t only work on Luminous Studio. They are sometimes moved to other projects where they will have to apply their skills to a new code base. They cover the full R&D spectrum, meaning they accommodate people who consider themselves more academic and less of a programmer, people who prefer just to implement, and everything between. The academics create new techniques and publish new whitepapers, pure programmers take white papers and implement them (from any source, not just the internal academics). The schedule is a bit more hectic, but that doesn’t mean more crunch time than you would expect anywhere else. It mainly means shifting gears as your tasks change dramatically. Deep Silver Dambuster Studios Ltd. (~100 employees) I won’t discuss why they temporarily removed their “Core Technology” (what they call R&D) positions, but here is how it looked 1 year ago: Senior Programmer – Core Technology Deep Silver Dambuster Studios have an exciting opportunity within their highly talented and experienced Core Technology department for a Senior Programmer. You will be working on an established AAA title for Next Gen Consoles and PC platforms and your primary remit will be to help keep our Engine, Editor and Tools on the cutting edge. We’re looking for someone who understands the processes involved in making a first-class, AAA modern game, and wants to make a big difference to our development team’s workflow. Main Duties and Responsibilities: Work with the Core Technology team leads to maintain and optimise existing systems, develop new engine features and build tools that give greater efficiency to our development pipeline. As a senior member of the Core Technology team you will be expected to work closely with other team members, leading by example and helping to ensure that a high level of coding standards are achieved and maintained. The R&D efforts here go towards maintaining an engine—optimizing, fixing bugs, adding features that might be needed for a game, etc.—and its tool chain. As game technology continues to move forward, there is a never-ending slew of new graphics techniques to add, new texture formats to support, tools to create and view those textures, etc. Development here is more closely tied to the game team, but many specific tasks are not. Crunch doesn’t happen that often. I can’t give too many details on the next few because I have never worked there, but here are a few more I know exist. I let their recruiting pages describe their roles. Naughty Dog They call it ICE (Initiative for a Common Engine). https://www.naughtydog.com/greenhouse/job/590792?gh_jid=590792 https://www.naughtydog.com/greenhouse/job/590787?gh_jid=590787 Guerrilla Games They call it their “Tech Team”. Since they are part of Sony, I expect some overlap with ICE, but as it is its own studio they will have their own set of tasks, schedules, points of focus, and demands. https://www.guerrilla-games.com/join/senior-graphics-programmer 2K Games No special term for it (check for jobs with “engine”). SENIOR SOFTWARE ENGINEER - GAME ENGINE SENIOR ENGINE PROGRAMMER Blizzard Entertainment No special term for it (check for jobs with “engine”). LEAD SOFTWARE ENGINEER, ENGINE SENIOR SOFTWARE ENGINEER, ENGINE Double Fine Productions Now that you know what an R&D programmer for games mostly does, you can spot hidden R&D positions. Senior Programmer Note that I found 2K Games, Blizzard Entertainment, and Double Fine Productions just by using GameDev Map, clicking on my area, and checking just a few entries on the first page. https://gamedevmap.com/index.php?location=San Francisco Tiny studios tend not to have these positions, but medium, large, and X-large do. There just seems to be so few R&D positions out there because many studios either call them something fancy or do not have a term for them at all. But almost every company is either making its own engine or using a 3rd-party engine such as Unreal Engine 4, and in both cases there is a need for people to keep these updated, add feature support, optimize, and fix bugs. Also note that even the Japanese companies and Guerrilla Games in Amsterdam seek English-speaking people. R&D means reading research papers and going to Siggraph and other events, so regardless of the country R&D positions always request English skills. L. Spiro
  30. 4 points
    Correct me if I'm wrong, but it's ambiguous because char* and char[] are the same type. Both of them are just pointers to the first character in an array of characters.
  31. 4 points
    Good code: does what it's meant to (i.e. meets the product specification) does what it claims to (i.e. has accurately descriptive names and comments) is easy to understand is easy to change and extend And really these are 4 overlapping aspects rather than 4 separate ones. With those thoughts in mind, here's how I would approach your code: ditch all the 'static' stuff. That implies there is, and can only ever be, one instance of those things. That is not "easy to change and extend". There's a lot of documentation about why singletons and globals are bad, and static variables are part of the same family. remove unused arguments like 'GameTime'. The presence of the argument implies that the function does something with the current time, but it does not. This makes it harder to understand. Make sure your comments match your code. A comment says "//Spawn Individual" but the code says "SpawnPolyGroup". Your code should do what it claims to, and here it doesn't. Add comments to your functions. You don't want to have to read the whole function to know what it does, and the function names are rarely descriptive enough. You want this code to be easy to understand months after you've written it. Rename SpawnPatterns to something more mathematical - there's nothing intrinsic to spawning in those functions, just mathematics. This means your code isn't really doing what it claims (you think you're getting spawn patterns, but actually you just get basic geometry) and it's harder to extend (because if you find yourself needing basic geometry in future, you have to remember that you have some hidden away inside a SpawnPatterns class). Be consistent. You have a timeDelta which ticks downwards, and a spawnTimer which ticks upwards. It's not immediately clear why they differ and it's certainly not necessary to have them counting in different directions. As such, it's error-prone (as you might change the code and forget which one counts up and which one counts down) and hard to understand (what do these 2 different timers mean?) and not so easy to extend (could you perhaps have a standard class for timers like this?)
  32. 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...
  33. 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!)
  34. 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.
  35. 4 points
    Talking about Devry graduates for a minute... they're not exceptionally skilled, and they aren't hired as team leads or genius designers. Many studios in fact prefer to hire people with traditional degrees and strong portfolios instead if candidates are available, as the education tends to be more well rounded. Devry graduates are expected to be entry level employees who will still require on-the-job training. But, Devry graduates will generally have a baseline of demonstrably useful skill in their chosen discipline: a hiring manager can trust that they have basic programming or asset creation skills, have worked on small-team projects, and have demonstrated that they can see something through to completion. They will have a portfolio demonstrating their basic skills. To compete with these people for a job, you first need to be applying for the same entry level jobs (not claiming you will revolutionise the industry). You will need similar demonstrably useful skills (you can't just say you have them, you need proof). You need a similar portfolio of work you have completed, where the interviewer can be reasonably sure of what your contribution is. Once you're on a par with those things you'll need to pass the interview: if a seemingly equally qualified candidate seems more likeable they will get the job before you. If you seem full of yourself you are less likely to get the job. If you can't communicate with others clearly you are less likely to get the job. Let's be honest: as you've presented yourself, it's perfectly normal and correct that a Devry graduate should get a job you miss out on - but those people aren't getting the jobs you seem to feel entitled to anyway, so there's not really any point repeatedly mentioning them.
  36. 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
  37. 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.
  38. 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.
  39. 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
  40. 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.
  41. 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.
  42. 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...
  43. 4 points
    So you impose a cost to ALL code using bitwise shift because someone once wrote a bug? Most functions have rules about their use, such as not passing null values as parameters, or ensuring elements are within a legal range. This is no different. Shift operations have a mandatory range between zero and the number of bits of the type. Passing a negative shift distance is a bad parameter, exactly the same as if the programmer had passed an invalid object address or dereferenced a null pointer. Don't do that in the first place, then you don't need to write special code to handle the buggy code.
  44. 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.
  45. 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?
  46. 4 points
    If an object needs a reference to the TextureManager to do its job, then give the object a reference to the texture manager. You can pass it in when the object is created. Better still, have the object grab these textures ahead of time, so that when the collision happens, it already has them ready for the change, without needing access to the TextureManager.
  47. 4 points
    Below is my preliminary draft design for the AI system within Spellbound. I'm slowly migrating away from scripted expert systems towards a more dynamic and fluid AI system based on machine learning and neural networks. I may be crazy to attempt this, but I find this topic fascinating. I ended up having a mild existential crisis as a result of this. Let me know what you think or if I'm missing something. Artificial Intelligence: Objectives: Spellbound is going to be a large open world with many different types of characters, each with different motives and behaviors. We want this open world to feel alive, as if the characters within the world are inhabitants. If we went with pre-scripted behavioral patterns, the characters would be unable to learn and adapt to changes in their environment. It would also be very labor intensive to write specific AI routines for each character. Ideally, we just give every character a self-adapting brain and let them loose to figure out the rest for themselves. Core Premise: (very dense, take a minute to soak this in) Intelligence is not a fixed intrinsic property of creatures. Intelligence is an emergent property which results directly from the neural topology of a biological brain. True sentience can be created if the neural topology of an intelligent being is replicated with data structures and the correct intelligence model. If intelligence is an emergent property, and emergent properties are simple rule sets working together, then creating intelligence is a matter of discovering the simple rule sets. Design: Each character has its own individual Artificial Neural Network (ANN). This is a weighted graph which uses reinforcement learning. Throughout the character's lifespan, the graph will become more weighted towards rewarding actions and away from displeasurable ones. Any time an action causes a displeasure to go away or brings a pleasure, that neural pathway will be reinforced. If a neural pathway has not been used in a long time, we reduce its weight. Over time, the creature will learn. A SIMPLE ANN is just a single cluster of connected neurons. Each neuron is a “node” which is connected to nearby neurons. Each neuron receives inputs and generates outputs. The neural outputs always fire and activate a connected neuron. When a neuron receives enough inputs, it itself fires and activates downstream neurons. So, a SIMPLE ANN receives input and generates outputs which are a reaction to the inputs. At the end of neural cycle, we have to give response feedback to the ANN. If the neural response was positive, we strengthen the neural pathway by increasing the neural connection weights. If the response was negative, we decrease the weights of the pathway. With enough trial runs, we will find the neural pathway for the given inputs which creates the most positive outcome. The SIMPLE ANN can be considered a single cluster. It can be abstracted into a single node for the purposes of creating a higher layer of connected node networks. When we have multiple source inputs feeding into our neural network cluster and each node is running its most optimal neural pathway depending on the input, we get complex unscripted behavior. A brain is just a very large collection of layered neural nodes connected to each other. We’ll call this our “Artificial Brain” (AB) Motivation, motivators (rule sets): -All creatures have a “desired state” they want to achieve and maintain. Think about food. When you have eaten and are full, your state is at an optimally desired state. When time passes, you become increasingly hungry. Being just a teensy bit hungry may not be enough to compel you to change your current behavior, but as time goes on and your hunger increases, your motivation to eat increases until it supersedes the motives for all other actions. We can create a few very simple rules to create complex, emergent behavior. Rule 1: Every creature has a desired state they are trying to achieve and maintain. Some desired states may be unachievable (ie, infinite wealth) Rule 2: States are changed by performing actions. Actions may change one or more states at once (one to many relationship). Rule 3: “Motive” is created by a delta between current state (CS) and desired state (DS). The greater the delta between CS and DS, the more powerful the motive is. (Is this a linear graph or an exponential graph?) Rule 4: “relief” is the sum of all deltas between CS and DS provided by an action. Rule 5: A creature can have multiple competing motives. The creature will choose the action which provides the greatest amount of relief. Rule 6: Some actions are a means to an end and can be chained together (action chains). If you’re hungry and the food is 50 feet away from you, you can’t just start eating. You first must move to the food to get within interaction radius, then eat it. Q: How do we create an action chain? Q: How do we know that the action chain will result in relief? A: We generally know what desired result we want, so we work backwards. What action causes desired result (DR)? Action G does (learned from experience). How do we perform Action G? We have to perform Action D, which causes Action G. How do we cause Action D? We perform Action A, which causes Action D. Therefore, G<-D<-A; So we should do A->D->G->DR. Back propagation may be the contemporary approach to changing graph weights, but it's backwards. Q: How does long term planning work? Q: What is a conceptual idea? How can it be represented? A: A conceptual idea is a set of nodes which is abstracted to become a single node? Motivators: (Why we do the things we do) Hunger Body Temperature Wealth Knowledge Power Social Validation Sex Love/Compassion Anger/Hatred Pain Relief Fear Virtues, Vices & Ethics Notice that all of these motivators are actually psychological motivators. That means they happen in the head of the agent rather than being a physical motivator. You can be physically hungry, but psychologically, you can ignore the pains of hunger. The psychological thresholds would be different per agent. Therefore, all of these motivators belong in the “brain” of the character rather than all being attributes of an agents physical body. Hunger and body temperature would be physical attributes, but they would also be “psychological tolerances”. Psychological Tolerances: {motivator} => 0 [------------|-----------o----|----] 100 A B C D E A - This is the lowest possible bound for the motivator. B - This is the lower threshold point for the motivator. If the current state falls below this value, the desired state begins to affect actions. C - This is the current state of the motivator. D - This is the upper threshold point for the motivator. If the current state exceeds this value, the desired state begins to affect actions. E - This is the highest bounds for the motivator. The A & E bounds values are fixed and universal. The B and D threshold values vary by creature. Where you place them can make huge differences in behavior. Psychological Profiles: We can assign a class of creatures a list of psychological tolerances and assign their current state to some preset values. The behavioral decisions and subsequent actions will be driven by the psychological profile based upon the actions which create the sum of most psychological relief. The psychological profile will be the inputs into an artificial neural network, and the outputs will be the range of actions which can be performed by the agent. Ideally, the psychological profile state will drive the ANN, which drives actions, which changes the state of the psychological profile, which creates a feedback loop of reinforcement learning. Final Result: We do not program scripted behaviors, we assign psychological profiles and lists of actions. Characters will have psychological states which drive their behavioral patterns. Simply by tweaking the psychological desires of a creature, we can create emergent behavior resembling intelligence. A zombie would always be hungry, feasting on flesh would provide temporary relief. A goblin would have a strong compulsion for wealth, so they'd be very motivated to perform actions which ultimately result in gold. Rather than spending lots of time writing expert systems styled AI, we create a machine learning type of AI. Challenges: I have never created a working artificial neural network type of AI. Experimental research and development: The following notes are crazy talk which may or may not be feasible. They may need more investigation to measure their merit as viable approaches to AI. Learning by Observation: Our intelligent character doesn’t necessarily have to perform an action themselves to learn about its consequences (reward vs regret). If they watch another character perform an action and receive a reward, the intelligent character creates a connection between an action and consequence. Exploration Learning: A very important component to getting an simple ANN to work most efficiently is to get the neurons to find and establish new connections with other neurons. If we have a neural connection topology which always results in a negative response, we’ll want to generate a new connection at random to a nearby neuron. Exploration Scheduling: When all other paths are terrible, the new path becomes better and we “try it out” because there’s nothing better. If the new pathway happens to result in a positive outcome, suddenly it gets much stronger. This is how our simple ANN discovers new unscripted behaviors. The danger is that we will have a sub-optimal behavior pattern which generates some results, but they’re not the best results. We’d use the same neural pathway over and over again because it is a well travelled path. Exploration Rewards: In order to encourage exploring different untravelled paths, we gradually increase the “novelty” reward value for taking that pathway. If traveling this pathway results in a large reward, the pathway is highly rewarded and may become the most travelled path. Dynamic Deep Learning: On occasion, we’ll also want to create new neurons at random and connect them to at least one other nearby downstream neuron. If a neuron is not connected to any other neurons, it becomes an “island” and must die. When we follow a neural pathway, we are looking at two costs: The connection weight and the path weight. We always choose the shortest path with the least weight. Rarely used pathways will have their weight decrease over a long period of time. If a path weight reaches zero, we break the connection and our brain “forgets” the neural connection. Evolutionary & Inherited Learning: It takes a lot of effort for a neural pathway to become developed. We will want to speed up the development. If a child is born to two parents, those parents will rapidly increase the neural pathways of the child by sharing their own pathways. This is one way to "teach". Thus, children will think very much like their parents do. Other characters will also share their knowledge with other characters. In order for knowledge to spread, it must be interesting enough to be spread. So, a character will generally share the most interesting knowledge they have. Network Training & Evolutionary Inheritance: An untrained ANN results in an uninteresting character. So, we have to have at least a trained base preset for a brain. This is consistent with biological brains because our brains have been pre-configured through evolutionary processes and come pre-wired with certain regions of the brain being universally responsible for processing certain input types. The training method will be rudimentary at first, to get something at least passable, and it can be done as a part of the development process. When we release the game to the public, the creatures are still going to be training. The creatures which had the most “success” will become a part of the next generation. These brain configurations can be stored on a central database somewhere in the cloud. When a player begins a new game, we download the most recent generation of brain configurations. Each newly instanced character may have a chance to have a random mutation. When the game completes, if there were any particular brains which were more successful than the current strain, we select it for “breeding” with other successful strains so that the next generation is an amalgamation of the most successful previous generations. We’ll probably begin to see some divergence and brain species over time? Predisposition towards Behavior Patterns via bias: Characters will also have slight predispositions which are assigned at birth. 50% of their predisposition is innate to their creature class. 25% is genetically passed down by parents. 25% is randomly chosen. A predisposition causes some pleasures and displeasures to be more or less intense. This will skew the weightings of a developing ANN a bit more heavily to favor particular actions. This is what will create a variety in interests between characters, and will ultimately lead to a variety in personalities. We can create very different behavior patterns in our AB’s by tweaking the amount of pleasure and displeasure various outputs generate for our creature. The brain of a goblin could derive much more pleasure from getting gold, so it will have strong neural pathways which result in getting gold. AI will be able to interact with interactable objects. An interactable object has a list of ways it can be interacted with. Interactable objects can be used to interact with other interactable objects. Characters are considered to be interactable objects. The AI has a sense of ownership for various objects. When it loses an object, it is a displeasurable feeling. When they gain an object, it is a pleasurable feeling. Stealing from an AI will cause it to be unhappy and it will learn about theft and begin trying to avoid it. Giving a gift to an AI makes it very happy. Trading one object for another will transfer ownership of objects. There is no "intrinsic value" to an object. The value of an object is based on how much the AI wants it compared to how much it wants the other object in question. Learning through Socialization: AI's will socialize with each other. This is the primary mechanism for knowledge transfer. They will generally tell each other about recent events or interests, choosing to talk about the most interesting events first. If an AI doesn't find a conversation very interesting, they will stop the conversation and leave (terminating condition). If a threat is nearby, the AI will be very interested in it and will share with nearby AI. If a player has hurt or killed a townsfolk, all of the nearby townsfolk will be very upset and may attack the player on sight. If enough players attack the townsfolk, the townsfolk AI will start to associate all players with negative feelings and may attack a player on sight even if they didn't do anything to aggravate the townsfolk AI.
  48. 4 points
    I'm locking this thread for now. Neither GDNet nor its moderators, administrators or members are qualified to offer advice or support with regard to mental health concerns and suicide. Ghonchi-- I urge you to seek counseling and support online or through whatever channels available in your area for your personal mental health risks. You can message me directly if you need help finding available treatment programs or online counseling services. GDNet can provide technical and creative support and input for game development, but as many other members may suffer from similar mental health issues, this thread may pose a threat to the well-being of the rest of the community. Concerning PC procurement, you can start a new thread provided you stay on subject.
  49. 4 points
    Trivial, just position the camera correctly, and the 3D renderer will do the rest. Don't remember the angles exactly, but wikipedia does: https://en.wikipedia.org/wiki/Isometric_graphics_in_video_games_and_pixel_art
  50. 4 points
    A few things: 1) Yes, gd3dApp is a global. Hence the 'g' prefix. 2) The global isn't actually necessary - Windows allows you to attach a pointer of an arbitrary type to a window, either at construction time or at any point later", albeit at the cost of type-safety. Look up "SetWindowLongPtr". Mind you, the point about not assigning a member function to the window still holds, though, because of how pointers to member functions work in C++. 3) The anonymous namespace is used to prevent the global from being accessible outside the source file in which it is defined. In C we would do this using the "static" keyword, but anonymous namespaces are how modern C++ accomplishes this. 4) Classes are constructed in order of inheritance hierarchy - and destructed in the opposite order. So the base class (D3DApp) would be constructed first, assigning the "this" pointer of the class to the global. 5) If you were to have two classes deriving from D3DApp, and you would instantiate both of them, the global would be set to the address of whichever one was most recently constructed without fanfare. You can probably see why this could be dangerous...