I Take That Back

Correction: the textbox now supports click-and-drag highlighting as well as cutting/copying/pasting with the clipboard.  So far, the multi-line textbox has been a separate class from the single-line textbox, but I created an option to make it single-line, so I think I will completely replace the single-line textbox with this one.  I think it's as far as I will take it.  It has all the most important features now.  Should make writing scripts much more convenient.  Now all I need to do is attach a scrollbar to the textbox in the script editor.

Now that I think of it, it would be nice to be able to scroll through the text with the scrollwheel.  Should be easy to implement.

Anyway, sorry for all the UI talk.  Seems irrelevant to Sever, but this is a dev blog and I'm developing the UI right now. Thanks for reading even though it's a bit boring right now.

clevceo

Multi-line Textbox

I know I said in my last post that I wouldn't add any more to the multi-line textbox, but it was nagging at me, so I did it anyway.  You can now highlight text, and you can hold down a key for it to repeat.  Both of these changes will be extremely convenient when writing scripts.  However, it does not yet support click-and-drag highlighting.  Just shift-click or shift-arrow-key.  But that alone will be extremely handy.  Anyway, thanks for reading!

clevceo

Multi-line Textbox, Scripting

I just finished adding multiple-line functionality to my TextBox class.  Unfortunately, it's still a pretty simple control.  You can't highlight anything, and you can't hold buttons down to repeat them.  For example, if you want to delete a large section of text, you can't select the whole thing and delete it or even press and hold backspace.  You have to repeatedly press backspace over and over until it's gone.

It can be a bit of a pain, but I think I'll leave it be until I feel I really need it.  If you read my early posts on this blog when I first started Sever, you'll notice that I was easily sidetracked with things like this.  I spent way more time than I should have on the user interface and input code.  Given, they were handy, but they were much more than I needed and the extra time spent on them could have been spent making progress on Sever.  Hence the fact that I never finished it.  The main reason why I'm actually making progress this time around is because I'm not allowing myself to get sidetracked.

Anyway, that's why I'm not going to add on to the multi-line textbox until I decide that I really need to.  I probably will at some point, but at the moment, I want to keep moving.  It does what I need it to do.  It allows me to write scripts directly into the editor, which is extremely convenient.  From here, I'll be able to move much faster.

I want to start adding scripting to more than just hotspots.  One on the list is a script that runs at the beginning of a level.  This will be extremely handy if the level won't be the same every time it is loaded.  Parts of it can be randomized, or it can change based on the player's choices in previous levels, etc.

I also want to add the ability to script the AI.  There will be levels where the AI is not really intelligent.  It will do one specific thing that can be easily scripted.  Also, the scripts could be used merely as a state-machine to switch between AI modes (of course, I'll need to build those modes first).

Anyway, I'm excited to move forward with this.  I feel like everything is finally beginning to come together.  It's really close to the point where I can start building real, playable levels.  Of course, I won't be building an actual campaign for another while.  I'll be experimenting with different level ideas until I have an extensive list of levels that I can compile into a campaign.  And I'm sure I'll be tweaking the gameplay as I go.  But the main thing is that I'll finally be able to move beyond the game engine to the game itself.  I've started over on Sever so many times, and I've never reached this point.  I'm excited.  I only hope that the game is fun in the end.

Thanks for reading, please comment!

clevceo

Scripting

Just had to post a screenshot of my first successfully executed script within the game:

The script was 'showMessage("It worked!");'.  Not very exciting, but it felt pretty good to see it work.

This was executed by building a node over a hotspot.  The scripting language I'm using is Lua via NLua, which wraps around Lua to make it more accessible to .NET.  There is currently only one method within Sever available to Lua: showMessage(string message).  But that's just fine.  The hardest part is behind me.  The next feature I might add to the scripting is the ability to switch to another map.

This is my first experience with scripting, so we'll see how it goes.  Hopefully I don't botch it.

Something tedious ahead of me that I'm not really looking forward to is building upon my current TextBox class to make it support multiple lines.  I have a script editor window with a big textbox, but you can only stay on one line (that's a lot of wasted space).  But I'm not sure if I'll do that now or wait until I have a script that needs it.  We'll see.  In the meantime, I might just add a way to run a script from a file.  That might hold me over.

Anyway, just wanted to share my victory.  Thanks for reading!

clevceo

Hotspots

I added hotspots to the game.  A hotspot is a special point on the map that you can build a node on top of.  Different hotspots will do different things when built upon.  For example, one hotspot might advance the player to the next level while another might simply allow the user to build a node type that can't be built anywhere else.

It actually took a long time to integrate hotspots into the game.  There were so many little places that I needed to touch in the code.  But the hard part is over.  Building onto them won't be too hard.  I want be able to add scripts to them as well as adding a few nonscripted options, such as allowing a special node type to be built on top of them.

At some point, I would like to have regions in the map that trigger scripts when the player enters them, but that will have to come later.  For now, hotspots will be my go-to script triggers.

Not a very exciting post to read, but it was exciting for me to write it.  Hotspots will give me much more to work with when designing levels.

Thanks for reading!

clevceo

AI, Puzzles, Design

I rewrote the AI over the past couple days.  Instead of running blindly into obstacles before trying to go around, it now avoids them from the beginning.  Also, it retracts useless nodes when the system density is low.  It still needs polish, but it's much more effective and looks less stupid than it did before.

The method I used is actually different than what I was planning on using before.  I had an idea for a while that I felt pretty sure about.  But a few nights ago, it clicked in my mind that it would be extremely inefficient.  Fortunately, I quickly thought of a new way that would be much easier to implement and more efficient.  It works pretty well.

After it's polished up a bit, the next step is to build the hunting state and the state machine that controls the transitions between states.  At that point, the AI will be able to function normally and appear intelligent.

However, I'm undecided whether I'll keep focusing on the AI right now or put it off for later.  After I got the new AI working, I started thinking of level ideas.  Oddly enough, none of them involved the AI.  I thought first of some puzzles.  Yeah, I know, how are there puzzles in a strategy game?  Well, this strategy game is different and the mechanics actually mesh pretty well with puzzles.  Here are some screens of a puzzle I made (excuse the placeholder graphics, they're terrible):

At first glance, this looks like a simple maze.  However, there is only one way through.

One of the mechanics of this game is that the farther away you build the node, the bigger it gets.  You'll notice the wide dark circle around the dark green node.  If the new node was built within that circle, the node would be smaller.  Outside of it, it's large, like the white circle.  It doesn't fit.

Once again, it's stretching too far.

This is the only way through.

This would be one of the earlier, easier puzzles.  Later levels would be much more difficult.  I plan to create more puzzles like this to accompany the AI fighting levels.  I know that puzzles and combat are very different and may feel awkward squeezed into the same game.  If people don't like it, then so be it.  But I want to explore these mechanics to their fullest and I think there's a lot of potential here.

I'm thinking my next step in the development will be integrating some simple scripting, at least enough to allow transitioning to new maps.  That way, I can start stringing them together.  I want to start giving the game a skeleton structure.  Once I begin making a real level that requires more development of the AI, then I'll probably come back to it.

The combat will come in later levels.  I want it to be clear that the combat isn't the point of the game.  Instead, it's only another application of the core mechanics.

I have a few more mechanics up my sleeve that expand upon the core idea and make things more interesting.

It's interesting to look back at my early posts on this blog and see how far Sever has come.  A long time ago, I was dreaming about fog of war and AI and had no idea how I would implement them.  In fact, many times I gave up hope that I would ever be able to do it.  And now here they are.  Now my only worry is about the actual game design.  I'm past the technical part.  I know I can do that.  Now on to something I have no experience with at all.

I've never designed a game.  Okay, I've made my own variant of minesweeper, and I think it's pretty fun (I'm probably the only one), but that was a pretty simple game to design, to be honest.  This game will be much bigger (though relatively small compared to mainstream games).

I am trying to design it by Jonathan Blow's philosophy.  I want the mechanics to inspire the levels and not the other way around.  Anything that isn't true to them will be cut from the game.  Of course, Sever would never compare to Braid, but it doesn't need to.  This project is more for my own experience.  And it's been a good experience so far.

Anyway, enough of my ramblings.  Thanks for reading!

clevceo

Back, Not Sure For How Long

I got a new laptop, installed VS 2015, and installed the new version of MonoGame, so I thought it might be fun to transfer Sever over to the new setup.  I did so, ran into a few of the errors I'd been having before I gave up last time, and instead of giving up again, I found myself digging into it and fixing them.  After a few hours, I'd progressed from fixing a few bugs to actually getting the fog of war working properly, which was something that had burnt me out last time around.

The fog of war was already displaying correctly, but invisible objects were still being drawn behind the fog.  For the player, this didn't make much of a difference.  However, the AI didn't know which objects were behind the fog, so it saw everything.  Now it knows.  It sounds easy, but it was quite the task.

From here, I will either working on AI pathing or begin work on scripting.  Both are elephants in the room that need to be completed before much progress can be made.

If you can tell, I think I could easily dive back into the development if I wanted to.  However, I'm so busy these days that I'm not sure how long it will last before it's on the backburner again.  Anyway, I'm going to give it a go and see what happens.

Thanks for reading!

clevceo

Thoughts on Sever, New Game Idea

I've been away from Sever for some time.  I've been thinking about it, and I want to come back to it.  I've been pretty swamped for the past while, and I was a little discouraged with the development.  I knew I had to work on AI and scripting, both difficult areas for me.  I feel like I made some really good progress on the AI at the beginning, but it still had a ways to go, and it was a bit daunting.  The scripting scared me as well because I wanted it to be the best that it could be, and I didn't know where to start.

However, I would like to eventually continue its development, but I'd have to simplify my plans for scripting.  There's a simpler way to do it, but it's apparently much less flexible and not always the best way to go.  However, Sever's scripting likely won't be extremely complex.  Plus, I can refactor it later if I really want to.  I guess what I'm trying to say is that I'm going to go the easy route with scripting.

My plans for the AI, however, probably won't change.  They weren't extremely ambitious in the first place.  The most complex thing I want it to do is to navigate the map intelligently, and I have some ideas for how to do that, as explained in my last post.  Everything else the AI does will probably be easier than that.

After the AI is improved and basic scripting is in place, I'll probably tweak and add to both as I start creating levels.  I'm hoping that there won't be any other huge systems that I'll have to create once those are done.  I'm hoping that the rest will just be minor additions as the game evolves.

Those are my thoughts about Sever.  As I've been away from it, my mind has wandered a bit with other game ideas that would be fun to try out one day.  The one that stands out the most is a detective puzzle game.  Most Sherlock Holmes-type detective games are just hidden object games, sometimes with general mind-bender puzzles thrown in for a challenge.  However, none of them really make you feel like Sherlock Holmes.

For example, Sherlock Holmes sees some white dust on someone's shoe, figures by its off-white color that it is limestone, knows that there is only one limestone quarry in the vicinity, knows that limestone falls off after a few hours, and deduces that the man was at the limestone quarry today.

No game can get the player to do anything that complex, but it could be simulated in a more simple way.  Compare it to the Arkham games.  Whereas the older Batman games had separate buttons for jump, punch, and kick, the Arkham games removed those in favor of a single attack button so that the player could focus more on strategy rather than on the actual attack itself.  If they hadn't, it would be too much for the player to strategize "and" make his attacks land just right.  They simplified one system so that the player could focus on the other.

Similarly, a Sherlock Holmes game could simplify the meaning of clues so that a player could look at them and instantly know what they are.  For example, rather than allowing white powder to be anything from flour to limestone to chalk, it would just be white powder.  There's only one kind of white powder, just like there's only one kind of red or blue powder, and each comes from one place.  Therefore, if you see red powder on someone's shoe, you know where it came from.  I don't know that we'll have powders of every color, but you see where I'm going with this.  The world is simplified so that clues are easy to follow.

This way, rather than the player just clicking on a highlighted clue to hear Sherlock explain what it means, they would decipher it themselves, just like Sherlock Holmes would.

I haven't thought through all the different elements of the gameplay, like dialogue or anything else that you'd expect in a detective game, but I'd have to keep that simple as well.  I considered making the game procedural somehow, but I decided that that would be beyond me, and even if I succeeded, it would probably be much more limited than if I crafted the levels myself.

Anyway, those are my thoughts.  Thanks for reading!

clevceo

Path-Finding, AI Plans

Like I said in my last post, the AI doesn't path-find very well.  It will head directly towards the player's location without creating a path around obstacles.  Well, it will eventually go around them, but it will go as far as it can before it has to start moving around it.  This works well enough on a map with little or no obstacles, but every other map gives the AI quite a bit of trouble.  Like I said, it eventually makes it around, but it's messy and not very intelligent.  Also, it's not very fun to play against because its offense is slow and it fills up the area around its home base with loads and loads of routes that you have to tediously make your way through.  Better path-finding would mean the AI would build its routes with more purpose and strategy rather than trial and error.

I've been brainstorming what would be the fastest way to do it.  I've known for a while now the the AI will calculate where it thinks its enemy is and send all of its routes in that direction.  The trick is doing the path-finding for each route quickly and efficiently.  I originally thought I'd just do an A* path search from each node one after another, but I figured that would quickly slow things down when the AI's routes get bigger.  Then I had an idea.  I could use Dijkstra's algorithm, starting at the end point and run it until it finds all of the nodes.  I can save alot of time and resources that way, sharing the processing time between all of the nodes at the same time.

The one issue with this method that I can see is that if there's a node that cannot reach the destination, the algorithm will keep running until it has tested every point on the map, which really really slows things down.  My solution is to run it until it finds one of the nodes, and then set a time limit for the next one.  For example, after one is found, it will only test 100 more before it ends unless it finds another in that time, in which case the time limit will reset back to 100 again.  That way, it will stop when it thinks that it has found all of the nodes that are actually reachable.

I'm excited to get this working.  It will really open up alot more possibilities with maps.  After that, I want to give the AI a state machine.  At the moment, it is always in attack mode.  Eventually, I want it to have modes like "Scouting", "Offensive", "Defensive", etc.  I want there to be routes that only attack you when they are attacked first, or routes that attack on sight, or routes that only attack if you're close, but stop when you back off.

I was hoping that at this point I could really take off with designing levels, but with a messy AI, it's just not very fun yet.  I like to think that once the AI starts acting more intelligently and is more flexible, the levels will start popping out of their own accord.  However, after the AI is beefed up a bit, I'll probably pull all of my time into integrating scripting into the engine.  It's something I've never done before, so I don't know the best practices.  I'll have to do some research.

Anyway, it's moving forward slowly but surely.  I can't wait for all of this "under the hood" stuff to be behind me so I can really start experimenting with the actual game.

Thanks for reading!
clevceo

Editor, Fog of War

The editor saves and loads now.  I know it's a stupid little thing, but it was exciting to save a level and open it again.  Also, I tried to make the file browser as convenient as possible.  I even added the path buttons at the top (a button for each folder; if the user clicks one, it backs up to that folder).  However, the scrollwheel doesn't scroll the listbox.  Instead, it just zooms out on the map in the background.  It's not that big of a deal because I can just grab the scrollbar and scroll fast that way, but I forget every time and try to scroll.  It's really annoying.  I think I'll add it just so it stops bothering me.

I tested the editor by making a level with the player and the opponent on opposite sides of the map.  It was exciting to actually play a map created with the editor.  However, there was an issue that I hadn't run into before.  Previously, I always had the player and the AI really close to each other on the map, so I didn't have to zoom out so much to see what was going on.  However, with the players so far apart, I zoomed out quite a bit on the new map.  Unfortunately, this meant that it was displaying alot more fog of war than usual.  This was a problem.

The way I implemented the fog of war was using a simple grid.  Initially, every square in the grid is considered unexplored.  When a new node is built, a circle is drawn in the grid, marking each square in the circle as explored.  When the fog of war is drawn, it just draws a black square on the unexplored squares.  When zoomed out over a large map, that's alot of squares to draw!  The framerate dropped considerably.

I searched the internet for solutions.  One said to stop the camera if it tries to enter unexplored parts of the map, so you don't even have to draw any fog of war.  That's a hack, in my opinion.  Plus, it would be a pain to play the game with that constraint.  However, that's the only optimization I could really find for actually "drawing" the fog of war.  There were plenty of articles about everything else concerning fog of war.  Maybe if I looked for a few more hours, I would have found something.  However, I was tired of looking.

I had an idea that I wanted to try.  I saw that there were big portions of the map that were completely covered in fog, and you could cover most of it with one big rectangle.  So I decided to try to fill up the fog with as many big rectangles as possible, and fill in the rest with smaller rectangles, thereby reducing the number of sprites to draw.  I wasn't sure if it would be faster because it was more processing (though the algorithm is as optimized as it can be), but when I tried it, it was lightning fast!  Fog of war no longer even comes close to lowering the framerate at all, even when zoomed out all the way.

I was really surprised that I didn't see this trick online.  I'm sure it's somewhere out there, but it should be more common because it worked extremely well for me.

My next step, I think is to put some work into the AI.  My currently AI doesn't path-find well enough for most of the maps that I'll be making, so I'll be improving that.

Thanks for reading!
clevceo

ListBox

I decided that in order to make a good save/load window, a flexible listbox control would help tremendously.  After I finished up the geos, that's what I began working on.  I finished it today...or at least I finished the base control.  I might make a custom control on top of it for the save/load window, but I'm not sure yet.  I also implemented the double-click event so that it can be navigated similar to windows explorer.  I just want to make my life a little easier, that's all.

I've created the window and you can open it and close it, but it doesn't do anything yet.  That's the next step.  It's taken alot more work than I expected just to get to this point, but I'm here.  Hopefully the next part doesn't take as long.  We'll see.  I wish I was past this so I could start building levels already.  But I'll be there before you know it.

Thanks for reading!
clevceo

Editing Geos

Man, the geos were tougher than I expected.  It turns out that I was almost done with the code before I realized that I'd made some big mistakes early on that affected almost all of my code.  Basically, I forgot how the vertices were stored.  The vertices in the geos are stored in pairs for each line.  For example [50,0,0,50,0,50,100,50] is a triangle with the vertices 50x0, 0x50, and 100x50.  However, I forgot that and thought each vertex was stored only once ([50,0,0,50,100,50]).  I didn't try to do any collision testing against them or display any textures on them until the end, so my error didn't show for a long time.

I got that fixed, though it took alot of debugging before it was working right.  And after that, some old errors that I didn't know about surfaced.  Fortunately, these ones were sort of expected.  They had to do with breaking the shapes down into triangles in order to draw them.  A triangle geo won't need any breaking down and a square will be only two triangles, but a complex shape requires some deep thinking to break down.

Because it's alot of complex math, it's easy to overlook things.  While one shape might be broken down just fine, another might present a case that I hadn't thought of and it will either draw incorrectly or crash.  After alot of bashing my head against my desk, I got it working.  It works flawlessly now as far as I can tell.  I just have a couple more things to do with it before I start on the save feature.

I know this post wasn't all that exciting (as usual, lately), but soon I'll have more exciting news to share.  The editor is the boring hurdle that I need to get over before things take off.  I won't be working on it again until Monday, however.  But stick with me.  Thanks for reading!

clevceo

Editor (Continued...)

I'm still hard at work on the editor.  Today I finished all of the route editing portion.  It took me a good while, but that part is done.  Once again, I probably put too much work into making it intuitive and foolproof, but hopefully it makes the level editing faster and easier in the future.

The next step is the geos.  It shouldn't actually be too hard.  I just need to allow the user to add, move, and delete vertices.  Also, for convenience, I'll probably add a way to move the entire geo at once.  The vertices in a geo are world coordinates rather than being relative to the upper-left corner of the geo, so moving an entire geo would mean moving all of its vertices simultaneously.

I'm stoked for the geos to be complete.  Once they're done, I can work on the save feature, which shouldn't be too bad.  Once that's done, I can finally create levels quickly and try them out.  At that point, I'll probably start posting more often because there will be alot more to talk about.  Also, I'll be going back into the engine and improving the AI, experimenting with new mechanics, etc.  It's exciting.

Thanks for reading!

clevceo

Editor

I decided that I didn't absolutely need the listbox control, so I decided to get started building the editor.  When I need the listbox, I'll build it.

Until today, all of my time has been spent just putting together the gui for the editor.  I probably spent more time than I had to, actually.  I put some work into the textboxes so that they validate your input.  I could have just left it, but I'm hoping that it will save time and frustration in the future.

I started building the rest of the editor today.  You can add nodes now, though you can't modify or delete them once added.  It's not that special yet, but now that the gui is done, it's going to progress quickly.  I'm excited for the day when I can load and save levels and actually try them out.

I've been thinking of more ideas for levels.  I'm itching to finally try them all out.  I wish the day was here already.

Thanks for reading!

clevceo

Graphical User Interface (Continued...)

Today, I made some good progress on the graphical user interface library.  Specifically, I completed the two most difficult controls that I'll need: the textbox and combobox.  Next is the listbox.

This library does something that my last one didn't.  When I built my previous library, I didn't know how to clip graphics at the edge of the control.  In other words, if there was too much text on a button, it would spill over the sides.  I thought you had to create a buffer the size of the control, draw on it, and then copy it to the screen.  I found out today, however, that you can use a "scissor rectangle" to clip the edges.  Basically, you say what part of the screen you want to draw to and it will clip anything that runs outside of it.

This doesn't make a huge difference with buttons and similar controls because I'm not going to put too much text in them anyway.  But it's really handy for textboxes.  In my last version, I just calculated how many characters would fit in the box and only drew that many.  This took more processing and wasn't pretty.  It will also come in handy if I ever need to build a scrolling panel.

I'm excited to finish the listbox because that means I'll be able to really start building the editor.  Before we know it, I'll be building levels willy nilly and Sever will be progressing much faster.

Once I have the editor up and running, I'll post screenshots.  If you ever have any suggestions or comments, please share them.  Thanks for reading!

clevceo

Graphical User Interface

I haven't really touched the gameplay since my last post.  Instead, I've been working on building a graphical user interface library for use in the game.  I'll explain why.

I feel like I've reached the point where I can really start experimenting with the mechanics of the game, but manually editing the levels with a text editor is really really tedious and I have to guess at the numbers and run the game to see what it looks like and then go back and tweak them until they look right.  Long story short, it's extremely inefficient and not fun at all.  That's why the latest videos have no geography.  It's just a blank space with two players in it.

Time to build a level editor.  With a level editor, I feel like I can experiment with level layouts quickly and test the gameplay to explore what's fun and what's not.  I really feel like this is the next step.

What was holding me back from building an editor before was the lack of a graphical user interface library.  I built one in 2006 or 2007, but I was too overzealous and it ended up being a big clunky mess.  I didn't think so at the time, however,  I thought it was the bees knees.  It was as close a copy of the WinForms functionality as I could get it, which is overboard for my needs, to be honest.  Because of the time I spent on it last time, I've had a good idea of how I wanted to do it, but it was a bit daunting.

However, I finally decided to stop dragging my feet and just build the darn thing.  The foundation is working now.  I have buttons, labels, etc. and they're working great.  I already like it alot better than my last one.  It's alot cleaner and smoother to use.  The next controls I need to build are the textbox, listbox, and combobox.  The listbox shouldn't be too bad, but the textbox and combobox will be a bit of a pain.  However, once they're done, building the game's and editor's interfaces will be a cakewalk.

After I'm done with it, I'll hunker down and build the editor.  After that's completed (enough), things should really start moving along with the mechanics.

Since the time is coming when I can start experimenting with different levels and even try to play with story a bit, my mind has been running wild with various ideas.  I have some good ones that I'm excited to try out.  I know it's probably a bit early for that, so I'm not setting anything in stone yet, but I think the mere act of experimentation and exploration will help me develop the mechanics of the game.

Thanks for reading!

clevceo

AI Threading, Route Density

The only thing I did with AI today was a quick optimization.  Being inexperienced with threads, I didn't realize that starting and stopping the AI thread with each cycle is costly.  It takes a little time and you could see a little stutter.  At the time, I wasn't sure if that was why it was stuttering, but I decided to change the AI so that it runs on a continuous thread and just loops while it waits for new info from the main thread.  I wanted to see if that would fix the stutter.  Sure enough it did.  It runs silky smooth right now.

The other change I made was to the balance of the game.  Specifically, it had to do with the density of people within the routes.  Before I explain the change, I'll explain the purpose that the people play in Sever.

The little builder people that run through the routes and build new segments exist as a resource.  The idea is that more you have, the faster you can build.  They are produced at a regular rate from the parent nodes, so you don't have to create them yourself like you would in other games.  Instead, it controls the player's pace in the construction of his routes.  If he builds faster than his people can be produced, then the people are too spaced out and don't build as fast.  This is especially crucial when actually fighting the enemy.  The one with the fastest routes has the advantage.  On the flipside, if he expands too slowly, he might reach full capacity and production will stop.

This causes the player to want to protect his people.  Some are lost in defending and attacking, but the less the better.  The more of the enemy's people are destroyed, the more of an advantage the player has.  Also, to prevent the enemy from replenishing, the player will want to keep attacking until the enemy is destroyed.  Otherwise, the enemy could make a comeback.

Having more people also allows for more strategies.  For example, if there are enough people in a segment that is aiming to intersect an enemy's segment, and the player needs to use that segment slot, he can split his own segment, freeing up the slot and allowing the end of the segment to run into the enemy like a projectile.

As long as the player continues to expand, production will likely never stop, so that's a rare issue.  However, density can still get really low.  Sometimes when fighting the enemy, the player can't help but expand quickly and lose lots of people.  In this case, the player can restore his density by retracting unneeded route segments.  Some players might even make a stockpile of them behind their base so that they have them when they need them.

That was the plan for the people when I was first thinking through Sever's concept.  This would only work if I could get the number of people to really matter and make a difference in the game.  Until now, the density made a minor difference.  Expanding fast and overwhelming the enemy with lots of slow routes coming at them was more effecting than precision attacks with a few fast routes.  Changing the rate at which people move, build, or are generated didn't make a difference.

I knew that if I couldn't fix this issue, then I should probably cut the people and have routes build at a smooth fixed rate.  I could do that and make the game work, but there would be alot less depth and strategy in the game.  Overwhelming the enemy with tons of attacks would be the primary objective, and the AI is an absolute pro at that.  But humans can't make issue commands as quickly as the AI can, so that puts the human at a disadvantage.  And besides, it's just not as fun and allows for less variety and styles of play.

I knew that to reward the player for having more people, I'd have to make the difference between a sparse route and a dense route wider.  I came up with the idea to make the people in dense routes move faster and sparse routes move slower.  I've implemented it and it works.  The AI went from unfairly hard to beat to alot easier.  However, the advantage is slightly on the player's side now.  The AI just throws routes at the player without even thinking about density.  Next, I'll have to get the AI to be a bit more picky with construction and retract unneeded segments.  We'll see how it goes.

Thanks for reading!

clevceo

Sweet AI Update

Good news!  I tweaked the AI and it's beautiful!  Of course, it can be improved (it leaves its backdoor open, which is honestly the only way I can beat it right now), but it's hard!  I had to play it over and over again to get a good video of me beating it.  However, I decided to include one of it creaming me as well.  It moves fast, much faster than I expected.  It's really exciting to see it working so well all of a sudden.

First, watch it destroy me (fog of war is faded so you can see what the AI is doing).  It's hard to see exactly how it beat me, so you might need to expand the video.  If you'll notice, after a segment is split, the end that was cut off still has a short amount of time to run into an enemy segment before it shrinks into nothing.  In effect, it turns into a short range missile.  Watch the AI take advantage of that when he takes me out.



Next, watch me exact my revenge.



I'll bet you're glad the big pink thing from my last video is gone.  Unfortunately, It will be back soon.  However, I might change the texture so it doesn't look so bad.  You might also have noticed that I've tweaked the colors.  The AI is red and mine are light blue (green when building a new node).

I think today's update is proof of Sever's promise as a fun game.  There are definitely some issues I need to consider as I move forward, but all of my fear that the AI would be too hard to implement are gone.  I may not be able to create a genius AI, but almost all AIs are exploitable, so I'll be in good company.

It's nice to finally have something interesting to show.  Hopefully I'm not the only one that thinks so.  Thanks for reading!

clevceo

AI Working (Enough)

The AI syncing works.  There were a few hiccups, but I figured them out.  It now tries to attack the player.  It's still not very smart at all, but it avoids obstacles and consciously aims for the player's routes.  It's somewhat easy to beat since it's so predictable.  In other words, it will aim a route at one of my segments, I'll block it, and it will repeat the same move over and over again until I do something different.  Meanwhile, I'll have another route circling around the back and flanking him.  It makes it pretty darn easy since he doesn't consider defense at all yet.  Nevertheless, it's real fun to see it actually having a strategy and making moves that aren't scripted.

From here, I want to create a level editor so that I can test the AI in different environments without manually typing up all the level data like I did for the one you saw in the screenshots and video.  It looks simple, but when you have to type it all out, it's not so simple anymore.

I created a level editor once before in a previous version of Sever, and I think it was pretty good.  However, I was using a custom GUI library that I had created.  I don't know if I want to pull that out again because it's way too complex for my purposes.  I was a bit overzealous.  I can probably make something much faster and simpler from scratch.  Unfortunately, it's going to take a little extra time to do.  But it will be worth it.

I know this blog is really boring because I'm still building the core game engine, and I understand if no one actually chooses to read it much just yet.  If you've read this far, however, I'm hoping it's because you're at least somewhat interested.  But please check back periodically to see the progress.  Hopefully you'll eventually start to like what you see.  Thanks for reading!

clevceo

AI Syncing Continued

Today, I got the AI syncing ready for testing.  It runs, but I don't know yet whether everything is syncing correctly.  It was a very tedious process to get it to this point, so I'm excited for it to be over.  I'm sure I'll be making modifications in the future, but I have the foundation completed.  Hopefully I'll just be making small revisions or adding to it in the future instead of rewriting everything.  But I don't think I will, because I really think it's a good system.

I'm debating whether I should just build a simple AI and the networking, and then put all of my focus into just experimenting with the mechanics so I can evolve the gameplay.  My reasoning is that I might write an entire AI only to either rewrite it to fit new mechanics or never evolve the game because I don't want to rewrite the AI.  I could instead build a simple AI and rely on networking to test the gameplay.  However, at the same time, I don't yet have someone to test it with, so I'd have to either find testers or another developer to work with before I can move forward, and I really don't want Sever's development to be dependent on anyone's time other than my own.

The other possibility is to try to make the AI flexible so that I can easily modify it to work with new mechanics.  I'm not sure.  It's a bit scary, to be honest.  But I don't want to give up just yet.  One thing that's encouraging is that I don't plan to change the mechanics that much.  I don't want to add features willy nilly.  I'll only add mechanics that I think will feel true to the game mechanics, like they belong.  The game will be hyper-focused on the core game mechanics and will merely try to explore every possible situation presented by those few mechanics.  This will keep the game tight and smaller than most RTS's.

I'm scared again, but I pushed through last time, and I plan to do it again.  Thanks for reading!

clevceo