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