## Tuesday, June 24, 2014

### AI System Progress

Long time no post. I've been working with M3D LLC to make software for the Micro 3D printer and that has been taking up a lot of my time, but today I had a little bit of extra time so I wanted to do a little coding. I've started designing and build the foundation of the navigation system for my AI engine. Hopefully I'll be able to get the basic stuff done before I go to work at M3D.

## Wednesday, May 21, 2014

### What's Up with Me and the Micro 3D

I've been away for some time now. A lot has changed since my last update. As I've said before, I used to teach English in Korea, but in April, my wife and I moved back to America. Now I've been trying to get back into the swing of things. I want to spend more time coding my game, and for a month, I did that, but since I need money for things like food and a place to live, I decided to get a job. Before I came back to America, I started doing some heavy networking and a 3D artist and designer that I've work with put my name into at this company M3D LLC which makes 3D printers. I've been working there for about 2 and a half weeks so far and like the startup environment. Everyone is very motivated and wants to put together a good product, but some the atmosphere is very relaxed. I guess that's what happens when you like what your doing. We joke around, talk, and do startup things like have barbecues. It's fun. It sometimes feels like a University of Maryland alumni meeting because almost everyone either graduated from UMCP (University of Maryland College Park) or is currently attending. I graduated from there in 2003. There's also an engineer who went to Yale. Yeah. He's pretty smart.

In my spare time, I still do Squared Programming stuff and continue to work on Auxnet. I've gotten a lot of work done on my AI system. For now I've decided to use a finite state machine as a low level framework of the AI system. I want to use the FSM system to develop more complex behavioral systems like planners, hierarchical FSMs, and behavior trees. The initial FSM system is done. Next I want to work on a navigation system that can be expanded to work with different algorithms and different kinds of maps. Then I'll add an extension to the system to allow state logic to be written in AngelScript. Once these things are done, I'll have a solid base. After that, I'll move onto other parts of the game like the animation and weapons systems. Once those are out of the way, I'll revisit the AI system.

In my spare time, I still do Squared Programming stuff and continue to work on Auxnet. I've gotten a lot of work done on my AI system. For now I've decided to use a finite state machine as a low level framework of the AI system. I want to use the FSM system to develop more complex behavioral systems like planners, hierarchical FSMs, and behavior trees. The initial FSM system is done. Next I want to work on a navigation system that can be expanded to work with different algorithms and different kinds of maps. Then I'll add an extension to the system to allow state logic to be written in AngelScript. Once these things are done, I'll have a solid base. After that, I'll move onto other parts of the game like the animation and weapons systems. Once those are out of the way, I'll revisit the AI system.

## Monday, April 7, 2014

### Auxnet: Battlegrounds Progress

I've been making a lot of progress these days. I've just finished most of a major renovation (hopefully the last until release) of the graphics engine. Before I had limited each model to one set of textures (diffuse, normal, effects map), but by artist request, I've added the ability to use a second set for added customizability(not a real word). I've also added the ability to change the colors of models in the engine. This will allow characters to be able to choose there colors. This isn't new earth-shattering technology, but it's a big deal for me.

I'll be moving back to the US tomorrow. Hopefully I'll be able to force my way back into the job market. I guess if things don't work out, I can always move back to Korea, but I'm going to try my hardest at becoming a successful indie developer.

I'll be moving back to the US tomorrow. Hopefully I'll be able to force my way back into the job market. I guess if things don't work out, I can always move back to Korea, but I'm going to try my hardest at becoming a successful indie developer.

## Sunday, March 30, 2014

### Latest - March 31

I've just finished the initial framework of the AI engine. I just need to add some more implementation and I hope to get the AI to move an AI agent around in a few days.

## Friday, March 28, 2014

### Useful Game Programming Videos

Here are some links to some useful programming videos that I've made.

An Intro To Video Game AI for Beginners and Young Programmers

http://youtu.be/wsmMOJj6ETo

Game Engine Modular Architecture Overview - Making a Video Game

http://youtu.be/TZ30H-dDWx4

Game Engine Entity Attachments - Making a Video Game

http://youtu.be/8FWULdNHqJE

An Intro To Video Game AI for Beginners and Young Programmers

http://youtu.be/wsmMOJj6ETo

Game Engine Modular Architecture Overview - Making a Video Game

http://youtu.be/TZ30H-dDWx4

Game Engine Entity Attachments - Making a Video Game

http://youtu.be/8FWULdNHqJE

## Tuesday, March 11, 2014

### New Journal Post on Game AI Engine

I've just added a post on my journal page about the AI engine that I've been developing. I give a lot of details. You can read it here. http://journal.squaredprogramming.com/2014/03/building-ai-engine.html

Building My AI Engine

Building My AI Engine

### Fun Indie Games in Development (playlist)

Fun Indie Games in Development (playlist)

I'm all for support other independent developers. That's why I've decided to put this little playlist together of some good indie games that I feel people should see.

I'm all for support other independent developers. That's why I've decided to put this little playlist together of some good indie games that I feel people should see.

## Wednesday, March 5, 2014

### Code Bits: Linear Equation From Two Points

These days, I've been building a simple 2D physics engine to test with. While I was programming the collision detection, I needed to find the equation of the line between two points. I show a little bit of the Algebra here and write some code. I want the linear equation to be in standard form because I find it to be more useful than slope-intercept form.

Here is the standard form of a 2D linear equation:

\[\begin{aligned} Ax + By + C = 0 \end{aligned} \]

How do we calculate A, B, and C?

Method One: Calculating from Slope-Intercept

One way to calculate A, B, and C is to start with the slope-intercept form of the line and use some Algebra until its in the standard form. The following is the slope intercept form:

\[\begin{aligned} y = mx + b \end{aligned} \] In this form, m is the slope of the line and b is the y-intercept. This is m and b are fairly easy to figure out. For points (x_0, y_0) and (x_1, y_1) \[\begin{aligned} m = \frac{y_1 - y_0}{x_1 - x_0} \end{aligned} \] \[\begin{aligned} b = y_0 - x_0(\frac{y_1 - y_0}{x_1 - x_0}) \end{aligned} \] After filling in the variables and manipulating it so it is in the form whereby the equation equals zero, we get this: \[\begin{aligned} (y_1 - y_0)x + (x_0 - x_1)y + ((x_1 - x_0)y_0 - (y_1 - y_0)x_0) = 0 \end{aligned} \] so ... \[\begin{aligned} A = (y_1 - y_0) \\ B = (x_0 - x_1) \\ C = (x_1 - x_0)y_0 - (y_1 - y_0)x_0 \\ \end{aligned} \]

Method Two:

The second method takes some special properties of the linear equation into account. Notice the picture below:

The direction of the normal vector is the direction of the vector from (x0, y0) to (x1, y1) rotated 90 degrees. A and B in the linear equation can be thought of as a vector whose direction is the same as the normal vector. So we can calculate A and B just by calculating the normal vector. If we normalize this vector (make the magnitude 1.0), it will also be more useful when doing collision detection calculations. C is the dot product of the the normal vector and any point on the line.

Here's the code for method two:

Here is the standard form of a 2D linear equation:

\[\begin{aligned} Ax + By + C = 0 \end{aligned} \]

How do we calculate A, B, and C?

Method One: Calculating from Slope-Intercept

One way to calculate A, B, and C is to start with the slope-intercept form of the line and use some Algebra until its in the standard form. The following is the slope intercept form:

\[\begin{aligned} y = mx + b \end{aligned} \] In this form, m is the slope of the line and b is the y-intercept. This is m and b are fairly easy to figure out. For points (x_0, y_0) and (x_1, y_1) \[\begin{aligned} m = \frac{y_1 - y_0}{x_1 - x_0} \end{aligned} \] \[\begin{aligned} b = y_0 - x_0(\frac{y_1 - y_0}{x_1 - x_0}) \end{aligned} \] After filling in the variables and manipulating it so it is in the form whereby the equation equals zero, we get this: \[\begin{aligned} (y_1 - y_0)x + (x_0 - x_1)y + ((x_1 - x_0)y_0 - (y_1 - y_0)x_0) = 0 \end{aligned} \] so ... \[\begin{aligned} A = (y_1 - y_0) \\ B = (x_0 - x_1) \\ C = (x_1 - x_0)y_0 - (y_1 - y_0)x_0 \\ \end{aligned} \]

Method Two:

The second method takes some special properties of the linear equation into account. Notice the picture below:

The direction of the normal vector is the direction of the vector from (x0, y0) to (x1, y1) rotated 90 degrees. A and B in the linear equation can be thought of as a vector whose direction is the same as the normal vector. So we can calculate A and B just by calculating the normal vector. If we normalize this vector (make the magnitude 1.0), it will also be more useful when doing collision detection calculations. C is the dot product of the the normal vector and any point on the line.

Here's the code for method two:

typedef float vec2[2]; void Normalize2(const vec2 in, vec2 out) { float inv_length = 1.0f / sqrtf((in[0] * in[0]) + (in[1] * in[1])); out[0] = in[0] * inv_length; out[1] = in[1] * inv_length; } float DotProduct2(const vec2 a, const vec2 b) { return (a[0] * b[0]) + (a[1] * b[1]); } void LineFromTwoPoints(const vec2 p1, const vec2 p2, float &A, float &B, float &C) { // first calulate and normalize a vector from p1 to p2 vec2 dir; dir[0] = p2[0] - p1[0]; dir[1] = p2[1] - p1[1]; Normalize2(dir, dir); // calculate the normal vector of the segment this will be our A and B vec2 normal; A = normal[0] = -dir[1]; B = normal[1] = dir[0]; C = -DotProduct2(normal, p1); }The two methods give the same formula. In method two I make sure the magnitude of the vector (A B) is 1. This can be done using method one as well by dividing A, B, and C by the square root of ((A * A) + (B * B))

## Friday, February 28, 2014

### Latest

I'm hoping to get back into Android programming in a week or so. These days I've been putting a lot of time into the small experimental 2D engine that I've been working on. I've been focusing on PC development, but long term, I want it to also work on Android. I've been putting a lot of time into it because eventually it'll be the test bed for some of the other systems that I want to develop.

Currently the 3D engine, Squared'D, has too many parts to use it as a simple testing platform. I stripped out it's core 2D elements (these were mainly used for the GUI) and built it into a smaller game engine that doesn't require much set up. I'm using the 2D engine for experimentation as well. I've been trying to leverage more C++ features to make development easier. One big design decision was to limit the use of pointers and to use handles and C++ references as much as possible. I want to avoid using shared pointers and limit my code to only a few unique pointers when absolutely necessary. So far so good. I've gotten a component-based entity system working already. Entities only store handles to there components, and all components are stored in an std::vector inside their respective system classes. As I've been playing around with the system though, I think in the future, entities will not even need handles to their components. Entities will eventually just morph into position orientation with the components knowing which entity they belong to, but not the other way around. If it goes well, I'll incorporate these ideas into the next version of the 3D engine. Hopefully I'll be able to simplify things enough so that the next 3D engine will be good for testing and able to run on the PC and Android, but all this will happen after 6 months or so.

Currently the 3D engine, Squared'D, has too many parts to use it as a simple testing platform. I stripped out it's core 2D elements (these were mainly used for the GUI) and built it into a smaller game engine that doesn't require much set up. I'm using the 2D engine for experimentation as well. I've been trying to leverage more C++ features to make development easier. One big design decision was to limit the use of pointers and to use handles and C++ references as much as possible. I want to avoid using shared pointers and limit my code to only a few unique pointers when absolutely necessary. So far so good. I've gotten a component-based entity system working already. Entities only store handles to there components, and all components are stored in an std::vector inside their respective system classes. As I've been playing around with the system though, I think in the future, entities will not even need handles to their components. Entities will eventually just morph into position orientation with the components knowing which entity they belong to, but not the other way around. If it goes well, I'll incorporate these ideas into the next version of the 3D engine. Hopefully I'll be able to simplify things enough so that the next 3D engine will be good for testing and able to run on the PC and Android, but all this will happen after 6 months or so.

## Thursday, February 27, 2014

### New Game Engine Article Posted

I've just posted a new article that gives a high-level overview of my 3D game engine. You can check it out here: Squared Game Engine High-level Overview.

## Monday, February 24, 2014

### Latest - Game Engine Development

I'm hoping to get back into Android programming next week. These days I've been putting a lot of time into asmall experimental 2D engine. I've been focusing on PC development, but long term, I want it to also work on Android. I've been putting a lot of time into it because eventually it'll be the test bed for some of the other systems that I want to develop.

Currently the 3D engine, Squared'D, has too many parts to use it as a simple testing platform. I stripped out it's core 2D elements (these were mainly used for the GUI) and built it into a smaller game engine that doesn't require much set up. I'm using the 2D engine for experimenting with different programming concepts and paradigms as well. I've been trying to leverage more C++ features to make development easier.

One big design decision I made in the 2D engine was to limit the use of pointers and to use handles and C++ references as much as possible. I want to avoid using smart pointers and limit my code to only a few unique pointers when absolutely necessary. So far so good. I've gotten a component-based entity system working already. Entities only store handles to there components, and all components are stored in an std::vector inside their respective system classes. As I've been playing around with the system though, I think in the future, entities will not even need handles to their components. Entities will eventually just morph into position orientation with the components knowing which entity they belong to, but not the other way around. If it goes well, I'll incorporate these ideas into the next version of the 3D engine. Hopefully I'll be able to simplify things enough so that the next 3D engine will be simple enough for testing and able to run on the PC and Android. Major changes to the 3D engine will be long in the future. If you're curious about why I've chosen not to limit pointer use in newer versions of my engines, you can leave a comment.

I'm currently working on an article and video that will give details on how both the 2D engine and the 3D engine work.

## Thursday, February 13, 2014

### New Journal Entry - "Indies--Stop Treating Your Ideas Like Classified Secrets"

One of the most important lessons that I've learned is indies shouldn't be concerned with keeping their game ideas secret and that it's much better when indies let others know about their ideas.

....

For the complete entry: http://journal.squaredprogramming.com/2014/02/secrets.html

....

For the complete entry: http://journal.squaredprogramming.com/2014/02/secrets.html

## Wednesday, February 12, 2014

### Latest Updates

I've been doing a lot of page restructuring this past week. I've decided to divide my page into three sections. The base squaredprogramming.com domain will be my main site. Here I'll give information on my current projects and other news. I've also started a articles.squaredprogramming.com sub-domain and a journal.squaredprogramming.com sub-domain. Inside of articles, I'll post all of my game development and general programming articles. the journal sub-domain will be more free. I'll use it to post my thoughts on certain topics.

Subscribe to:
Posts (Atom)