Screens

I fixed a few bugs with the collision detection. All the sudden it wanted to test outside the map's boundaries, which of course crashed the game instantly.

Anyway, I redid the color scheme. Originally, when I first created the GUI, I created a scheme that looked nice with the default background color (CornflowerBlue). The forms imitated the look of pre-xp windows. All gray except the title bars, which were a nice shade of blue. Anyway, I changed it all to a nice dark blue. I don't know if this will be the final scheme I choose, but I wanted to reflect the mood I want the game to have. Every once in a while, you need a break from development to have a little fun. Anyway, here are some screens (the form and button borders look blurry because the pics are jpeg):

This is the Main Menu.


This is in-game. The circles around the nodes are the distance each one must be from other nodes. The line at the top is the top of the map. You cannot build beyond it. I also draw the borders of each grid square, but they are not shown in this pic. Each pair of nodes is a different player. I'm the top left and as you can see, I'm performing a drag n' drop to build another route. In the upper-left corner is the Statistics form that tells me how many people, nodes, and route sections I have.

As time moves on and the graphics improve or change, I'll probably be posting more pics. Until then, adieu.

clevceo

Collision Detection, Grid

I've finished the collision detection for the drag n' drop. I must tell you that it wasn't easy. What began as some simple, easy code for the grid became an overblown messy nightmare. When it was basically complete, I realized that coming back to it to fix bugs and whatnot would take more patience than I have, so I created a reusable function that simplifies my work with the grid. Whenever I need to perform operations on multiple grid squares, particularly a line (all grid squares that a route passes through) of them, All I have to do is pass a few bits of info to the function and a delegate linking to the operation I want to perform.

I can't tell you how convenient this makes things. However, though simplified somewhat from the original, the new function is still long and chaotic. I'm waiting for some problems to surface. Later on, I might even come back and run through it line by line to find any minimal glitches. For now, however, I'm going to shift my focus to collision detection for growing routes to see whether they intersect with any enemy routes.

After that, I hope to start on the fog of war.

Comment, please. Say hi if nothing else, just so I know someone's reading.

clevceo

Grid, Mouseover, Drag n' Drop, Sever and Retract, Collision Detection

I completed the grid functionality. There were a few cases where a section wouldn't be added to all squares it passed through, but with some hard work and deliberation, I fixed the problem.

I completed the mouseover stuff. I had to make some decisions over which methods to use, accuracy vs. performance. The route sections are rectangular, but there is a semicircle zone at each endpoint that still registers as within the route. However, this small zone is usually beneath the nodes at either end, so the anomaly will usually be unnoticeable. It only happens when a route isn't completely built, so that there isn't a node covering the zone. I may use a more accurate method when the section isn't completely built.

I added the drag n' drop functionality, allowing the player to build new nodes and routes. I also added the ability for the player to retract or sever his own routes. As with my last rendition, this was fairly difficult. Trying to get people to die when they're supposed to was hard. Every once in a while, someone would just keep on running off into the distance. More often than not, it threw an exception. But it's working fairly well now. I'm just waiting for the last few bugs to show up spontaneously.

Next on my list is to add collision detection for the drag n' drop. At the moment, you can place nodes wherever you want, on top of other nodes, intersecting other routes, and you can even place them outside the map's boundaries.

After that, I will add collision detection to the routes that are changing in length in case they are running into an enemy route or node. If the route hits an enemy node, then the route will retract, and the enemy is unaffected. However, if the route hits an enemy route, the player's route retracts and the enemy's route is severed, destroying everything branching from it.

I think (plans tend to change) I will then begin work on the fog of war.

Stay tuned.

clevceo

Grid

I've created the grid and altered my draw method to only test entities in grid squares the camera overlaps. I've started to implement mouseover testing for the entities. I've completed the initial coding and I've only tested it once. It didn't work. I've had no time to debug yet, but I'll get around to it eventually.

While writing the the mouseover testing, I did a lot of rewriting, trying to find the optimal method. I still don't know whether my current method is the best, but it works well enough. It's certainly faster than my last rendition.

After I get thee mouseover testing done, I'll probably adding the drag n' drop functionality for building new nodes, which will require more collision testing, but I inherited some of the math from my last rendition, so it shouldn't take too long.

clevceo

Input, Collision Detection

The new input class is working beautifully. I've returned to what I was doing when I hit the rut with the last input class and this time the wrinkles were quickly smoothed over and I've had no problems. The problem with my old class was that I couldn't easily switch from wsad (up/down/left/right on the keyboard) to a joystick or a mouse because buttons and axises were treated differently. My new system has the capability of treating a button as an axis and vice-versa. It also has the ability to combine axises. This feature comes in handy when creating an up/down axis for the keyboard. I created two buttons, W and S, wrapped them individually with an axis converter, W == -1 when pressed and S == 1, and combined them.

Anyway, I can now move the camera around and zoom in and out. All entities are now displayed (nodes, people, and routes). However, I've been progressing slowly because I'm allowing my mind a little time to mull over how I'll do the next step. In the last rendition, I would run through every node and section in the collision detection. However, I've realized that in a long game, the playing board may have hundreds of routes and nodes, slowing the collision detection down significantly. Therefore, I've been thinking of ways to filter the tests. I'm thinking of creating a grid of classes, each representing a square of the playing board. Each class would contain any node or section within it or passing through it. This way, when I'm building a route, only the grid squares it passes through will be tested. I imagine this would improve the performance considerably.

I could also use that method to determine what entities are within the camera's range. I wouldn't have to test every single entity, only those in the squares that the camera overlaps. The next question would pertain to the size of these boxes. However, I can set an arbitrary value now and test the performance later when I have a functioning game.

Comments? Thoughts?

clevceo

Input

I can now start a game. The players will be placed about 500 pixels apart in a diagonal line. Only the nodes are displayed at this point and you can't do anything. You can't even move the camera or zoom in or out. A window is displayed at the top-left corner, telling me the number of nodes, sections, and people I own.

As I began working on the game engine, I hit a few ruts with my new input class, so I rethought it and came up with a better idea, which is not only more flexible, but more organized and easier to understand and use. Long story short, I redid a good amount of the input class and I'm feeling pretty good about it.

Comment.

clevceo

Sound

I read up on sound yesterday. With XNA, you have to use XACT (Microsoft Cross-Platfrom Audio Creation Toolkit), which allows you to organize the sound and music for your game and compile it into the game through the content pipeline rather than loading it dynamically. I've heard pros and cons for this approach, but as a one-man-show indie, I don't think the lessened flexibility will affect me. The good part about precompiled sound is that it means less work for me and faster loading times.

I haven't created a helper class yet, but I have added a sound effect to the game. When you press a button on the GUI, you hear a "click" sound, which is actually "C:\Windows\Media\Windows Navigation Start.wav". It's nothing special, but I can only progress from here. Soon I'll have a working helper class for my sound effects.

Before we know it, I'll be getting back to work on the actual game engine. I'm almost there. It's amazing how much progress I've made in the past few months (amazing to me; I have no training whatsoever, so I'm teaching myself).

Any thoughts?

clevceo