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