1) He says that the level summary that is displayed at the start of each level is oddly seeming to be displayed partly in the "More bugs in:" indicator in the upper right corner. I dunno what would casue this, except maybe buffer overruns? I'll look at the code then.

EDIT: ok looks like this just happens at the beginning of the level… as you start… so it's annoying. but not game crashing… I'm working on it.

2) this is not as big a problem, but if we can, James would like if wall segments that block hoses would not be drawn. He thinks that the post of the next tile over that blocks it is enough, and that the wall segment that blocks the hose is not necessary and hurts the game a bit.

Ok then… see you soon!

Are we done? Ready to burn?

Deadline is in 45 mins! hope the art is up soon since I'll need at least a little bit of time to make sure it works right!

It seems to work just fine for me…

What was the screenshot functionality that you had built in, Muhammad? maybe it works better.

So if you would like more than my personal input on what you want after your name in the credits, just tell me here and I'll put em in. Or, if you see how I do it in the code, go ahead and put it in there.

I think it is related to a null pointer exception in loading, but I'm lost in that area.

But, how do we want the credits to cue up? after they finish the final level? Have a button on the menu? What do you think?

Just give me signal when the hose art is DONE for good, then I'll make it at the right spot. Until then, I'm waiting for your cue.

In our code, this is the only place using variable (char) sgf.

/* load savegames definition */
void FileIO::LoadSavegames()
{
savegames.clear();

for (unsigned i = 0; i < 10; i++)
{
char sgf[120];
sprintf(sgf, "%s\\Savegames\\__slot%02d.sav", XMLDirectory.c_str(), i);

savegames.push_back(GetSaveGameInfo(sgf));
}
}

Found a ton of tech forums when I googled "Run-time check failure #2 - Stack around the variable" but it doesn't really mean anything to me.

My computer is like the new benchmark for our game.. If it doesn't crash on this baby then we're golden to operate on anything CSUG can throw at us. ^_~

This is because _currWave is apparently null. I think it has something to do with how RandomWaves are spawned in the long period from the first rat wave to the next almost 5 minutes into the game.

So those of you who worked on the waves… any idea what is going on?

However, I do not yet have a way for the user to modify this value in game, which would be TOTALLY classy and fun. Any way we can fit that into the interface, muhammad? If it can go on the pause menu, I can try implementing the two volume sliders myself.

Since I constructed all 4 directions symmetrically, I'm not sure what is causing this. the code is identical nearly for north, south, east, and west.

James thought it might be one of those "power of 2" bugs… but anybody have a guess? Some stupid mistake I made that I'm missing?

Also, since I was exploiting random spawns pretty heavily for both maps, I sort of balanced out all of our pests, so that the rats weren't crazily overpowered, resulting in devastation when you get randomed rats. I think it's a better idea to try to keep the pests equal overall, rather than having an elite-ness chain of Rat > Roach > Termite. If you guys approve of this, I'll update the Pests section of the Wiki. Here's a short summary of what the pests are like now.

- Rats: small, agile. Fast SPEED, with mediocre HP and ATK.
- Termites: aggressive. Higher ATK, with mediocre HP and SPEED.
- Roaches: defensive tanks. High HP, with slower SPEED and mediocre ATK.
- Spiders: ranged. Mediocre HP, but slower SPEED and lower ATK to balance for range.

I think I might have tweaked Defenses a bit, and also lowered the Wall HP from the inexplicably high values they were before (Stone = 3000hp while pests hit for 15hp??).

Otherwise, work I've been doing will be uploaded late tomorrow since I can't get CVS going on this.

Remember, the three segments are:

1. Initial ideas
2. Development (big topic, likely)
3. End product (probably will be smaller because we'll describe final decisions in the previous topic)

p/s: I'll complete the 't' part to match up with the 'g' when I get bored anytime soon :)

For some reason, the defense animation drawing throws an error becuase it is trying to point to a non-existent defense. I'm not sure why, but I think this happens when a defense dies in a cycle, but no guarantees. A null check, however, doesn't seem to solve it.

This is probably very annoying to you guys, so sorry… for awhile it seemed to be gone, and all of a sudden it's cropping up again.

FileIO.obj : error LNK2001: unresolved external symbol impGetOpenFileNameA@4
FileIO.obj : error LNK2001: unresolved external symbol impGetSaveFileNameA@4
Garden_Debug.exe : fatal error LNK1120: 2 unresolved externals

This was part of the original design, if you remember, but sorta got phased out. Tell me if you like it or not.

Do you know what the usual problem is for this?

Also, James was telling me that he would have the images split up by now… but I think they're still together (as in, all four directions for pests and defenses are still in one image file). James, please tell me if you still intend to split them. I CANNOT PROGRAM ANIMATION until I have the art! For now I"ll assume you're not splitting and I'll work with those.

Question:
How do I fetch the tile associated with each capturepoint, mainly interested in the victorypoint right now, so that I can restrict calculating and drawing of off screen indicators to only when said tile->IsVisible() = false?

The code can pretty much be copy/pasted from the pest and board source files otherwise. But without the IsVisible() check, indicators will most likely display at the edge of screen along the straight line path between the center of the screen and the flag even if the flag is visible.

Here is perhaps a better way to organize the targeting:

• Instead of just storing all the tiles in a vector, also store the center tile. all defenses has center tiles — they are the tiles that the player clicks to finalize the defense. in case of magnifying glass it's the tile the glass is on itself.
• keep and use the targetTiles and potentialTargets like before but the next point is the trick
• store an integer that has the value of the size/range value you use to fill up targetTiles
• every cycle in Defense::Run() compare that integer values with the variable that holds the range value loaded from XML
  • if they are the same then do nothing (and use the tiles pointers in the vectors)
  • if they are not the same, well the fun part, empty and rebuild targetTiles using the stored center tile info and the new range value. then update the integer in the previous point to the new value
• that's all it takes .. it shouldn't be too complicated :)

apart from allowing range changes from XML to be applied to defenses on the board during a gameplay, it also allows the changes to apply to defenses stored in level XML .. and yes, the level XML would be smaller because we don't have to store all the target tiles coordinates there — simply store the target center tile coordinate and … that's it, just one coordinate since the other tiles would be deduced from the range value from global.xml

and wait! there's more! (wow now I really sound like a telemarketer) did anyone notice that hoses loaded from level XML point in the wrong directions? that is because we don't set the direction when we load them but with current way of storing all target tiles, it might be hard to deduce the direction because we have all bunch of tiles there .. but with only one target center tile to look at when we change the defense data structure like I explained above it would be a piece of cake! (an easier alternative is to store the direction in the level XML since target center tiles are fixed)

owh btw, I decided that I won't be the one implementing the changes .. I'm pretty tied up with level editor plus the defense classes look so fragile that if someone that knows little about them tinker with them they will break and we'll get the real post-apocalyptic garden game in no time …

so, anyone up to the challenge?

Plus, it leaves open the possibility of modifying the XML file while we're playing and then reloading it to change the game in real time. Twould be very sweet.

All we need to do is load in the XML values, then set them to what will be global variables in global.h (just change all the #define statements to global vars).

The only problem is (similar to my enum question), how do we convert from a char * that we get from XML parsing into a variable definition. For example, if I parse an XML attribute with name "GLASS_ATTACK_POWER" and value "56", how would I assign that value in global.h without simply calling a big switch statement to find the GLASS_ATTACK_POWER variable? Is there a way to lookup variables based on a character input? Don't want to embark on a lot of work if there's an easy solution, so thanks for the help!

Since I won't be there on account of a family matter, I thought I might at least contribute some by making the balancing a bit more reasonable and constructing a small sequence of levels for them to play through (as in not just our 3 levels right now). Did anybody else plan to do this or is it safe for me to do it after my prelim tonight?

Anyway, download the latest CVS copy and run the game yourself, in both game level and level editor, there is an extra arrow icon at the bottom of the toolbar on the left. Click and hold down the mouse button on that icon and see what pops up :) Play around with it until you get bored.

note to Ben:
I made this interface feature with level editor in mind. would you please list down what kind of icons you want on the toolbar? give me a list that looks like:

• Icon/Tool 1
• Icon/Tool 2
• [Subtoolbar]
  • Icon/Tool 3
  • Icon/Tool 4
  • Icon/Tool 5
• Icon/Tool 6
• Icon/Tool 7
• [Subtoolbar]
  • Icon/Tool 8
  • Icon/Tool 9

Unfortunately, we can't have sub-toolbars of depth more than one since it's much more complicated and we won't probably need that many icon holders anyway.

I'm working on it, but as it's 3:30 in the morning, I'm off to other things for now.

Some bimbo landowner has this plot of land, recently discovered to be bug infested like crazy. Even in desperation, these businessmen manage to sell to you and your family at ripoff price for all your wealth. It was you and your family's dream to own their own land and establish a house and make a peaceful living in the countryside. Now you're stuck battling it out against pests to succeed in the garden/crops business, or you and your family starve to death… well maybe the gameover won't be that terrible, you have to live with your parents or something.

***
Some more details because I'm on fire. Our goal each level will be capture point because these will be nests/dens of evil, but if the beauty of garden is revived to the land the dens collapse in the wake of such goodness.

Since after playing our game we found that it feels more like a constructino management game than an RTS, I think we should implement a feature that promotes building on what you have, rather than just striking out to get the goal tiles to win the game. The way I propose this is to add another type of capture point… SEED PACKETS

Capturing seed packets will upgrade your gardens to a better crop that will yield more money per garden. I think it underscores our garden aspect, as we currently do not actually have anything to do with gardening (just building them), yet our very strong theme is that of gardening. Plus, it emphasizes the garden aspect and not so much the "'kill bugs!" aspect. So it complements and adds to the idea that you're building a garden/gardening.

Plus, it goes along well with the overall design of capturing points. We capture defenses on the board in order to use them, we'll be capturing points for a victory condition, so why not capture points to upgrade your garden?

Now, implementation should not be so bad. Since we already have capture points, we just add an array of garden upgrades rather than defense upgrades. If you have that capture point, you have better gardens. If you don't, it downgrades to the next best capture point you have, or to the basic garden type if you have none. You would need to have the "sequence" captured, so suppose that corn is better than wheat, which is better than flowers. You would need to have both the corn and wheat capture points in order to have corn as your garden type.

Gardens would need minimal modification. Just add a type and money amount, and change it based on your current best captured seed type. Gardens would all change together, so when you capture a point all of them change to corn/wheat/etc. This should make programming it easy enough, which would be a very nice thing as the alpha game is due tomorrow!

I'm going to finish up the level editor today (hopefully), but after that I could do this, since it uses the very handy capture points.

I really think it adds a nice element to the game that does not complicate it, only enriches it. Your thoughts? Since tomorrow is the alpha build, it's now or never probably.

OMG what a difference a bit of a UI makes! Nice job on that Muhammad! That'll definitely help with the tutorial and it makes the game feel SO MUCH MORE COMPLETE.

Looking great… it's a big jump from last I saw it on friday! Now to get a better editor… that is forthcoming.

1. I have moved all the cpp and h files into a folder "SRC" and I also edited the vcproj file to reflect these changes.
2. Our game will now compile as "Garden_Debug.exe" and "Garden.exe" for debug and release build respectively in the Garden2 folder, and not Garden2/Debug or Garden2/Release like before .. this would solve the need to copy XML, Sounds and Images folder to those folder before running the game.

So is this an AI bug? I haven't looked at all the code thoroughly, so I'm not sure where exactly the bug positions and newpositions get updated. I think that AI waypoints would be the natural place to look though.

reason: the code does not check if a destroyed defense is a new incomplete defense, in which case appropriate action should be taken to nullify the pointer _newG/_newSP/_newH/_newSC in Board and also to exit "select targets" mode

If a defense is set to true in _available_defenses array, but is not yet captured, the player is still able to select the grayed out defense icon and place that defense. I think that it is supposed to be that the defense is still not available until it is captured? Muhammad?

const char * type = elem->Attribute("type");
TILE_TYPE t;
if (!strcmp(type, "ROCK")) t = ROCK;
else if (!strcmp(type, "WATER")) t = WATER;

This seems really odd and outdated, but I don't know how else to convert a string to an enum

For now I'll just have the files in the same directory. It's cluttered but should let you compile for now

You'll also notice that defenses are kinda in… but don't try messing with them too much… like switching the interface while targeting… theyr'e still FRAGILE (still need to implement checks to remove the defense if the ISTATE_TARGETING state is interupted).

Oh and hey… we have a menu! Hallelujah we are now more than a one screen game! Nice job!

1. Wall building is pretty much complete
2. Garden creation is done but we still need to implement the wave-like destruction of garden
3. Pests movement is working so cutely
4. Basic AI seems working (head to a spot while destroying anything in the way)
5. Defense placement seems working for magnifying glass. Things might get complicated when we start implementing defenses that require setting the target tile(s)

Unfortunately I've instead spent the past additional 2 hours banging my head on the wall as CVS refuses to let me merge the two different file types. It says that permission to the files is denied, but if I'm not trying to merge them I can check them out just fine.

Point is, too much work on CVS, not enough on the code, and I have other work that needs doing now. Sorry to dissapoint, but hopefully I can figure out how to merge later then, as I basically restructured the whole defense/wall interaction to be more akin to the sprite/tile interaction, and I'm really not looking forward to doing it all again.

If we can clear up how to cast tomorrow, I can move all that ugly code back to Glass and have other Defense derived classes.

So if Defense seems oddly hardcoded for the magnifying glass, it is.

I added a new class AnimationX that will take care the animation of a sprite. In the latest CVS copy I added some code to demonstrate the use of the new class. Run the program and take note of the 'pest' animation :)

I'll write a documentation on AnimationX in the Programming Notes section before class tomorrow.

I know James has been saying we'll have realistic art, but I mean would we prefer actual scary looking bugs, or would it be better if they were more comical, less detailed? I'd vote for the latter.

1. Peaceful construction theme.
2. Fade into faster paced hostile theme.
3. Each enemy gets its own theme that will be folded into the hostile theme when its type is on the map.

Current Mood/Genre:
I have no idea. I posted the music I readied from the week of our first prototype. After looking at our mockup, though, I think I overestimated the cuteness of our game. Since we don't really have an explicit setting or story/premise (as far as I'm aware) I'm currently basing my music on the art mockup.

Any input on the preferred mood/genre that our music should be going for would be appreciated. I put up a notes.txt in the music folder on CVS so you can leave comments there too.

So I guess what I'm saying is… we probably don't want to worry about any possible drawing frills for now… we just need basic working drawing for wed. Colored squares still works instead of art I think, just so long as people can tell what's going on. We mostly wanna demo defenses, wall building (with the contstraint), and pest AI at work, or that's how I saw it, since we already proved how gardens work.

I think this might have to do with using CVS and changing the user profile/project file as we update the files. Anybody else experiencing this and have a solution?