Explaining how games work?

[DarthAsthma]

I was musing about making something like this for a while because I just like the topic so much, but what kept me from it is pondering about if anyone here has any interest in learning/talking about this on an OP forum. But you know what the heck, why not try it.

My mission statement with this thread is trying to dispel some of the feelings that games are made with "computer magic"(cause that's somewhat how I felt years ago) so people maybe have a basic understanding of the logical construct behind games themselves. To that end I want to avoid any deep technical mumbo jumbo.

So anyone feel free to throw any questions and I'll try my best to answer(although I think we have other AP people that will be more qualified on certain things, so they might chime in), otherwise I might just muse over how things get on your screen to begin with for a start.

(Yes this is an act born of the need to procrastinate studying)

[Foolio]

Cool thread. I have never directly dabbled in game programming, though I have coworkers who have, but it's really something I should at least try at some point. I don't know if you've given it a shot yourself, but one of these days I swear I'm going to install the Unity engine and just start messing around with some basics and tutorials. It's free and I heard there is pretty good documentation surrounding it.

[DarthAsthma]

Yeah one of my current student projects is done with Unity to get my feet wet some kind of Walking Simulator nothing amazing.
Unity is great takes a lot of work off your hands but the best thing about Unity I feel like is really its community which is generally really helpful.

If you're all about getting into making stuff, engines are mega good at enabling you, but I think for me they don't help you connecting some of the dots that I personally feel like are important to understand what games actually are, things like the construct of the "game loop" you're most likely going to skip on when you use one of these engines.

But as someone with a programming background that might not even be something that would be that much of an issue. There are so many things that just become really easy to grasp when you get that method of thinking going. But I certainly do remember being mystified by wait what are animations etc etc and how does math connect to anything in games xD.

**–---------------------------------------------------------------------------------------------------------------------------

1. How shit gets on your monitor!**

I think the very first hurdle to understand what games actually are is probably knowing how things get onto your screen.
Now I'm not going into the technical details of different monitor technologies but instead I'm going to try to provide a very very basic understanding.

It basically boils down to that everything your computer can do is based on the fact that it is representable in numbers(and thus it can be computed down to 1 and 0).

Anyone that used photoshop in their lives might be familiar with RGB/CMYK, those are color models that are in essence one of the ways to translate colors into numbers. If we take RGB, red/green/blue can take on numbers from 0 to 255 which basically translate to the portion of light that is emitted to your monitor(if we simplify what a monitor basically is, it's a ton of super small light emitters put in glued together and with a computer you can control how strong each light glows. The light then goes to different filters to get certain colors).

Basically to a computer any color of every pixel on your monitor is just a bunch of numbers. The important thing to know on that front regarding games is we can basically manually tell our monitors to change any color of any pixel based on what values we feed into our machines. Of course you're not going to tell all the million pixels one by one, that means it's all about creating smart rule sets and going into those we're kind of getting a bit into what shaders are but more on that later maybe.

Dunno if that was enough or too little, ask away. Or feel free to make suggestions(like maybe if someone needs a visual representation of a certain explanation? Or different formatting.) or wishes on what I should maybe talk about.
Like I'm actually not sure what the next logical step is, personally I would maybe go into the very basic logical tools of programming since it kind of relates to other stuff later.

[KaizokuJinbei]

I use Unreal Engine 4 it's not a bad thing to use. I also use Blender which is a real nice free modeling tool though I suck at modeling.

I was thinking about trying Unity for comparisons.

[Foolio]

@DarthAsthma:

If you're all about getting into making stuff, engines are mega good at enabling you, but I think for me they don't help you connecting some of the dots that I personally feel like are important to understand what games actually are, things like the construct of the "game loop" you're most likely going to skip on when you use one of these engines.

Well feel free to talk about it then :)

[DarthAsthma]

This post is deleted!

[DarthAsthma]

2. Programming concepts! So I hope I can sum up all the important parts here in a way that anyone can understand.
I assume everyone knows that computers run on the ones and the zeros?
I ask because the most basic tools of every programmer are based on that fact, talking about calculations, if/else and the loops .

So lets remember how everything your computer can do is based on our ability to translate real world circumstances into numbers.
That also means that one of our most powerful tools working with a computer is going to be math(in a lot of cases actually just the most basic math like addition and subtraction) and without going into the circuitry stuff or truth tables I think it's enough to know that this math is possible based on our knowledge of numeral systems. We can translate binary into decimal and hexadecimal and really anything else we want and vice versa(I hope people have dark memories of this from school and going back to the prior rgb thing from black to white it's just telling the monitor through our computer he should go from 0/0/0 to 255/255/255 via addition). And in this way we can do calculations.

I'm actually not sure what anyone would like to know about if/else and loops. I feel like as logical constructs they're very straightforward.
Both are just basic concept of programming languages and just a convenient way to condition your computer to do something or not to do something in certain cases or to make your computer do something for a certain amount of time/a certain amount of times.

Like 2 examples for each thing.
Making it somewhat games related(if/else): if I shoot someone and hit him, that entity takes dmg(substract health) if I shoot someone and miss he doesn't take damage.
Coming back to our monitor(loop): tell our monitor what each pixel should be as long as our computer is running.

And relating it back to our 1 and 0 again. Both of these are basically just state checks. Replace the if/else and the loop statements with 1 and 0. If the computer checks an "if" for 1 he follows through with the if statement if he checks it for "0" he goes to "else". Same for the loops if a loopcheck takes on a "1" the computer makes a repeat if "0" then he stops.(not entirely true in a way because different loop types but I think this should suffice)

In case this isn't enough I have to rely on your questions to go into more detail.
Next probably game loops? Or maybe a little bit on data formats again hammering home that everything is just numbers in the end not sure…. Definitely anyone let me know if there's already a disconnect at this point or if people can kind of see how these things connect in a way. If both of these things are understandble we're actually super close to understanding how games generally work and from there we can maybe go into more specifics(What is animation in 3d from a programming aspect, what are shaders, what are engines, etc, whatever might be of interest).

[Foolio]

I guess the interesting part to me is more how it handles the distinction between user inputs and everything else. Like the game has to keep updating the ball's position regardless of whether or not I press anything, so in what way is it listening for user input? Is it a separate thread that just loops infinitely? Is there an "update" event loop that at fixed intervals simultaneously checks for input as well as the state of the "world" it has to recompute and draw?

I mean this is probably not much different than how any event-driven language functions; it could even get compared to a browser having to render a web page but also listen for click events and the like. But even there I have a pretty shallow understanding of how the underlying code is actually setting up and running the main process and managing all the events. So if we're talking about the most low-level concept of a game loop, that would be what I would research.

[DarthAsthma]

@Foolio:

I guess the interesting part to me is more how it handles the distinction between user inputs and everything else. Like the game has to keep updating the ball's position regardless of whether or not I press anything, so in what way is it listening for user input? Is it a separate thread that just loops infinitely? Is there an "update" event loop that at fixed intervals simultaneously checks for input as well as the state of the "world" it has to recompute and draw?
I mean this is probably not much different than how any event-driven language functions, it could even get compared to a browser having to render a web page but also listen for click events and the like. But even there I have a pretty shallow understanding of how the underlying code is actually setting up and running the main process and managing all the events. So if we're talking about the most low-level concept of a game loop, that would be what I would research.

Correct! :). The game loop is basically just a scheduling algorithm that manages the input reading, updating your game state to the drawing/rendering. Mmmh maybe the only other thing of note is that it's common to my knowledge to control the amount of drawing that happens per second -> basically the fps business.
I mean you're probably going to get it instantly after reading through 1 documented code example of the game loop, like many things in programming it's pretty simple if one dissects it right.
–--------------------------------------------------------------------------------------------------------
3. Gameloops, dispelling the magic (part1)
I think the last thing to gain our basic understanding of how games work is the concept of the gameloop.
So we know how things get on our monitor and we know about the programming concepts of loops and if/else and we generally know that anything that happens is just numbers translated/transformed into things like colors, sound, etc etc.

With that games basically are just a sequence of interactive images. Interactive in the sense that depending on your input/the change in certain values the image that is drawn is different. That means games are only possible because computers are so damn fast at calculations thus changing what your monitor displays in fractions of seconds.

So before we get more into the game loop lets review this fact by dissecting pong a bit(this will help us for the game loop as well). So at first we have our super simple image of the 2 lines reflecting the ball and 1 point, the ball, the scores as well the general field.
Lets sum up the whole fact that our monitor displays what it should display as a "draw" action, meaning the process in which our computer tells every pixel on our monitor to be a certain color until the whole thing ends up being an image we'll call "draw".
Simplified every time the picture changes it's a "draw" action that happens(and to those savvy to the human eye/general animation, even if nothing changes we're still drawing a bunch of times even if nothing about the picture changes, we're just drawing the same image over and over. Or to be even more exact as long as your monitor is on displaying something you're "drawing" a bunch).

Now back to everything just being numbers. To understand this part you just have to know a basic understanding of the coordinate system(2 dimensional is enough x/y). Imagine every pixel being a point in our coordinate system. Using math relating to coordinate systems(vectors/matrices/etc) we can basically make a rule set on what the monitor should display. But if that's to complicated the important thing here is just knowing that the 2 lines and the ball have position data saved.

Through programming using the loops and the if/else and calculations we set up a consistent rule set to make the computer draw what it should draw. Like if you press UP the position of the left line gets updated per simple calculation from for example (0/10) to (0/11) and then your computer makes a new "draw" for your monitor. Every arrow up key press is for example 1 pixel up. Another reminder everything is just simple numbers. A button press is just another form of 0 and 1.
Either you pressed it = 1 or you didn't 0. We check with our if/else tool. If you pressed it -> update position, else -> position remains the same. In any case "draw".

So at this point maybe I'll throw a question at everyone else to see if people get it(preferably someone that doesn't have a clue about programming :P). Can someone roughly sum up the process of either how the score gets updated or maybe slightly more difficult how the ball moves using our knowledge of if/else/calculations/"draw"? Don't think too complicated it's a simple squence of things.

[Hanz]

i think collision boxes and hit detection are a very important part of games. i'd love to explain about them myself but you seem more knowledgeable and better in english so can you please tell us what collision boxes are?

[DarthAsthma]

@Hanz:

i think collision boxes and hit detection are a very important part of games. i want to explain about them myself but you seem more knowledgeable and better in english so can you please tell us what collision boxes are?

Mmmh so at first I'm calling back to everything being math/numbers, that means that when we have two 3D objects we can always know if those two are colliding(and we want to know this to make sure two different models don't clip into each other or simply so something can stand on a surface) by checking the position data on any point of both objects. If they share the same point or if we want some leeway if the points are exactly next to each other in coordinate space -> a collision is happening.
The problem we run into here is that with the growing complexity of any given two 3d models(number of polygons/vertices/edges) the calculations for if something is colliding become more costly(they take longer because more calculations have to be made).

Game programming is a lot about finding cheats to be cost efficient(cause machines have limited computing power), and our cheat here is instead of calculating the collision between our 3d models we put an imaginary box around each model. This simplifies collision calculations immensely by cutting down the number of calculations we need to do. Because by checking all the few relevant points to ascertain one of the surfaces of the box we know if another object box touches that surface and is thus colliding.

In case it is colliding we can just tell the objects to not move into each others collision boxes -> preventing clipping, etc.
I think this is the simple version? Of course in reality if you just put super simple boxes around your character models you get weird stuff like a character always keeping a certain distance to a wall, so it's not uncommon I believe to use multiple collision boxes for one character(in case the characters geometry is complex enough to call for it).
Also I was talking 3d but it's basically the same for 2d.
–----------------------------------------------------------------------------------
Sidenote on vertices, edges, polygons(3d modelling):

So basically imagine a 3D model of a dice.
The corner points, are called vertices. A vertice is basically a point where lines meet/connect.
The lines connecting the vertices are called edges.
The surface that is created through the edges and vertices is called a polygon.

Let me know if this was ok, or if my explanation on why the collision box takes less calculations wasn't clear.

[Noqanky]

I'll have to make a mental note to come back here when I've accumulated enough knowledge, time and resources to scratch that game design itch. This could also be a great place eventually for people to share their work.

[DarthAsthma]

@Noqanky:

I'll have to make a mental note to come back here when I've accumulated enough knowledge, time and resources to scratch that game design itch. This could also be a great place eventually for people to share their work.

Feel free though to throw questions in here if you catch yourself wondering about a certain aspect of something you're playing(doesn't matter how mundane it might appear, even something like how jumping works I'll be happy to answer)! Like I said the hope is basically giving people especially with 0 knowledge some kind of base understanding on how stuff works or how stuff connects with each other.

[Sakonosolo]

One thing I've recently found interesting when playing old DOS games is that apparently back then games only updated when they needed to rather than what we have today where games area always running at the same framerate regardless of if there's anything happening or not. So if you monitor your framerate while playing something DosBox it'll constantly go up and down depending on if you're sitting still or moving. This was actually important early on for things like smooth scrolling which the NES and SNES could do because they were built to but you had to do it in a sort of roundabout way on PC back then which is what led John Carmack to make Commander Keen.

One thing that kind of confuses me though is that some stuff is still done on the CPU rather than the GPU. Like shadows I think are still (at least in some cases, though I'm not sure if this has gotten lessened with current gen) calculated on the CPU rather than the GPU and some other things. I imagine it's just harder to do the calculations needed for them on the GPU and that's why it's done that way but with GPUs getting stronger and it still be difficult to multithread games well I imagine it would be useful to offput everything you can to the GPU. The people who make Sniper Elite actually have a self shadowing method that works extremely well on the GPU but it's only for character models.

http://www.dsogaming.com/interviews/rebellion-talks-sniper-elite-3-tech-tessellation-mantle-dx12-multicore-cpus-obscurance-fields-shader/

[maxterdexter]

Nonono, you are talking about virtual worlds, a game is rules that draw you in to complete meaningless actions. the rest is code, brick and mortar, models, textures and sprites.

It's like a home, you have your blueprints, you have your building, but untill people live and experience it, it ain't a home.

But yeah, videogames, it takes a lot to imagine every posibility, and think ahead of the players in order to build them an experience that they will enjoy.

[Jarhead]

Very relevant to the topic.

[DarthAsthma]

@Sakonosolo:

One thing I've recently found interesting when playing old DOS games is that apparently back then games only updated when they needed to rather than what we have today where games area always running at the same framerate regardless of if there's anything happening or not. So if you monitor your framerate while playing something DosBox it'll constantly go up and down depending on if you're sitting still or moving. This was actually important early on for things like smooth scrolling which the NES and SNES could do because they were built to but you had to do it in a sort of roundabout way on PC back then which is what led John Carmack to make Commander Keen.

One thing that kind of confuses me though is that some stuff is still done on the CPU rather than the GPU. Like shadows I think are still (at least in some cases, though I'm not sure if this has gotten lessened with current gen) calculated on the CPU rather than the GPU and some other things. I imagine it's just harder to do the calculations needed for them on the GPU and that's why it's done that way but with GPUs getting stronger and it still be difficult to multithread games well I imagine it would be useful to offput everything you can to the GPU. The people who make Sniper Elite actually have a self shadowing method that works extremely well on the GPU but it's only for character models.

http://www.dsogaming.com/interviews/rebellion-talks-sniper-elite-3-tech-tessellation-mantle-dx12-multicore-cpus-obscurance-fields-shader/

I'm actually not that savvy yet on this topic, I would only say though that based on the limited knowledge I have, is that a possible reason for why one would want to render something on the cpu it might be directX related since any draw calls from the GPU still have to be approved by the CPU(because scheduling), so that might be one of the deciding bottlenecks. This is also why the Vulkan API had a lot of excitement around it since it basically got rid of the need for the CPU approval. But I might be just talking out of my ass.

[Purple Hermit]

@Jarhead:

Very relevant to the topic.

Finally an explanation as to how the legendary game "Chex Quest" was made

[K. Kira XXIII]

This thread is great, I switched degrees from computer engineering to software eng. With a specialization on games about two years ago. And I can only regret how much I have pushed it aside, to the point I feel so lost, but at the same time getting bombarded with new knowledge. Hopefully, I can help others with their questions one day, for now, I just want to get into the gaming world, maybe translating and finishing up a story board for a game I'd like to make.

Recently I worked with Opengl/C++ to make a procedural 3D world. It really hyped getting to know all these different techniques, like Cubemaps/Skyboxes.

[DarthAsthma]

@Tamiel:

This thread is great, I switched degrees from computer engineering to software eng. With a specialization on games about two years ago. And I can only regret how much I have pushed it aside, to the point I feel so lost, but at the same time getting bombarded with new knowledge. Hopefully, I can help others with their questions one day, for now, I just want to get into the gaming world, maybe translating and finishing up a story board for a game I'd like to make.

Recently I worked with Opengl/C++ to make a procedural 3D world. It really hyped getting to know all these different techniques, like Cubemaps/Skyboxes.

That's super cool feel free to share anything you like on this. Procedural has been something I've been really interested on for a while now I just didn't have the time(or rather I haven't taken the time :ninja:) to get into it yet. I get the overwhelming thing there is just too much stuff to learn, you're just not ever getting into all of it. Makes it even harder to try to find something you want to specialize in when you haven't dabbled with everything yet. Also doesn't help that I feel like a lot of times to really understand something in a way that I don't forget it I need to write a little project utilizing whatever concept I want to learn. So casually reading stuff about AI programming/etc is interesting in the moment but I rarely yield lasting results from it.

Also if anyone was still interested I try to write up gameloop part 2 after all exams are done unless something hits me again.
I originally just maybe wanted to take something I wrote myself and go over it but I feel like since it's not like I've figured this stuff out myself that it's that interesting. I've learned it from the web so that knowledge is kind of out there.

Instead I feel like on trying to muse over possible scenarios where interesting challenges arise that most of the standard loops you find out there don't really account for. The two things that come to me on that right now are the uncharted 2 train section and accounting for network features.

[ShinigamiKing]

What a great idea for a thread. I'll ask something here later!

[KaizokuJinbei]

So for Unity I wanted to try it out but i noticed it has premium versions that have features not available to the free version I just want to know if these features make using the free version any harder to use

[DarthAsthma]

@KaizokuJinbei:

So for Unity I wanted to try it out but i noticed it has premium versions that have features not available to the free version I just want to know if these features make using the free version any harder to use

I don't think any of those features would be of any importance to someone just starting out or using unity for non commercial use.

[DarthAsthma]

Sry no update yet but wanted to share this. Found it super interesting although there seemed to have been a ton of stuff to cover so they didn't go into as much depth as I would have loved. But it was great to get certain confirmations on a few assumptions I had on the game and also hearing a few things I didn't really understand about how they were doing it. Even if the game ends up sucking I still will be impressed by the engineering effort behind it.

Watch it if you're kind of interested maybe in how certain different systems are linked to each other.

[Sakonosolo]

I feel like procedural generation is a good tool but I don't think it works well for open world games, especially if it's being used to generate the entire world and everything in it.

[KaizokuJinbei]

@DarthAsthma:

I don't think any of those features would be of any importance to someone just starting out or using unity for non commercial use.

I want to make a game I just want to make sure none of the features premium versions exclusively have are crucial for it

[DarthAsthma]

@KaizokuJinbei:

I want to make a game I just want to make sure none of the features premium versions exclusively have are crucial for it

I mean the answer doesn't really change I don't think unless you're going full professional(especially with a team) planning to make money from it I don't think it's going to be of any importance. It's hard to answer though without knowing your position just based on the question itself I just assume you're just starting out(but dunno maybe it's a special case I'm not thinking of)? If yes in that case questions about pro licenses etc aren't really thing you should bother with. Rather worry about anything that gets you going actually making stuff.

I feel like people just trying to get into making games have a tendency to worry about the equivalent of artists conundrums regarding what type of pencil thickness to use to draw something completely forgetting about actually drawing something. Just out of curiosity what features would you realistically expect you would need from the pro version when you look at the license page?

[KaizokuJinbei]

@DarthAsthma:

I feel like people just trying to get into making games have a tendency to worry about the equivalent of artists conundrums regarding what type of pencil thickness to use to draw something completely forgetting about actually drawing something. Just out of curiosity what features would you realistically expect you would need from the pro version when you look at the license page?

Nothing in particular it's just when I use game development/graphic design software I like to have as many resources as possible at my disposal so that when I'm working on any projects I'll have more options and diversity

[Sakonosolo]

UE4 might be better if you're just starting out as you get the entire engine for free (so you dont have to worry about misding fratures) and only have to pay if you actually start selling it and make a good deal of money. Unity might be easier to use at some things but it's scripting languages aren't common in other engines and UE4 has that blueprint mode which basically doesn't require programming knowledge to use.

[DarthAsthma]

Gameloops part 2 https://docs.google.com/document/d/1WX2SlqERSCJ23iPNS6OGSE8jz1jpdVOqdc8g5aaVMi4/edit?usp=sharing

Would have posted directly but formatting is busted and this would have become a nightmare to read otherwise(it already kind of is since I don't have the time to add good pictures). Hope this was interesting if not let me know as well and why if you have a why. I'll try to consider for the next topic if I can think of one.

[DarthAsthma]

So I've encountered an interesting problem for one of my projects where the "optimal" solution that you can find being talked about seems to be a not so trivial technical challenge. Just wanted to share cause the contrast seemed amusing for how something that seems very simple actually requires quite a bit of ingenuity to solve depending on the resources you have.

So basically I just want to have a 3d character seen from the third person perspective be able to walk stairs up and down.
The simple solution is basically just make the walking animation cycle in a way that would blend perfectly with the stairs you plan to implement.
And now encountering this I will actually pay attention now to how many games employ stairs of exact step height everywhere so the animation works no matter what. :ninja:

The harder solution(actually not sure if it's really that hard I'm basically sharing this like 30 min after running into it, but that's what I read so far) is actually learning about inverse kinematics and basically program joints to dynamically adjust to the ground.
Which to my understanding allows way more freedom creating/designing stairs/obstacles with variable step height(actually just writing this out that doesn't sound like it's something worth the effort xD), but seems also to be somewhat complicated.

Sorry for not really explaining anything here and instead being somewhat taken aback myself.:ninja:

[Sakonosolo]

Inverse kinematics I don't think is hard to implement (I've never done it but I imagine like anything else there are set ways you can do it) but it takes a larger toll on performance because it involves physics calculations and such. I remember the game Sir, You Are Being Hunted wanted to implement it but said their performance hit with it was too much. Probably has a lot to do with how well you can optimize your game though as GTAIV, V, and the Stalker games all use it, among with lots of other games.

Actually I think the first game to use inverse kinematics was Trespasser in 1998. It's kind of messy with it though because it's so old and it had tons of development issues.

[DarthAsthma]

@Sakonosolo:

Inverse kinematics I don't think is hard to implement (I've never done it but I imagine like anything else there are set ways you can do it) but it takes a larger toll on performance because it involves physics calculations and such. I remember the game Sir, You Are Being Hunted wanted to implement it but said their performance hit with it was too much. Probably has a lot to do with how well you can optimize your game though as GTAIV, V, and the Stalker games all use it, among with lots of other games.

Actually I think the first game to use inverse kinematics was Trespasser in 1998. It's kind of messy with it though because it's so old and it had tons of development issues.

Yeah as far as I understand it, it's actually not that costly depending on how you use it/optimize it/limit it. There also seems to be something dealing with it for free on the Unity asset store but I haven't tinkered with that. Was pretty late yesterday for me to do more research on it and if I'm honest there is still lots of other stuff for me to do before tackling this stair thing. Oh well back to this thread drifting into obscurity :ninja:

[K. Kira XXIII]

Hello everyone,

This semester, I took an Introduction to Game Development class, and we had to build a game in a group project. I was unsure where to post, making a new thread for this one and only post didn't seem reasonable, and Nokanqy had mentioned that this could be a good spot for users to share their games. It is a very short game, and we had to reduce the scope a bunch of times. This is NOT for sale, download it, have fun (hopefully) and if possible I would love all the feedback I could get. I can give more details about my involvement in the project, but I'd rather respond to that from any questions you might have like: which software we used, planning and other design questions. Using Unity we have built a copy for Windows. Also I do not own every asset in the game (you'll see what I mean, but for example: the map tiles). Anywho, without further ado, my first game:

Title: The Casualties Report
Platform: Windows
Genre: Multiplayer, Co-op, Survival, Arena

Link: https://drive.google.com/file/d/0B5iTSviXl92PYklHOGI3NFFNNjQ/view

Note: The build has Player 1 mapped to a keyboard and player 2 to a gamepad (I was using an Xbox 360 controller).
Note 2: Keyboard: Movement -> W,A,S,D; Left Click -> Activate Ability + Basic Attack; Right Click -> Cancel Ability; Skills -> Q,E,R,T
Note 3: Gamepad: Movement -> Left Joystick; Aim -> Right joystick; Activate Skill + Basic Attack -> Right Bumper; Skills -> A,B,X,Y

THANKS, HAVE FUN!

[Noqanky]

@Tamiel:

Hello everyone,

This semester, I took an Introduction to Game Development class, and we had to build a game in a group project. I was unsure where to post, making a new thread for this one and only post didn't seem reasonable, and Nokanqy had mentioned that this could be a good spot for users to share their games. It is a very short game, and we had to reduce the scope a bunch of times. This is NOT for sale, download it, have fun (hopefully) and if possible I would love all the feedback I could get. I can give more details about my involvement in the project, but I'd rather respond to that from any questions you might have like: which software we used, planning and other design questions. Using Unity we have built a copy for Windows. Also I do not own every asset in the game (you'll see what I mean, but for example: the map tiles). Anywho, without further ado, my first game:

Title: The Casualties Report
Platform: Windows
Genre: Multiplayer, Co-op, Survival, Arena

Link: https://drive.google.com/file/d/0B5iTSviXl92PYklHOGI3NFFNNjQ/view

Note: The build has Player 1 mapped to a keyboard and player 2 to a gamepad (I was using an Xbox 360 controller).
Note 2: Keyboard: Movement -> W,A,S,D; Left Click -> Activate Ability + Basic Attack; Right Click -> Cancel Ability; Skills -> Q,E,R,T
Note 3: Gamepad: Movement -> Left Joystick; Aim -> Right joystick; Activate Skill + Basic Attack -> Right Bumper; Skills -> A,B,X,Y

THANKS, HAVE FUN!

Ok, I think I kinda finished the game. As in completed waves with the bounty hunter (kiku?) and cannot find a way to beat the second one with numbers robot.
Feedback below spoilered for those who don't want to have their experience colored by my commentary:

! Technical difficulties:

• I use a trackpad instead of a mouse and had difficulties with the game actually recognizing my inputs now and then. Mostly with the regular attacks, as there would be times I'd be clicking constantly and nothing would happen, whereas other times I'd be shooting lasers/slashing repeatedly.
• Let's talk about the second wave for the robot… much as I tried, I was not able to complete it, and I noticed in part there was a section where the small green enemies would fly around the screen and latch themselves on to me with impossible speed, draining my health. Naturally, the reaction would be placing bombs around me as quickly and often as possible, but the enemy speed would have them surround me rather fast over again and I would die. I was able to get to this wave with almost full health too, and still died super fast.
  Putting it under technical since the speed of those green guys doesn't seem consistent with other waves where I can outrun them and plan accordingly.
• There were times that the hook special of the bounty hunter didn't stun enemies. Like I would bring an octorok close to me and it'd be blue, but it'd continue to shoot.

! Also of note is I only did single player due to lack of a second player.
! Design comments:

• I appreciate the mechanics of the game dictating the gameplay. For example, when I was reading the differences between the robot and the bounty hunter I simply assumed one to be shooty and the other more of a melee character, which was true, but the special abilities and enemy types led to more tactical differences.
  For example, the bounty hunter feels super strong and it's easy to chain from one super dash to slashing, or to turn the tables on enemies with the shield that takes their health or the black hole of death. BUT, when dealing with the octorok while trying not to take damage I had to give more thought to things, and bam, the hook thing became useful.
  Robot took a lot more getting used to, but once I realized how much more effective bombs were than running around I got dramatically better at the first wave. I like that for this guy the shield plants you in place (hope that's intentional?) forcing me to resort to bomb spreads and mines around me instead of shielding and running away.
  In short: there's clear tactics to each character that take playing with them to figure out, and I could see it being fun in multiplayer to collaborate with each other to overcome weaknesses

! - That said, the difficulty curve for the robot was much much higher, and like I said in the tech. difficulties section, I was unable to finish the game with it. From that sense, if I were to play this with people I would be compelled to play as the bounty hunter a lot more. Do they have the same health/defense? Can't say I noticed. And hey, this is a case where the abilities and trade-offs are obviously meant to balance them, that much is clear that thought went into it, but only once play-testing happens can you realize what character people gravitate to the most. Curious to see how other people respond to this.
! - The learning process was... kinda non-existent. While there was a screen explaining differences between the characters, the game started me up immediately and I was suddenly and harshly dealing with a bunch of enemies crowding me. Having small waves before what is currently the first one to introduce enemy types would be nice. Like, introduce a wave with just one enemy type (green crabs). Then a wave with a second enemy type (octoroks?), which involves a different approach. Then once you assume the player has learned how to deal with each in isolation, you can have a stage with both of them in it. Then, have a wave where people deal with green crabs while introduced to a buff dude, to learn that they're similar enemy types but the buff dude is stronger while moving slower. Thus, the player learns about how to deal with that enemy type, and then you have buff dudes with octoroks. And then all three!
For players who die and have to start over, it would also be nice for them to feel their increase in skill, as they go back to that first level and are able to quickly end the wave with mastery of skills.
This would also give time to let the player flesh out their control and abilities with more of a safety net and comfort than suddenly being overwhelmed by enemies and inevitably dying (both first runs with each character I either died or lost huge amounts of health and then got insta killed in wave 2). While it is the case that many people would die and be compelled to try again, there ARE people who would instead just stop playing altogether.
! - There wasn't a pause function <<;
or was there? I tried pressing multiple keys and nothing happened, but maybe I just missed it?
! - Let's talk about the character select UI. What it has going for it is that it clearly introduces both characters and explains how they are different.
My issue with these is that the descriptions and structure involve a lot of reading. OK, relatively not that much, but still, they're blocky paragraphs and means that instead of just being able to jump into the game I have to read.
And then, based on reading about things I can't possibly know much about (assuming I have never played before or don't know what this game is), I have to make a choice, a choice I am not informed enough to make. Inevitably means I pick a character for shallow reasons ("I guess I'll go with Samus instead of Portal robot"), and then don't know how much of what I'm doing pertains to the character until the point I die and go try the other character. Assuming I do instead of just quitting the game.
That second one is hard to deal with in a small-scope game, but that first issue can be dealt with with more basic UI.
For example, things like mario sports games have where they have the character, and then a word and a color naming their gameplay style. Robot could be things like range, or tactical, whereas the bounty hunter is more speed and close-combat. You could still do this with flavor text too, like "KIKU - 'time to get up-close and personal'; "124253 - 'you'll explode before you reach me'", instead of a long paragraph with story-telling about a story no one is going to be interested in (it's an action game) with some of these key words thrown in.
(Btw, the robot needs a simpler name >>;)

• Other UI consideration... I like that the weapons are in the bottom of the screen in a game where enemies approach mainly from the top. Clean, ensures the UI isn't obstructing anything, good stuff. Ways to go further: color coding weapons so their borders let me know what to expect before using them.
  Like, say I didn't read the lines about the weapons... but, I see that this purple circle is yellow, and when I press it it's an AoE attack... now I know if I pick the other character that a yellow border (around the bomb spread for example) is going to be an AoE attack, and will only be compelled to use that when enemies are surrounding me without having to botch it, learn from that, and then wait (and die) while waiting for the re-charge.
  On this, a side note is that the mine power-up feels like the most crucial for the robot, but also the most unintuitive. When I read that you would dash and then drop a mine before doing so, I kept pressing the keys to dash to the right and nothing was happening later on (since Kiku's dash works with keys.) As I learned it worked with clicking, I would still often make the mistake to click in the direction I wanted to dash to, but instead I would drop a bomb in that direction and dash straight into the enemies, dying (it was hilarious btw.) I DO notice that there are little indicators when you activate a power about where it goes and how it would function, but the mine overall still feels unintuitive and it gets confusing going from one character's dash ability to the other's. The indicators are also hard to read when the enemies are all crowding you like you have the last must-have toy in black friday.

! I think that's all that comes to mind for now design-wise. OH, the music. Who did the music? I kept the character select screen on while writing that last part and the song in there is such an earworm. Pretty good stuff. Feels distinct and fits the game properly, and hasn't gotten grating. I dig it.
! Hope all that helps! I realize of course it's a first effort and given that there's a lot in here that show work and dedication and great design choices. Playing just a little bit reveals the presence of possible advance strategies using weapons and skills and environments, and even good possibilities of co-op from asymmetricality, and it's fun in that the challenge is clear and the rules and ironed out and fair. Lots of good stuff in there, and with more polish it can definitely evolve into more.

This is a reminder too I need to begin investing in development tools and get working on stuff for myself. Been busy with design docs and studying, but I want to get my hands dirty already.

[K. Kira XXIII]

@Noqanky:

Ok, I think I kinda finished the game. As in completed waves with the bounty hunter (kiku?) and cannot find a way to beat the second one with numbers robot. Feedback below spoilered for those who don't want to have their experience colored by my commentary:

Kiku - bounty hunter / melee class.
131201307 (Brobot) - sentry unit / ranger class.
Thank you so much for your quick reply! I'll also spoiler my answers.

! > Technical difficulties:

• I use a trackpad instead of a mouse and had difficulties with the game actually recognizing my inputs now and then. Mostly with the regular attacks, as there would be times I'd be clicking constantly and nothing would happen, whereas other times I'd be shooting lasers/slashing repeatedly.
  ! -You can hold the basic attack and it will shoot constantly, I also had problems not using a mouse, however another team member didn't at all. I am not sure if the problem lies in the trackpads themselves or how the input is handled.
  ! > - Let's talk about the second wave for the robot… much as I tried, I was not able to complete it, and I noticed in part there was a section where the small green enemies would fly around the screen and latch themselves on to me with impossible speed, draining my health. Naturally, the reaction would be placing bombs around me as quickly and often as possible, but the enemy speed would have them surround me rather fast over again and I would die. I was able to get to this wave with almost full health too, and still died super fast.
  Putting it under technical since the speed of those green guys doesn't seem consistent with other waves where I can outrun them and plan accordingly.
  ! -Yes, the green enemies: Sleazy Crawlers; have a bug where they build up moment if they are stuck between an enemy and an obstacle which when they get out of, they launch at you at impossible speeds. There are bugs we were not able to fix before the submission date and I have been sharing the game without fixing them ( I plan to keep working on the game after the semester and exams are done) because I think you can still appreciate the overall idea. Another tactic would be to raise your shield and drop bombs combined later with the Big Laser "T" ability. I know, this is not the way to go around things, but if you want to beat the game with Brobot. The game is only those two waves!
  ! > - There were times that the hook special of the bounty hunter didn't stun enemies. Like I would bring an octorok close to me and it'd be blue, but it'd continue to shoot.
  ! -That is actually a big bug on my part. While making Daspitter (Octorok) I tried to have a Spawn Bullet object attached to Daspitter, instead of just instantiating it from itself. A lot of turret tutorials followed that approach, I only realized the problem on our final play testing!
  ! > Also of note is I only did single player due to lack of a second player.
  ! - Multiplayer is focused on co-op gameplay. What I do is i push Brobot into a corner, and fight the enemies with Kiku (I user her a lot better than ranger). However, if you beat the 2 waves there is a twist at the end! I'll spoiler it just in case you want to try:
  ! >! In 2 player mode, after the waves are completed both players have to fight each other out. So co-op becomes player versus player. The ~lore~ behind it is that, Kiku and Bro have been captured and are subjects to intergalactic gladiator fights. So at first you survive the environment, but then you fight each other. During development phase I would joke about wanting an alternative ending where if players did not hit each other you'd get a screen saying: Peace wins!
  ! > Design comments:
• I appreciate the mechanics of the game dictating the gameplay. For example, when I was reading the differences between the robot and the bounty hunter I simply assumed one to be shooty and the other more of a melee character, which was true, but the special abilities and enemy types led to more tactical differences.
  For example, the bounty hunter feels super strong and it's easy to chain from one super dash to slashing, or to turn the tables on enemies with the shield that takes their health or the black hole of death. BUT, when dealing with the octorok while trying not to take damage I had to give more thought to things, and bam, the hook thing became useful.
  Robot took a lot more getting used to, but once I realized how much more effective bombs were than running around I got dramatically better at the first wave. I like that for this guy the shield plants you in place (hope that's intentional?) forcing me to resort to bomb spreads and mines around me instead of shielding and running away.
  In short: there's clear tactics to each character that take playing with them to figure out, and I could see it being fun in multiplayer to collaborate with each other to overcome weaknesses
  ! - Yes the shield for Brobot plants in you in place intentionally, and it also increases your attacks by 2x. We found that impeding your movement was a good drawback for the gains. I am happy that the tactics were clear, personally I am addicted to co-op games so I hope you get the chance to test out the part of the game!
  ! > - That said, the difficulty curve for the robot was much much higher, and like I said in the tech. difficulties section, I was unable to finish the game with it. From that sense, if I were to play this with people I would be compelled to play as the bounty hunter a lot more. Do they have the same health/defense? Can't say I noticed. And hey, this is a case where the abilities and trade-offs are obviously meant to balance them, that much is clear that thought went into it, but only once play-testing happens can you realize what character people gravitate to the most. Curious to see how other people respond to this.
  ! -Yes the attributes for both players are different. Kiku has more speed and health than Brobot because of her melee traits. There is no defense attribute. Kiku has: 1250 health points while Bro has: 1000. The Big Meanie(big dude) has: 800 and the other two have below 200. Also yeah Kiku is way cooler so play with her always! :3 (I made her sprite sheet, I also made Big Meanie, Enemy Crawler)
  ! > - The learning process was… kinda non-existent. While there was a screen explaining differences between the characters, the game started me up immediately and I was suddenly and harshly dealing with a bunch of enemies crowding me. Having small waves before what is currently the first one to introduce enemy types would be nice. Like, introduce a wave with just one enemy type (green crabs). Then a wave with a second enemy type (octoroks?), which involves a different approach. Then once you assume the player has learned how to deal with each in isolation, you can have a stage with both of them in it. Then, have a wave where people deal with green crabs while introduced to a buff dude, to learn that they're similar enemy types but the buff dude is stronger while moving slower. Thus, the player learns about how to deal with that enemy type, and then you have buff dudes with octoroks. And then all three!
  For players who die and have to start over, it would also be nice for them to feel their increase in skill, as they go back to that first level and are able to quickly end the wave with mastery of skills.
  This would also give time to let the player flesh out their control and abilities with more of a safety net and comfort than suddenly being overwhelmed by enemies and inevitably dying (both first runs with each character I either died or lost huge amounts of health and then got insta killed in wave 2). While it is the case that many people would die and be compelled to try again, there ARE people who would instead just stop playing altogether.
  ! -I think the main issue for us was time. I had many level designs scenarios, which we could not finish implementing. So we decided to just show everything in two waves, so the professor would get the idea: each waves get harder, these are all the enemy types. I completely agree with your comment. The first wave should only spawn Sleazy (green), second blue and green, third maybe one heavy unit. We also thought about adding environmental traps such as electrified walls and lasers. With a better structured level design I think it could be challenging without being completely overwhelming. The spawning function is along the lines of: if (#ofenemies < wavecount * 6), if(#ofenemies < wavecount *3) and so on for each enemy type (green the most, big dude the least).
  ! > - There wasn't a pause function <<;
  or was there? I tried pressing multiple keys and nothing happened, but maybe I just missed it?
  ! - No pausing for the elite! sorry about that.
  ! > - Let's talk about the character select UI. What it has going for it is that it clearly introduces both characters and explains how they are different.
  My issue with these is that the descriptions and structure involve a lot of reading. OK, relatively not that much, but still, they're blocky paragraphs and means that instead of just being able to jump into the game I have to read.
  And then, based on reading about things I can't possibly know much about (assuming I have never played before or don't know what this game is), I have to make a choice, a choice I am not informed enough to make. Inevitably means I pick a character for shallow reasons ("I guess I'll go with Samus instead of Portal robot"), and then don't know how much of what I'm doing pertains to the character until the point I die and go try the other character. Assuming I do instead of just quitting the game.
  That second one is hard to deal with in a small-scope game, but that first issue can be dealt with with more basic UI.
  For example, things like mario sports games have where they have the character, and then a word and a color naming their gameplay style. Robot could be things like range, or tactical, whereas the bounty hunter is more speed and close-combat. You could still do this with flavor text too, like "KIKU - 'time to get up-close and personal'; "124253 - 'you'll explode before you reach me'", instead of a long paragraph with story-telling about a story no one is going to be interested in (it's an action game) with some of these key words thrown in.
  (Btw, the robot needs a simpler name >>;)
  ! - Those are great suggestions, the paragraphs were literally copied from the game design document jajaja. Would your suggestion also be for the abilities?
  ! > - Other UI consideration… I like that the weapons are in the bottom of the screen in a game where enemies approach mainly from the top. Clean, ensures the UI isn't obstructing anything, good stuff. Ways to go further: color coding weapons so their borders let me know what to expect before using them.
  Like, say I didn't read the lines about the weapons... but, I see that this purple circle is yellow, and when I press it it's an AoE attack... now I know if I pick the other character that a yellow border (around the bomb spread for example) is going to be an AoE attack, and will only be compelled to use that when enemies are surrounding me without having to botch it, learn from that, and then wait (and die) while waiting for the re-charge.
  On this, a side note is that the mine power-up feels like the most crucial for the robot, but also the most unintuitive. When I read that you would dash and then drop a mine before doing so, I kept pressing the keys to dash to the right and nothing was happening later on (since Kiku's dash works with keys.) As I learned it worked with clicking, I would still often make the mistake to click in the direction I wanted to dash to, but instead I would drop a bomb in that direction and dash straight into the enemies, dying (it was hilarious btw.) I DO notice that there are little indicators when you activate a power about where it goes and how it would function, but the mine overall still feels unintuitive and it gets confusing going from one character's dash ability to the other's. The indicators are also hard to read when the enemies are all crowding you like you have the last must-have toy in black friday.
  ! -JAJAJA Black friday toys. I guess making the indicators a different color would help. Dashing forward for Brobots skill works too. I think the decision was that usually as a ranged unit, you are shooting while moving away, so you are aiming towards the enemy moving in the opposite direction, and then you activate it to move even further back. With that said: I find that one of the difficulties we did not manage to surpass were the controls. For example, playing with a keyboard and mouse is a lot easier than with the gamepad, and it is mainly due to our game having influences from MOBA games. That's why some abilities trigger automatically, like AoE and shields, Kiku's abilities except the hook are also automatically cast. The dash works with the moving buttons. I think when I get back to working on the game, the control map is something I will revise, especially for gamepad.
  ! > I think that's all that comes to mind for now design-wise. OH, the music. Who did the music? I kept the character select screen on while writing that last part and the song in there is such an earworm. Pretty good stuff. Feels distinct and fits the game properly, and hasn't gotten grating. I dig it.
  ! - You should go and get the game: VVVVVV (I have been telling everyone to get it), the song is called: Predestined Fate, I would recommend jumping on youtube and listening to the entire soundtrack. It is le amazing.
  ! > Hope all that helps! I realize of course it's a first effort and given that there's a lot in here that show work and dedication and great design choices. Playing just a little bit reveals the presence of possible advance strategies using weapons and skills and environments, and even good possibilities of co-op from asymmetricality, and it's fun in that the challenge is clear and the rules and ironed out and fair. Lots of good stuff in there, and with more polish it can definitely evolve into more.
  ! - IT HELPED TONS! One of my teammembers wanted to thank you for taking the time to reviewing the game! We had so much planned at first (the game was supposed to be a dungeon crawler at first!), we also wanted a level system for the abilities jajaja. I think with a bit more of work, the game can turn out to be quite fun as you said once level design and the bugs are fixed!

This is a reminder too I need to begin investing in development tools and get working on stuff for myself. Been busy with design docs and studying, but I want to get my hands dirty already.

• I understand that feeling too, although my perspective does not compare to yours seeing your experience in the industry. I am scared and nervous but I would be happy to work with anyone on small projects. I have RPG Maker, and well now I have some Unity knowledge as well. Thanks again, I really appreciate your comments!

[K. Kira XXIII]

Sorry for the double post, but there is a humble bundle going on for making your own game books. You get them all for 15$.