Tech Demo, musagi

The tech demo is nearing completion. I'm debating whether or not to add any sound. If I do, I risk opening a can of worms so to speak. Like everything new that I try, I end up revising it a hundred times before I'm satisfied, and I'm positive sound won't be any different. I'll probably leave it out, but that's okay because Sever's strength is in its unique gameplay, and that at least will be intact.

It will probably skip past the menu screen and dive right into the gameplay. The main menu can only really show off my nifty GUI, and that's not what I need feedback on. Plus, even though the GUI's a major feat to me, many of the people playing the demo would already have one of their own. I'll be showing Sever to people more experienced than I, so the gameplay will be the only news.

There'll be one map and a single enemy to fight. He'll be stationary of course, but he'll have a premade layout of arms. I'm not sure whether I'll add any new graphics either. I would like to, but it's too time consuming and hard. I need some practice. The arch sprite was a stroke of luck actually. It just happened to turn out right, but I have no guarantee that my next attempt will be as successful.

Anyway, I have a feeling it will be here in a few days. As I prepare for school to start again, I find my time filled up, but I'll find a few minutes here and there to work on it.

Good news regarding music: I found musagi, which is by the same guy that made sfxr, the amazing sound effects tool I found. I followed the tutorial for musagi and frankly, I love it. It beats the tar out of Anvil Studio when it comes to usability. And the best part is that its author is an indie dev himself. And his tutorial is grand. By the end, I actually had a basic enough understanding of music theory to realize why all my music on Anvil sounded so bad.

Anyway, I have a feeling I'll be experimenting with sound and music over the next few months. Thanks to DrPetter (the author of these tools), I think I have the ability to do everything myself. I have GIMP and Inkscape for graphics; C#, XNA, and VS Pro for programming; sfxr for sound; and musagi for music. It's overwhelming to think that I have all these tools at my fingertips.

Thank you DrPetter. And thanks to TIGSource for bringing him to our attention. And many thanks to TIGSource for giving all of us saplings a chance to make it in the indie scene.

Stay tuned for updates on the tech demo.

clevceo

Editor, Mission Editor, Tech Demo

I've been working on the grid system. The editor didn't use the grid before, but it does now. Also, the editor can save to a specified path, and load as well. I've also consolidated alot of my drawing code into a single static class rather than rewriting it for every state. That way, both my editor and in-game can draw all the world graphics with a single method call. Also, I'll be able to use this in any future states that need the same drawing code.

I've made a decision: there'll be two editors. The first one is the map editor. The second is the mission editor. There'll be two kinds of missions: single-player and multiplayer. Multiplayer missions aren't exactly missions; they'll contain player placement data and not much more. Single-player missions, however, will contain events, AI enemies, and all other required data besides the physical map.

This way I can reuse maps. A single-player map can easily be used as a multiplayer map and vice-versa. Plus, we can revisit old locales in the single-player campaign with ease. To top it off, you'll be able to adjust the tint in the mission editor, so while the map will be bright and sunny in one level, it might be dark and eerie the next time you visit it. All it takes is adjusting a few sliders.

I also worked on my camera class. I decided that I'll never add split-screen support. It's too much work and not very reasonable. It just won't fit in the gameplay because it will defeat the purpose of fog-of-war. Thus, I made the camera class static so there can only be one and it is easily accessible.

I've been reading up on sprite batches and how to get the best performance. There's still some work to do, especially on my GUI library, but I've made some headway on the optimization.

The next logical step is to start on the mission editor, but before I do that, I might just polish up what I've got and get that tech demo out. The mission editor's going to be tough. From the mission editor comes events, and from events come scripts. I'm brainstorming how I'll do the scripts. Lua maybe?

Thanks for reading. Questions? Suggestions?

clevceo

Map Editor, Collision, Demo

The map editor can now save (to a hardcoded path, but that will change probably today). It also loads, go figure. That's exciting because I can start ridding Sever of all the hardcoded content.

I'm also working to weave the collision grid even tighter into the game so that it automatically adds and removes all objects to and from the map so I don't have to keep remembering to do it myself. It seems that I spend almost as much time streamlining as I do creating. But that's okay because every improvement to the game makes me feel awesome.

I've been making alot of progress and I commented on some plans for the near future in my Experimental Gameplay page:

I hope to have a little taste of Sever to release in the next few weeks. I plan to have a few maps with a few mindless enemies. I imagine that will be taste enough. From there you can imagine what multiplayer might be like.

I promised some vids a while back, but I've dropped them since I'm so close to releasing a...tech demo?. I'll put some effort into a little art and hopefully get some sound code in there. There'll be no music; that's a headasplode for another day. I sincerely hope that you like it and would like to start some discussion in my Google group.

I would love to hear your questions and suggestions. I'm pretty sure there's more that can be done with the gameplay, and I'm positive that you guys can help me out in that regard.

Thanks,
clevceo

Map Editor, Experimental Gameplay Project

The user can now change the tile set and add a color tint to the map and all objects on it. The latter is the most exciting. It could really add to the mood of the game. It will also give more individuality to each level in the game.

I have created an account on the Experimental Gameplay Project. My page is here. And I added Sever as my "experimental" game, here. I plan to submit Sever to the Experimental Gameplay Workshop. I probably won't make it, but so what.

Thanks,
clevceo

Map Editor, Grid, Sound Effects

First off, the map editor is coming along nicely. You can change tiles; load, place, and transform sprites (scale and rotate); create and manipulate geos (formerly called geometric objects); and resize the map. To do: allow user to change tile set, add color tint option for map and all objects on it, add sprite editor, save it all to a file, and load it back up from the file.

I'm getting closer. I'm feeling pretty good. As soon as I can save and load maps, I'm going to create a test level to play around with. So far I have two players on a map with a small geo off to the side and two sprites below, both arches, one scaled and rotated slightly.

I spoke previously about how segments will inevitably be tested multiple times when dragging due to my grid setup. I thought I'd done the best I could and there wasn't much else to do. However, the solution hit me this morning and I tapped away at the keyboard until it was done. The result was success. No segment will be tested twice. Neither will any sprite, geo, etc. I'm quite proud of my little discovery.

Originally, the size of each geo and sprite would've been smaller than a grid square so that there wouldn't be any chance of being tested multiple times, but that was quite restrictive and would've been alot of trouble. But that's irrelevant now. I can now make them as big as I want. What I do is assign each run through the grid an ID and check with each object to see if it has already been tested during this particular run. It works beautifully and it will make things easier in the future.

I also allowed for blank tiles, which would be placed beneath large sprites. The idea of big sprites is becoming more attractive as I improve my engine. At first it looked ugly, but it's growing on me. I'm excited.

Lastly, I was reading TIGSource, and came upon sfxr, which is an easy to use sound effects generator. The creator described it as an "MS Paint for sound effects." I like that description and while I think it's slightly more difficult than paint, it is nevertheless, as promised, easy. I've never generated a sound before and I now have some fun test sounds for Sever. They are by no means the final cut, but sfxr may be my sfx program of choice. It really is good for us sound newbies. Give it a try. It's mostly retro, but you can play with it to make it a little less electronic.

Now that I have some sounds, I'll probably get to work on some sound code. I'll probably finish the few things I'm working on now, but I'll get to it soon. I'm excited to "hear" Sever. I'm feeling comfortable with sfx now. I think I can do it. Next stop: music.

Thanks for reading! Questions? Suggestions?

clevceo

Welcome

For those who've already been reading my blog, this post is for newcomers. It is this post that I will link to outside this blog. I want this to be a starting point.

Welcome to my dev blog. I've been working on Sever for a while, and as it's finally taking form, I'd like to get a little more exposure, even if that means just a few regular readers. I've even started a Google Group. Please join and share your input.

Sever's development began a year and a half ago. In fact, if you'd read from the beginning, you'd see I'm on my fourth attempt. I've matured as a developer and so has Sever. And after all the frustration, it's finally coming together. If there's a fifth attempt, it will be Sever 2.

Sever is an odd sort of RTS. I don't think there's another like it...anywhere. I guess the best comparison is a competitive connect-the-dots match where the goal is to sever the others' lines with your own. However, that's a very incomplete picture. For a more complete concept, look here. I've made a few conceptual changes since then, as you'll see if you read on, but nothing huge.

Also, it's not a simple arcade game like many indies out there. The gameplay mechanics are just complex enough to merit a more polished and complete game. If I can gather the people, both graphics and music will be high-quality. To top it off, there will also be a single-player campaign mode with a compelling story. Yes, a connect-the-dots fan fic.

The only two things haunting me at the moment are fog-of-war and AI. Neither of which I've done before. However, I have a few ideas. I've read a few articles on fog of war, but none seem to fit Sever's needs. I have one idea that's perfectly doable, but I don't know that it's the most efficient. But have faith. I'll figure it out.

Thanks for reading. And remember to take a look at my Google Group.

clevceo

Map Editor

I've made progress on the map editor. You can now edit tiles. There you go.

Anyway, it was hard work. I had to modify my listbox control. Originally it only displayed text for every element, so I had to split it in two: the first part is a base class that displays no text and each element is an object with unknown contents; the second inherits the first part, reading each element as a string, and displaying them on the box. The reason I did this is because I needed to use the base class without the text for displaying the tiles for the map editor.

Therefore, I made a second child of the listbox class, this one taking images with a caption, scaling them to fit in the element, and displaying them. Of course, the picture is the tile and the caption is the tile's name. This took some work because I had to make some decisions while I was at it. I had to rewrite some code a few times.

I also added some new functionality to the base Control class. Each control now has a 'Visible' property. Obviously, when set to false, the control disappears. I didn't do this before because I didn't need it. However, I need it for the map editor because the user is going to switch between edit modes (tiles, sprite objects, and geo-objects), each requiring a different toolbar. I'll only display the one being used.

For the tilesets and sprite object animation, I have each tile or frame in the same bitmap. So far, I've manually glued them together with Gimp. However, I just found a program that can do it automatically for me. This will save me alot of time. The only trouble was that it lines them up vertically while Sever was coded to read from left to right. But it wasn't hard to fix that.

Anyway, I'm getting there. Next step: sprite objects. After that, geo-objects. After that, grouping sprite objects with geo-objects. That's the daunting one. The idea is that you take something like my arch in the last post and draw a circular geo-object at each foot; then you can take that arch and put it in as many levels as you want without having to draw the geo-objects every time.

Progress has been made. Suggestions? Questions?

clevceo

Sprite/Geo-Objects, Single Player, Fog of War

I've made some decisions with the geo-objects. They'll be separated from the sprites. Also, the map editor will be able to draw geo-objects. The idea is that borders will be drawn around the sprites manually. Of course I'll include some prefabs that link the two together as well, if only for convenience.

Here's my first sprite object to place on a map:

If I don't meet an artist this next semester, I'll be doing the art myself. And I'll need some art to start off with anyway. Thus, I'll probably be making a few more.

Once the code for the sprites is complete, I will most likely get to work on the editor. I already have a base listbox control I can use to display the various tiles and sprites.

I'm making progress. Once the map editor is complete, I'll get the multiplayer up and running. Once that's working, I'll work on the structure of a single-player campaign. Right now you can only run a single map before returning to the main menu, but I need to be able to go from map to map, showing any cutscenes (pictures with text) and messages in between levels. I'll also need to do the scripting. That'll be a challenge.

Eventually, I hope to do the fog-of-war. I think the fun of the game will be multiplied if I do. But I'll have to think about that later. I really don't know how I'll do it. I would also like to display ghost images of opponent routes that were seen, but are now covered in fog. Basically, you'll see what was there last time that portion of the map was uncovered. I have an idea of how I'll implement that, but I just don't know how I'll detect whether a route is covered by fog or not. That's what has me befuddled.

Thanks for reading. Questions? Suggestions?

clevceo

Map Editor, Tile Engine

I've begun to build a map editor. Before I got too far, however, I decided I had to beef up the tile engine a little. The game now reads a text file with info on a tileset for a map, such as the image's path, the size of a tile, and so forth. Also, on the spur of the moment, I added the capability to animate the tiles. Anyway, I tested it and voila, it worked. Of course, nothing on the screen had changed, but the new code had worked nonetheless.

Next, I wanted to test the animation code, so I took my one tile and put a duplicate right next to it with some highlights. I set the duration for each frame as half a second. It worked. There were no errors. None. I got it on my first try. That's a first. Anyway, I changed the frames again so that the highlighted one only flashed every so many seconds, so it was more like lightning than a consistent blinking light. Not that I'm keeping the animation for good, but I want it to look as good as it can until I add more tiles. And I won't be adding tiles until I have a working version of the editor. And even then I'll probably only add one more tile.

There you have it. A decent tile engine. I'm planning on sticking with it unless someone suggests something better.

Suggestions? Questions?

clevceo

Debugging, Distribution, Tile Engine

A few hours of the day were spent debugging. I had a problem with the people's behavior. For some reason, when a segment was just almost fully packed with people, all the people would all of a sudden jump backwards behind the nodes, out of the segment entirely, then come back in. I was baffled too.

Anyway, a whole lot of divide and conquer to find the single erroneous line of code...excuse me, erroneous number. All that work just to find one simple small number. But it was fun though. It was a real challenge, and it feels good when you fix it and the bug is gone forever. In the process, I also found a few other small details that needed tweaking. So all in all it was sort of productive.

Of course, there were other minor glitches and so forth that I've come upon and fixed involving severing and retracting. It seems most problems are triggered by one of the two. But they're becoming more stable every day. I'm pretty confident in them.

I hit a problem with the grid testing. I've mentioned before that when testing against a segment, you have to test every grid square it passes through. The code for it is a heck of alot simpler than the code in my last iteration and faster too. But it's also newer and thus more prone to error. It was fine when testing down and to the right, but any other direction and it hit a never-ending loop.

I had to look at the math and figure it out. Sometimes my mind fogs up when I try to do math in my mind. But after about 10-15 minutes of trial and error, it clicked. Doh! The solution was simple and the test now works wonders. Also, to make sure it was working as intended I wrote a few extra lines of code to display an X over every square tested.

I added a little to the..."Person Distribution AI" we'll call it. To start with, each time a person hits a node, the node has to decide which of its branching segments to put the person in. I use a little recursion to determine the cumulative density of each path and all beyond it, and place the person in the one that is least dense. That's old hat. What I did today involved only segments that are retracting. Their density returns as 100%, which means no person in their right mind will try to enter it. More people are saved this way.

I created a simple tile engine. So far there's only one tile. It'll probably stay that way for a bit; I just wanted the tiles there for the sake of progress and prettiness. I'm still open for suggestions if anyone knows of a better method than a grid of tiles. Anyway, even though the tile isn't great, it's better than nothing.

Suggestions? Questions?

clevceo

Geo-Objects, Glitch, Tiles, Sounds

I now have a working version of the geometric object class. It's drawn with the PrimitiveBatch for now, though I plan on changing that eventually because it's too pixelly. Plus, it's only an outline, and it needs a texture. I'll probably just make some prefabs with static textures. Once I have a few, I'll make a map editor and try them out.

I finished the collision detection for the geo-objects as well. It wasn't so bad. I'm proud of my work. In the process I made some optimizations to some other collision detection as well. It works beautifully.

I also discovered a glitch. To create a new node, you click and drag from an existing node. Normally while dragging, a single node and segment are displayed under the cursor. However, I discovered that they were displaying once per grid square in view. When zoomed out that's alot, 100 at the moment. Two sprites (node and segment) x 100 = 200 sprites! That's fairly inefficient if you ask me. However, I'm proud to say that the game didn't slow down a bit. I didn't even notice it was happening until I saw the code in the wrong place.

I'm piddling around with Gimp and Inkscape, trying to come up with some presentable background tiles to try out. I could just go with the ones I made for the last iteration, but they were thrown together in seconds and really don't look right. I want a working look & feel for the game.

It would also be nice to get some sound effects going. Unfortunately, my webcam's microphone is broken. It's a LifeCam VX-6000. $60. I looked it up and many people have had the same problem. I haven't even dropped the thing. Anyway, I don't have a microphone to use, so I'll have some trouble managing the sound effects. However, once I find a way, I know how to cancel noise with Audacity.

Suggestions? Questions?

clevceo

Collision Detection, Geometric Objects

Severance is complete. Easier than I expected. Only a few errors, all easy fixes. As promised, the collision detection was next in line, and it is all but done. In other words, it's finished until it blows up. Everything blows up at least a few times before it's complete.

Most of my time was spent on the collision detection. But there are a few other things. I downloaded the PrimitiveBatch sample from the XNA Creator's Club website. I hate to use other people's code, but I'm not ready to learn shaders just yet, and I desperately needed to draw some lines for debugging purposes. I could've gone back and used the ol' sprite rotate and scale for lines as I did in the last iteration, but that's slower. However, I may just do it anyway later on unless I learn shaders and figure out a way to anti-alias the lines. Sprite lines look great, but performance is key. We'll just have to wait and see what happens.

Anyway, I've been thinking about the geometric shapes that will been strewn around the map. I looked up geometric collision detection to see if there's a better method than the one in my head and found this. It was nothing new. That is, nothing except the line intersection code. Incidentally, my code is shorter, and thus probably faster. I replied with my code here.

Now that I know how I'll manage the geometry, I don't know how I'll manage the rendering. I would like to draw the lines and fill the shape in with a tileable texture, but as I don't know how, I may have to resort to pre-rendered sprites, which would put a damper on variety and require more sprites to be loaded into memory (not to mention the extra effort producing them). But if that's what's required, then that's what I'll do.

If you know of a better method, please please please tell me. In the meantime, I'll probably use the PrimitiveBatch to draw them.

Any suggestions? Questions?

clevceo

Loading Screen, Drag-n-Drop, Collision-Detection

I'm done for now with the loading screen. That doesn't mean it's complete. Why? There's not much to load yet. When there's more to load, there'll be more work to do on the loading screen. Anyway, I've made some decisions concerning the networking to get all players on the same page before starting the game. I like it. I've simplified it to the maximum and it's looking good. Who knows if it works, though. We'll see.

I've added drag-n-drop capability. Fortunately, I was able to borrow some code from my last iteration. There's some math involved with determining whether or not the cursor is above a segment or whether two segments intersect. In fact, I posted in the past about how horrible it was figuring that out for the first time. I'm glad I don't have to do it again.

Unfortunately, as soon as I added my first node, I received an error. After I fixed it, another popped up. As usual, it finally worked after about a half-hour to an hour. But of course, it still behaved incorrectly. It took the better part of the night fixing the behavior. I'm sure there are a few more problems that will crop up in time.

I added retraction. Same as before, problem after problem. I've fixed all that I've come across so far, and it's looking good. I've yet to add severance, which I'm positive will introduce a new multitude of errors.

Destroyed people and buildings now leave a ghost behind. They don't go away just yet. I'll do that next.

I redid some networking stuff. Simplified it. It's much easier now. More robust.

Soon, after severance is complete, I will add the collision detection. It won't be that hard. Just a little more code. At that point, I will probably focus my efforts on the network game, as I'll be able to trust everything other than networking to work fine.

Unfortunately, XNA 2.0 beta requires C# Express, which I can't install on the work computers for testing because it requires administrator rights to install. Maybe XNA 2.0 non-beta, which won't require C# Express, will be able to install without administrator rights. I'm crossing my fingers.

Any suggestions? Questions?

clevceo

First Run, Multiplayer, Music, Tile-Engine

The game plays.

Of course I've only tested single-player mode. I still have a few things to work out before I can test multiplayer. Anyway, I kept starting the game and fixing the errors it threw at me until all of a sudden there weren't any errors. Neither were there any nodes or segments, but that's beside the point. I had yet to write the drawing code. Anyway, the drawing code was simple enough.

Of course there were some problems with the behavior of the people inside the segments. For some reason they formed a line that went back behind the node, away from the segment itself. Though frustrated, I wasn't surprised. I'd seen crazier things. I just can't believe it's actually running.

After I fixed the above issue, there were still some more bugs to fix, but at the moment I'm focusing my attention on the loading screen. I'm trying to figure out the best way to get all the players on the same page in the most efficient way possible. I've had to do and redo the code a few times. At first I had decided that I would allow AI players in multiplayer. Why? Because I could. I also thought that since PCs don't support local players, I would create my own local players that would communicate through the first player's account. Of course this is all doable and I have concrete ideas of how I'd do it, but as I began to code it, my head started to whirl. I can't use any more head-whirling at the moment, so I'm putting that off until a later date. Until further notice, multi-player is as XNA intended.

I'm still composing little diddies. I like one of them (my second one), but it's not nearly good enough to put in the game. I might test with it just for fun, however. In January, I'm transferring to another school, one with more people like me. I'm hoping to find someone with some musical talent to compose some music for me. Maybe I'll find an artist, too.

I'm having thoughts about the background tile engine. It's going to be hard work making tiles that come together seamlessly. I wonder if there's a better way. I sure can't think of one. I'm looking for a combination of performance and ease. Any suggestions? Anyway, if I don't think of anything, I'll just bite the bullet and do it anyway.

Suggestions? Questions?

clevceo

Close to Testing

Nearly the entire day was spent on Sever. Anything else was an interruption. I think I'm getting too impatient. Every second is Sever. But it feels so good. I'm making so much progress in so little time. Every day I try something new and succeed. Success used to be foreign to me, but Sever gives me success on a daily basis. I can't wait for the day I release it.

The next milestone is to get a game started, displaying everything on-screen, camera movement, etc. No mouse interaction yet, but that will come soon thereafter. Right now, I'm just focusing on making that first step. Once I'm there, I can finally test and debug. All this time I've been coding in the dark. It compiles, that's all I know.

The networking code is mostly done! I actually did it! It was easy! I created a separate class for each type of packet. I hope it works.

The player classes are getting closer. I'm at the point were I'm no longer building, and instead filling in the holes. The problem is finding them all. For now, I'm just doing the ones I can find easily. I'll let the others show up when I start the testing. There's going to be alot of debugging before I get the first node on-screen. It's discouraging, but I've beaten it before. I can do it again.

I'm making a loading screen. In the past, the loading was so quick and simple that it was done all in one quick method when the game started. Now, with networking, there's some extra stuff to do, such as getting all players on the same page before the game starts. It's still going to be short. In fact, for all I know it'll display for only a few frames. Nonetheless, it makes it easier for me to put all that code in a separate state.

I redid my camera code from the last Sever iteration, which was borrowed from the before it. Yep, I said I would eventually redo it and I finally did. It was messy. It supported rotation, which required alot more math and is useless in Sever, so it was tossed. The class is now simpler and cleaner. However, instead of doing it from scratch as I have with everything else in this iteration (aside from the GUI and Input libraries), I still borrowed generously. It was alot of trial and error initially and I know it would be again if I didn't borrow. Besides, with a little tidying it's still good code.

I've been thinking about music, and I've realized that unless I either a) find someone to do it for me, or b) learn to myself, I'm not going to have any. I would very much like to find someone to do it for me, but it's unlikely and I don't want to take that chance. Therefore, I've taken it upon myself to download Anvil Studio and compose a diddy-a-day. I have four short songs so far. Later on when I'm ready to start on the music code, I'll use the least terrible song for testing. Hopefully I'll improve. That's the intention anyway.

Suggestions? Questions?

clevceo

Grid, Story

I've made a little progress on the player classes. They most definitely aren't complete, however. I'm still trying to process all the networking stuff in my head, thinking of ways to put it all together in the most efficient and effective manner.

I've completed the grid helper code. If you haven't read my posts from the past and you're unfamiliar with such a thing, it's useful for collision testing. Say I was looking to place a node, and I'm dragging it around the map. The game dynamically tests it against other nodes and segments to see if the placement is valid. Without a grid, it would test every node and segment on the map. A grid allows me to test only the nodes and segments near the one I'm testing. When I place a segment and node, they are added to the grid squares they land on, so I can retrieve them later. Likewise, they are removed from the grid square when they disappear.

Grids are normally a simple concept, but they become problematic with segments, which pass through multiple squares. First off, I have to create an efficient and accurate way to test a line of squares. The method I'm using this time is simpler, and hopefully faster than the last one (which took days to debug). Second, When testing against nodes, I have to test not only the squares the segment passes through, but those around them as well in case a node overlaps the border.

The method I chose is two-step. Beforehand, I have a grid of bools (true/false) ready. The first step uses the line method to run through a line of grid squares and set each one and those surrounding it as true. The second step runs through the grid and tests the squares that are true. I wish there was a more efficient method, but I sure can't think of one. The efficiency of the method drops with longer lines. Fortunately, the lines will always be only a few pixels long with growing and shrinking segments. Only when dragging to create a new node will the lines ever be long, and that only tests once per update.

I've been thinking about the story and graphics. Before, I had two options in mind: A casual game without any meaning or story, and a foreign planet setting, the segments being domed tunnels with breathable air for the people building them. Unfortunately, I wasn't excited about either of those.

Neither one fit the atmosphere I'd imagined. I'd imagined a mystical piano melody that would play in the background, maintaining a slightly eerie ambience. The coloring would be dim and bluish. There'd be some ambient sound as well, both to soothe and to make it more immersive. Also, something I just thought up, there'd be faint clouds when the player zooms out.

I also wanted the player to care about the little "people" in his routes. That was possible with the space-oriented version, but it was unoriginal, and therefore easily taken for granted. Recently, I've thought up a new idea. The player is a creature, the segments arms, and the nodes joints. When a segment is severed, it is literally cut from the creature's body. I'm still thinking about the people, however. Maybe symbiotic creatures that help the creature to grow and receive protection in return? I like that idea.

Maybe you'd hear an ambient heartbeat when you're near the parent nodes. And maybe the segments' widths would fluctuate with the beat. And maybe they would shake in pain when one is severed?

Lastly, there's the story. I have nothing concrete in mind, but I do like the idea that the creature is unsure of his identity. Either he thinks he's the only one of his kind (until he meets another), or he's the only one that can think for himself while his opponents grow in a mindless pattern. If I make an expansion or a sequel with actual AI, maybe the story could be expounded upon.

Questions? Suggestions?

clevceo

Networking, Single-Player

The better part of the day was spent on Sever. It's coming along nicely. I've completed the segment's distribution code. In fact, the node and segment code are nearly complete (ready to test). I'm now creating the player classes, different ones for local, remote, Human, and AI players.

I've been reading more into the networking and all of a sudden it looks deceptively simple. Since I won't be sending person data over the network, network traffic should be low. All I'll send are changes in a player's state. For example, if he adds a node and segment, if a segment's length changes, or a node or segment disappears. And for severing and retracting, which change every frame, instead of updating the length I'll send the rate at which they are shrinking, and update the length on the recipient's PC. This would decrease traffic tremendously.

Though I've yet to test it, I have a feeling I'll be left with alot of room left over. However, that's not a bad thing. In fact, it would keep the performance up and be easier to run on worse connections. Plus, for all I know I might be adding more features later on down the road.

I've been keeping single-player in mind as I work. As mentioned in the past, the enemies will be a mindless growing mathematical pattern rather than a dynamic thinking foe. Though there isn't much to that, I have a few reasons for it. First off, it would be fun to play. Single-player always gives a different kind of satisfaction than multiplayer. Second, some people don't always have a connection to the internet, which would render the game unplayable without single-player. Third, should I create a more complex AI later on, the game would be ready for it.

Vids coming soon.

Suggestions? Questions?

clevceo

Distribution

I've made a whole lot of progress on the gameplay. So far it's a ton easier than it was the last few iterations, I think due to my increased experience and the improvements in the design. The design is much better.

The toughest part before (and one of the biggest overhauls this time around) was the distribution of the people. When a person reaches the end of a segment and has multiple directions to go (including turning around), he picks based on which way needs more people. This requires some math thinky.

However, if all the lanes are full, he can't pass through. Determining that also takes some more code piled on top of the previous.

What if the route isn't fully built? We have to increase its length and turn the person back around.

What if the segment is retracting? We have to turn the person around.

What if there are multiple people passing through at once?

These don't sound like huge problems, but I had them all in one method in the node class. Even people that don't reach the node are run through it because the node contained all distribution code. Piled on top of each other, they made a mess and the code became hard to manage. Coding this portion took alot of debugging the last few times around.

However, this time I'm cutting it in half and putting the first half in the segment class. This code will be concerned with everything that doesn't involve the node, such as building and retracting.

I've already completed (yet to test) the node's distribution code, and now I have to write the segment's.

If you've noticed, I've started calling sections segments. I've changed the official name because segment is more fitting. Section was invented as a "for lack of a better word", but now I've found a better word. Segment.

Vids of the last iteration will be posted soon. Patience, grasshopper.

Suggestions? Questions? Singing praises?

clevceo

Network Problem Solved

Correction: my network is fine. Sever and the Net Rumble Starter Kit were broken for two different reasons. The Net Rumble Starter Kit didn't work because the GUID's were different on each computer. Sever didn't work because I wasn't updating the network session each frame. Doh! It works now. Awesome.

clevceo

Network Trouble, Gameplay

I just received my second comment, only this one's legit. It wasn't long or detailed, but it was a complement, and that always counts for something, especially when it's all you've got. Anyway, it was from Zygote. He has a blog, Ziggyware XNA News and Tutorials, and a website, www.ziggyware.com. Thanks, Zygote.

On to the update:

I made some minor improvements and fixes to my input library. Nothing important enough to mention, especially since I'd have to explain how the whole library works first.

I also finally tested the network. It didn't work. I googled and googled, finding nothing, so I decided to test a sample game from the web, namely the Net Rumble Starter Kit. It didn't work either. Conclusion? Something's up with my network.

I've somehow completed four years toward an IT degree and still don't know a whole lot about networks. It's probably because I hated IT (I'm now CS) and blocked it all out of my mind. Anyway, I'll just have to figure it out.

I made some changes to the lobby and join screens. In the process, I think I've found some bugs in the beta. When I end a session, the SessionEnded event is never raised. This will cause problems on the client end. Nevertheless, I went into this knowing it was beta. They say they'll be releasing fairly soon, so I won't give up.

I've gotten as far as I can for now on the main menu. Now I'm just beginning to work on the gameplay (once again). Before I get too far, however, I'm brainstorming better ways to implement it. I already have a few ideas. I have to keep in mind the fact that it will be running over a network.

I'm also keeping scripting in mind. I said before that I'll implement it last, but I've had a few ideas for an interesting single-player with an AI that is purely made from scripts. The opponent would expand in interesting patterns from his base and the player would have to eliminate him within a time limit. If I'm going to have scripting, I may as well prepare for it now.

I'm going to redo my camera class. My previous camera class supported rotation, which was never used in Sever and probably never will be (as long as it's 2D; who knows what's in store?). Less math in the calculations means better performance.

I'm pretty sure I'm going to make each little person a Vector2 as opposed to a special class. The X value will be the person's progress through the route section and the Y value will be his current speed. Structs are faster than objects, so the performance should be improved.

Also, I'm thinking of hiding opponents' people. Each player will only be able to see his own people. This sounds arbitrary, but it means that I won't have to send data about each little person over the network. Much much less traffic. It also means less sprites to display. Can you go wrong with better performance all around?

I'm also going to look into geometric collision detection and fog-of-war. Geometric collision detection is important because it will allow me to places obstacles in a map. If I didn't have those, then what would distinguish one map from another aside from tiling?

Fog-of-war is important for two reasons. First, I think it will add to the fun. It will allow players to scheme in private. It will also allow players to move around the map without the opponent noticing, allowing for more complex strategies, such as sneaking around and attacking from the side. Without fog-of-war, the game would be brute-force. Second, I think I would enjoy implementing it. It would be a real challenge, but I think it would be worth it.

I'm planning to post some gameplay videos from my last Sever implementation. I don't know why I didn't do that before.

Suggestions? Questions?

clevceo

Intro Screen

I added an intro screen that fades in and out with the Clev logo. It's nothing huge, but plenty of fun to do. I made the logo a few days ago as I was working on a website design for Clev. Anyway, here's my working logo:



Like it? Suggestions? Questions?

clevceo

First Comment!

I just received my first comment on the post just before this one! It may be spam, but hey, you take what you can get. Furthermore, it's advertising dialup, which is useless considering the fact that those reading my blog already have an internet connection, most likely broadband at that. But the best part of the spammy comment is that it's in Portuguese. It doesn't get better than that. Thanks for the laugh, crescenet.

Anyway, he wanted me to add his url to my blogroll. While I won't go that far, I will add a link right here in this post for the sake of laughs: www.provedorcrescenet.com

clevceo

ListBox & Scrollbar, GUI Rendering

The scrollbar and listbox are both complete. However, as with everything, changes will probably be made in the future. Nevertheless, they work and that's the most important thing. They took the better part of the day to complete, so it feels good to be done.

Anyway, the Join Game window now displays all available games. Excuse me, the Join Game window would display all available games if there were any to display. Excuse me, I don't know whether or not the Join Game window displays all available games because I have yet to create another game on a separate computer, and thus have not tested it, and thus have no idea whether or not it works. In other words, the listbox is blank.

Nevertheless, the listbox is there and it works beautifully. I must say, I love my GUI library. The only problem with it at the moment is that it's drawn with scaled sprites. Scaled sprites can be a pain sometimes, and they're inflexible, but they're easy to implement. In fact, in my last implementation of Sever, I scaled and rotated a single-pixel sprite to draw lines.

However, once I understand shaders (when and if), I will use them to render the GUI (and lines). Shaders mean more flexibility and efficiency for the GUI. If only they weren't so weird and confusing!

Suggestions please? Questions?

clevceo

Local Sessions Xbox-Only, Join Game Window

Unfortunately, the whole idea of a "Local Network Session" (split-screen play on a single system) is Xbox only. That took me no less than four hours to figure out. For some reason, it wouldn't let me add any local players, so I searched and searched online until I finally found the bad news. The help files don't even make this clear.

I am forced to use an alternative, but I can't use the internet because Live play requires a Gold membership. Furthermore, Live play in the beta release also requires a Creators Club membership. To sum it up: not free.

Therefore, I can only use System Link, which means multiple computers over a local subnet. I'll probably eventually add Live support since the devs went to great lengths to make Live and System Link behave like twins in XNA. Only a few minor differences.

Anyway, without Local, testing will be a challenge. I can probably test the gameplay in a single-player mode, but I'll have to make arrangements for network testing (all I've got is my laptop).

At the moment I'm working on the Join Game window. I've basically finished the New Game window. For the Join Game window, I'll need a listbox, and for the listbox, I need a scrollbar. Scrollbar it is.

clevceo

Starting Fresh

Wait until I'm done before you say anything.

I'm starting over on Sever. Agh! I said it! Fact is, it could be done better. Plus, I want the entire game created with multiplayer in mind.

First, however, I'm creating a template for any future games I start. Trying to get RefLib on its feet was a real pain because of all the nuances in my GUI and Input libraries. I've done a thing or two to make it easier, but I still want a template. The template will contain a simple main menu and no more.

Also in the template, I'm creating a server window for multiplayer games. That's what's occupying my time at the moment. It's a learning experience. I'm finding it easier than I expected, but still daunting all the same.

I'm always tempted to give up on it. I continually let myself become distracted by small things (like blogging), or find myself staring at a wall for long periods of time trying to remember what I'm doing. And then I think about how I should be working on RefLib. It's a painful process.

I wish I could jump a few years into the future when all schooling is over and I've established myself as a software engineer.

Anyway, thanks for reading. Comment please.

clevceo

Route Theft

I'm debating whether to allow the player to steal his own routes. That doesn't sound right but I couldn't think of a better way of saying it next to explaining it in full.

However, a full explanation I will give. You have an extensive set of routes on the board. You send in a separate route route and connect it to an existing node within the first set, retracting its original source route. This way, if the source route is severing, you can save the rest of the route.

Here's a little ASCII art to illustrate:


\   /
 \ /
  Y      O
  |      |
  O      |
 /       |
/        |


\   /
 \ /
  Y------O
         |
  O      |
 /       |
/        |


The following route is no longer part of its original source, but becomes part of the second route. It is effectively stolen from its parent.

I thought of this a while back, but at the time I thought it was just "another feature" that I'd thought up in my head, contradictory to my goal to rely on the simplicity of the game to move it forward. However, I've recently begun to see the strategic possibilities the feature would present. Plus, it's still simple to do in-game. It would be a mere drag-n-drop. It would fit perfectly. As I write this, I like it more and more.

I'm going to do it. If you think I shouldn't, say so now. If you have any suggestions, please share them. Thanks for reading.

clevceo

XNA Networking

First off, Sever and its referenced libraries all converted just fine to XNA 2.0, though there were a couple deprecated functions. It ran fine without changing them, but the changes would be so small that I did it anyway.

I've been reading up on networking within XNA. I was deathly afraid that it would require as much code as the game itself, but fortunately, it does not. XNA has once again managed to simplify something so complex without losing any capability that I will need any time soon.

Anyway, it's still daunting. I have no experience with this stuff and it's still going to take some figuring out. Fortunately, it seems Sever's current structure is a perfect fit for networking (wipe the sweat off my forehead). I must be a prophet. No, that's going a little far. I'm probably just a genius.

Fortunately, I'll be able to do part of the multiplayer testing without a second computer. XNA allows multiple players to play from one instance on one pc. In other words: split-screen. I could've implemented split-screen before, but the required code would've gone off course from the intended structure of the game. I would've had to undo alot of code come XNA 2.0. But the waiting is over, so I can move on.

Please comment your suggestions, questions, thoughts, praises, musings, etc. Thanks for reading.

clevceo

XNA 2.0 Beta

What do you know. At the end of last night's update, I mentioned that the next step in Sever's development depends on XNA 2.0's release. Lo and behold, here I am in my bedroom with my laptop on (guess) my lap with the beta downloading at 76%. Hanginaround by Counting Crows shuffled its way to my speakers to celebrate.

I've never been much for beta testing. I've always been one to use the stable versions because I'm afraid I'll either lose some work or lose my patience with bugs. However, I will try the XNA 2.0 beta because my work is stunted without it. Plus, the what could happen, other than an in-game crash? The code always saves before it runs, so there's nothing to lose.

Visual Studio Express 2008 is also out. I downloaded it, but I haven't used it yet because it doesn't like XNA and any non-XNA code I've written was with VS 2005 Pro, which is a step up from Express, even if it is 2008. So if I ever use it, it will be purely for fun. Even if it does eventually accept XNA, I won't switch because...

XNA 2.0 integrates into Visual Studio 2005 Pro! I was bummed when I found out that XNA 1.0 required Express. I know I could add the references and all that to get it to work in Pro anyway, but it's just a nuisance that it isn't supported natively. Anyway, the biggest problem I had with Express was that there wasn't an option to retain tabs rather than treating them as spaces.

Anyway, the download is complete. Goodbye XNA 1.0, hello XNA 2.0 Beta! I know I shouldn't be working on Sever with RefLib on the clock, but I can't help myself. Expect updates.

clevceo

Sever: Explained in Full

I realize that I haven't explained clearly what Sever is all about. I've spoken mostly to myself in this blog and haven't given any readers a chance to understand what the hay is going on. I would very much like to get your input, so I'm going to explain it as best I can.

For starters, imagine you're designing a connect-the-dots picture, no intersections. Say some impatient kid is connecting the dots right as you draw them. In other words, every time you make a dot, the line makes its way to your pencil in realtime. Now, say the path we are making can split into two lines like a Y, then three, four, and so forth.

Now lets throw in another person at the other side of the sheet drawing his own dots. How dare he? And to make things worse, he's crossing your lines with his own. To your surprise, the lines he crosses are severed and all lines beyond them disappear. Your ears are steaming now.

You start making dots like mad, hoping the kid connecting them can keep up. You start cutting your enemy off, driving him back to where he started. Finally, when he only has a few dots left on the page, you cut off his first line and everything disappears. You have effectively conquered the page.

That's Sever.

Back to reality (meaning the Seververse), there's no page, no impatient kid, no pencil. The dots are, in Sever terminology, called Nodes. The lines are called Routes, each individual segment called a route Section. These terms are merely a working vocabulary, subject to change.

There are a few more mechanics to make the game more interesting. Instead of a kid drawing the routes, there are little people building them. These people are little dots that run mindlessly back and forth through the routes. Every time a person runs into the end of an unfinished route section, the section's length increments. Once the section is complete, the people then begin to build the node in the same fashion.

These people are generated at a consistent rate by the two connected dots that each player begins with, called Father Nodes. The section connecting them is called the Soul Section. When the source section is severed, the player is finished.

A player can sever his own routes if he chooses. However, when a route is severed, all people within it are lost and must be regenerated in time. If he's not in a hurry, he can retract his routes, drawing them in at a rate slow enough for the people inside to retreat to safety. This is what happens to the offensive route in a severance.

There are different kinds of nodes. Each one varies in a the following properties: radius, spacing, branches, speed boost, and person generation rate. Radius is the size of the node. Spacing is how much space is required between this and another node owned by the player. Branches is how many branches can follow this node. Speed boost is how much of a boost to give each person that passes through the node. Person generation rate is how many seconds between each person generated (0 if none). At the moment, I have only four different types:

Father Node: Gives a speed boost; generates people; doesn't split the route; not buildable.
Sub Node: Builds fast; doesn't split.
Switch Node: Splits the route in two.
Accelerator Node: Gives a boost; doesn't split; large spacing.

That's the current status of the game, only there is no multiplayer or AI. If you've read my past posts (you don't have to; I'm writing this to compile all the important stuff into one post), you'll know my future plans. However, for the sake of clarity, I'll give a short list:

1) Multiplayer
2) Fog-of-War
3) Map Obstacles
4) AI
5) Scripting

Multiplayer can't be done (with my experience) until XNA 2.0 is released in the next coming months (hopefully). But I plan to get to work on it as soon as I can because I can't truly playtest until I have an opponent that fights back.

Fog-of-War was the last task I had been working on when I took my hiatus to work on RefLib. I hadn't yet put any code into it because I was still brainstorming how I would implement it in Sever. It was (and is) a daunting task, but it is doable.

Map obstacles are required if I'm going to make unique maps, and as of yet I'm trying to figure out how to implement them in a way that's workable with AI pathing and performs well with collision testing.

AI is very daunting. I've read up on pathing, which doesn't sound so bad, but getting the AI to make a plan and implement it is beyond me. This feature I will put on the backburner until I'm ready for it.

Scripting is definitely doable, but it's useless without AI. It would only be used on a single-player campaign, and a single-player campaign makes no sense if the baddies have no AI to drive them. Until I do the AI, Sever will be a multiplayer game.

So that's the plan. As I've mentioned, I'm working on RefLib right now, so Sever will have to wait at least another month. Once Sever is back on track, I will start on the fog of war unless XNA 2.0 is out, in which case I will set to work on the multiplayer.

Please, please, please comment. Tell me what you think. Give me suggestions. Criticize me. Ask questions. Please.

Thanks for reading!

clevceo

Why, XNA 2.0/Multiplayer

For the past month or so, I've been slacking on my projects. A lot is going on right now in my life, of which I will not elaborate. Anyway, I've missed the enjoyment I always had in my work with Sever. RefLib is not complete, though I planned to finish it by...right now. Anyway, I still have a ways to go with it, so Sever will be put off even longer.

Due to all the distractions, Sever rarely crossed my mind over the past month. But today a co-worker asked me about my personal projects and I ended up showing her Sever and Idea, and suddenly I realized how much I had invested in them and how much enjoyment I'd had working on them. And suddenly I dearly wished that I could drop everything, form a team, and work on them fulltime. I've had that wish many times before, but it hadn't been seen for over a month.

I sometimes wonder what it is about software development that intrigues me. I think it is similar to what novelists feel...in more ways than one. On the surface, you could say that mainstream developers are like mainstream novelists. They spit out their projects like a machine gun and reel in the money. But underneath, you'll see that some developers (ex. indie) are like the rare novelist that writes for his own fulfillment, sans success.

There is something about seeing all the code I've written come together on the screen. Knowing that my blood and sweat actually accomplished something. I can't get enough of it. Knowing that I'm capable of creating a full-fledged real-deal computer game, ignoring the scale, baffles me. It makes me feel like I can do anything.

There is also something about the indie cause. I call it a cause because it seems all indie developers have a common purpose: to bypass the publisher and enter unfamiliar territory, doing what hasn't been done before. The thought that I'm creating a game that is new and original excites me.

Plus, I feel I'm not settling. Many indie developers create casual games, as they're called. Casual games have their place, but I want to create something of real merit. Something with depth. Something immersive, beyond casual. Not many indie games can claim such a feat. But Introversion is one developer who's done it. Games they've made stand up to mainstream games. Many indie developers cower beneath the mainstream, but Introversion stands apart with games that are different but every bit as fun. And the ambience of their games is often more influential than your average mainstream game. It is that that I am striving for. I don't know that I'll achieve it any time soon, but I'm not going to stop until I do.

It's this passion that drives me. I just hope I'll eventually have the resources and the luck to make a living off of it.


On a different note, Microsoft plans to release XNA 2.0 later this year. This will be pivotal in the development of Sever. There is a new feature in the upcoming release that was conspicuously absent in the previous: multiplayer support! One of my biggest discouragements during the development of Sever was knowing that I could never really test the gameplay. I could never actually play the game. Of course if I were to stick some AI in there, I could, but I don't know enough. That will take a ton of work and research just to figure out. And I'd probably run through a hundred tries at the AI before I'd have something that would actually work.

Anyway, this news has me excited. Unfortunately, I'm afraid that I might have to start over on my development of Sever because its current structure may not be comfortable for multiplayer networking. Then again I could be wrong and it might be just perfect. We'll just have to wait and see.


The most important mission of this post is to remind my readers (and myself) that I'm still excited about Sever and I have no intention of dropping it. Thank you for sticking with me, and please stick with me a little longer. Thanks.

clevceo

RefLib

Recently, I've been focusing on another project, codenamed RefLib, which is a game I've mentioned a couple times before as a commission from my boss. It may not be as interesting as Sever since it is much simpler, but it's my first commission and also my first collaboration. Also, it has a deadline: september, so it will also be my first completed project, as Sever and Idea are long-term projects.

Anyway, if you're interested, you can find my new RefLib blog here.

I may get bored with RefLib every once in a while and spend a day or two working on Sever, so don't go away. After RefLib is complete (in september), I plan to get back to work on Sever. Thanks.

clevceo

Grid, GUI, Cosmetics, Settings, Custom Maps

I discovered yet another problem with grid interaction. For those who don't know, I separate all nodes and route sections into a grid so that when searching for collisions, I only have to test the relevant grid squares. This, of course, improves performance. The problem comes when deciding which squares to test with a route, which passes through multiple squares. Unfortunately, though my code worked fine when the slope of the route was positive, when negative it went all over the place. However, I devoted an hour to fixing it and it's working fine now.

I did some more work on the GUI, making it even more flexible. Also, I'd previously been using a font that I'd created myself, but it didn't look too good, so for the time being, I'm using Haettenschweiler, which looks much better. I also bolded and centered the title bars of the forms.

I also changed the node spacing from thick broken lines to a thin solid line that's less distracting. All in all, the game looks pretty good (especially when fullscreen).

What I plan to do next, before I start the fog of war or map objects, is use xml to create a settings file in which I would contain the specs for the different nodes and the settings for the GUI and anything else I would need. That way I can avoid recompiling after every single tiny change (not that it takes a long time to compile). This would also allow for more flexibility. Less hardcoding.

The next step after that is to create custom map functionality. Until I get a better idea of how to implement the fog of war and the geometric map objects, I will do everything I can to create the basis of the maps. The objects and fog will extend what is already there. I think they will be easier to do once I have a better idea how things will work.

clevceo

Grey Outlines

I mentioned a while back that my textures had gray outlines whenever they were shrunk or displayed at a floating point coordinate rather than a whole number. I figured that it might have been the format I was using: png.

The suggested method for transparency in the help files is to use DirectX's texture tool to convert the png to a dds by dragging the png file into the window. I did that and it didn't change anything. So I used gimp to separate the png into two bitmaps: the non-transparency image and the mask, which I then combined in the texture tool. This time, it worked.

Those gray outlines were getting under my skin and I'm glad to be rid of them.

clevceo

Tooltips, Unit Info Window

Last night, on a whim I added tooltip functionality to my GUI library. I will admit right now that it wasn't entirely necessary. I did it because I thought it would be cool. But I'm glad I did because I want my game to be as professional as possible. Any extra features to make it more windows-like and familiar to the average user are welcome.

I also added a unit-info window that shows the picture, name, and description of any nodes or routes your mouse is hovering over. I didn't necessarily need to do this right now, but I was planning on doing it eventually anyway and I thought it would be fun.

If you haven't noticed yet, whenever the next step in the project is big and intimidating, I tend to put it off and work on smaller, less important things. But I'll get to it soon enough.

clevceo

Input and GUI Libraries, Route Placement, Mini Map, Camera Smoothing

The input and gui classes are now fully reusable. Instead of making them components, however, I made them into libraries. Initially, I didn't know what a component was, and now that I do, I realize that they're not suited for the gui and input classes. Anyway, I've simplified them and added readmes to both of them. I figure I'll probably forget how to use them later on and a readme will be helpful.

I did some thinking as to the gameplay and realized a few things that I'd have to change. For example, near the end of a game, one player is at the other player's base trying to sever his central route section. The way I had it before, you couldn't place a route section if it was intersecting one of your own routes. Unfortunately, this meant you could only send one route at a time at the enemy's central route because in that narrow space, you're bound to intersect any other routes you try to send through.

To fix this problem, I now allow the player to place any routes anywhere, but if the route runs into another route or a node while it is building, then it will retract. This allows more flexibility in the gameplay.

I also did some work on the mini map. It is now in its own window that you can move around. The hardest part, however, was displaying the camera's bounds on the mini-map. It turns out that some of my code in the camera class (which I reused from my last effort) was haywire. After hours of trying to debug the dang thing (breakpoints everywhere), I discovered that in one of my functions I had a temporary piece of code that I'd forgotten to remove that was skewing some things.

Anyway, my mini-map is working like a charm now. Everything's going great. I forgot to mention last time that I'd added smoothing to the camera's movements. Rather than zooming out and moving around at a boring static rate, it smoothly moves from one point to another as in professional games.

Next, I think I'll make a geometric object to place on the map. After that's complete, I think I'll create functionality for loading maps from a file, maybe xml. After that, hopefully I'll be able to start work on the fog of war (cross your fingers).

clevceo

GUI, AI, Maps, Cosmetics

As usual, plans change. Instead of getting into the fog of war or even working on the mini-map, I decided to improve the reusability of my gui. I'm trying to remove the dependencies between it and Sever so that I can make it into a component. I have another project I'm beginning work on (it's a commission), and my gui code will come in handy. I'll probably have to do the same for my input classes, but they should be easier. Anyway, it's taking a while.

Sometimes coding can be tiring, especially when you are rewriting or modifying because it's more of a chore than a challenge. So anyway, I've decided to try reading up on AI again. The last few tries failed and my brain just about blew up. However, after all my time working on Sever, my understanding of the underground mechanics of a game has improved tremendously. So this time I was able to run right through the few chapters I read in the book ("Programming AI by Example" by Mat Buckland).

I read up on graph theory and pathfinding. I never knew it was so simple. All of a sudden, ideas have begun rolling on how to implement my AI. I realize it will be a huge challenge, but it will be satisfying just to see it work at all, especially while I wait for multiplayer support in XNA.

Before I do the AI, I want to add some geometric objects on the map (geometric makes it easier for me [a newbie] to do collision tests) so that I don't have to do any recoding with the AI later. Also, the map is currently hard-coded, so I need to allow custom maps to be loaded in. These maps will contain the tiles, objects, pathing info, and any other details they would need. So the AI will have to wait a bit longer.

I did a few cosmetic things. The two central nodes for each player now glow. I also changed the color of the route sections and changed the highlight color of the nodes (which may need to be changed again, because it's hard to see beneath the central nodes' glow).

Comments? Questions?

clevceo

Options Menu, Main Menu Background, People Distribution, Grid Problems, Mini-Map, Textbox

I added the options menu to the in-game pause menu. I also made it so when the resolution changes, all forms on-screen retain positions proportionate to what they were previously (ie. forms in the center stay in the center, forms on the right side stay on the right side).

I also added an interesting series of routes in the main menu's background. They are tinted a dark blue. I also added a gradient to the background that goes from a very dark blue at the top to a...slightly lighter dark blue at the bottom.

As I was creating the routes in the main menu background, I began to notice even more anomalies in the way people are distributed. They would often move to one route section and rotate through it rather than filling up the rest of the routes.

I have a large block of code dedicated to deciding where to direct a person when he reaches a node. Should he turn around? Should he go to the first or the second route on the other side? It calculates which route needs people the most and sends them through.

However, this code being large, bugs are inevitable. My last rendition of this game had many bugs and it didn't quite do what I wanted it to. This time around, I thought I'd done a much better job, and I had, but it still wasn't sufficient. Unfortunately, there were a few things I implemented later on that conflicted with the existing code, so I had to go back and figure out a way to make it work. Unfortunately, I was only able to "jerry rig" it.

So, I completely rewrote the code. I now know better what I am doing and was able to create more organized and robust code than before. Everything seems to be working fine if not better than I've yet seen it work. It was very satisfying to see it work so well.

I also noticed a few problems with the way the game interacted with the grid squares. When collision testing a route through a series of grid squares, only the squares it passes through should be tested. It seemed to be working fine until just now when it missed a few squares. Unfortunately, this code was fairly large as well (smaller, but large enough). So I rewrote it, too. The new code is slightly shorter and more robust. So far, it has worked perfectly.

I've begun to create a min-map that displays all routes on the map. I plan to eventually show the fog of war on it. I thought this would make testing easier for the fog of war when I can see it all at once on the mini-map.

Lastly, I perfected the textbox. You can now use the mouse to move the bar. The bar blinks now, too. I also added functionality that allows a control to decide what cursor to display when the mouse is over it. Thus, the usual "I" cursor is used above the textbox.

After the mini-map is as far as it will go, I will do the fog of war. I've let my ideas brew for the last few days before I get to work on it. Only recently has it sounded so feasible. I predict I will be deep into it tomorrow or the next day after the mini-map is complete.

Comment, please.

clevceo

Endgame Window, Options Menu, TextBox, Fog of War

I created the endgame window and the pause menu. So far, the pause menu has two options: resume and forfeit. Forfeit, of course, destroys all of your nodes, routes, and people and displays the endgame window.

In the main menu (as you can see in the screenshot in a previous post) is an Options button. Until now, that button did nothing, but now it displays an options menu. The menu so far has only one option: windowed/fullscreen. Soon, I'll be adding the options menu into the in-game pause menu.

I also created a textbox control. It wasn't easy, but it's here. I added textboxes to the play options screen to input the player's names. The control needs a little work (it doesn't react to the mouse; you have to use the left/right buttons on the keyboard to move the bar), but it's a big step forward.

I have an idea for how I'll implement the fog of war. I thought of it last night in bed, but it's much more practical and effective than any of the methods I'd thought of previously. Anyway, it's sounding less and less intimidating every time I think about it.

To make the main menu screen a little more visually exciting, I think I'll add some routes in the background arranged in an interesting design, with the people flowing through them as in the game. Maybe it'll be a different design each time.

I've been thinking about sound and music. I want the sounds to be soft and almost soothing. The kind of music that enters my mind whenever I think about it is a soft piano melody that's like that suspenseful music you hear in a movie when the character begins to see that something's wrong.

Comment please,

clevceo

Collision Detection, Fog of War, Post-Game, Graphics

I completed the collision detection for growing sections. I found a bug or two in past code that was surfaced by the severing and retracting going on. It took me a few minutes of frustration to figure out, but I solved it.

There's a logic error I've noticed in how the people run through the routes. Fortunately, this isn't hampering the gameplay, so I've been able to put it off for a little while, but I'll have to tackle that sooner or later.

I began working on the fog of war, but I came upon some crossroads and need some time to think them through, so I instead worked on a simple tile engine for the background. It was fairly simple and was easy to build from start to finish. I've created a single tile that covers the entire map for the moment.

Now, while I'm still thinking the fog of war through, I'm going to create an post-game window that declares the winner and shows scores. An okay button at the bottom of the window will send you back to the main menu. I also need a pause function in-game that displays a list of options, including an Abort option. This way, I can start a new game without having to shut the game down.

I have to do some thinking with the graphics. The bitmaps when displayed at an unusual scale or location (floating point rather than a whole number) tend to have a grey outline. It may be due to the format I'm using (.png), when I could be using a bitmap with a mask. I'll try that and see if it fixes things.

Questions? Comments?

clevceo

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

GUI, State Machine, Sound

I've made various updates to the gui. I made the main menu more functional and created a "play options" menu where you can choose the number of players and start the game. As I went, I fixed any bugs that cropped up and added a few more features, like a Label control. A favorite of mine is the messagebox dialog which is created the same way it is in Windows Forms: "clsMessageDialog.ShowMessage(string Message);". This way the code can alert me of errors without having to throw an exception. There are a few more improvements to make that I can think of at the moment, but I'm sure there'll be plenty of changes in the coming weeks/months. I'm still looking into clipping, but nothing has yet come up. Maybe I'll leave it be.

The state machine underwent some big improvements. It is now "far" along as opposed to "far enough" along.

Soon, I'll get to work on sound. I want to prepare as many helper classes as I can before I dive back into the game engine because I want to develop it knowing exactly what resources I have.

Comment please.

clevceo

GUI, sound, procedural content

The state machine is just far enough along to test the GUI, which is now functional. I have a form control and a button control that are working wonderfully. I also learned to use the sprite font functionality added in the latest XNA update, and it is working wonderfully as well. I created a quick main menu form with "Play" and "Exit" buttons. It's amazing how easy it is now that I've made this helper class. I'm planning on using the class for the in-game heads-up display as well.

The only problem so far with the class is that it isn't totally independent. I'll need to put some work into it before I can reuse it in future projects. And I don't think I'll be releasing the source code. Besides, you can probably find better implementations elsewhere. I refuse to use them myself because I want to learn it the hard way. The hard way is the best way. I'd thank you to remember that.

One thing I haven't figured out yet with the gui is clipping. The only way I can imagine is to create a new texture for each control, but that would eat the resources. Maybe I'll leave it as it is and refrain from having any graphics on my controls that might run over the edge.

I'll finish up the gui quickly and maybe go on to a sound helper class. Maybe I'll test it with my gui. A "click" sound will play when you press a button. I don't know how much help the book will be. He'll want me to use his helper class again. I have a hard time reading code that isn't mine. Maybe I need to brush up on those skills, but I don't have the patience for it now. Besides, I want to figure out how to make the helper class myself. I don't want to copy his code. All I want are the base sound classes.

By the way, I've been looking into procedural content lately and I found this little post on Introversion Software's dev blog for their new game Subversion. They've created an engine that generates a city from scratch in a couple minutes. They even has a video demonstration. If you're interested, you can check it out here.

clevceo

GUI, state machine, input, cursor

The base GUI helper class is basically complete and is ready for testing. However, the game isn't far enough along to test it yet, and I don't feel like taking the extra time to make a unit-test. Thus, I am now working on structuring the core game loop.

I'm creating a state machine that's a little cleaner than my last rendition. This time, each state has its own class, rather than all states being contained in one big class.

The input helper class is complete. I unit tested the mouse and keyboard input and they're working great, but I have yet to test the gamepad. The great part about the new input class is how customizable it is. For example, one player can have controls on multiple different inputs. The A button on gamepad 1 shoots and the B button on gamepad 2 jumps. Maybe shift on the keyboard runs. Heck, if I wanted to, I could assign one button to multiple players. I could even treat a control stick as a button. If it's moved in one direction a certain amount, it will be considered "pressed" like a button. This would work nicely for the triggers.

I unit tested the mouse with a new cursor class I made, which is working like a charm. It doesn't use the exact position of the OS's cursor. Instead, it has its own position and uses the movement of the OS's cursor to move. Also, it uses my input helper class, which means I can easily change what controls the cursor. For example, I could easily have the gamepad to control the cursor without much change to the code.

clevceo

GUI

I made some finishing touches to the input helper class and to the overall structure of the game, and then went to work on some interface stuff. I've basically copied Windows's method with a Control class, Container class, and all their methods and events, like OnPaint and MouseDown. I'm making some great progress on it. I have a cursor class that utilizes my input helper class to work, and once I get the basics of the gui going, I'll go on to make some controls like buttons, labels, and a few others. Eventually, I'll make a textbox. That will be an experience. And once I have all of these made, I think I'll somehow separate them from the game as a component that I can reuse in the future.

I've been thinking alot about the fog-of-war. I have a general idea of how I want to do it. However, I've also been thinking about adding "objects" to the map, obstacles that you would have to build around, so the map wouldn't be one big open area. It only makes sense. However, I've also been thinking that it would be interesting to make these objects affect the fog-of-war, so that if someone was building on one side of an object, they wouldn't see the other side. This would open up some interesting gameplay possibilities. However, I'm not sure exactly how to implement that. I'm not even sure how I'll implement the "objects" and all the collision testing involved.

Next in line is sound, which sounds pretty easy (no pun intended, really) with XNA.

Anyway, that's it for now. Comment.

clevceo

Book, Progress

The book isn't quite what I expected. He doesn't detail all the important classes like I wanted him to. Instead, he provides his own helper classes and shows me how to use those. However, he still tells the most important concepts, so I've been trying to figure out the classes from those. I really don't like using someone else's code if I don't have to. Another book is coming out in june written by someone from the XNA team. I hope that one is better.

Anyway, I've made progress. The one thing I've reused so far from the last run is the camera (psuedo-camera, 2D) class because it has alot of math I'd have to work through again. Unfortunately, since I wrote it, I discovered that there are more efficient ways to do that math, so I'll eventually have to rewrite alot of it anyway.

I redid my input helper class, which is now much more flexible and data-driven. Overall, things are going well. The structure is much more cohesive and organized than it was before. Now that I see the big picture, the development is much more efficient and effective.

And by the way, still no problems with Vista.

I just wanted to post my progress so my readers don't think I'm gone. I will finish Sever. I promise.

clevceo

Book

The Book has come, Wrox's Professional XNA Game Programming For Xbox 360 and Windows, by Benjamin Nitschke. I've only read the first chapter, but I've seen enough to know that there's alot I can learn, and thus alot I can change in Sever's structure. Hopefully I'll have time in the next few weeks to read through it so I can get back to work on Sever.

Anyway, this hiatus is only temporary so I can read up on XNA and become more productive and effective in my progress with Sever. Please keep checking back. I'll update on the things I'm learning and the ideas I'm coming up with for Sever. Thanks.

clevceo

Starting Over, Book

I've had some ideas for the game the game that would require starting over, and I've been considering that anyway because I know what I'm doing now and I could really clean it up. Just yesterday I ordered a book on XNA. It's about time someone wrote a book on it. Anyway, this book should enlighten me and give me even more ideas, so at the moment, I'll put coding on hold and write my ideas down for later after I've read some of the book and have a better idea of the direction I want to take.

Comment.

clevceo

Player-to-Player Interaction, Victory Screen

The players can now sever each other's routes. Also, if one severs the other's source route that connects his two central nodes, the victory screen now pops up with the players' statistics. There are a few more tasks to complete concerning player interaction before I move on to the next step, which I think will be fog of war. But you never know.

clevceo

Vista, Busy

Vista is up and running just fine. The only trouble I had was connecting to the VPN at work, which I finally figured out was a problem with the firewall. I tested the game and it ran flawlessly.

Finals week is coming up, so time is precious. I've been pretty busy lately outside school as well, so I haven't made any progress in over a week.

Hopefully I can soon get back to work. I'll first allow interaction between players, and then I'll get started on the fog of war. That's the plan for the next few weeks. Comment.

clevceo