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
Thursday, December 6, 2007
Wednesday, December 5, 2007
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
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
Tuesday, December 4, 2007
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
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
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
Sunday, December 2, 2007
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
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
Saturday, December 1, 2007
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
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
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
Subscribe to:
Posts (Atom)