I have concluded that if I am to come back to Sever in two years, I would be smart to throw something together that I can come back to. So I collected all the gameplay decisions and ideas together and made a small and crusty excuse for a design document. And then I decided it might be cool to post it up here because I figure there are probably alot of people that are confused about how this game works. You pick up bits and pieces here and there, but finally I have the whole thing in one spot right here in the design document. Let's just hope that it's clear and makes sense even though the grammar isn't all that great.
Sever Design Document
General premise
Player consists of a series of nodes connected by paths in a hierarchical form, all leading back to one node.
Different kinds of nodes have different uses. Some only allow one path to branch from it while others allow more. Maybe some allow none.
Each path is like a two-way street with little people walking each way. When a person reaches the next node, he decides which of the following paths to take depending on which needs him the most. This is decided based on a preset formula designed to keep the population spread out evenly throughout the route system.
People are generated by certain nodes at a regular rate or some other rate to be decided later.
People move at a regular speed through the paths. Sometimes, all paths at a junction may be full, in which case people stop moving and wait for an opening. All people following are stopped too.
Some nodes accelerate people that pass through them. The people then gradually decelerate to their regular speed. However, they will slow to match the speed of anyone they run into that’s moving slower than them; or maybe the two colliding people will agree on an average speed, slowing the faster one and speeding up the slower one.
There are certain hot spots on the map that a player can build a node upon that will grant him certain bonuses. For example, one might generate people. Another might increase the speed of all people within the system, or increase the length each person adds to a path under construction, or maybe one decreases the number of passes required to build a node. Maybe the player’s first node is built on a spot that generates people and that’s why it’s so important.
There may be neutral, prebuilt routes with or without people inside them that can be claimed by you or an enemy by building a path to its parent node.
Obstacles in a map will be geometric vectors that cannot be intersected.
How the player creates his route system
To build a new node and path, the player clicks on a node with an open slot and drags to a new location, meanwhile right-clicking to cycle between the different kinds of nodes. Each kind of node requires all other nodes owned by the player to be a certain distance away from it, and they cannot touch enemy nodes. When he lets go, people begin to build a path to it.
A path that is being built increases in length each time a person reaches its end. The person then turns around and heads back the way he came. When the path reaches its full length, they begin to build the node. Each node requires a certain number of passes from people to be built. Until it is built, it is unusable. People that pass by it act normally and turn around to head back the way they came.
A player may retract a set of routes by right-clicking a node. All routes following the node will retract. When a set of routes retract, the nodes at the ends are destroyed and their paths gradually shrink in length. A node is only destroyed when all of its branches have shrunk completely, after which its parent path begins to retract. Meanwhile, the people inside the retracting routes rush out to the rest of the system and nobody enters them. If the rest of the system gets overcrowded and jams, the remaining people will die when their paths are destroyed.
A player may also sever his routes by right-clicking a path. This will do the same thing as retraction, except it will start from the route that was clicked and go forwards. When a node is destroyed, all of its branches will begin to shrink towards the following nodes. In this case, all people inside are destroyed. However, to show humanlike behavior, they will all rush to the tips of the routes to escape the destruction, not realizing the inevitability of their deaths.
Retraction is useful when the player needs to get rid of a certain set of paths while salvaging the people inside them. The process may take a while, so he must have the time for it. If he needs the space or to use the parent node fast, or he already has a fairly crowded system, severing is the better choice.
A player may build a path to another of his own nodes if that node is not a parent of the one he is dragging from. When the new path reaches the node, the node’s current parent path will retract and be replaced by the new one. This allows the player to reorganize his system without destroying everything.
Interaction with the enemy
A player may sever another player’s routes by intersecting his with theirs. If a route intersects another route, the game will measure which route’s end is closest to the intersection to determine which ran into which. The closest will retract and the furthest will sever. This is how the player attacks his enemy.
When a player is reduced to his first node, he loses.
One offensive technique is to build an accelerator node, then start building paths aiming at the enemy, then sever them fast, and repeat. The people inside will be moving so fast that they will build as fast as the path severs and will act as a projectile. If the player is fast enough he will create a machine gun effect and the enemy will only be able to block so many before they get through. Of course the player will be sacrificing precious people to do it, but the enemy will hurt more if the player is successful.
When an enemy severs one of your routes, you can save the following routes by building a route to one of the endangered nodes, thereby disconnecting it from the destruction.
It may be smart to have accelerator nodes around so that you may quickly intercept any attacks.
Possibilities for the future
There may be a “capture” feature where the player can somehow capture enemy routes and the people inside them. I’m not sure how this would happen, but it sounds pretty cool.
Fog of war may or may not be implemented in the game depending on whether it is feasible. It really depends on how I implement the AI and whether the AI can deal with the fog of war intelligently. Also, it may just be cut if it doesn’t add to the game.
There’s also the faint possibility of a 3D world. In this case, maybe people move faster downhill and slower uphill, and hills affect fog of war. This would also require more coding and processing, and I don’t know that it would add a whole lot to the game unless I can think of some more gameplay features to validate it. And the features must be worthy. You can’t just add features unless you can make them essential to the core of the game.
THE END
Well, that's what I've got. See you in two years!
clevceo
Monday, December 1, 2008
Saturday, November 8, 2008
I'll Be Back
It's been a loooong time since I last posted. I'm still alive and well, though I haven't touched Sever for a while. In fact, I think I last touched it around the time I last posted. I was trying to build that new tech demo. But I became preoccupied with alot of new things, and alot is changing in my life, so my projects have been put on the backburner. In fact, there was a short time when I thought they'd be dropped indefinitely, but in the last few months, my desire to complete them has returned. However, my plans for the next two years will be occupying my full attention and I cannot work on the projects in the meantime.
For the next two years I'll hardly touch a computer, except for email. In fact, I'll have to relearn quite a bit of the knowledge I've picked up over the years, but it should come back quick. There will also be plenty of new stuff to learn after two years of absence.
For some reason I always feel the need to say how important to me Sever is. Right now, I feel it's important to express it to show that I really do want to come back and finish it in two years. Also, I want to remind myself of its importance.
Sever is my baby. I've always dreamed of creating something truly unique, and here it is. I remember vividly the night I thought it up. I had played Introversion's Defcon, and I'd read Chris's rants against content, and I decided to drop my current project, which was an isometric RPG engine. At the time, I thought the RPG engine was fun and exciting, but in the back of my mind I knew that I didn't have enough time to create an entire RPG by my inexperienced self.
It was disappointing to drop it for sure. It was hard to admit to myself the impracticality of my efforts. It was the first project that I really hoped would work. In the past, I'd made tiny QBasic games, like an ASCII fighting game and a really bad partially completed text adventure. But my hugest past effort was a QBasic tile-based top-down RPG engine, which I'd made alot of progress on. In fact, though I took a hiatus to focus on other things, I planned to come back to it, and finally did only to find all my code missing. So naturally, I was really disappointed, and when I found Microsoft XNA, my first thought was to recreate my RPG engine.
However, my QBasic RPG was more practical because of the 10x10 pixel tiles, 256 colors, and really simple mechanics. The new engine was much more ambitious and I just didn't have the variety of skills required, much less the time. So I was easily convinced by Chris to drop it altogether.
I was sitting on my couch at my parent's house that summer two years ago (wow, I can't believe it's been that long), thinking about what Chris said about content. I had already stopped working on the RPG and I was wondering to myself what kind of game I could make with minimal content. My first thoughts were casual games, but I had no interest in casual games, playing or creating. I began to doubt that I would ever think of anything.
I forget where the idea came from (I wonder if I've posted about it before; I should check), but when it came, it slowly became my focus that night. I remember it starting more as an idea passing through. I gave it an audition, thought it through a bit, and suddenly I began to realize that it was real. Of course, the mechanics were a bit different to begin with. Each node was a "building" akin to a traditional RTS.
The following morning, I began coding. It was at this point that I began reworking the idea, removing and adding until it became the jist of what it is now. And at the time it was so fresh and new that I hadn't had the code structure thought up yet, and I was still learning XNA, so it took a few days just to get everything to show up on screen. And when that finally happened, I was tired of my messy code and I'd thought of a hundred ways I could do it better if I started over, so that's what I did.
On my second try, I got everything on screen a little faster and finally came to the point where I needed to code the user inputs if I was to get any farther. I believe I reused a bit of my input code from my RPG engine. Finally, I was starting to think up the controls. It all came simply. The game doesn't ask for complex controls. It's all really smooth. I programmed the ability to create a new node. But then came the big problem of getting the little guys to move into the new segment (called a section at the time) and build it.
This became a huge ordeal. Though there was only one segment to move into, I knew that there would be more in the future, so I tried to code with that in mind. One thought was to decide randomly, but that was the easy way out and the people would take forever to spread into newly built segments. There needed to be something more intelligent. So I decided to calculate which path needed the person more by use of simple statistics.
I created a recursive function in the segment code that would run through every segment after it and return its person/length density and eventually created an average density so that the person could pick out the least dense. Basically, the people try to keep the entire system's density even. So if the player builds a new segment, the people will sense that there are no people in it and try to congregate to it.
Anyway, with my messy coding practice, this was all a jumbled pile of spaghetti. However, I finally got it to work without crashing, so I moved on. I created a few new nodes, one that split the route into two, and one that accelerated the people passing through. At this point, I realized that I needed collision detection.
The collision detection took me a bit to figure out, mostly because I thought up the formulas in my head rather than finding them online...well all but one. I've always enjoyed figuring stuff out myself and seeing it work, and I have a knack for math. So I figured out most of the formulas successfully, but for the life of me I couldn't figure out the line intersection formula, so I finally looked it up and discovered that it was long and I wouldn't ever figure it out by myself.
So I figured that out and it was working fine. But I was beginning to get bored of programming the mechanics, so I decided to make a menu screen. I first developed a quick text-drawing function and made a simple font to use, then made a very simple button class and threw together a quick and dirty menu screen. It wasn't very pretty, but it was fun.
It was time to return to the gameplay, but I'd thought up so many things I could do better (sound familiar?), so I dropped it again and started over. Until then, I had created all my code from scratch and put it straight into the game code, but I was beginning to consider making a separate framework first that I could reuse and improve aside from Sever. So I created an input and gui library (both of which I'm quite proud of), then created a state machine class that would handle switching between game screens, and I created some more doodads to make things easier for myself. And then the game coding started.
I optimized alot of my previous code and added some more functionality. It was much better. I also took my camera class, which I'd reused from my RPG engine, and gave it a makeover, optimizing it and smoothing the zoom and motion. I added a tiled background, created a mini map and a unit info window, a grid system that would allow me to do collision detection on only nearby units, figured out collision detection with enemies, added support for severing and retracting, created a rad menu screen, and, and, and... It was pretty cool. I was proud of it.
However, I was planning to add multiplayer support and had been coding with that in mind. Unfortunately, I'd never worked with multiplayer before, so when XNA 2.0 finally came out with multiplayer support, I discovered that there was alot of reworking to be done. I decided that the game could be improved even more if I started over again with my new knowledge. I was really bummed because I'd invested alot of time into that draft and had plans for some new features such as fog of war and some simple AI. But it had to be done.
Since I was starting over anyway, I figured I might as well give the entire thing, framework and all, an overhaul. I redid alot of my input class and optimized and extended my gui class (both of which are now awesome in my mind). I redid my state machine code and created my own game class that brought all the framework code together and managed more than it did before. I created a drawing layer system that would manage when things are drawn and in what mode.
I created a quick menu that would manage the multiplayer settings and dove into the gameplay. As usual, I started from scratch on all the code, improving it drastically, removing old discrepancies and preventing future theoretical problems that were present in my old method, and optimizing the processing. It was also more flexible, opening more doors down the road. I also added a couple more gameplay features that I'd thought up.
And then I began to create the networking code. It was confusing, since I'd never done it before, but I worked and reworked my code (as I always do with new things). But as I became more and more confused, I thought I'd give it a rest and come back to it. I decided that I would redirect my attention to a new project: the map editor.
I'd created some new sprite code, a background tile class, and a brand spanking new geometric boundary class (lines that the player cannot cross), and put them into the new map editor. I made it pretty easy to use with instructions and everything. It had a nifty interface and...gosh it was pretty cool. So I made a map with it and made it the default map when the game loaded.
Then I went back to the game. There was more to do on the map editor, but the most important part was done and there was something more urgent to do, namely the network code. But goodness me, the networking code was confusing! And problems kept coming up.
So I decided that I would release a quick demo of what I had online to get a little attention (and motivation), but I had to do some touching up first, which proved too frustrating in and of itself, so I decided to start over and create a quick proof-of-concept multiplayer game without any frills so that I could focus on the networking and forget all the other stuff. But it was at this point that I became preoccupied with all the new stuff going on in my life.
And there you go. That's the story.
I've invested so much time into this game and I still plan to complete it. However, I still think I'll create a proof-of-concept first so that I can focus on networking and maybe create a small framework for it to use in the full game. That would be the smartest thing to do. And then I'm not sure whether I'll continue the last iteration or start over again, but I have a feeling I'll do the latter, especially since there'll probably be a new XNA with different requirements and so forth, requiring me to make some changes anyway. Plus, my old code might be unfamiliar by then.
So anyway, I plan to finish the project. Please come back in two years. Until then, goodbye.
clevceo
For the next two years I'll hardly touch a computer, except for email. In fact, I'll have to relearn quite a bit of the knowledge I've picked up over the years, but it should come back quick. There will also be plenty of new stuff to learn after two years of absence.
For some reason I always feel the need to say how important to me Sever is. Right now, I feel it's important to express it to show that I really do want to come back and finish it in two years. Also, I want to remind myself of its importance.
Sever is my baby. I've always dreamed of creating something truly unique, and here it is. I remember vividly the night I thought it up. I had played Introversion's Defcon, and I'd read Chris's rants against content, and I decided to drop my current project, which was an isometric RPG engine. At the time, I thought the RPG engine was fun and exciting, but in the back of my mind I knew that I didn't have enough time to create an entire RPG by my inexperienced self.
It was disappointing to drop it for sure. It was hard to admit to myself the impracticality of my efforts. It was the first project that I really hoped would work. In the past, I'd made tiny QBasic games, like an ASCII fighting game and a really bad partially completed text adventure. But my hugest past effort was a QBasic tile-based top-down RPG engine, which I'd made alot of progress on. In fact, though I took a hiatus to focus on other things, I planned to come back to it, and finally did only to find all my code missing. So naturally, I was really disappointed, and when I found Microsoft XNA, my first thought was to recreate my RPG engine.
However, my QBasic RPG was more practical because of the 10x10 pixel tiles, 256 colors, and really simple mechanics. The new engine was much more ambitious and I just didn't have the variety of skills required, much less the time. So I was easily convinced by Chris to drop it altogether.
I was sitting on my couch at my parent's house that summer two years ago (wow, I can't believe it's been that long), thinking about what Chris said about content. I had already stopped working on the RPG and I was wondering to myself what kind of game I could make with minimal content. My first thoughts were casual games, but I had no interest in casual games, playing or creating. I began to doubt that I would ever think of anything.
I forget where the idea came from (I wonder if I've posted about it before; I should check), but when it came, it slowly became my focus that night. I remember it starting more as an idea passing through. I gave it an audition, thought it through a bit, and suddenly I began to realize that it was real. Of course, the mechanics were a bit different to begin with. Each node was a "building" akin to a traditional RTS.
The following morning, I began coding. It was at this point that I began reworking the idea, removing and adding until it became the jist of what it is now. And at the time it was so fresh and new that I hadn't had the code structure thought up yet, and I was still learning XNA, so it took a few days just to get everything to show up on screen. And when that finally happened, I was tired of my messy code and I'd thought of a hundred ways I could do it better if I started over, so that's what I did.
On my second try, I got everything on screen a little faster and finally came to the point where I needed to code the user inputs if I was to get any farther. I believe I reused a bit of my input code from my RPG engine. Finally, I was starting to think up the controls. It all came simply. The game doesn't ask for complex controls. It's all really smooth. I programmed the ability to create a new node. But then came the big problem of getting the little guys to move into the new segment (called a section at the time) and build it.
This became a huge ordeal. Though there was only one segment to move into, I knew that there would be more in the future, so I tried to code with that in mind. One thought was to decide randomly, but that was the easy way out and the people would take forever to spread into newly built segments. There needed to be something more intelligent. So I decided to calculate which path needed the person more by use of simple statistics.
I created a recursive function in the segment code that would run through every segment after it and return its person/length density and eventually created an average density so that the person could pick out the least dense. Basically, the people try to keep the entire system's density even. So if the player builds a new segment, the people will sense that there are no people in it and try to congregate to it.
Anyway, with my messy coding practice, this was all a jumbled pile of spaghetti. However, I finally got it to work without crashing, so I moved on. I created a few new nodes, one that split the route into two, and one that accelerated the people passing through. At this point, I realized that I needed collision detection.
The collision detection took me a bit to figure out, mostly because I thought up the formulas in my head rather than finding them online...well all but one. I've always enjoyed figuring stuff out myself and seeing it work, and I have a knack for math. So I figured out most of the formulas successfully, but for the life of me I couldn't figure out the line intersection formula, so I finally looked it up and discovered that it was long and I wouldn't ever figure it out by myself.
So I figured that out and it was working fine. But I was beginning to get bored of programming the mechanics, so I decided to make a menu screen. I first developed a quick text-drawing function and made a simple font to use, then made a very simple button class and threw together a quick and dirty menu screen. It wasn't very pretty, but it was fun.
It was time to return to the gameplay, but I'd thought up so many things I could do better (sound familiar?), so I dropped it again and started over. Until then, I had created all my code from scratch and put it straight into the game code, but I was beginning to consider making a separate framework first that I could reuse and improve aside from Sever. So I created an input and gui library (both of which I'm quite proud of), then created a state machine class that would handle switching between game screens, and I created some more doodads to make things easier for myself. And then the game coding started.
I optimized alot of my previous code and added some more functionality. It was much better. I also took my camera class, which I'd reused from my RPG engine, and gave it a makeover, optimizing it and smoothing the zoom and motion. I added a tiled background, created a mini map and a unit info window, a grid system that would allow me to do collision detection on only nearby units, figured out collision detection with enemies, added support for severing and retracting, created a rad menu screen, and, and, and... It was pretty cool. I was proud of it.
However, I was planning to add multiplayer support and had been coding with that in mind. Unfortunately, I'd never worked with multiplayer before, so when XNA 2.0 finally came out with multiplayer support, I discovered that there was alot of reworking to be done. I decided that the game could be improved even more if I started over again with my new knowledge. I was really bummed because I'd invested alot of time into that draft and had plans for some new features such as fog of war and some simple AI. But it had to be done.
Since I was starting over anyway, I figured I might as well give the entire thing, framework and all, an overhaul. I redid alot of my input class and optimized and extended my gui class (both of which are now awesome in my mind). I redid my state machine code and created my own game class that brought all the framework code together and managed more than it did before. I created a drawing layer system that would manage when things are drawn and in what mode.
I created a quick menu that would manage the multiplayer settings and dove into the gameplay. As usual, I started from scratch on all the code, improving it drastically, removing old discrepancies and preventing future theoretical problems that were present in my old method, and optimizing the processing. It was also more flexible, opening more doors down the road. I also added a couple more gameplay features that I'd thought up.
And then I began to create the networking code. It was confusing, since I'd never done it before, but I worked and reworked my code (as I always do with new things). But as I became more and more confused, I thought I'd give it a rest and come back to it. I decided that I would redirect my attention to a new project: the map editor.
I'd created some new sprite code, a background tile class, and a brand spanking new geometric boundary class (lines that the player cannot cross), and put them into the new map editor. I made it pretty easy to use with instructions and everything. It had a nifty interface and...gosh it was pretty cool. So I made a map with it and made it the default map when the game loaded.
Then I went back to the game. There was more to do on the map editor, but the most important part was done and there was something more urgent to do, namely the network code. But goodness me, the networking code was confusing! And problems kept coming up.
So I decided that I would release a quick demo of what I had online to get a little attention (and motivation), but I had to do some touching up first, which proved too frustrating in and of itself, so I decided to start over and create a quick proof-of-concept multiplayer game without any frills so that I could focus on the networking and forget all the other stuff. But it was at this point that I became preoccupied with all the new stuff going on in my life.
And there you go. That's the story.
I've invested so much time into this game and I still plan to complete it. However, I still think I'll create a proof-of-concept first so that I can focus on networking and maybe create a small framework for it to use in the full game. That would be the smartest thing to do. And then I'm not sure whether I'll continue the last iteration or start over again, but I have a feeling I'll do the latter, especially since there'll probably be a new XNA with different requirements and so forth, requiring me to make some changes anyway. Plus, my old code might be unfamiliar by then.
So anyway, I plan to finish the project. Please come back in two years. Until then, goodbye.
clevceo
Wednesday, March 12, 2008
Tech Demo, Smaller Demo, Hiatus
You've probably noticed that the tech demo is still yet to be released. I have one last thing to do before it's complete, but it's intimidating. I have to rework some code that I've already written, and that always means trouble. If I rework this code, I have to rework that code, and that code, and that code, too. Plus, I haven't touched Sever since December, so I'm bound to forget a few things.
Why haven't I been working on it? I'm busier than heck this semester. If I work on Sever, I have to put off homework. It's as simple as that. But the summer sounds more promising.
Now, I had an idea recently that may change my plans. In the past, I've made alot of progress on the game only to change my mind about a few things and start all over again. I'm thinking I might change my method. So far, I've tried to make a fully functional game engine, but now I think I might start over and make something smaller. I'm not giving up on my current draft, but I might stop before I get too far.
If I can make a small, easy version that only demonstrates the game mechanics without having to worry about the GUI, grid, and so forth, I can finish it quicker and will have more room to experiment. That way, I can get the mechanics down before I create the real game engine. Plus, I'll have something fully playable to show in less time. If I keep going the way I've been going, it'll be a while before I have something playable, which, as I'm about to tell you, means a few years.
In the fall, I'm going to leave for two years and I won't be working on any of my projects for that time. However, I plan to pick them back up afterwards. That is, if I'm still interested. I hope so.
Anyway, that is what's running through my head at the moment. If I have the time, I'll keep you updated on the tech demo and the smaller demo. Thanks for reading.
clevceo
Why haven't I been working on it? I'm busier than heck this semester. If I work on Sever, I have to put off homework. It's as simple as that. But the summer sounds more promising.
Now, I had an idea recently that may change my plans. In the past, I've made alot of progress on the game only to change my mind about a few things and start all over again. I'm thinking I might change my method. So far, I've tried to make a fully functional game engine, but now I think I might start over and make something smaller. I'm not giving up on my current draft, but I might stop before I get too far.
If I can make a small, easy version that only demonstrates the game mechanics without having to worry about the GUI, grid, and so forth, I can finish it quicker and will have more room to experiment. That way, I can get the mechanics down before I create the real game engine. Plus, I'll have something fully playable to show in less time. If I keep going the way I've been going, it'll be a while before I have something playable, which, as I'm about to tell you, means a few years.
In the fall, I'm going to leave for two years and I won't be working on any of my projects for that time. However, I plan to pick them back up afterwards. That is, if I'm still interested. I hope so.
Anyway, that is what's running through my head at the moment. If I have the time, I'll keep you updated on the tech demo and the smaller demo. Thanks for reading.
clevceo
Subscribe to:
Posts (Atom)