Trending Games | World of Warcraft | Overwatch | The Division 2 | Albion Online

    Facebook Twitter YouTube Twitch.tv YouTube.Gaming Discord
Register
Quick Game Jump
Members:3,840,296 Users Online:0
Games:949 

Show Blog

Link to this blogs RSS feed

IfThen Software

Development log for IfThen Software. IfThen Software is a family owned and operated indie game development company. http://www.ifthensoftware.net/

Author: InvisibleLf

Newsletter #80 - Time of Intersection

Posted by InvisibleLf Thursday March 24 2011 at 3:08PM
Login or Register to rate this blog post!




News

The sixth demo of the SHMUP has been released.  For details, click here.

The SHMUP is now officially an IfThen Software project.  http://www.ifthensoftware.net/forums/index.php?showtopic=2231.


From the Programmer
Written by Invisible

Last week I was stuck on what should have been a simple problem: Calculating the time at which two objects will intersect.  The objects in question have constant velocity, so that helps simplify things a bit.  My original plan was to set both object's motion formulas equal to each other and solve for time.  This would have worked splendidly, if not for the fact that division is undefined for vectors...  It was impossible to get time alone on one side of the equation.  The breakthrough which helped me finally solve this problem was the realization that both objects are moving parallel (along the same line).  This allowed me to get rid of the vectors and use the well known equation d = r*t.  In order to use that equation, I needed one of the objects to be stationary so I calculated the relative velocity of one of the objects.  vrel = va - vb  vrel is the relative velocity of object a with respect to object b.  So the final equation became: t = |(rb - ra)|/|vrel|  where ra and rb are the positions of the objects.

I still don't know how I would handle this if the velocities are not parallel.  I'll have to tackle that eventually, so you may be able to read the solution in a future newsletter issue.

It appears as though the alpha component of specular is not added to the color like the red, green, and blue components are.  This was unfortunate, since a certain visual effect was depending on it.  We eventually got a similar effect in another way though.  From what I have read, the alpha component is largely (and possibly only) used for fog calculations.  It is possible that this could be taken advantage of and used to get the desired effect, but I did not have enough time to research that.  It is worth keeping in mind though.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #38

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

For the latest SHMUP demo, Jay created yet another video:


If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

ace: I'm hanging up a sweater, and my closet is organized from most like a trench coat (a trench coat) to least like a trench coat (a travel toiletries case that functions as a gameboy case)

Newsletter #79 - Heightmap Tool Complete

Posted by InvisibleLf Friday March 18 2011 at 5:04PM
Login or Register to rate this blog post!




News

The fifth demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.


From the Programmer
Written by Invisible

The heightmap tool is finally finished!  Since I decided to use the arrow keys rather than the mouse to move the tile selector, the tool was completed easily.  The tool isn't very well optimized (every tile in the map is being rendered) but it runs fast enough to get the job done.  The one tricky bit I ran into was making the selector turn green when behind tiles.  I eventually got it to work by checking for intersection between the selector and any tiles with the same x coordinate as it, but a lower y coordinate (in map space, not screen space).

The one big feature I added to the SHMUP was the mission selection screen.  The dotted lines in particular were somewhat difficult to code.  I ended up storing a dotted line graphic in a texture, which is then attached to a quad.  One end of the quad is attached to the mission's starting point and the whole thing is rotated around to point at the mission's destination.  The angle for this rotation is calculated by taking the dot product between the unit vector pointing from the mission's initial position to its final position and the unit vector i=(1, 0).  This dot product is the cosine of the angle between the two vectors, so the angle is calculated by using acos().  This will only return an angle between 0 and 180 degrees though, so we need to figure out which half it is in.  This is done by performing another dot product, this time against the unit vector j=(0, 1).  If this dot product is less than 0, the following is used to recalculate the angle: angle = PI + (PI - angle).  The line changes its length by modifying the width of the quad based on a "path progress" percentage.  I will probably change that last bit in order to get a certain effect though.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #37

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

In the past few weeks, several players have begun playing Volund. The source of this income of players is unknown, but we are glad they decided to play.

Jay made another video spotlighting the SHMUP:


If you have anything you would like to say in the next community spotlight article, please post it here.

Newsletter #78 - Moving Enemy Ships

Posted by InvisibleLf Thursday March 10 2011 at 12:30PM
Login or Register to rate this blog post!




News

The fourth demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.


From the Programmer
Written by Invisible

I spent the majority of last week working on the alien ship's movement.  They needed to enter the screen and then circle around in front of the player's ship, both in an effort to avoid the player's shots and to hit the player's ship with their own projectiles (a moving target is difficult to hit).  There are several ways you can go about this, and it took me a while to both discover those systems and try them out.  These are some of the systems which I found: track, track and spring, move commands, waypoints, and a waypoint track.

Track
With this system, the alien ship would be on a fixed track.  This fixed track would most likely be determined offline by the designer.  The ship has a specific shape which it is following, setting its position to exactly match that shape.  For example, if you wanted the ship to fly down the screen from the top to the bottom, you would use a line beginning at the ship's starting point and ending at the bottom of the screen.  The most useful shapes would probably be lines, line segments, circles, ellipses, and curves.  These shapes could be strung together to make more complicated shapes, and thus more interesting movement patterns.  The disadvantage of this system is that the ship will be very rigid.  For example, you can't knock the ships back when they get hit by a projectile.  This could be solved by using an animation to give the illusion of the ship being knocked back.

Track and Spring
A modification to the track system.  This method attaches the ship to the track with a spring.  The spring fixes the inflexibility issues which the track system had, allowing ships to be knocked back, and jostled around in general.  The spring causes the ship to... Well, spring back to where it is supposed to be.  Unfortunately, this can cause the ship's movement to become too bouncy, flinging the ship back and forth as the track it is on curves this way and that.  This is the system I ultimately decided to use, but I made the springs heavily dampened to prevent excessive bouncing.

Move Commands
With this movement system, you have an AI which controls each alien ship in the same way that the player controls his ship.  The AI examines the state of the game and decides which way the ship should be moved.  Once the AI knows what it wants to do, it sends the appropriate commands to the ship it is controlling, just like the player sends commands to his ship by pressing keys on the keyboard.  This will ideally result in the best possible movement.  The main disadvantage with this system is that the AI can be very difficult to program.  I tried this system, but coding the AI would have been too big of a job for this project.

Waypoints
Each ship has its own list of waypoints.  These waypoints form the shape that the ship should move in, and can be easily updated to reflect changes in the game.  For example, the alien ship can follow the player's ship simply by having its waypoints move along with the player.  The alien ship has its velocity set so that it moves towards its next waypoint.  When that waypoint has been reached, it moves on to the next, and the next, etc.  A waypoint list can either loop around when the end is reached, or load another waypoint list.  Being able to load different waypoint lists makes movement more flexible, and editing the waypoints list in real-time is easier.  This system is flexible enough to allow the ship to be jostled around as much as you want, and it will still make its way towards its target.  The disadvantage to this system is that it forms rather rough and jagged paths.  You can smooth them out by adding more waypoints, but it will be difficult to get it as smooth as it would have been if a track had been used.

Waypoint Track
This is a combination of the track system and the waypoints system.  Basically, you have a waypoints list which contains a single waypoint, and the list is set to loop.  This waypoint is moved along the track as long as the ship is at the waypoint.  I did not get the chance to try this exact system myself, but it seems like a "best of both worlds" solution.  Unlike the track system, this allows the ships to be knocked around.  This also takes advantage of the smoothness which the track system provides.  This could be thought of as a very dampened track and spring system, but you do not need to worry about the high accelerations which are caused by being too far from the track.

I am sure this is not a list of every single option available, but I hope it helps anyone who is currently interested in this.  Another thing to keep in mind when choosing a movement system is how you want the game to feel, and how the ships should act.  If the ship is a scary attack drone, using a very fast speed and the waypoints system would give the effect of sharpness and decisiveness.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #36

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

Another week, another video; Jay has created yet another video showing off the latest SHMUP demo:


If you have anything you would like to say in the next community spotlight article, please post it here.

Newsletter #77 - Destroying Aliens

Posted by InvisibleLf Friday March 4 2011 at 9:23AM
Login or Register to rate this blog post!




News

The third demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.

Forum account registration has been reopened.
http://www.ifthensoftware.net/forums/index.php?showtopic=2201


From the Programmer
Written by Invisible

We have postponed the heightmap tool which I discussed in the previous newsletter issue.  This is good news for me, since I can work on the fun stuff (destroying alien ships) and I don't need to worry about the problems with the tool yet.  Our artist doesn't need to work on backgrounds right now, so this shouldn't hurt that side of development.

So yes, I worked on making it so that you can destroy alien ships.  I personally think that it turned out quite nicely, and have been found to sit and constantly kill aliens just for the fun of it.  Feedback is part of the reason why they are fun to kill.  When your projectiles hit the alien, it jerks back from the impact and the projectile seems to encounter the alien and explosively disperse into and around it.  When the alien reaches about 30% of its health, there is an explosion inside of it which causes visible damage.  And there is a final explosion when the alien is destroyed.  More can be done of course, most notably the addition of sound effects, but it works well so far.

I ran into a couple problems while making it possible to destroy alien ships.  The first one I remember involved a lot of debugging and turned out to be a somewhat embarrassing oversight.  Your ship's projectiles would appear inside of the alien ship for an instant before colliding with it.  The alien's collision area is large enough to prevent this kind of problem, so that wasn't the issue.  The next thing I investigated was the depth of the projectile with respect to the alien ship; maybe Direct3D was translating it a bit further than I was expecting due to depth?  This was an issue with other things, but it apparently wasn't causing the present problem since the projectiles were given the same exact depth as the aliens and they still penetrated too far.  I eventually thought to check if collision detection was being performed after movement, and found that it wasn't.  Because of this, the projectile was allowed to penetrate the alien ship for a single state (one or two frames) before it was finally detected and removed.

The other issue wasn't a bug, but it was a task I hate dealing with: orientation interpolation.  States are interpolated by the renderer in order to ensure that there is no "jitter".  The "jitter" is caused by an accumulated extra amount of time when updating at a fixed time-step; you eventually create multiple frames at once, and the screen appears to "jit" because of this.  Interpolation is easy, but you run into trouble when you try and do it with Euler angles.  One of the issues is that you could spin around multiple times before reaching what it thinks is the correct destination angle.  Another issue is that the interpolation code may interpolate in the wrong direction.  Fortunately, 3D Math Primer for Graphics and Game Development has a section dealing with this issue, 10.3.4 page 156 which describes a solution.  I recommend reading that section for a proper description, but it boils down to limiting the angles to within 360 degrees (-180 to 180 is what the book uses) and calculating which direction is the shortest path to the destination angle and using that to interpolate.

I am currently tackling the problem of how to control the alien ships.  One idea involves springs, and the other involves a destination position and AI which directs the alien towards that point.  I might discuss this in more detail in the next issue, by which point I should have this solved.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #35

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

Jay has once again made a video featuring the latest demo of Ifthen Software's SHMUP.


If you have anything you would like to say in the next community spotlight article, please post it here.