game-programming

Vague post is vague

While not becoming intensely annoyed with a co-worker for wasting hours tinkering with something I built that worked perfectly until he tinkered with it today, I had a pretty damn good day.

I started the day with a huge programming problem that I didn’t really know how to begin to solve, and ended the day on an hour long sprint writing perhaps the most elegant solution I’ve conjured in quite some time. I just have to hope the client understands what on earth I’ve done. I don’t usually do “clever” - if given a choice, I will almost always choose simple and methodical, because it’s easier to test, debug, deploy, and maintain.

I’m secretly hoping they will smile when they see what I’ve done, and how they will be able to use it.

Apologies for being vague. If you knew what it was that I’ve solved, you would probably roll your eyes, but just take it on faith that it wasn’t easy, and it’s pretty awesome. Honest.

At the time of writing it’s heading towards 9:30pm. I’ve only just sat down after getting home from work, washing up, fetching our youngest from dance class, washing up again, eating dinner, and washing up again. I have to be up at 5am tomorrow to take Miss 11 to school early (she’s going to France for the day). I’m guessing the tidal wave of tiredness will hit at some point tomorrow afternoon while I’m hunched over my desk at work.

Massive change of subject - I downloaded the beta of “LEGO Worlds” at lunchtime, to see what all the fuss is about. Think “LEGO Minecraft”. It’s built by the same people that have made all the LEGO computer games (Travellers Tales), and I have to admit it’s great fun. There’s a very simple reason why it’s never going to do anywhere near as well as Minecraft though - it’s too resource hungry. The best computer in our house cannot run it without stuttering and pausing all the time, whereas you can run Minecraft quite happily on a Raspberry Pi. How many families own a £1000 gaming PC?

Last Thursday I contacted Robbie from RCSolstice to do some 2D mini-games, since he had some experience in that field. Without ever touching the Unity engine (I’m not sure what program he used before), he downloaded it Thursday and gave me this update SATURDAY. I’m so proud to have such talented hands working with me and can’t wait to see what we are able to create together.

Teenage boys are perhaps more known for playing computer games but girls are better at making them, a University of Sussex study has found.

Researchers in the University’s Informatics department asked pupils at a secondary school to design and program their own computer game using a new visual programming language that shows pupils the computer programs they have written in plain English.

Dr Kate Howland and Dr Judith Good found that the girls in the classroom wrote more complex programs in their games than the boys and also learnt more about coding compared to the boys.

There are persistent concerns about the underrepresentation of women in computing – only 17% of the UK’s computer science graduates in 2012 were female, despite a promising reduction of the gender gap in maths-related subjects at school level.

Some believe that girls are put off in their teenage years by the common portrayal of the ‘nerdy boy’ in TV and film.

This new study, published in the January 2015 issue of the journal Computers & Education, suggests that girls can be motivated to explore programming and create rich gameplay experiences by building on their skills in literacy and storytelling.

Continue Reading.

Roles in the Industry: The Graphics Programmer

Not every programmer works on gameplay. There’s a whole lot of them who don’t ever even get close to the rules of the game, or how it feels to the player. Some of them spend their time bringing the hardware to heel and harnessing its power. Others solve networking problems, allowing players to play together across thousands of miles. And then there are graphics programmers, the ones who are absolutely dedicated to one task - making things look and perform better. So today, I’ll go into a bit more depth on just what it is these people do.

Keep reading

anonymous asked:

In one of your past posts, specifically the one on Feb 17th 2014, you mentioned that an AI that acted sensibly (in your example an AI that would flank the player) was poorly received. For aspiring designers, should the takeaway be that designing sensible computer opponents (opponents that "play" the same game as the player in terms of mechanics and rulesets) is a bad idea? Thank you.

Is designing “sensible” AI a bad idea? Not really. It depends on the sort of role the AI is meant to fill. We can typically divide AI design into two major categories - asymmetrical and symmetrical AI, which each have different implementations and assumptions made. Both categories, however, must retain the same core element - the takeaway should be that the AI is fun to play against, regardless of whether it is symmetrical or not. Read on to find out what the difference is, and what role each type of AI serves.

Keep reading

youtube

So, my studios first big game is gonna be hitting Steam for sale on Friday. This is such a big deal for all of us at the studio and I am so excited to see the response. If you want to check it out, this is the link to our steam page: The Sun At Night

anonymous asked:

Are there any books you would recommend to a game designer? (doesn't necessarily have to be on the topic of games!)

Sure. Here are a few books I like across various topics:

Game Design specifically:

Programming specifically:

Not about design or programming specifically, but still very useful:

Note that these books aren’t necessarily authoritative, nor are they always applicable but they are useful to read through just to get a different perspective on things and to work into your repertoire. If you do read them, try to understand what circumstances they’d be useful and how to apply the principles conveyed therein in a general way. 

4

It’s exam period, so I don’t have any Pitfall Planet updates this week! However, I can still enjoy posting up GIFs from unreleased projects like Rocket Deer.

One day some friends and I were brainstorming a bullet hell game. One of us was like, “how about a deer strapped to a rocket?” and that was it.

We had fun making it look pretty (like the unnecessary day-night cycle), but we never got around to refining the gameplay. Most of the pixel art is courtesy of wawaboopboop!

anonymous asked:

So, I know that all games/animations are rendered in polygons (triangles), but what do you do when you want to render a sphere? I've seen programs/games with 3D spheres, that seem perfect to the naked eye. Now, a perfect sphere would require infinite polygons, which would take infinite computing power to render. Are these spheres just regular old models that only look like they are perfect because the polygons are so small on the model, or is there some sort of programming trickery involved?

It’s trickery, and it’s actually a pretty interesting trick. What you’re seeing is the combined effects of shading and normal mapping

Shading is when the renderer uses positional data to calculate the color of a particular pixel on screen. There are a number of different techniques for this with differing results. Here is the first one, using a technique called “Flat Shading”. Flat shading is when the renderer adjusts the color of a polygon surface based on what it determines the color of the center of the polygon is.

You can pick out the individual polygons pretty easily here, right?

Now we’ll switch to a different shading technique. This one is called Phong shading. Instead of using the center of the polygon to determine what color the polygon is, the renderer will take the color value from the corners of each polygon and interpolate between them and the color value from the center of the polygon. This results in shading that is much more gradual and smooth, as you can see here:

If you look closely, you can see that the number of polygons here actually hasn’t changed. You should still be able to pick out the vertices along the outline of the “sphere” here. But it certainly looks a lot rounder, doesn’t it?

But this still has issues, because we might have something that’s very polygon-intensive, like a cobblestone street. This poses a problem - we want streets to be flat in terms of polygons, because it’s a street and you walk on it, but it should still visually look like cobblestones. You don’t want to spend extra GPU cycles rendering extra polygons for the street when you could spend them on hair or fingers or facial expressions or something, but you don’t want it to look flat either. So how do you fix this?

Have you ever seen the movie Indiana Jones and the Last Crusade? There was a scene in the movie where Indy has to take a step out into what looks like a bottomless gorge:

But he’s not really stepping onto a bottomless gorge, is he? If you look closely, you can see it. When you change the angle of the camera, you can easily see what’s actually going on:

The step of faith here is actually a cleverly painted (and flat) bridge to make it look like there’s a huge drop. From the viewer’s perspective, it looks 3D even if it actually isn’t. And since we have a computer fast enough to do all the calculations for us every frame, we can make it calculate what the 3D surface would look like from different angles and repaint it on the fly, even if the polygon we’re displaying is actually still flat.

This is called bump mapping (or often normal mapping, which is a specific kind of bump mapping). The way it works is that you apply a texture like this to the polygon, but instead of being directly displayed on the polygon, it’s used by the renderer to determine the way the pixel at that point should look in terms of height, even if the polygon is flat at that point. It simulates a bunch of different heights or depths, even though the polygon is still actually flat. The result is what you see to the top right - lighting as if it were bumpy or pock marked, but without actually needing additional polygons to get the visual effect.

The results of this can be pretty interesting. Take a look at these. This is a model with a lot of polygons in it to create a bunch of different shapes:

And here is a completely flat polygon with a normal map based off of the above shape applied to it:

You can see that the stuff that really sticks out far like the cone doesn’t look right, but the stuff that only pokes out a little bit like the donut and the hemisphere actually look pretty good for taking up no additional polygons at all. If you looked at both of them from directly above, without the side angle view, it’d actually be pretty tough to tell them apart without touching them. And that’s the point - it’s a way to fake heights and depths without adding extra polygons. This is why it works best on flat surfaces like walls and the ground that you view from (nearly) straight on:

These are both flat polygon roads, but the right side looks a lot more like it’s made of real stones than the left. There are other effects also at play, like specular maps (which are used to calculate how shiny/reflective or dull an object is) and more, but they also operate on the same sort of mathematical principles.

It takes a good artist to create the proper map textures for 3D models, and it takes a graphics programmer with a solid understanding of math to create the renderer that can do all of the proper calculations to take those maps and figure out exactly what color each pixel actually is. I will say that it can be pretty fascinating stuff.

7 Tips to finishing a game in 48 hours

Let’s start by asking, what is a game jam?

A game jam is where one or more game developers (programmers/artists/sound engineers/etc.) create a game within a short period of time, usually 24-72 hours. If you’ve never participated in one, the Ludum Dare competition is held about three times a year, and is a great place to start.

I’ve participated in a few game jams myself and in this article I’ll be sharing with you my tips for creating a polished and fun game! So whether you’re working by yourself or in a team, hopefully these tips will help you out during your next jam.

1. Choose an art style which allows you to create assets quickly.

In 48 hours you won’t be able to create a huge amount of art with a single artist. You really have two choices - you can spend most of your time on a few assets, or you can spend a short amount of time on many assets. The latter implies that quick art is low quality. This is not true. While creating intricately detailed assets will usually take a long time, stylized art can be created very quickly. The trick to making gorgeous art in a short period of time is constraining your style. A perfect example of this is pixel art and low resolution graphics. In Stray Whisker, I decided to constrain my art style in a few ways. I knew that the cat’s animation would be prominent and require many frames to make it fluid, so in order to have enough time to do all of these frames I used a single colour and a low resolution. Each frame took seconds to draw, but the sheer number kept the animation smooth. I used single colours for all of the assets, and the backgrounds typically only used three colours each. Other examples of constraining art styles include games creating in black and white, monotone, or only using simple shapes such as triangles, circles and squares.

2. Create a low barrier for entry.

If you actually want people to play your game, you need to create a low barrier for entry. That is to say, make it very simple for people to start playing your game. iPhones are not the best platform to develop for during a game jam, as your game will be quite difficult to distribute quickly, and only people with an iPhone can play it. In contrast, web games, such as a flash games, are very easy to distribute, are typically cross platform and can be run without any installation required. However, not all games suit the web based format. CPU/GPU intensive games such as 3D ones or games which require fullscreen for immersion should stick to compiled binaries.

Low barrier for entry can also be taken to mean, “make it easy for people to get into your game”. For example, don’t have a wall of text that is required for a player to read to understand how to play your game - players don’t read, don’t force the player to watch long cutscenes - save them for your bigger projects, and let them get to the fun elements of your game quickly - game jams can produce hundreds of games and if yours isn’t immediately fun, they may just move onto the next one.

3. Use tools you are familiar with.

Game jams are a great opportunity to:

  • learn new game development skills
  • make a new game

Some people use game jams solely as a chance to learn a new language, toolkit or other piece of software. That’s great! I’ve done this on a few occasions myself to improve my C++ skills and learn new libraries. However if you want to finish your game and make it the best it can possibly be, I highly recommend that you use a tool that you’re already familiar with. If you’re using something that you’re inexperienced with then it’s going to slow you down and you’ll struggle to finish.

4. Make sure you have a title screen and credits.

Every good story has a beginning, a middle and an end - your game should too!* In a game jam you should aim to finish a game. This means that it should have all the basic elements that you’d expect from any other completed game. A title screen with the title of your game and a “Press space to start” shouldn’t take more than 15 minutes to implement (or 1 minute if you’re particularly familiar with your chosen tools), and will add a lot of polish to your hard work. Similarly, a credits screen will let players know who made the game and give you the chance to credit your sources. I usually combine the end screen and the credits screen into a single image. Without these two elements, your game will come across as a “fun demo”, a “nice prototype” or an “interesting toy”. However, if you include them, you’ll have a polished game. No matter how bad your game is, a title screen and credits screen will always make it appear like a finished product.

*Unless you’re making an open-ended free roaming game or you derive some sort of awesomely artistic meaning from having no proper end! In a case like this you should still include a credits screen which can be reached from your title screen or menu.

5. Choose a decent screenshot.

When it comes to submission time, if you actually want people to play your game then don’t forget to add some awesome screenshots. Make your primary screenshot one which includes all of the action or your best graphics. Make sure that your screenshot looks good even when it’s resized to a smaller resolution thumbnail. Remember that if you’re submitting to something like Ludum Dare your game will be among hundreds of others and an amazing screenshot is a great way to stand out.

6. Include a README.

README.txt - it’s a file that’s seen with a lot of programs. But what’s in a readme?

Whatever you want to put in there! Typically I use it as a way of communicating my contact information and the purpose of a game to anyone who is interested in simply more than just playing the game.

You should include:

  • Name of the game
  • Brief description (1-2 sentences)
  • Date and reason for creation (name of the game jam)
  • Your name (and/or your team’s name)
  • Contact information (website, email, twitter, other social media)

And also importantly:

7. Include a license.

In most game jams, games are required to be released open source. Even so, it’s good practice to include a license with your game so that people know what they can and can’t do with your software. If anyone wants to sell part of your work, they will hopefully contact you (this is why you put your contact information above).

I typically use a creative commons license. In particular I use this one:  http://creativecommons.org/licenses/by-nc-sa/3.0/, which basically states that nobody can profit from my work, and if they redistribute it they must credit me. Additionally, if they create a derivative work it must be released under the same license.

Conclusion

Game jams are a lot of fun! Use them as an opportunity to make a game, polish it to the best that it can be, and release a finished product. Finally, don’t forget to make them easy for people to pick up and play.

anonymous asked:

How exactly do developers go about making AI gunmen realistically miss the player, particularly with games that use a lot of hit scanning weapons?

When it comes down to it, AI accuracy is really just a random roll that takes factors into account to make a decision. Once you decide, then you have to figure out how to actually adjust the aim so as not to cause any damage to the player. There are factors that should affect this (such as no direct line of effect from the AI to the target) but that’s easy enough to work around. The way we usually do it is by using a little math.

So first off, we can hold the AI to as many restrictions as we want. Since players don’t typically pay that much attention to exactly where the enemy AI is firing, we can simply make the AI shots determined to be “misses” have no effect on hit. The AI could be shooting accurately, but just not hit anything, as if any bullet fired simply vanished in midair, as if the AI was shooting blanks. This isn’t necessarily the best way to go - it isn’t particularly believable if this is the only solution, since you’d expect things like nearby objects to take damage and shatter even if you don’t, breakables like glass to break when shot by misses, and even bullet hole decals to appear on nearby surfaces. 

The next step you can take is to have all shots be “live” and cause damage to everything, and then intercept it at the player level. If the shot would hit the player and the attack roll is a “miss”, it simply doesn’t hit the player and hits everything else. For this purpose, the shots fired by the AI (or even another player) would simply treat the target as if he or she didn’t exist on a miss. This would work for most action games, since the player most likely won’t be measuring the shot trajectories and calculating ballistics. This would work just fine for shooters that didn’t involve visible projectiles, but could also break immersion if the AI was in a situation where missing would be practically impossible (e.g. point blank) and the to-hit roll somehow decided to miss anyway. For those with visible projectiles (arrows, bolts of energy, etc.) you could have some visual problems since a missed projectile would still visibly pass through the target without causing damage. You can see this happen quite often in RPG type games like Diablo.

But let’s say that we didn’t want to have these “holes” in the shot, and wanted it to be even more realistic. Maybe we want to treat bots in the game the exact same way we treat players, so that we can have symmetrical game systems - the rules are the same for everybody, bot or human. Maybe we want the chance to miss be part of the AI, and not part of the overall shooting mechanics instead. If that’s the case, we can also affect the trajectory of the shot from our gun to the target. If the AI has a clear line of sight to the player, it can hit the player if it decides it wants to. All we have to do is add a slight rotational offset to the target vector which nudges the aim off slightly. We can then randomize the offset vector so that the misses are guaranteed to be close but probably won’t hit.

This solves the problem of point blank shots missing - if you’re super close, you can clamp the maximum variance of the shot, which would result in hits occuring even on “missed” rolls anyway. It does have a natural scaling effect - the further away you are, the further the shots will be from the target. The drawback to this method is that the AI will occasionally get hits that are supposed to be misses because sometimes a miss roll will result in a random hit anyway. However, it is the most realistic means of determining a missed shot, since this is effectively what causes shots to miss in reality.

This doesn’t necessarily go into the math of how misses are actually determined, of course. The determination of a hit or miss is entirely arbitrary - it can be as simple as flipping a coin, or as complicated as taking things like distance, character attributes and skills, position, high ground, environmental factors, and so on into account. The complexity of this determination should be up to your engineers and designers - each additional variable is something that needs to be tracked and tuned, after all.

I hope I answered the question properly. I wasn’t sure if the question wanted me to break down the actual way to implement a miss once one was determined, or to actually go over what sort of factors usually calculate into making an AI decide to miss, so I went with the former. If you want me to get into the latter, drop me a note and I’ll try to get to it.