• 12
• 12
• 9
• 10
• 13
• ### Similar Content

• By GytisDev
Hello,
without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
• By Descent
Wow what a wild game by GalaXa Games Entertainment Interactive. Play now... it's really fun but IF you have epilepsy then don't play. It does not feature flashing pictures, but there is lots of animated stuff that might get ya. Anyway, 4 levels, 2 endings, insane action, BY INFERNAL. Please play it, right nao! Also , nice midi music composed by me is in the game.

demons.rar

• Killing Floor 2 has the best dismemberment/gore system by far.
No other game comes even close; how enemies react, segmented body parts depending where you shoot them, how dead bodies react, etc.
Is there an easy-to-set up system, but with scaled down features, for the Unreal Engine 4, while still offering the same visceral physicality?

When humans play games – like chess, for example – they play differently every time. For a game developer this would be impossible to replicate. So, if writing an almost infinite number of possibilities isn’t a viable solution game developers have needed to think differently. That’s where AI comes in. But while AI might like a very new phenomenon in the wider public consciousness, it’s actually been part of the games industry for decades.
Enemy AI in the 1970s
Single-player games with AI enemies started to appear as early as the 1970s. Very quickly, many games were redefining the standards of what constitutes game AI. Some of those examples were released for arcade machines, such as Speed Race from Taito (a racing video game), or Qwak (a duck hunting game using a light gun), and Pursuit (an aircraft fighter) both from Atari. Other notable examples are the text-based games released for the first personal computers, such as Hunt the Wumpus and Star Trek, which also had AI enemies.
What made those games so enjoyable was precisely that the AI enemies that didn't react like any others before them. This was because they had random elements mixed with the traditional stored patterns, creating games that felt unpredictable to play. However, that was only possible due to the incorporation of microprocessors that expanded the capabilities of a programmer at that time. Space Invaders brought the movement patterns and Galaxian improved and added more variety, making the AI even more complex. Pac-Man later on brought movement patterns to the maze genre – the AI design in Pac-Man was arguably as influential as the game itself.
After that, Karate Champ introduced the first AI fighting character and Dragon Quest introduced the tactical system for the RPG genre. Over the years, the list of games that has used artificial intelligence to create unique game concepts has expanded. All of that has essentially come from a single question, how can we make a computer capable of beating a human in a game?
All of the games mentioned used the same method for the AI called finite-state machine (FSM). Here, the programmer inputs all the behaviors that are necessary for the computer to challenge the player. The programmer defined exactly how the computer should behave on different occasions in order to move, avoid, attack, or perform any other behavior to challenge the player, and that method is used even in the latest big budget games.
From simple to smart and human-like AI
One of the greatest challenges when it comes to building intelligence into games is adapting the AI movement and behavior in relation to what the player is currently doing, or will do. This can become very complex if the programmer wants to extend the possibilities of the AI decisions.
It's a huge task for the programmer because it's necessary to determine what the player can do and how the AI will react to each action of the player. That takes a lot of CPU power. To overcome that problem, programmers began to mix possibility maps with probabilities and perform other techniques that let the AI decide for itself how it should react according to the player's actions. These factors are important to be considered while developing an AI that elevates a games’ quality.
Games continued to evolve and players became even more demanding. To deliver games that met player expectations, programmers had to write more states for each character, creating new in-game and more engaging enemies.
Metal Gear Solid and the evolution of game AI
You can start to see now how technological developments are closely connected to the development of new game genres. A great example is Metal Gear Solid; by implementing stealth elements, it moved beyond the traditional shooting genre. Of course, those elements couldn't be fully explored as Hideo Kojima probably intended because of the hardware limitations at the time. However, jumping forward from the third to the fifth generation of consoles, Konami and Hideo Kojima presented the same title, only with much greater complexity. Once the necessary computing power was there, the stage was set for Metal Gear Solid to redefine modern gaming.
Visual and audio awareness
One of the most important but often underrated elements in the development of Metal Gear Solid was the use of visual and audio awareness for the enemy AI. It was ultimately this feature that established the genre we know today as a stealth game. Yes, the game uses Path Finding and a FSM, features already established in the industry, but to create something new the developers took advantage of some of the most cutting-edge technological innovations. Of course the influence of these features today expands into a range of genres from sports to racing.
After that huge step for game design, developers still faced other problems. Or, more specifically, these new possibilities brought even more problems. The AI still didn't react as a real person, and many other elements were required, to make the game feel more realistic.
Sports games
This is particularly true when we talk about sports games. After all, interaction with the player is not the only thing that we need to care about; most sports involve multiple players, all of whom need to be ‘realistic’ for a sports game to work well.
With this problem in mind, developers started to improve the individual behaviors of each character, not only for the AI that was playing against the player but also for the AI that was playing alongside them. Once again, Finite State Machines made up a crucial part of Artificial Intelligence, but the decisive element that helped to cultivate greater realism in the sports genre was anticipation and awareness. The computer needed to calculate, for example, what the player was doing, where the ball was going, all while making the ‘team’ work together with some semblance of tactical alignment. By combining the new features used in the stealth games with a vast number of characters on the same screen, it was possible to develop a significant level of realism in sports games. This is a good example of how the same technologies allow for development across very different types of games.
How AI enables a more immersive gaming experience
A final useful example of how game realism depends on great AI is F.E.A.R., developed by Monolith Productions. What made this game so special in terms of Artificial Intelligence was the dialog between enemy characters. While this wasn’t strictly a technological improvement, it was something that helped to showcase all of the development work that was built into the characters' AI. This is crucial because if the AI doesn't say it, it didn't happen.
Ultimately, this is about taking a further step towards enhanced realism. In the case of F.E.A.R., the dialog transforms how you would see in-game characters. When the AI detects the player for the first time, it shouts that it found the player; when the AI loses sight of the player, it expresses just that. When a group of (AI generated) characters are trying to ambush the player, they talk about it. The game, then, almost seems to be plotting against the person playing it. This is essential because it brings a whole new dimension to gaming. Ultimately, it opens up possibilities for much richer storytelling and complex gameplay, which all of us – as gamers – have come to expect today.

• Solved: didn't think clearly and realized I can't just compare the cross-product with 0,0,0.
Fixed by doing this:
float3 originVector = float3(0.0, 0.0, 0.0) - v1.xyz; if (dot(cross(e1, e2).xyz, originVector) > 0.0) { //... } I'm trying to write a geometry shader that does backface culling. (Dont ask me why)
What I'm doing is checking the cross-product of two edges of the triangle (in NDC space) and checking if it's facing 0,0,0 .
The problem is when I compile I get this error:
this is i guess because if it isn't facing us, I dont append any verts to the stream. I always assumed maxvertexcount implied I can emit as few verts as I like, but I suppose not.
How do I get around this?

struct GS_IN_OUT { float4 Pos : SV_POSITION; float4 PosW : POSITION; float4 NorW : NORMAL; float2 UV : TEXCOORD; }; [maxvertexcount(3)] void GS_main( triangle GS_IN_OUT input[3], inout TriangleStream< GS_IN_OUT > output ) { //Check for backface float4 v1, v2, v3; v1 = input[0].Pos; v2 = input[1].Pos; v3 = input[2].Pos; float4 e1, e2; e1 = v1 - v2; e2 = v1 - v3; if (dot(cross(e1, e2).xyz, float3(0.0, 0.0, 0.0)) > 0.0) { //face is facing us, let triangle through for (uint i = 0; i < 3; i++) { GS_IN_OUT element; element = input[i]; output.Append(element); } } }

# BMFont: Different results with forcing zero offsets

## Recommended Posts

Hello,

I'm using BMfont to create a Bitmap font for my text Rendering. I noticed some strange behaviour when I use the option "force Offsets to Zero".

If I use this option my rendering resultions looks ok, but without it, there is some missing space between some characters.

I attached the BMFont configuration files and font that I used.

In the rendering result with variable Offset you can see that there is missing space right next to the "r" letter.

To get the source and destination of my render rectangles I basically to following:

void getBakedQuad(const fontchar_t* f, int* x_cursor, int * y_cursor, SDL_Rect* src, SDL_Rect* dest) {

dest->x = *x_cursor + f->xoffset;
dest->y = *y
_cursor + f->yoffset;
dest->w = f->width;

dest->h = f->height;

src->x = f->x;
src->y = f->y;
src->w = f->width;
src->h = f->height;

}

Has somebody noticed a similar behaviour?

orbitron-bold.otf

variable_offset.bmfc

variable_offset.fnt

zero_offset.bmfc

zero_offset.fnt

##### Share on other sites

I see nothing wrong with the generated font files in either case. For this particular font there shouldn't be any difference between the two. When forcing the offsets to zero BMFont will embed the offsets within the quads themselves, and inspecting the font files I can see that this was done.

The difference you see might be a case of rounding errors when drawing the text. Either with the texture coordinates, or the placement of the quads on the screen.

For reference, here's the code I use to draw text with:

void CFont::InternalWrite(float x, float y, float z, const char *text, int count, float spacing)
{
if( render->GetGraphics() == 0 )
return;

int page = -1;

y += scale * float(base);

for( int n = 0; n < count; )
{
int charId = GetTextChar(text, n, &n);
SCharDescr *ch = GetChar(charId);
if( ch == 0 ) ch = &defChar;

// Map the center of the texel to the corners
// in order to get pixel perfect mapping
float u = (float(ch->srcX)+0.5f) / scaleW;
float v = (float(ch->srcY)+0.5f) / scaleH;
float u2 = u + float(ch->srcW) / scaleW;
float v2 = v + float(ch->srcH) / scaleH;

float a = scale * float(ch->xAdv);
float w = scale * float(ch->srcW);
float h = scale * float(ch->srcH);
float ox = scale * float(ch->xOff);
float oy = scale * float(ch->yOff);

if( ch->page != page )
{
render->End();
page = ch->page;
render->GetGraphics()->SetTexture(pages

);
}

render->VtxColor(color);
render->VtxData(ch->chnl);
render->VtxTexCoord(u, v);
render->VtxPos(x+ox, y-oy, z);
render->VtxTexCoord(u2, v);
render->VtxPos(x+w+ox, y-oy, z);
render->VtxTexCoord(u2, v2);
render->VtxPos(x+w+ox, y-h-oy, z);
render->VtxTexCoord(u, v2);
render->VtxPos(x+ox, y-h-oy, z);

x += a;
if( charId == ' ' )
x += spacing;

if( n < count )
}

render->End();
}


The complete code can be found here: http://svn.code.sf.net/p/actb/code/trunk/source/gfx/acgfx_font.cpp

Regards,
Andreas