MrDaaark

So, is this a valid concern, or just silly?

It's silly that it's a valid concern.

A few years back, someone claimed to have invented spherical texture mapping and went after the entire industry.

SCO claimed to have patents on everything in Linux and tried to extort every one who even knew Linux existed.

Creative Labs went after John Carmack over his shadowing algorithm during the making of Doom 3. They held the project hostage, and I believe, made him include functionality for their new (and useless at the time) sound card.

Those who can, create
Those who can't, litigate



We're all liable to be litigated at some point. Someone will claim to have invented something in C++'s runtime, and try to extort 1000$ out of everyone who ever installed Visual C++ or GCC. That's just the way it is.

The book itself is great but I desperately need a bunch of stuff from the CD, like the appendixes and the source code. Does anyone know where to get a copy of what's on it or, if that's not available, would anyone mind uploading the CD contents? Thanks.

No one can upload the CD, because that is piracy and copyright infringement.

Why not buy a copy of the book? It's only 75$ from indigo.ca (Amazon.com has people charging 200$+ for it). 75$ is cheap for the amount of knowledge you can get from that book.

Failing that, there are a trillion and one MUD game programming sites around the internet, with tutorials and free code bases. You have almost infinite free learning material.

*ahem*

It's possible to beat any of them on 1 quarter. But to get that good at them, you have to spend a lot of quarters practicing. Arcade machines are something someone buys for their business. They are there to make money for the operator and have to justify the floor space they take up.

At one point, where fighting game machines were at their heyday here, and charging dollar a pop, they were making about a dollar a minute on a busy day when people were lined up to play them against each other.

Games designed for an arcade machine have different design goals than something that is made for a home release. They are designed to keep money flowing into the machine as much as possible. No different than carnival games, or those games you see in malls and stores where you put in some money and try to grab a prize with a robotic arm (and they are rigged to not give anything out until a certain $ threshold has been reached.)

I remember when the guy running one of the old arcades here would walk into the convenience store across the street, and buy a 2$ comic book to offer as a prize, and people would burn through 10$-20$ each trying to get it.

We are in a very different era. When the Saturn, PSX, and N64 came out, arcade machines no longer had any real technological advantage, and the bar was raised content wise. Arcade style games became simple and outdated almost overnight.

There was a store across the street from my highschool that had an X-Men machine, a Killer Instinct Machine, and a Virtua Fighter machine. We'd all blow our money in there at lunch time if we were lucky enough to play! We were lined up so deep there was no room to move in the store. The owner must have made a killing with those. A year later they were gone. They were no longer making enough to justify the space they were taken up.

Dedicated Arcades held on for a little bit longer and tried new things, like debit cards you had to pre-load, and dark rooms with Quake 2 lan parties you could play for 15 minutes at a time. That didn't go over well.

Why would you pay to play Quake 2 on local lan for a few minutes at a time in a room full of noisy arcade machines when you can play at home and have a much better experience?

Why would dump quarters into a beat em up when you could take 10$ to blockbuster and take 2 much better ones home to play all weekend?

Same with fighting games. The home releases got much better for most games. And the allure of going to the arcade to match up against good players was gone, because no one else was going. Your opponent would be a random kid who just begged his mom for a single quarter and never saw the game before.

This is probably all completely alien to anyone born in the early nineties.

Inputs is a matter of opinion.

In my main update loop, I would only first check global inputs, like for pause or anything that affects the game as a whole, then I would do specific checks on a per state basis.

STATE_DAZED:
Check for ANY possible input, and use it to reduce the daze timer.
STATE_IDLE or STATE_WALKING
Check for anything and respond. Like movement keys, attack, jump, whatever.
STATE_DASHING:
Check for anything and respond, but the responses are different than above.
STATE_ATTACKING:
Player is busy is attacking
STATE_HIT:
No valid input in this state, player is reacting to being hit.
etc...

I find that cleaner and straight forward than other methods. But that is a matter of opinion and organization. I find checking input and then later trying to match it up to a correct state to be backwards thinking. Why do the logic up front only do find out later down the line that you aren't even in the correct context?

Question 2:

As for the attack stuff. I kept my description very high level. I'll try to answer it better

You have a character object, and he references a sprite sheet, such as: http://soronline.net/sprites/sor3/Axel(sor3).png

So now you have a list of animations for this character. An animation is a class that has some data that describes it, plus a list of frame structures...

PSEUDO CODE

class animation
{
	string Name;

	ANIMATION_TYPE Type;

	//with enums
	ANIMATION_TYPE_WALKING
	ANIMATION_TYPE_RUNNING
	ANIMATION_TYPE_ATTACKING
	etc...

	//a list of frames
	vector <Frame> Frames;

}


class Frame
{

	bool isContact;	//contact frame?
        someType delay; //delay until the next frame, in whatever measurement form you are using

	//coords of the frame on the sprite sheet
	int x,y;
	int height,width;

	//coords of the hitbox
	int hitbox_x,hitbox_y;
	int hitbox_width,hitbox_height;

	//coords of the contact hitbox, if applicable, on contact frame only
	int contact_x,contact_y;
	int contact_width,contact_height;
	
}

The logic in your update function will deal with the attack. The SetState function example was just code to handle state switching cleanly.

I forgot STATE_WALKING in the list above. That's a big oversight!

I put SetState() as a function because you shouldn't be setting all those random variables all over the place like that. Everything should be single responsibility, and as clean and simple as possible.

STATE StateCurrent;
STATE StatePrevious;


void SetState (STATE s, STATEINFO si)
{
	//buffer the current state into a previous one, just incase
	//you ever want to know what the character was doing right before now
	//you have that information easily available
	StatePrevious = StateCurrent;

	//now use a switch statement to setup the state s
	switch(s)
	{
		//character got hit
		case STATE_HIT:
		{
			StateCurrent = STATE_HIT;

			//use the info in si to figure out what to do
			//if the attack was high, medium, or low, set
			//the proper reaction animation to current
			//IMAGINARY CODE HERE


			//use other info in si about how strong the attack
			//was or whatever to determine knockback distance
			//and animation speed to simulate weight and impact
			//IMAGINARY CODE HERE			
				

			break;
		}

	}

}

I'll use Streets of Rage 3 logic and the main character Axel as an example for everything below.

First, you'll need an input array that can hold up to whatever the maximum amount of inputs for a move is. In streets of rage, this is 3.

Every time the user presses a button, you check against previous inputs to see if matches any specific patterns. So Up,Up or Down,Down cause Axel to roll up or down. Forward, forward or back, back, cause him to dash. Forward,Forward,Attack causes the Bare Knuckle Uppercut.

So you need an array of inputs 3 entries long, and a SetState(STATE s, STATEINFO si) function.

STATE_IDLE
STATE_ROLLING
STATE_DASHING
STATE_JUMPING
STATE_ATTACK
STATE_HIT
STATE_KNOCKBACK
STATE_DAZED

Each state will have it's own input code and logic. The logic and input for STATE_DAZED will be very different than STATE_IDLE.

Any keypress in STATE_DAZED just goes towards decreasing the dazed timer.

STATE_HIT doesn't need to concern itself with input, because the player is just reacting to getting hit. The only important information would come from STATEINFO_HITHIGH, STATEINFO_HITMED, STATE_INFOHITLOW, STATEINFO_HITKNOCKBACK, etc to know which animation to play, and then when it's down, you go back to STATE_IDLE. I would probably actually make STATEINFO a struct and include a ton of information in there for any state.

Press the attack button while in STATE_IDLE, STATE_DASHING, or STATE_JUMPING will change state to STATE_ATTACK, and then you will play the relevant attack animation. Unless you have special situational rules, you shouldn't need to concern yourself with STATE_DASHINGATTACK, or STATE_JUMPINGATTACK.

You will also have an array of animation frame data which will be specified in a data file somewhere.

All your attack data will come from here while in STATE_ATTACK. You will need to know
*-the number of frames, and their coordinates on the sprite sheet
*-which frame(s) are the contact fames, and their hitboxes
*-which animation is next in the chain (0 for no combo ability (used on jump kick, dashing attack, and the last move in any combo)
*-frame delays, so each frame is played with the proper time delay

With this system, if the user presses attack button during the attack, or is idle but pressed attack within the allowable grace period, you automatically know if you can combo based on the current or last animation.

In Streets of Rage 3, attack 3 times causes something like left punch, right punch, uppercut.

The left punch is the basic attack. It's frame data would indicate that it combos into the right punch.
The right punch would frame data would indicate that it combos into the uppercut.
The uppercut frame data would indicate that it combos into nothing. So you return to STATE_IDLE.

It's all in the data set. Your code for the attack will read in the data and be able to handle every possible attack with it's general purpose code. Even if you want to want to have people tossing projectiles, you will have data that specifies this, and the contact frame is just the frame where you spawn a projectile (which should just need type, direction, owner data).

That's just an example off the top of my head. Your rules will be different, and it will get a bit more complex, but hopefully that helps you understand a way to get it done. Also, why not check out this thread I'm in that analyzes these types of games? http://www.gamedev.net/topic/637975-what-makes-a-good-beatem-up-game/

This stuff should be data driven, and you really only need one attack state. The data for each attack will handle the rest. You should know which frame is the attacking frame, and have the hitbox for it on the part that is doing the attacking. Like a box around the fist on the frame where it would connect.

That looks amazing.

Don't ever use .blend files with Unity. Every time you edit and save your .blend file, Unity responds by making a mess of everything. Export your blender files to fbx, and then put those in the Unity folder to be imported.

Because graphics cards have limited memory and are only able to address so much. When a texture is loaded for use, it goes into a special area where it can be sampled from very quickly. The size of that memory is the maximum size of the texture you can load. Some cards had 256, then 1024, 2048, and then 4096, and beyond.

4096 is the largest size Xbox360 can use. It may be the largest size that XNA GS supports for PC as well. Then your own GPU will have it's own limit, which may be less or more.

There is no way in hell you need a texture any larger than that. Most textures at 4096x4096 are being used for atlasing, and not for a single texture, and there aren't even that many pixels visible on screen.

Hardly true at all. bla bla bla

Every word of what I wrote is true. I'm not even sure what you are arguing with? Because I did't post anything about engines and their speeds. This is a thread about how someone new should proceed.

If someone wants to make a game, they should go grab an engine, learn to use it, and start putting in their content. There is no need to waste time learning to program D3D or OpenGL if your goal is to make a game. I'm sure his game idea isn't a rotating, normal mapped, teapot or Standford Bunny. Rendering behavior has become pretty standardized and there is no need to go fooling around with all those low level calls. Barring a graphical feature or two (which amount to useless niggling), your content will look like whatever the artist came up with.

Now for the rest of that crap you prattled on about.

A lot of old OpenGL games certain DON'T run better on newer hardware. Especially when they can't find all the outdated extension strings they are looking for, and switch to software fall backs, or worse rendering techniques.

For instance, my newer PC in 2007 with a newer geforce couldn't run Quake2 anywhere near as good as my old machine with a Riva TNT2 in it. One start-up the console would scroll past a huge list of missing extensions, one of which was an old multi-texturing one. So now the game was doing multiple passes over every frame, and I was struggling with it at 800x600.

1) Look up roguelike maze generation techniques. Here is one with source, but keep looking until you find one method that suits you best.
http://www.roguebasin.roguelikedevelopment.org/index.php?title=Simple_maze

2) Open Blender, and make a few tiles. Make 1 tile for every unique part you will need.

3) Open the Python editor in Blender, and write out a script that will generate a maze using instances of your tiles.

What is OpenGL

OpenGL is a library of C code that talks directly to your graphics driver, which in turn sends commands to your GPU. Basically, it does little more than set rendering options, and than send commands to draw lists of vertices. Microsoft has a version of this for their platforms called Direct3D, and it has just about the same functionality.

Should I start with it?

Only if you are programming a graphics engine (as that's all it's good for). If you just want to make games, go use a toolkit like Unity3D, Panda3D, or something similar, and focus on your content, design, ideas, and actually making a working game.

There is really no reason to write your own graphics engine anymore.

For several reasons:

Graphics engines have gotten complex. It's very difficult and time consuming to implement all the required features, and make sure they work across all the different GPUs. Making a graphics engine will take on a life of it's own, that will detract from actually making a game.

There is nothing left to invent. A graphics engine just organizes the steps of setting up vertex buffers, render states, and draw calls. Everything interesting after that happens on the GPU. It's all standardized behavior. So regardless of what your code looks like, the end result is entirely up to your content(models, shaders, materials).

Given the same content input should get you a similar final image from any rendering engine regardless of if it uses Direct3D or OpenGL, and regardless of who wrote the engine.

So if you want to make games, go find a toolkit and make games.
If you want to be a graphics programmer, start mucking around with Direct3D or OpenGL.

Settle For Less isn't a negative option. Consider it a stepping stone on your way to better things.

You have many options here:

If you go to deviant art, you can search for figure templates there. Find something that matches your preferred proportions and draw your unique features on top of it. Then you can draw your characters face and skull shape and stuff and let the modeler interpret it. Here are 2 random ones that I like
http://xandria-tchebbi.deviantart.com/art/Male-Turnaround-Study-346911478
http://xandria-tchebbi.deviantart.com/art/Female-Turnaround-Study-346904861

Decide how many heads tall your character is, then draw lines across a sheet of paper. Put that paper UNDER the paper you are going to draw on, and then just match things up as you draw. If you didn't know, all drawn figures are measured as 'heads tall'. An average person is considered 5 r 6 heads tall. A huge person can be 8 heads tall. Cartoon or chibi like characters can be 3 or 4 heads tall.

Check out Concept Cookie and learn from their tutorials.
http://cgcookie.com/concept/2013/02/07/creating-a-stylized-character-turnaround-from-concept/