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