Skipping Ahead

I started out basically retyping all my old GUI code. Of course, that is a really inefficient way to go about things when I could easily copy all the old code files into a new project and build them under the new version of XNA, but I thought that I would get to know the code if I did it this way. However, as time passes and I realized that it would take forever and by the time I was done, I would probably only remember the few things I had just copied and forget the rest, I decided to just do it the efficient way. I did the same for my input library.

Since I was on a roll, I started to copy old game files into my new project, like the state machine, the grid system, the camera, etc. Basically all the stuff I did not think about for the last two years so that I would be able to skip ahead to the stuff I did think about. Frankly, I am a bit rusty and I do not think I am ready to start over completely yet. Right now, I am going to focus mostly on gameplay. Of course, if I run into something I want to change or add with the other code, I will, but that will be the exception.

Honestly, with how rusty I am now, having not programmed for two straight years, I do not think I could write that code any better than it already was. Maybe later when I get my groove back. Then again, I think it is plenty good for what I need anyway. It is decent code. I am proud of it. It is fun skimming through it and admiring my work.

There you go. I am skipping ahead, which is a good sign that this build will not be my last. I will not do any skipping on my last build.

One thing that is daunting is networking. For all I know, it will be easy, but I would not know. I started coding it in my last iteration, but I did not complete it. I was never even able to test it. But I will figure it out. I know I will. It is not impossible. AI, however, may be out of my range of skills.

Thanks for reading,

clevceo

I'm Back

I'm back and I can continue work on Sever. When I got back, I bought a new laptop, a Pavilion dm4, which, despite the integrated graphics, has decent hardware for its modest price. I tried to pick back up on Sever, but when I tried to run the build, it gave me an error "No suitable graphics card found." I stopped breathing for a moment. For a few days, I didn't touch Sever and wondered if I'd just drop it or if I'd just go straight to C++. However, I'm taking a Java course (I haven't fiddled around with Java in years) this semester and I don't think it would be very fun juggling those two different languages. It would be much easier to juggle C# and Java because they are fraternal twins.

Just now, as I was writing a post about how I wasn't sure how I'd proceed, I had the wild idea to google the error and see if there's a way around it. Hip hip hooray, I found it. Basically, I change the project from a HiDef profile to a Reach profile, which is more limited, but can run on lower-end hardware, including phones. Since Sever is fairly simple graphics and input-wise, I don't find this a problem. And besides, by the time I get skilled enough that those limits get in the way, I'll probably have a better computer.

So there it is. I'm back and I'm ready to get started. But first, I have to re-familiarize myself with C#, XNA, and my code. That will take a little time. I'm basically running through all the code from my last build so that I can remember what it is, and I'm revising it as I go. I have some changes to the gameplay code that I'm looking forward to trying out.

I'll tell you what happens.

clevceo

One Month

In only a month, twenty-eight days to be exact, I will be free to pick back up where I left off. There will be some things to do before I put my full attention to it, buy a new laptop for example, but it will happen.

I have been considering a few things that I might do different this time. For example, I want to make the switch to C++ and OpenGL at some point. However, that won't happen immediately. Even with C#, I spent alot of time just building the groundwork. The groundwork is like the roots of a tree. If the roots aren't strong, the tree can't grow as tall. Hence my starting over so many times: the roots needed some work. Thus, with all the extra work required with C++ and OpenGL, I want to know exactly what the framework will need to do, so I will first create a working model of the game with C# and XNA.

Those are my thoughts. I do not know if anyone has been reading this blog, especially since the hiatus, but if anyone is there, please be patient for one more month. For all I know, this post will be read for the first time a year from now. If so, I hope you enjoyed looking back at the early development of Sever, and I also hope that your interest was spawned by the popularity of the game.

Thanks for reading,
clevceo

3 More Months!

In 3 more months, Sever will be back. Sever has been on my mind almost constantly for the last couple weeks. I have been thinking the gameplay through, making changes and added new elements. I am excited to get started. The game is more well-thought out, though there are still alot of things to sort through.

I think this hiatus has been healthy. I have been able to step back and look at the project from a distance, see its flaws, and fix it up a little bit. I am excited to work on it again and apply my ideas.

3 more months!

clevceo

5 More Months

Five more months and I can pick Sever back up. I can't believe it's been this long already. Time has flown. Sever only occasionally crosses my mind. I haven't touched it for over a year and a half. But it'll be back on track before you know it. However, it will probably be started from scratch. Like I said last time, I have alot to relearn and there's alot of new stuff coming out all the time so it's a good thing.

clevceo

11 More Months!

Eleven more months before I can come back to Sever!

I've been thinking about Sever alot lately. I miss it so much. In my free time I've played around with a few ideas for it and have written them down, but I haven't been able to sit down and work on the project for the last thirteen months.

In eleven months, I will pick the project back up out of the ashes and revive it. I haven't done any coding for a while, so I'll be rusty and technology has changed besides, so I'll have to relearn alot. But hey, I've done it before. I can do it again. Have no fear, clevceo is still here.

clevceo

Design Document

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