openglmm_shaders Test 20150817

Here is a video demo of my OpenGL 3.3 library libopenglmm.
Source

YouTube Video

Materials:
Lambert shading (Mirror’s Edge style)
Fog
Cube mapping
Multitexturing
Normal mapping
Car paint (Slighty broken, I think a texture look up is incorrect)
Glass mixed with dirty metal texture (Similar to an old rusty/broken mirror)
Cel shading
Smoke particle system with lambert lighting with 4 normals that very roughly approximate a sphere (I think something is wrong with the depth texture look up)

Post render effects:
Sepia
Teal and orange
Noir
Matrix
HDR (It is cheesy and over done, but you get the idea, it would normally be a lot more tame, either brought back or blending less of the HDR textures in at the end)
Colour blind simulation (3 modes are possible, only one is shown)

Blender Export OBJ Python Script

First of all I’d like to state that I’m definitely a Blender n00b and I have never touched Python in my life.

Baby steps, textured sphere loaded from an obj file
Baby steps, textured sphere loaded from an obj file

In my game engine I basically have this sort of layout:

sphere/
sphere.obj
sphere.mat
sphere.png

The .obj points to the .mat file which points to the .png file. So in Blender I would set the material name to “sphere” and ideally in the .obj file it would have a line like this, “usemtl sphere”, I would then get the sphere part and append “.mat” and load the material. I’m not sure if this is standard practice for Blender export scripts, but when exporting to the obj file format, Blender adds the texture name to the material like so, “usemtl sphere_sphere.png”, not cool. Anyway I thought, hey, the export script is written in Python, I wonder if I can fix this?

1) Locate the script. I read somewhere on the Blender site that scripts are in “/usr/share/blender/scripts/”. “export_obj.py” is there, along side “export_obj.pyc” and “export_obj.pyo”.
2) Edit the script.

gedit /usr/share/blender/scripts/export_obj.py

3) The script is pretty well documented. I knew that I should search for “usemtl” as that is the only constant part of the string (Apart from “_” which is much harder to search for). There are two in the file and we want the second one:

mat_data= MTL_DICT.get(key)
	if not mat_data:
		# First add to global dict so we can export to mtl
		# Then write mtl
 
		# Make a new names from the mat and image name,
		# converting any spaces to underscores with fixName.
 
		# If none image dont bother adding it to the name
		if key[1] == None:
			mat_data = MTL_DICT[key] = ('%s'%fixName(key[0])), materialItems[f_mat], f_image
		else:
			mat_data = MTL_DICT[key] = ('%s_%s' % (fixName(key[0]), fixName(key[1]))), materialItems[f_mat], f_image
 
	if EXPORT_GROUP_BY_MAT:
		file.write('g %s_%s_%s\n' % (fixName(ob.name), fixName(ob.getData(1)), mat_data[0]) ) # can be mat_image or (null)
 
	file.write('usemtl %s\n' % mat_data[0]) # can be mat_image or (null)

mat_data is a dictionary that is filled out and then written the file with “usemtl”. I replaced the offending line:

mat_data = MTL_DICT[key] = ('%s_%s' % (fixName(key[0]), fixName(key[1]))), materialItems[f_mat], f_image

with this:

mat_data = MTL_DICT[key] = ('%s'%fixName(key[0])), materialItems[f_mat], f_image

And then I realised that it was exactly the same as the line from the “if key[1] == None:” so you could probably remove the branch etc. if you want, I didn’t bother.

If you are exporting groups by material you may also need to edit the “if EXPORT_GROUP_BY_MAT:” branch also, again I didn’t bother. Anyway, save and you’re good to go.

4) I was worried that I would have to compile into bytecode or something for Blender to be able to use this, nope, either restart Blender or hit “Update Menu”. Actually as it is an export script, I’m not sure you even need to do that, it probably gets reloaded when you hit “File > Export > Wavefront (.obj)”?

This is the entirety of my Python knowledge, oh, I also know that whitespace is important or something, woo.

PS. I’m loving git, I can’t believe I didn’t switch earlier!

Yearly Update :)

Sudoku Work in Progress
Skysytem background, testing wireframe grid, TombRaider MD3 model, testing material boxes, particle systems, frames per second messages, pegs, shocks, all the necessary elements of a Sudoku game.

It’s been a while, I have like 20 draft entries in WordPress ranging from 1 paragraph comments up to 10 paragraph full on entries that still need that final once over and edit before going live. Actually it might be cool if there was (There probably is) a plugin so that people could optionally go to a page on my blog where they can see everything that hasn’t been published yet, like tagged with “draft” or something and comment on which ones I should flesh out and which ones I should ditch before they are even finished.

Anyway, so I have been working (Getting side tracked while working on) my Sudoku game.

Basically in Sudoku mode you get to select a number from the “palette” at the top and then click on all the places you want it on the board. The solver I have coded up can solve about 80% of Sudoku boards with “human solvable” methods and the remaining 20% can be solved with a combination of human solvable and then resorting to brute force for anything it can’t find. A valid board should not need brute forcing which means that I need to implement more rules for my human solving methods first. I should be doing something like this:

if (solve_human_methods()) ... solved
else ... this board is invalid as it could not possibly be solved by a human without resorting to brute force

However I haven’t implemented all human methods of solving yet, only about 4 or 5 simple ones, actually probably less, there are about 2 or 3 real rules and then 4 or 5 extrapolated rules that are just combinations of the first ones.

Anyway, in First Person mode there is flying around (No clip mode) as well as moving Lara Croft around (Optionally other MD3 models) with sort of appropriate animations based on velocity (But not facing direction yet). One thing I have noticed is that half of the MD3 models I download have different file naming conventions, so at some stage I want to break out some Quake 3 action and see what file names it uses and use that as my standard.

Why all this other stuff in a Sudoku game? Whichever game I am working at the time becomes my test bed application for whatever I feel like implementing when bored. I really need to make a dedicated test bed that does nothing else but demonstrate stuff. I’ve also split my game engine into Spitfire and Breathe portions, which splits the library into two halves, the generic tools for any application (string, math, xml, md5 hashes etc.) and game specific features (OpenGL rendering, audio, physics, MD3 animation, etc.) respectively.

Crank very early testing of heightmap and basic physics

This is what I have been working on in my spare time. I think it is going alright. I still have to do:
The brakes can’t be locked up at the moment, they always give a little so you can’t for example lean on the front wheel and hold the brakes and expect to stay in the same place.
Create the level editor, at the moment the level is just a bunch of sin waves added together.
Add a little bit of parallax scrolling to add a bit of interest and depth.
Create better artwork for example shocks and rider.
Add dynamic bike bits such as suspension that compresses and a rider that leans forwards and backwards and has a weight (At the moment I fake weight transfer by just rotating the bike).

Library source
Game source

Call of Duty 4 AI and difficulty levels

I started and finished Call of Duty 4 yesterday. Basically it is war themed FPS that tries to capture the feeling of helplessness of being in a war. The standard method for creating each level in a game like this (Quake 1) is to create the “map” that the player will run around in and then manually add a series of points (Spawn points) in the map that represent each bad guy. So if you add 20 points, you will have 20 bad guys. Another method is to specify 100 spawn points and then spawn 20 bad guys at 20 of those points, which mixes it up a little bit so that the game is less predictable. In earlier games like Quake 1 and Wolfenstein, these bad guys have a problem where they just sit on their starting position until they saw the player, at which point they would basically run straight at the player shooting, pretty simple stuff.

Call of Duty differs slightly from other games:
a) I think there are actually fewer spawn points than in a conventional game, however,
b) There is not a 1 to 1 mapping of bad guys to spawn points, bad guys constantly stream out of these spawn points.
c) These spawn points are placed slightly off the player accessible part of the map, and then the enemies jump over walls, emerge from doors and alleyways, helicopter and rapel in, etc.

There are also the usual predictable, “There’ll be a guy behind the door here, a guy will run through now”, but it’s much less noticable. Each spawn just continuously spawns bad guys until you either get to a certain pointon the map at which point the next spawn point will start spawning, or a time constrain runs out (“Defend this point for 2 minutes”).

All of the Call of Duty games (And most FPS games in general) have a configurable difficulty system consisting of something like “Easy”, “Medium”, “Hard”, “Insane”. The problem is that it is usually set for the whole game so you choose medium and go to the first level which introduces you to the game, then the levels get progressively harder, now the problem is that the first level isn’t a real representation of the difficulty. By the middle of the game it can feel way to hard or way to easy. Grand Theft Auto solves this problem by having every player play the same difficulty and then the missions get progressively harder until I give up and don’t finish the game, so that solution isn’t without its problems. It would be much better if every game were Grand Theft Auto style, but were the game adapted to how good the player was. Some games are already similar to this, but instead of lowering/raising the difficulty of the enemies they give you more or less health and ammunition. However it could be possible to exploit this method by playing badly until the last level and then easily beat the last few levels and completing the game. The other problem is how to differentiate between a good and bad player. Each player would have a few areas where they are judged, such as health at the end of each level, health lost per enemy encountered (A ratio something like 15% health lost per enemy killed), speed through the level, accuracy with each weapon/speed. You could even add other things such as exploration of the level, stealth and variety of weapons/styles.

It’s hard to tell the difference between whether a player is going slow because they aren’t competent enough or if they are just taking their time and being methodical for example. The other problem is how do tell the player’s speed through the game? The easiest (And roughest) way is to get their total time through the level from entry to exit. You could also have points along the typical player’s route and time the player between them, or find the average time between the player seeing each enemy and killing them, or the total kills divided by the total level time. You could even have an experienced player play through the game, then a less experienced player, recording both their play and then scaling the difficulty based on which one the player is playing most like.

Another interesting method would be to identify a few main playing styles such as bunnyhopping, rushing, camping. You could then spawn more or less enemies and at different distances from the player to force the player into the mode you want them to be in. For example if they are rushing, spawn more enemies behind the player or above the player to force them to take their time and look around a bit more. If the player is taking too much time and sniping too much, spawn some enemies just around the corner who will rush the player and force her to switch to a short range weapon.

The first mission of Call of Duty 4 is the unskippable training mission for people who have never played an FPS before. “Here’s a gun, here’s a target, here’s a grenade, etc.”. It takes about 10 minutes and should be skippable considering that almost everyone who plays will have played an FPS previously and a lot of them would have actually played previous Call of Duty games. It is a prime candidate for starting with a message box that says “Do you want to try a training mission before you get stuck in?”. Another option would be to have everyone go straight to the first real mission and either start real slow, with a run through the woods or something with lots of running and one enemy every minute and then gradually introducing the player to other weapons and skills (“Here’s a grenade, throw it with this button…”, “Crouch behind this wall so that the guard can’t see you”).

Anyway, it’s a good game, but doesn’t really do anything the previous versions didn’t do. The highlight for me was running around in Ghillie hiding awesomely. It would have been better if there were a lot more Ghillie suit missions. Being the gunner for the DC aircraft was fun too but went on way too long.