Blog for Greg Tedder at GarageGames.com

The constant tweak of an RPG

Greg Tedder — 2008-09-14T23:55:22+00:00

I have been so busy I didn't notice May was my last post here. But before I start rambling about that I had better move on. Anyway, I have been somewhat level building while tweaking several elements of the RPG I am making in TGB. I am in a hurry to get this project done, but I have trouble just letting things go. My biggest nagging concern for the last month has been wall clearance and visibility in dungeons and houses. I tried a really quick distance based fading approach, but it just never felt right and looked sloppy. I finally decided to implement a method of checking the characters wall-side and changing frames to a chopped down wall frame that allows full visibility of the room. I am very pleased with the results and really need to get this code ported over to a slower machine to check the performance hit. On my macbook the performance hit is almost unnoticeable.

If anyone is interested, here is the wall-side check for TGB with y positive to the bottom of the screen. I simply check the angle from the walls sort point to the players sort point, see if it is greater than the upward angle and less than the downward angle of the wall. Since it is a fixed isometric perspective the wall angles are always the same.

        // Get an angle from wall sort point to player sort point
	%pos1 = $player.getWorldPoint(($player.getSortPointX()), ($player.getSortPointY()));
	%pos2 = %this.getWorldPoint((%this.getSortPointX()), (%this.getSortPointY()));
	%vec = t2dVectorSub(%pos2, %pos1);
	   
	// get the angle between both positions   
	%angle = -mRadToDeg(mATan(getWord(%vec,0),getWord(%vec,1)));
	
	//error(%angle);
	%frame = %this.getFrame();
	
	if(%frame == 0 || %frame == 2) {
		if(%angle > 63.435 || %angle < -116.565) { // full wall
			%this.setFrame(0);
		} else {
			%this.setFrame(2);
		}
	} else if(%frame == 1 || %frame == 3) { // shrunken
		if(%angle > 116.565 || %angle < -63.435) {
			%this.setFrame(1);
		} else {
			%this.setFrame(3);
		}
	} else if(%frame == 4) { // door
		if(%angle > 63.435 || %angle < -116.565) { // full wall
			%this.setBlendColor(%this.savedBlendColor SPC "1");
		} else {
			%this.setBlendColor(%this.savedBlendColor SPC "0.5");
		}
	} else if(%frame == 5) { // door
		if(%angle > 116.565 || %angle < -63.435) {
			%this.setBlendColor(%this.savedBlendColor SPC "1");
		} else {
			%this.setBlendColor(%this.savedBlendColor SPC "0.5");
		}
	}

As evident I also added some lighting. I did absolutely no programming on lighting, it is all artwork and blending effects available in the scene editor. Every now and then TGB and I duke it out on an issue, but the results always prove to be worth it. I am currently trying to keep myself talked out of trying shadows and "REAL" lighting and effects as I would really like to complete this project before next summer.

Flat Tile to Isometric

Greg Tedder — 2008-05-25T01:24:45+00:00

I just tried to put this on the forums, but it was too big, so I put it here.

I finally broke into the code this weekend. I have barely touched C++ in the last 3 years and was surprised at how easy it was to jump into. So, as my first little stab at getting used to the source, I decided to play with the quad rendering in t2dStaticSprite and t2dAnimatedSprite. I wanted to see how an isometric textured quad would render compared to an actual isometric tile. I don't know which I really like better, so I am probably going to go with the new technique. I also spent several hours trying to track down the script that managed editing it in the level editor, so it's as easy as checking a box to try it out.

First off, add these members and methods to t2dStaticSprite.h:

bool                            mIsometric; // with the others at top

bool setIsometric(bool isISO);   // put in the public area
bool getIsometric();

Now go to t2dStaticSprite.cc and add these:

ConsoleMethod(t2dStaticSprite, setIsometric, bool, 3, 3, "(bool isometric) - Sets the tile to isometric.\n"
                                                         "@return Returns true on success.") 
{
 //object->setVisible( dAtob(argv[2]) );
  // bool iso = (bool)argv[2];
   object->setIsometric( dAtob(argv[2]) );
   return true;
}
bool t2dStaticSprite::setIsometric(bool mISO) {
   mIsometric = mISO;
   return true; // you might actually want to check something here :-)
}


ConsoleMethod(t2dStaticSprite, getIsometric, bool, 2, 2, "() - Gets whether or not this is an isometric tile.\n"
                                                         "@return (bool isometric) The boolean.")
{
   return object->getIsometric();
   
}
bool t2dStaticSprite::getIsometric() {
   return mIsometric;
}

In the renderObject method, we need to change how the quad is rendered when isometric is checked. So change that small block of quad rendering code to include this logic and add the isometric rendering code below.

       if(!mIsometric) {
		    // Draw Object.
          glBegin(GL_QUADS);
            glTexCoord2f( minX, minY );
            glVertex2fv ( (GLfloat*)&(mWorldClipBoundary[0]) );
            glTexCoord2f( maxX, minY );
            glVertex2fv ( (GLfloat*)&(mWorldClipBoundary[1]) );
            glTexCoord2f( maxX, maxY );
            glVertex2fv ( (GLfloat*)&(mWorldClipBoundary[2]) );
            glTexCoord2f( minX, maxY );
            glVertex2fv ( (GLfloat*)&(mWorldClipBoundary[3]) );
          glEnd();
      } else {
          // Draw ISO Object
          glBegin(GL_QUADS);
            glTexCoord2f( minX, minY );
            t2dVector v = ( getHalfSize() );
            F32 x = (mWorldClipBoundary[0].mX) + v.mX;
            glVertex2f( x, mWorldClipBoundary[0].mY );
            glTexCoord2f( maxX, minY );
            F32 y = (mWorldClipBoundary[1].mY) + v.mY;
            glVertex2f( mWorldClipBoundary[1].mX, y );
            glTexCoord2f( maxX, maxY );
            x = mWorldClipBoundary[2].mX - v.mX;
            glVertex2f( x, mWorldClipBoundary[2].mY );
            glTexCoord2f( minX, maxY );
            y = mWorldClipBoundary[3].mY - v.mY;
            glVertex2f( mWorldClipBoundary[3].mX, y );
          glEnd();
       }

Now there is another method called initPersistFields where we need to add this code. I commented out the last part because I kept getting errors and never figured it out, but this much works for all points and purposes.

addField("isometric", TypeBool, Offset(mIsometric, t2dStaticSprite) );//, &setIsometric, &defaultProtectedGetFn, "" );

Just one more stop in the code, and then we get to editing TGB's editor forms. You need to add the last line 'mIsometric(false)' to the constructor to make it read like this.

t2dStaticSprite::t2dStaticSprite() :    T2D_Stream_HeaderID(makeFourCCTag('2','D','S','S')),
                                        mImageMapDataBlock(NULL),
                                        mImageMapDataBlockName(NULL),
                                        mFrame(0),
                                        mIsometric(false)
{
}

Now go into the Torque game builder directory and navigate to: tgb/tools/levelEditor/scripts/forms/quickEditClasses/t2dStaticSprite.ed.cs. In the CreateContent method, add this line before the function returns.

%rollout.createCheckBox ("Isometric", "Isometric", "Is this isometric");

That should be it. Now you can take a square tile and render it with an isometric look by checking the Isometric check box in the level editor. To do this to t2dAnimatedSprite, just follow the exact same steps. You will find an exact replica of the quad rendering code there, and the level editor script for animated is found in the same directory as for the static.

This was all done on a mac, so I am not completely confident in it working with Visual Studio.

Will Macintosh Intel Graphics Work for TGB

Greg Tedder — 2008-03-04T11:56:56+00:00

IMPORTANT: These are not the problems of TGB, these are the problems with Intel Graphics! I am simply writing this as a guide to any debating purchasing a Mac w/Intel Graphics. While I have had a good experience, I took a chance buying Intel Graphics, and you will be too if you choose to purchase them.

I thought I would post this here because I spent hours on this site searching for a definite answer. The truth is, I am now unconvinced as to whether there is a definite answer. The answer I have found using the intel GMA X3100 graphics card is yes. TGB works good, and it works fast with a few odd errors that most likely have something to do with multiple viewports in OpenGL.

What happens with the graphics is a slight bleed over out of the programmed boundaries. For instance, the scene editor window graphics have a tendency to bleed into tool bar. Luckily, the mouse picking works correctly, and the toolbar button is pressed rather than a graphic is selected. This may turn a few off, but I have yet to find this troublesome.

The other viewport error that happens a lot is with text. It is very similar to the other error, with the exception that occlusion does not trim the bleed over to the right. The only time this is really apparent is when you bring up the console.

Bottom line, if you are going to be programing your own multiple viewports into the engine, you may need to look into a higher end mac. I am not 100% that this is the problem, but from past experience this is what it looks like to me. So unless Intel updates their drivers some time soon, this problem is going to persist.

Aeges Road Alpha Testing

Greg Tedder — 2008-03-02T20:19:25+00:00

Aeges Road is now ready for public alpha testing. There are alphas available for Mac and Windows. The art in this game is not complete, so there is just one test level at this time. There are two AI's in this dungeon. The bats are very low level and should off a well balanced fight for an un-leveled character. The look-a-like is an even match, making it a bit more of a challenge.

Everything is done with the mouse right now. Right click or ctrl+click to bring up the game menu. The game menu includes saving, inventory, and other options. It is not available during combat. Combat menus pop up when it is your turns. Turns are based on timers. The more you do in a turn, the longer you wait for your next turn.

The combat menus are set up mobile so they don't block your view of the action. They will follow the mouse around as smoothly as possible. Movement is click based right now. You can drag the mouse and keep paths coming, but mouse hold steering is not available yet.

There are three weapons available. The currently equipped weapons are two daggers and a short bow. You can also find a sword and two other items. Casts are not available right now, but they follow the same patterns of Items and Attacks.

Stats skills and classes are not locked to experience yet, so you can edit them to your hearts content. Some skills do not exist yet. They are set up on a framework for extensibility, so there may be more available in the final release.

Here is the main alpha testing page. http://www.codeugly.com:12001/aegesroad

A Thought on Saving the Game

Greg Tedder — 2007-12-31T22:04:40+00:00

The power of a scripting language is a beautiful thing. While you can stand to loose a few FPS, the flexibility that comes with a scripting language versus that of a compiled language is in itself powerful. Take for example, naming multiple gui components in the gui editor and then accessing them as an array from the engine. While treating the names exactly as an array will throw an error, simply concatenating the numbers in the proper place will render the variable name in real time. So when trying to come up with a way to save the game, I have decided to go with the obvious. While this has yet to be fully tested, it should give enough theory to help anyone get started on saving a game.

Writing out a file has rarely been a problem. It is reading the file back in that tends to carry the work load. In any language, reading a file back in line by line can be a tedious process. The last file I remember writing a reader for was the AC3D files format, which is one of the cleanest file formats I have ever seen, but still not a joy to work with. Even using XML and their parsing API's can put more work on the plate than any one programmer could want.

This brings me to a solution I imagine many developers use. Since I am writing my game in TorqueScript, why not save the game into a TorqueScript file. My thought is to write out a TS file with single line commands that can be evaluated line by line when loading the game. All of the needed save variables will be contained within a series of four or five global sets which will make loading and saving easy. A lot of the repetition can be written in set functions rather than saving it all out to the file each time.

There is also the possibility of compiling the written cs file in order to preserve data integrity in multiplayer games where cheating effects other players. Of course, there are many that feel it is important to keep cheating out of single player games, and I am unsure of how I feel on the topic at this point. Before this week is over, I hope to have this fully tested.

As it is with Aeges Road

Greg Tedder — 2007-11-04T22:30:27+00:00

This is a long post to give a good outline of where Aeges Road currently stands. Things are looking good, but I have been feeling the time crunch for the last two months. I might even get an ulcer if I am not level building come December. :-) Looking back, I can see that my biggest problem was that I had no experience in many of these areas, and developing balanced tactical combat has taken longer than I expected.

This weekend marked the half way point in the game competition in which I have Aeges Road entered. It was interesting to see the feedback on all of the projects, and very humbling to see so many incredible teams and individuals working so hard towards this. If you haven't taken a look at all of these projects, than a visit is necessary, go here.

Recently I posted some oddity item artwork, and after several comments I have gotten, I am just as surprised as I am excited to say that this is the direction I am taking with the equipment artwork. As a note, I liked it, I wanted it, but I was skeptical as to whether I could sell it, literally sell it. :-) Now I feel a bit of optimism shining through the clouds, and I am going with it. My original plan was to have these items as part of the Weird Eddies collection in the Chalt Village. Oh well, maybe Eddie can design some high heal hiking boots or something?

On other artistic notes, unless I change my mind again, I am going with the original tile set look and feel for the game. It has a bit of a mid-90s RTS look to it. I always liked the RTS tiles sets, they usually just lacked good scenery, though a few really stood out. Stat and inventory screens have changed significantly, and so have the combat screen controls. I felt that what I had was a bit to hard to manage for a new user, and simplified things with a dedicated stat and inventory screen. For some reasons I had grand illusions of a console release early on, then realized I need to cater toward my current platform first and foremost.

AI is fully working, with just a few bugs right now. It uses a heuristic approach to terrain, and enemy placement and weighs the risks and rewards of each possible move. I think I have located the worst bugs as being directly located in both the path finding and the range finding algorithms. I have an algorithm on paper that will soon replace the range finding algorithm, and the oddball A* is solid theory, I think I am just missing something which will hopefully show itself during beta testing. Luckily, this hard to locate bug is not a show stopper, it just causes unresponsiveness sometimes, and the occasional silly path. I think the silly path has to do with an error in the terrain preprocessing (sorry, I'm running out of angles, and I have no one else to blame). :-)

After play testing my old rule set against two AI algorithms (the first AI was boring, but solid), I found it be pretty much a gamble rather than progress and tactical. While there needs to exist that gamble that adds to the anxiety and possible consequences of each action, there does need to exist some consistency as well. The ability to tactfully give yourself an advantage, or the ability to realize you are at a disadvantage is important to me. It helps bring skill into the game. So I decided to keep base stats and professions, but I completely changed their purpose with a complete rewrite of the derived stats system and the skill system.

While this is still in development, I have not posted a screen shot in a while, so I can't help myself. As you can see, things have really changed. There is a new five elemental system that is used to determine both physical and elemental combat modifiers. It also changed the way professions and equipment are used in terms of tactics. Professions are a bit more static in their level ups, giving them more obvious strengths and weaknesses. Weapons and armor are now modifiable through gem slots. Here is a screen shot of the inventory system in action. Currently, the gem slots are not in operation, but that will change very soon. The rest of the inventory system is almost fully functional. I just need it working with the characters and updating stats, which will happen when I finish the stats portion of the project.

Of course, character creation is taking on a rewrite, but it will actually be simpler than the old method, making it easier for a player to customize and get into the game. With 100 levels possible per character, this will give the player plenty of customization options throughout the game. One possible problem that may arise later on in the game, is that a part full of jack of all trades will have difficulty overcoming enemies who are specialists. While the idea of the game is to bring a bit of balance to both tactics, the bottom line is that math eventually finds its limits as Enron and World Com found out. :-)

The story line is shaping up, and sequel and prequel notes are being kept in order to offer an intriguing series rather than a loosely knit set of games loosely based on a similar concept. I may eventually do the latter, but trilogies seem to be a popular thing. I still have no building art to speak of. I have a bit of dungeon art and a level mock up. I have quite a bit of out doors art. I have some character art, I have stopped to spruce up the animations a bit before continuing use of my template. The few characters I have are all NPCs, and will be usable for the game since I did not have to update their animation frames.

I currently do not have save game functionality. I do have a file template wrote up, pretty much a simple markup type language used to save variables and arrays to file. Level building is waiting for more artwork, but I have general guides made up to help me structure the outdoor map which will greatly speed things up. The structure is based on the game map, so with some luck, the game map will be usable in game with just a few modifications. I also need to re-write the level transition and spawning code.

Music is still in the air, though I think I can do it myself. I am waiting until later in the project to make sure everything else is done first. I have six songs noted down for possible tracks in case I don't have time to make my own. Sound effects will most likely be purchased. I have very little experience with wave form, and don't have time to get creative with it. Particle effects are still needed, but I have some fun ideas. I programmed some cool particles in Java once for a PLAF I never finished because I was afraid I would give someone epelepsie (like me). I called it Drop, because its biggest feature was that it would make ripples when you were typing or moving the mouse over it. I may dig those up and try and port them over to torque.

The main parts of the website are just waiting for me to fill with content. This weekend I finally got the template finished, and working on IE 6 no less. The forums, games sales, and possible blog integration will be added as I get more acquainted with Ruby on Rails. Nice framework for anyone looking into MVC application development.

So this is where Aeges Road stands. Come test time in March, I may still have some place holder art in the levels. I will also probably wait until then to work out my AI issues, because none of the problems are show stoppers and I can currently play my game without any crashes. Some errors I expect are just bad heuristic calculations that in making these simple fixes, I will get re-acquainted with the code easily.

Aeges Road, The Time Draweth Nigh

Greg Tedder — 2007-08-26T21:27:42+00:00

Aeges Road is still in hot (probably more of a luke warm) development. It seems like only yesterday I started, the weeks have just flown by and the deadline is drawing near all too fast. This past month has been extremely exciting. Artwork is in process, combat is in process, and path finding is improved and working across multiple isometric levels. So what could be better than this. Having all this done weeks ago. :)

Looking back I can see the mistakes made in time management. Planning did not take off, I started with a fresh new idea and it took months of trial and error work to nail everything down. Most notable of time wasters was the graphics. Another time waster was my original professions list. It was great, but too big. I had to shrink it in order to budget time. In shriking the professions list, I had to redo the skills list as well as the item details. Overall, it seems to be a good call, but only time will tell.

A few things I was really wanting to do is going to have to be hired out or purchased. I am a musician, but I just don't have the time to pull off a quality sound score for the game. If by some chance things change I was be extatic, but I have something else in mind as a fallback. Sound effects are deffinately going to be purchaced, I just can't make a clashing steal sound with my armpit into a computer mic. :-)

So here the project goes into September, and the goal is to finish up all major elements of the script and start on graphics and level design. Here is an update of where the project stands.

Planning: 90%
Rule System: 90%
Character Creation: 80% (Took a serious setback with the profession changes)
Level Up: 50%
Inventory Management: 40%
Character Graphics: 10% (Finally! :-)
Terrain Graphics: 5%
Item Graphics: 0%
Path Finding: 100%
Path Following: 90%
AI: 10% (This was interesting)
Storyline: 20% --> On paper anyway.
Combat: 30%
Level Design: 3% -->
Sound: 5%
Music: 5% --> I have some very low quality scores done

Overall: 39%

Well, talking about it isn't getting it done. :-)

Finding My Way Around

Greg Tedder — 2007-07-23T03:24:07+00:00

The past two weeks have definitely been an educational journey. Getting path finding to work took a while, but after a week I was able to get it refined and polished for collision detection on a flat surface. This week I have been busy making severe modifications to the path finder in order to have multiple levels on the map.

Getting the height based path finding to work was a trick, but fairly easy. The hard part has been getting path following to work with the multiple height terrain. I am now in the process of re-writing the entire structure I have been using in order to handle player movement. The new method makes for much smoother movement, and much more accurate path completion. The problem is weeding out all the old methods that are working against the new system.

I expect to spend the week tweaking and modifying the system until it resembles something semi-professional looking, and then moving on to artificial intelligence and getting a fight started. It may be a few weeks, but things are looking good.

I have to put in a good work for Sickhead Games TGB add-on pack. The scripts have been truly useful as well as educational. The animated characters that come with the pack are a great time saver. While there are many features I am trimming out and replacing, I would not be anywhere near this point in development right now.

Here is a quick update on a few areas of the game.

Planning: 80%
Rule System: 90%
Character Creation: 100%
Level Up: 50%
Inventory Management: 40%
Character Graphics: 0%
Terrain Graphics: 5%
Item Graphics: 0%
Path Finding: 100%
Path Following: 75%
AI: 0%
Storyline: 15% --> On paper anyway.

Aeges Road

Greg Tedder — 2007-06-03T23:25:14+00:00

Aeges Road is an RPG I have been slowly planning and working on, and I have finally got something to look at. It took a while to design some terrain tiles I was happy with, and took some quick shots to get things rolling. I am now going to crawl back into my cave and hash out some more tiles.

My post and the screenshots are located here at http://www.codeugly.com/blog/.