The better part of the day was spent on Sever. It's coming along nicely. I've completed the segment's distribution code. In fact, the node and segment code are nearly complete (ready to test). I'm now creating the player classes, different ones for local, remote, Human, and AI players.
I've been reading more into the networking and all of a sudden it looks deceptively simple. Since I won't be sending person data over the network, network traffic should be low. All I'll send are changes in a player's state. For example, if he adds a node and segment, if a segment's length changes, or a node or segment disappears. And for severing and retracting, which change every frame, instead of updating the length I'll send the rate at which they are shrinking, and update the length on the recipient's PC. This would decrease traffic tremendously.
Though I've yet to test it, I have a feeling I'll be left with alot of room left over. However, that's not a bad thing. In fact, it would keep the performance up and be easier to run on worse connections. Plus, for all I know I might be adding more features later on down the road.
I've been keeping single-player in mind as I work. As mentioned in the past, the enemies will be a mindless growing mathematical pattern rather than a dynamic thinking foe. Though there isn't much to that, I have a few reasons for it. First off, it would be fun to play. Single-player always gives a different kind of satisfaction than multiplayer. Second, some people don't always have a connection to the internet, which would render the game unplayable without single-player. Third, should I create a more complex AI later on, the game would be ready for it.
Vids coming soon.
Suggestions? Questions?
clevceo
Friday, November 30, 2007
Thursday, November 29, 2007
Distribution
I've made a whole lot of progress on the gameplay. So far it's a ton easier than it was the last few iterations, I think due to my increased experience and the improvements in the design. The design is much better.
The toughest part before (and one of the biggest overhauls this time around) was the distribution of the people. When a person reaches the end of a segment and has multiple directions to go (including turning around), he picks based on which way needs more people. This requires some math thinky.
However, if all the lanes are full, he can't pass through. Determining that also takes some more code piled on top of the previous.
What if the route isn't fully built? We have to increase its length and turn the person back around.
What if the segment is retracting? We have to turn the person around.
What if there are multiple people passing through at once?
These don't sound like huge problems, but I had them all in one method in the node class. Even people that don't reach the node are run through it because the node contained all distribution code. Piled on top of each other, they made a mess and the code became hard to manage. Coding this portion took alot of debugging the last few times around.
However, this time I'm cutting it in half and putting the first half in the segment class. This code will be concerned with everything that doesn't involve the node, such as building and retracting.
I've already completed (yet to test) the node's distribution code, and now I have to write the segment's.
If you've noticed, I've started calling sections segments. I've changed the official name because segment is more fitting. Section was invented as a "for lack of a better word", but now I've found a better word. Segment.
Vids of the last iteration will be posted soon. Patience, grasshopper.
Suggestions? Questions? Singing praises?
clevceo
The toughest part before (and one of the biggest overhauls this time around) was the distribution of the people. When a person reaches the end of a segment and has multiple directions to go (including turning around), he picks based on which way needs more people. This requires some math thinky.
However, if all the lanes are full, he can't pass through. Determining that also takes some more code piled on top of the previous.
What if the route isn't fully built? We have to increase its length and turn the person back around.
What if the segment is retracting? We have to turn the person around.
What if there are multiple people passing through at once?
These don't sound like huge problems, but I had them all in one method in the node class. Even people that don't reach the node are run through it because the node contained all distribution code. Piled on top of each other, they made a mess and the code became hard to manage. Coding this portion took alot of debugging the last few times around.
However, this time I'm cutting it in half and putting the first half in the segment class. This code will be concerned with everything that doesn't involve the node, such as building and retracting.
I've already completed (yet to test) the node's distribution code, and now I have to write the segment's.
If you've noticed, I've started calling sections segments. I've changed the official name because segment is more fitting. Section was invented as a "for lack of a better word", but now I've found a better word. Segment.
Vids of the last iteration will be posted soon. Patience, grasshopper.
Suggestions? Questions? Singing praises?
clevceo
Tuesday, November 27, 2007
Network Problem Solved
Correction: my network is fine. Sever and the Net Rumble Starter Kit were broken for two different reasons. The Net Rumble Starter Kit didn't work because the GUID's were different on each computer. Sever didn't work because I wasn't updating the network session each frame. Doh! It works now. Awesome.
clevceo
clevceo
Network Trouble, Gameplay
I just received my second comment, only this one's legit. It wasn't long or detailed, but it was a complement, and that always counts for something, especially when it's all you've got. Anyway, it was from Zygote. He has a blog, Ziggyware XNA News and Tutorials, and a website, www.ziggyware.com. Thanks, Zygote.
On to the update:
I made some minor improvements and fixes to my input library. Nothing important enough to mention, especially since I'd have to explain how the whole library works first.
I also finally tested the network. It didn't work. I googled and googled, finding nothing, so I decided to test a sample game from the web, namely the Net Rumble Starter Kit. It didn't work either. Conclusion? Something's up with my network.
I've somehow completed four years toward an IT degree and still don't know a whole lot about networks. It's probably because I hated IT (I'm now CS) and blocked it all out of my mind. Anyway, I'll just have to figure it out.
I made some changes to the lobby and join screens. In the process, I think I've found some bugs in the beta. When I end a session, the SessionEnded event is never raised. This will cause problems on the client end. Nevertheless, I went into this knowing it was beta. They say they'll be releasing fairly soon, so I won't give up.
I've gotten as far as I can for now on the main menu. Now I'm just beginning to work on the gameplay (once again). Before I get too far, however, I'm brainstorming better ways to implement it. I already have a few ideas. I have to keep in mind the fact that it will be running over a network.
I'm also keeping scripting in mind. I said before that I'll implement it last, but I've had a few ideas for an interesting single-player with an AI that is purely made from scripts. The opponent would expand in interesting patterns from his base and the player would have to eliminate him within a time limit. If I'm going to have scripting, I may as well prepare for it now.
I'm going to redo my camera class. My previous camera class supported rotation, which was never used in Sever and probably never will be (as long as it's 2D; who knows what's in store?). Less math in the calculations means better performance.
I'm pretty sure I'm going to make each little person a Vector2 as opposed to a special class. The X value will be the person's progress through the route section and the Y value will be his current speed. Structs are faster than objects, so the performance should be improved.
Also, I'm thinking of hiding opponents' people. Each player will only be able to see his own people. This sounds arbitrary, but it means that I won't have to send data about each little person over the network. Much much less traffic. It also means less sprites to display. Can you go wrong with better performance all around?
I'm also going to look into geometric collision detection and fog-of-war. Geometric collision detection is important because it will allow me to places obstacles in a map. If I didn't have those, then what would distinguish one map from another aside from tiling?
Fog-of-war is important for two reasons. First, I think it will add to the fun. It will allow players to scheme in private. It will also allow players to move around the map without the opponent noticing, allowing for more complex strategies, such as sneaking around and attacking from the side. Without fog-of-war, the game would be brute-force. Second, I think I would enjoy implementing it. It would be a real challenge, but I think it would be worth it.
I'm planning to post some gameplay videos from my last Sever implementation. I don't know why I didn't do that before.
Suggestions? Questions?
clevceo
On to the update:
I made some minor improvements and fixes to my input library. Nothing important enough to mention, especially since I'd have to explain how the whole library works first.
I also finally tested the network. It didn't work. I googled and googled, finding nothing, so I decided to test a sample game from the web, namely the Net Rumble Starter Kit. It didn't work either. Conclusion? Something's up with my network.
I've somehow completed four years toward an IT degree and still don't know a whole lot about networks. It's probably because I hated IT (I'm now CS) and blocked it all out of my mind. Anyway, I'll just have to figure it out.
I made some changes to the lobby and join screens. In the process, I think I've found some bugs in the beta. When I end a session, the SessionEnded event is never raised. This will cause problems on the client end. Nevertheless, I went into this knowing it was beta. They say they'll be releasing fairly soon, so I won't give up.
I've gotten as far as I can for now on the main menu. Now I'm just beginning to work on the gameplay (once again). Before I get too far, however, I'm brainstorming better ways to implement it. I already have a few ideas. I have to keep in mind the fact that it will be running over a network.
I'm also keeping scripting in mind. I said before that I'll implement it last, but I've had a few ideas for an interesting single-player with an AI that is purely made from scripts. The opponent would expand in interesting patterns from his base and the player would have to eliminate him within a time limit. If I'm going to have scripting, I may as well prepare for it now.
I'm going to redo my camera class. My previous camera class supported rotation, which was never used in Sever and probably never will be (as long as it's 2D; who knows what's in store?). Less math in the calculations means better performance.
I'm pretty sure I'm going to make each little person a Vector2 as opposed to a special class. The X value will be the person's progress through the route section and the Y value will be his current speed. Structs are faster than objects, so the performance should be improved.
Also, I'm thinking of hiding opponents' people. Each player will only be able to see his own people. This sounds arbitrary, but it means that I won't have to send data about each little person over the network. Much much less traffic. It also means less sprites to display. Can you go wrong with better performance all around?
I'm also going to look into geometric collision detection and fog-of-war. Geometric collision detection is important because it will allow me to places obstacles in a map. If I didn't have those, then what would distinguish one map from another aside from tiling?
Fog-of-war is important for two reasons. First, I think it will add to the fun. It will allow players to scheme in private. It will also allow players to move around the map without the opponent noticing, allowing for more complex strategies, such as sneaking around and attacking from the side. Without fog-of-war, the game would be brute-force. Second, I think I would enjoy implementing it. It would be a real challenge, but I think it would be worth it.
I'm planning to post some gameplay videos from my last Sever implementation. I don't know why I didn't do that before.
Suggestions? Questions?
clevceo
Sunday, November 25, 2007
Intro Screen
I added an intro screen that fades in and out with the Clev logo. It's nothing huge, but plenty of fun to do. I made the logo a few days ago as I was working on a website design for Clev. Anyway, here's my working logo:
Like it? Suggestions? Questions?
clevceo
Like it? Suggestions? Questions?
clevceo
First Comment!
I just received my first comment on the post just before this one! It may be spam, but hey, you take what you can get. Furthermore, it's advertising dialup, which is useless considering the fact that those reading my blog already have an internet connection, most likely broadband at that. But the best part of the spammy comment is that it's in Portuguese. It doesn't get better than that. Thanks for the laugh, crescenet.
Anyway, he wanted me to add his url to my blogroll. While I won't go that far, I will add a link right here in this post for the sake of laughs: www.provedorcrescenet.com
clevceo
Anyway, he wanted me to add his url to my blogroll. While I won't go that far, I will add a link right here in this post for the sake of laughs: www.provedorcrescenet.com
clevceo
Saturday, November 24, 2007
ListBox & Scrollbar, GUI Rendering
The scrollbar and listbox are both complete. However, as with everything, changes will probably be made in the future. Nevertheless, they work and that's the most important thing. They took the better part of the day to complete, so it feels good to be done.
Anyway, the Join Game window now displays all available games. Excuse me, the Join Game window would display all available games if there were any to display. Excuse me, I don't know whether or not the Join Game window displays all available games because I have yet to create another game on a separate computer, and thus have not tested it, and thus have no idea whether or not it works. In other words, the listbox is blank.
Nevertheless, the listbox is there and it works beautifully. I must say, I love my GUI library. The only problem with it at the moment is that it's drawn with scaled sprites. Scaled sprites can be a pain sometimes, and they're inflexible, but they're easy to implement. In fact, in my last implementation of Sever, I scaled and rotated a single-pixel sprite to draw lines.
However, once I understand shaders (when and if), I will use them to render the GUI (and lines). Shaders mean more flexibility and efficiency for the GUI. If only they weren't so weird and confusing!
Suggestions please? Questions?
clevceo
Anyway, the Join Game window now displays all available games. Excuse me, the Join Game window would display all available games if there were any to display. Excuse me, I don't know whether or not the Join Game window displays all available games because I have yet to create another game on a separate computer, and thus have not tested it, and thus have no idea whether or not it works. In other words, the listbox is blank.
Nevertheless, the listbox is there and it works beautifully. I must say, I love my GUI library. The only problem with it at the moment is that it's drawn with scaled sprites. Scaled sprites can be a pain sometimes, and they're inflexible, but they're easy to implement. In fact, in my last implementation of Sever, I scaled and rotated a single-pixel sprite to draw lines.
However, once I understand shaders (when and if), I will use them to render the GUI (and lines). Shaders mean more flexibility and efficiency for the GUI. If only they weren't so weird and confusing!
Suggestions please? Questions?
clevceo
Friday, November 23, 2007
Local Sessions Xbox-Only, Join Game Window
Unfortunately, the whole idea of a "Local Network Session" (split-screen play on a single system) is Xbox only. That took me no less than four hours to figure out. For some reason, it wouldn't let me add any local players, so I searched and searched online until I finally found the bad news. The help files don't even make this clear.
I am forced to use an alternative, but I can't use the internet because Live play requires a Gold membership. Furthermore, Live play in the beta release also requires a Creators Club membership. To sum it up: not free.
Therefore, I can only use System Link, which means multiple computers over a local subnet. I'll probably eventually add Live support since the devs went to great lengths to make Live and System Link behave like twins in XNA. Only a few minor differences.
Anyway, without Local, testing will be a challenge. I can probably test the gameplay in a single-player mode, but I'll have to make arrangements for network testing (all I've got is my laptop).
At the moment I'm working on the Join Game window. I've basically finished the New Game window. For the Join Game window, I'll need a listbox, and for the listbox, I need a scrollbar. Scrollbar it is.
clevceo
I am forced to use an alternative, but I can't use the internet because Live play requires a Gold membership. Furthermore, Live play in the beta release also requires a Creators Club membership. To sum it up: not free.
Therefore, I can only use System Link, which means multiple computers over a local subnet. I'll probably eventually add Live support since the devs went to great lengths to make Live and System Link behave like twins in XNA. Only a few minor differences.
Anyway, without Local, testing will be a challenge. I can probably test the gameplay in a single-player mode, but I'll have to make arrangements for network testing (all I've got is my laptop).
At the moment I'm working on the Join Game window. I've basically finished the New Game window. For the Join Game window, I'll need a listbox, and for the listbox, I need a scrollbar. Scrollbar it is.
clevceo
Starting Fresh
Wait until I'm done before you say anything.
I'm starting over on Sever. Agh! I said it! Fact is, it could be done better. Plus, I want the entire game created with multiplayer in mind.
First, however, I'm creating a template for any future games I start. Trying to get RefLib on its feet was a real pain because of all the nuances in my GUI and Input libraries. I've done a thing or two to make it easier, but I still want a template. The template will contain a simple main menu and no more.
Also in the template, I'm creating a server window for multiplayer games. That's what's occupying my time at the moment. It's a learning experience. I'm finding it easier than I expected, but still daunting all the same.
I'm always tempted to give up on it. I continually let myself become distracted by small things (like blogging), or find myself staring at a wall for long periods of time trying to remember what I'm doing. And then I think about how I should be working on RefLib. It's a painful process.
I wish I could jump a few years into the future when all schooling is over and I've established myself as a software engineer.
Anyway, thanks for reading. Comment please.
clevceo
I'm starting over on Sever. Agh! I said it! Fact is, it could be done better. Plus, I want the entire game created with multiplayer in mind.
First, however, I'm creating a template for any future games I start. Trying to get RefLib on its feet was a real pain because of all the nuances in my GUI and Input libraries. I've done a thing or two to make it easier, but I still want a template. The template will contain a simple main menu and no more.
Also in the template, I'm creating a server window for multiplayer games. That's what's occupying my time at the moment. It's a learning experience. I'm finding it easier than I expected, but still daunting all the same.
I'm always tempted to give up on it. I continually let myself become distracted by small things (like blogging), or find myself staring at a wall for long periods of time trying to remember what I'm doing. And then I think about how I should be working on RefLib. It's a painful process.
I wish I could jump a few years into the future when all schooling is over and I've established myself as a software engineer.
Anyway, thanks for reading. Comment please.
clevceo
Wednesday, November 21, 2007
Route Theft
I'm debating whether to allow the player to steal his own routes. That doesn't sound right but I couldn't think of a better way of saying it next to explaining it in full.
However, a full explanation I will give. You have an extensive set of routes on the board. You send in a separate route route and connect it to an existing node within the first set, retracting its original source route. This way, if the source route is severing, you can save the rest of the route.
Here's a little ASCII art to illustrate:
The following route is no longer part of its original source, but becomes part of the second route. It is effectively stolen from its parent.
I thought of this a while back, but at the time I thought it was just "another feature" that I'd thought up in my head, contradictory to my goal to rely on the simplicity of the game to move it forward. However, I've recently begun to see the strategic possibilities the feature would present. Plus, it's still simple to do in-game. It would be a mere drag-n-drop. It would fit perfectly. As I write this, I like it more and more.
I'm going to do it. If you think I shouldn't, say so now. If you have any suggestions, please share them. Thanks for reading.
clevceo
However, a full explanation I will give. You have an extensive set of routes on the board. You send in a separate route route and connect it to an existing node within the first set, retracting its original source route. This way, if the source route is severing, you can save the rest of the route.
Here's a little ASCII art to illustrate:
\ /
\ /
Y O
| |
O |
/ |
/ |
\ /
\ /
Y------O
|
O |
/ |
/ |
The following route is no longer part of its original source, but becomes part of the second route. It is effectively stolen from its parent.
I thought of this a while back, but at the time I thought it was just "another feature" that I'd thought up in my head, contradictory to my goal to rely on the simplicity of the game to move it forward. However, I've recently begun to see the strategic possibilities the feature would present. Plus, it's still simple to do in-game. It would be a mere drag-n-drop. It would fit perfectly. As I write this, I like it more and more.
I'm going to do it. If you think I shouldn't, say so now. If you have any suggestions, please share them. Thanks for reading.
clevceo
Tuesday, November 20, 2007
XNA Networking
First off, Sever and its referenced libraries all converted just fine to XNA 2.0, though there were a couple deprecated functions. It ran fine without changing them, but the changes would be so small that I did it anyway.
I've been reading up on networking within XNA. I was deathly afraid that it would require as much code as the game itself, but fortunately, it does not. XNA has once again managed to simplify something so complex without losing any capability that I will need any time soon.
Anyway, it's still daunting. I have no experience with this stuff and it's still going to take some figuring out. Fortunately, it seems Sever's current structure is a perfect fit for networking (wipe the sweat off my forehead). I must be a prophet. No, that's going a little far. I'm probably just a genius.
Fortunately, I'll be able to do part of the multiplayer testing without a second computer. XNA allows multiple players to play from one instance on one pc. In other words: split-screen. I could've implemented split-screen before, but the required code would've gone off course from the intended structure of the game. I would've had to undo alot of code come XNA 2.0. But the waiting is over, so I can move on.
Please comment your suggestions, questions, thoughts, praises, musings, etc. Thanks for reading.
clevceo
I've been reading up on networking within XNA. I was deathly afraid that it would require as much code as the game itself, but fortunately, it does not. XNA has once again managed to simplify something so complex without losing any capability that I will need any time soon.
Anyway, it's still daunting. I have no experience with this stuff and it's still going to take some figuring out. Fortunately, it seems Sever's current structure is a perfect fit for networking (wipe the sweat off my forehead). I must be a prophet. No, that's going a little far. I'm probably just a genius.
Fortunately, I'll be able to do part of the multiplayer testing without a second computer. XNA allows multiple players to play from one instance on one pc. In other words: split-screen. I could've implemented split-screen before, but the required code would've gone off course from the intended structure of the game. I would've had to undo alot of code come XNA 2.0. But the waiting is over, so I can move on.
Please comment your suggestions, questions, thoughts, praises, musings, etc. Thanks for reading.
clevceo
Monday, November 19, 2007
XNA 2.0 Beta
What do you know. At the end of last night's update, I mentioned that the next step in Sever's development depends on XNA 2.0's release. Lo and behold, here I am in my bedroom with my laptop on (guess) my lap with the beta downloading at 76%. Hanginaround by Counting Crows shuffled its way to my speakers to celebrate.
I've never been much for beta testing. I've always been one to use the stable versions because I'm afraid I'll either lose some work or lose my patience with bugs. However, I will try the XNA 2.0 beta because my work is stunted without it. Plus, the what could happen, other than an in-game crash? The code always saves before it runs, so there's nothing to lose.
Visual Studio Express 2008 is also out. I downloaded it, but I haven't used it yet because it doesn't like XNA and any non-XNA code I've written was with VS 2005 Pro, which is a step up from Express, even if it is 2008. So if I ever use it, it will be purely for fun. Even if it does eventually accept XNA, I won't switch because...
XNA 2.0 integrates into Visual Studio 2005 Pro! I was bummed when I found out that XNA 1.0 required Express. I know I could add the references and all that to get it to work in Pro anyway, but it's just a nuisance that it isn't supported natively. Anyway, the biggest problem I had with Express was that there wasn't an option to retain tabs rather than treating them as spaces.
Anyway, the download is complete. Goodbye XNA 1.0, hello XNA 2.0 Beta! I know I shouldn't be working on Sever with RefLib on the clock, but I can't help myself. Expect updates.
clevceo
I've never been much for beta testing. I've always been one to use the stable versions because I'm afraid I'll either lose some work or lose my patience with bugs. However, I will try the XNA 2.0 beta because my work is stunted without it. Plus, the what could happen, other than an in-game crash? The code always saves before it runs, so there's nothing to lose.
Visual Studio Express 2008 is also out. I downloaded it, but I haven't used it yet because it doesn't like XNA and any non-XNA code I've written was with VS 2005 Pro, which is a step up from Express, even if it is 2008. So if I ever use it, it will be purely for fun. Even if it does eventually accept XNA, I won't switch because...
XNA 2.0 integrates into Visual Studio 2005 Pro! I was bummed when I found out that XNA 1.0 required Express. I know I could add the references and all that to get it to work in Pro anyway, but it's just a nuisance that it isn't supported natively. Anyway, the biggest problem I had with Express was that there wasn't an option to retain tabs rather than treating them as spaces.
Anyway, the download is complete. Goodbye XNA 1.0, hello XNA 2.0 Beta! I know I shouldn't be working on Sever with RefLib on the clock, but I can't help myself. Expect updates.
clevceo
Sever: Explained in Full
I realize that I haven't explained clearly what Sever is all about. I've spoken mostly to myself in this blog and haven't given any readers a chance to understand what the hay is going on. I would very much like to get your input, so I'm going to explain it as best I can.
For starters, imagine you're designing a connect-the-dots picture, no intersections. Say some impatient kid is connecting the dots right as you draw them. In other words, every time you make a dot, the line makes its way to your pencil in realtime. Now, say the path we are making can split into two lines like a Y, then three, four, and so forth.
Now lets throw in another person at the other side of the sheet drawing his own dots. How dare he? And to make things worse, he's crossing your lines with his own. To your surprise, the lines he crosses are severed and all lines beyond them disappear. Your ears are steaming now.
You start making dots like mad, hoping the kid connecting them can keep up. You start cutting your enemy off, driving him back to where he started. Finally, when he only has a few dots left on the page, you cut off his first line and everything disappears. You have effectively conquered the page.
That's Sever.
Back to reality (meaning the Seververse), there's no page, no impatient kid, no pencil. The dots are, in Sever terminology, called Nodes. The lines are called Routes, each individual segment called a route Section. These terms are merely a working vocabulary, subject to change.
There are a few more mechanics to make the game more interesting. Instead of a kid drawing the routes, there are little people building them. These people are little dots that run mindlessly back and forth through the routes. Every time a person runs into the end of an unfinished route section, the section's length increments. Once the section is complete, the people then begin to build the node in the same fashion.
These people are generated at a consistent rate by the two connected dots that each player begins with, called Father Nodes. The section connecting them is called the Soul Section. When the source section is severed, the player is finished.
A player can sever his own routes if he chooses. However, when a route is severed, all people within it are lost and must be regenerated in time. If he's not in a hurry, he can retract his routes, drawing them in at a rate slow enough for the people inside to retreat to safety. This is what happens to the offensive route in a severance.
There are different kinds of nodes. Each one varies in a the following properties: radius, spacing, branches, speed boost, and person generation rate. Radius is the size of the node. Spacing is how much space is required between this and another node owned by the player. Branches is how many branches can follow this node. Speed boost is how much of a boost to give each person that passes through the node. Person generation rate is how many seconds between each person generated (0 if none). At the moment, I have only four different types:
Father Node: Gives a speed boost; generates people; doesn't split the route; not buildable.
Sub Node: Builds fast; doesn't split.
Switch Node: Splits the route in two.
Accelerator Node: Gives a boost; doesn't split; large spacing.
That's the current status of the game, only there is no multiplayer or AI. If you've read my past posts (you don't have to; I'm writing this to compile all the important stuff into one post), you'll know my future plans. However, for the sake of clarity, I'll give a short list:
1) Multiplayer
2) Fog-of-War
3) Map Obstacles
4) AI
5) Scripting
Multiplayer can't be done (with my experience) until XNA 2.0 is released in the next coming months (hopefully). But I plan to get to work on it as soon as I can because I can't truly playtest until I have an opponent that fights back.
Fog-of-War was the last task I had been working on when I took my hiatus to work on RefLib. I hadn't yet put any code into it because I was still brainstorming how I would implement it in Sever. It was (and is) a daunting task, but it is doable.
Map obstacles are required if I'm going to make unique maps, and as of yet I'm trying to figure out how to implement them in a way that's workable with AI pathing and performs well with collision testing.
AI is very daunting. I've read up on pathing, which doesn't sound so bad, but getting the AI to make a plan and implement it is beyond me. This feature I will put on the backburner until I'm ready for it.
Scripting is definitely doable, but it's useless without AI. It would only be used on a single-player campaign, and a single-player campaign makes no sense if the baddies have no AI to drive them. Until I do the AI, Sever will be a multiplayer game.
So that's the plan. As I've mentioned, I'm working on RefLib right now, so Sever will have to wait at least another month. Once Sever is back on track, I will start on the fog of war unless XNA 2.0 is out, in which case I will set to work on the multiplayer.
Please, please, please comment. Tell me what you think. Give me suggestions. Criticize me. Ask questions. Please.
Thanks for reading!
clevceo
For starters, imagine you're designing a connect-the-dots picture, no intersections. Say some impatient kid is connecting the dots right as you draw them. In other words, every time you make a dot, the line makes its way to your pencil in realtime. Now, say the path we are making can split into two lines like a Y, then three, four, and so forth.
Now lets throw in another person at the other side of the sheet drawing his own dots. How dare he? And to make things worse, he's crossing your lines with his own. To your surprise, the lines he crosses are severed and all lines beyond them disappear. Your ears are steaming now.
You start making dots like mad, hoping the kid connecting them can keep up. You start cutting your enemy off, driving him back to where he started. Finally, when he only has a few dots left on the page, you cut off his first line and everything disappears. You have effectively conquered the page.
That's Sever.
Back to reality (meaning the Seververse), there's no page, no impatient kid, no pencil. The dots are, in Sever terminology, called Nodes. The lines are called Routes, each individual segment called a route Section. These terms are merely a working vocabulary, subject to change.
There are a few more mechanics to make the game more interesting. Instead of a kid drawing the routes, there are little people building them. These people are little dots that run mindlessly back and forth through the routes. Every time a person runs into the end of an unfinished route section, the section's length increments. Once the section is complete, the people then begin to build the node in the same fashion.
These people are generated at a consistent rate by the two connected dots that each player begins with, called Father Nodes. The section connecting them is called the Soul Section. When the source section is severed, the player is finished.
A player can sever his own routes if he chooses. However, when a route is severed, all people within it are lost and must be regenerated in time. If he's not in a hurry, he can retract his routes, drawing them in at a rate slow enough for the people inside to retreat to safety. This is what happens to the offensive route in a severance.
There are different kinds of nodes. Each one varies in a the following properties: radius, spacing, branches, speed boost, and person generation rate. Radius is the size of the node. Spacing is how much space is required between this and another node owned by the player. Branches is how many branches can follow this node. Speed boost is how much of a boost to give each person that passes through the node. Person generation rate is how many seconds between each person generated (0 if none). At the moment, I have only four different types:
Father Node: Gives a speed boost; generates people; doesn't split the route; not buildable.
Sub Node: Builds fast; doesn't split.
Switch Node: Splits the route in two.
Accelerator Node: Gives a boost; doesn't split; large spacing.
That's the current status of the game, only there is no multiplayer or AI. If you've read my past posts (you don't have to; I'm writing this to compile all the important stuff into one post), you'll know my future plans. However, for the sake of clarity, I'll give a short list:
1) Multiplayer
2) Fog-of-War
3) Map Obstacles
4) AI
5) Scripting
Multiplayer can't be done (with my experience) until XNA 2.0 is released in the next coming months (hopefully). But I plan to get to work on it as soon as I can because I can't truly playtest until I have an opponent that fights back.
Fog-of-War was the last task I had been working on when I took my hiatus to work on RefLib. I hadn't yet put any code into it because I was still brainstorming how I would implement it in Sever. It was (and is) a daunting task, but it is doable.
Map obstacles are required if I'm going to make unique maps, and as of yet I'm trying to figure out how to implement them in a way that's workable with AI pathing and performs well with collision testing.
AI is very daunting. I've read up on pathing, which doesn't sound so bad, but getting the AI to make a plan and implement it is beyond me. This feature I will put on the backburner until I'm ready for it.
Scripting is definitely doable, but it's useless without AI. It would only be used on a single-player campaign, and a single-player campaign makes no sense if the baddies have no AI to drive them. Until I do the AI, Sever will be a multiplayer game.
So that's the plan. As I've mentioned, I'm working on RefLib right now, so Sever will have to wait at least another month. Once Sever is back on track, I will start on the fog of war unless XNA 2.0 is out, in which case I will set to work on the multiplayer.
Please, please, please comment. Tell me what you think. Give me suggestions. Criticize me. Ask questions. Please.
Thanks for reading!
clevceo
Subscribe to:
Posts (Atom)