Blogs - Ash87

Preamble

Hello all, hope all is well as you read this. Today's update wont be as convoluted as the last few. As You've probably begun to find out from my stuff, I typically will run a few conflicting posts on single problems while I find a solution, followed by one blog that sums up said solution. I'm kind of hoping this is the sum-up post. I've been kind of bogged down in this AI mess, which makes sense, I mean people commit their whole career to working on AI afterall. The larger part of today's update will actually be the upcoming section, where I'm going to reveal some lore stuff to you, that I've been alluding to in older blogs, and finally explain it's relevancy.

Update

Well to begin, random movement is out. There is just no way I can make a random movement system, at my current level of expertise, that will do what I want it to do with the main monsters. I've already lost a week on this, probably best not to loose another. The solution, is to make custom paths and program the monsters to follow those paths. It was pointed out to me by a couple readers, that custom paths would allow for tighter control of my monsters, when it came to setting up encounters. Further, there is always the option to make multiple paths and set up something by which the monster will choose a path to take at random, after completing one path. This will prevent the player from just memorizing the monster patrol routes.

Sight detection has been fixed too. The sight cone has long since been a problem, because I had a few little variables that I couldn't quite fit together right. Basically I had all the puzzle pieces, but I wasn't putting them in the correct places. After a bit of research I finally found an example of somebody doing something similar to what I am trying to do, and was able to see the mistakes I had made. How it works is that the monster will be looking for the player to be in a certain range, between 2 lines, based on the angle between the monster and the player, and the distance from the monster to the player. The way I was setting up my if-then statements, because of some little quirk in Gamemaker, wasn't looking at the angles as being part of a 360 degree circle, but rather as whole numbers. To those who don't follow: Looking at the degree measures as whole numbers, means that if I say: if X < 15 degrees and Y > 345 detect, then gamemaker will be looking for a number that is both Higher than 345, and lower than 15. In a perfect world, the degree measures would be a 360 degree circle, and not count values outside of 360 (Since any value above 360, would just have 360 subtracted from it to make the value above 0 degrees). This is one of those, "That makes sense in retrospect" things, but I've got the solution now and it should be going in tonight.

Upcoming

So with the completion of monster detection, I have something that I'm going to need to look into next. So each monster in this game, is meant to be a huge deal. Well, scratch that. There will be Rats... which are kind of... well, rats (They actually, may revitalize the whole, random monster wandering script at some point). But the real monsters, are something else entirely. Here is the basic idea I've been working from:

The source material is the Case of Charles Dexter Ward. In that book, the narrator enters a space beneath the house of the eponymous title character. Therein, he finds that somebody (I wont spoil the twist ending of a 100 year old Novella, that is well worth the read) is conducting necromancy in that dungeon-esque place. The means by which this person is resurrecting people, is that he creates "Salts" of the person. These salts can then be chanted at, at which point the person resurrects. The problem, is that sometimes when reducing somebody to a salt, the dead body the salt is produced from, will not be complete due to decomposition or biological forces. This leads to some "Imperfect salts" which are twisted, deformed monstrosities that the dungeon's master keeps in a pit.

So my working title for the game as of now is: Imperfect Salts. The monsters you'll deal with, that detect and hunt you are... you guessed it, the aforementioned Imperfect Salts. NOW, why did I tell you all of this? My plan right this moment, is to make each monster unique. The whole, custom made paths is part of what pushed me down this line of thinking again (I had originally, kind of planned to do this, but was never sure if I would or not). practically speaking, this means that each monster can have, half a dozen paths assigned to them, and even have a fixed routine... which would be a really cool way of doing this, in my opinion. Further, the imperfect salts are in all kinds of a mixed up state. One thing I've figured, was that they would be kind of going through the motions of their old lives, in the dungeon. I could probably bring this across better by setting up their paths and routines by hand. Even if it'll mean more work, I figure the result of a hand crafted dungeon with that level of detail would be more appreciated by players. There may be exceptions to this by the way. I've considered there being some monsters that aren't Imperfect salts, because they are Perfect salts (There is again, a precedent for this in the source material, but I'm not going to bog you down with another paragraph explaining it... unless you want me to, at which point, ask me below). These guys I'll probably give walking paths that are changed based on other larger events in the dungeon, over multiple levels of the dungeon (Of which, at this moment, I'm projecting that there will be 3-5 dungeon levels).

Anyway, thanks as always for reading!

Preamble

Good afternoon all! I'm back with another update on the game. Everything is moving along quite nicely, now that I've recovered from my trip to see the family. I had time to get a few more art assets done last week before I left, and I'll be posting those up soon on in my image gallery. Really looking for a critique on the art when it goes up. This is the first time I've done pixel art for something like this, and I'm under no illusions that I'm some kind of great artist. So, please tear up what I do in the comments section for the images, if you feel like you need to. I'll probably throw a whole update on art work up one day too, but today is all about detection and complicating things so... on to the update!

Update

Last time I posted, I mentioned that I was working on adding in a rudimentary state machine, that would swap between separate behavior states (read: Scripts) when certain criteria were met. Well, that went in without a hitch. Actually, I scaled the state machine down from what I talked about in the last blog post, so that the cases for each state are now just references to the scripts. My intention was to do that First, and then for each case, add in the logic I'd been using to swap between states; thereby cleaning up my scripts a bit. Thing is, when I implemented that first iteration, the state machine actually did more than I anticipated, and shone a light on an issue that I had been having. What I have come to find out, is that with each individual script I had before, the scripts were still running even when I didn't tell them to. This was causing conflicts when the monster was trying to decide on which state to swap to. With the state machine in place, that doesn't happen anymore. Infact, since I implemented it, my monsters have been reacting much more smoothly than before, which is good. So, close the door on state swapping issues, and state scripts conflicting with each other...

...Open the door on new issue: Monster movement. Basically, I'm backtracking and tearing my hair out over how the monsters should walk around the dungeon. Setting paths would work, but I don't know if I want to break down and assign all the paths. If I do that, the monsters will run predictable routes, and you'll just need to memorize said routes to avoid danger. Thing is, setting up a monster that will wander in random directions, covering a 45 block area... and setting up monsters that will wander a path that makes sense (Walking down hallways, checking through rooms, etc) are two Entirely different things. I've got some ideas on how to do this, and it's fast coming the time when I'll need to implement something.. but for now the monsters are just stationary (I took out their wandering script). By the way, this is only in the idle, wandering state. Every other form of monster movement: Chasing, detecting through scent, etc. all work perfectly, obeying collisions and everything. Why random wandering is such an issue, is that it ties directly into the next thing...

...Which is the sight cone. Since the majority of your time will be spent sneaking around, I want there to be a sight cone on all the monsters. The system by which the cone detects is working pretty well. Basically, there is a distance from the player, angle to the player, a line that detects collisions between the monster's LOS and the player, and the angle the monster is facing. If the player walks into a 60 degree cone centered around the angle the monster is facing, player detected, as long as there is no wall or other obstacle in the way. The coding is all in for the cone itself (And the cone's sight distance scales based on the light level), I just need to get the monster pathfinding put in, to test it all out.

Upcoming

Detection is the major goal for now, as it's one of those core mechanics, but avoidance will come next. This will probably take the form of ducking to get under furniture, places to hide in, odorous areas that can throw off tracking, etc. But, if there are areas that help you Avoid monsters, there should be areas that make it more likely you'll be caught. Some of this will be part of dungeon design: Well lit rooms, lack of cover, etc. That said, I'm thinking of adding an echo effect that means that walking in open rooms or halls, will make the sound travel down the hall. We'll see about that once we get hearing detection in.

I have also been considering the game's objective. So my goal this whole time, has been to make it so that you'll be searching for incriminating evidence, that will get the owner of the dungeon locked up. Documentation will be a big part of this, but it occurs to me, it could also mean other things, that could be spread around the dungeon. Some of it, even requiring the killing of monsters. I am Hoping that I can make it so that the player can leave the dungeon at any time... walling them in for limited amounts of time at most. In doing this, I'm hoping I can encourage people to go deeper and find more stuff, and create a more rogue-like atmosphere. Just playing with this idea though, and if anyone has any thoughts comment below.

Anyway, that is today's update. Should have another up in a few more days. Thanks as always for reading!

Preamble

Hello again everyone. As I've finally explained to almost everyone the blog's goals and the project I'm working on (That would be blogs 1 and 2 respectively, for those interested), the length of these blog reports should start growing shorter. So if ever you've looked at what I'm writing, and decided you had something better to do, than read a late 20-something prattle on about nothing for an hour: Good News! It should only slice like, 15 minutes out of your day now tops... Probably more just a hair over that when I am feeling especially verbose. Bit of quick news: this will probably be my only post for the week. I've had a tragedy in the family, and I will be away from my keyboard until Sunday. So, it'll likely be late next week before I put out another one of these. Anyway, on to the update!

Update

Well I've spent the last 2-3 days researching how to proceed from here, and this is what I've got.

Currently, there are states (These are independent scripts, swapped between, based on stimuli effecting the monster) for Idle, Chase, and Scent Tracking. The idle state handles the movement, the Chase handles the monster zeroing in on the player if the player comes inside a radius, and the scent tracking detects scent markers inside of a radius and follows them. None of these radii obey collisions as of now. The problems faced, are detailed in the last blog, but basically: The movement script that happens in the idle state, is causing the state swapping if-then functions to not work. Further, implementing detection scripts one at a time, causes all kinds of bugs. That means I have to go back and debug the existing scripts to fit the new script... screwing up the old scripts... it's just a mess.

The solution: The new states will be Idle, Chase, Scent Tracking, Hearing Alert, and attack. General movement, will be handled by coding the monster object, rather than in it's own standalone idle script. For those who aren't familiar with Game Maker Language: You can apply code directly to objects, or you can get the objects to reference scripts, when you are constructing AI. If you push everything off onto scripts and states, then you don't have to have uber complicated if/then statements set up for every possible situation the object will encounter, while it rolls through the lines of logic necessary to decide what to do. The movement code I am using will be built into the monster, and not be part of the scripts from now on, because that way the scripts can reference variables used in the movement script, without needing to clog up the script by re-declaring the variables for each state for different styles of movement. Rather, the references can be pulled from the main object's code and applied to the scripts themselves. This was already somewhat built into the existing system, yet the aforementioned problems were causing me to have to restate variables over and over while I tried to patch up the code.

Further, the state switching will be unloaded onto a step event (A check that happens once every Step of the game, there being 30 steps a second), that checks each step which state applies. This will be done with a Switch function. Currently I'm using a series of if-then statements in each script. The problem is, that while now it looks like:

If (track <= scent_Range && object_exists (obj_scentMarker)

{

state = scr_enemy_scent

} else if (dis <= sight_Range)

{

state = scr_enemy_Chase

} else if... Etc.

In Each and Every script... I should be able to reduce All of that down to:

switch (state)

Case 1: "chase"

(dis <= sight_Range)

break;

Case 2: "Track"

(track <= scent_range)

...Only being checked in 1 place, once a step by the monster object. Further, if you look at the new switch function setup, where it says "Break" that means (According to what I've read) that each 'Case' to 'break' is one function, that once it's been checked, returns a simple True/False, and doesn't require going through a Long line of Boolean logic, like the If-Else statements I was using before. It reduces the CPU use in other words. Also it'll be more organized, which I can tell you, is a freaking blessing in my opinion.

Now, I know I'm probably going to regret this, but I'm JUST focusing on the monsters detection for now. Attacking, combat... I still haven't hammered that out. I will probably spend the next few days I'm away, doing some theorycrafting on the combat. I'm wanting it to be frantic and difficult. The player character isn't meant to be some avatar of martial prowess, so he shouldn't be able to beat up monsters with half their nerve endings missing, and no sense of pain, who operate via parasitic slug pulling them about like flesh marionettes. I also need to answer for myself some questions about the monsters from a story perspective. Basically, the monsters will be reanimated corpses, that things didn't quite work right. They were either incomplete, or too far degraded to bring back as something quite human, so the badguy started cutting corners. In doing so, he found a way to animate them, to get what he wanted... but the result is less: Coherent person awaken from long sleep, and more: Forcing the consciousness through the pain and lack of neural connectivity, and putting it in the hands of something that... well... controls the dead person like a fleshy marionette. So... how much coherent thought and memory would that monster have? That'll determine some of the mechanics of monster detection.

Still, got tonight and tomorrow, So I'm going to try and throw the framework I discussed above, in tonight and see how it works. Wish me luck, and as always, thanks for reading!

Good evening readers, Ash here. Today we'll be discussing the current project that I am working on. Since this is introducing this project to you, there will be a section explaining the ins and outs of the game, it's setting, mechanics, etc. so as to catch everyone up. Following that, I'll go into what I'm currently working on. That said, you aren't here for the preamble, so...

Project History

For my first major project I had 3 choices: a platformer based around spelling, a re-imagining of the old game Motherload, and a lovecraftian dungeon crawler. When deciding, I realized I would have to balance what I was capable of, with my ambition for the title. As I still am brand new to game development, I decided to err on the side of caution and go for something that was pretty straightforward: So I went for the dungeon crawler. The spelling game, and the Motherload reimagining would have both required me to have some form of random block generation, something I wasn't prepared to do. Conversely, making dungeons is something I've done modding for fun in the Elder Scrolls series, and I love both writing and Lovecraft.

So my plan has been to make something based on The Case of Charles Dexter Ward (Link included, it's a pretty good read). The basics of my story are thus: You are a doctor in a small town located in Rhode Island, following the Civil War. You retired to this village following the war, in which you helped liberate the Andersonville Prison Camp (Link to wikipedia). While you settled into your New English life, you started to notice some weird behavior from a local man who lived off the coast, on a small island. Eventually you decide it was time to take drastic action, for the safety of the town. Traveling to the island and steal into the man's house, you are intent on finding evidence that he is a threat, before his work does damange to the people around him. Doing so, you stumble across a subterranean labyrinth that is inhabited by all kinds of unspeakable monsters conjured by the man in question. It is your job to find the evidence you need to incriminate the man who lives there. The further you go into the dungeon, the more you discover about what is going on, but the more damage you sustain.

Mechanically, the game is based around stealth. The standard monsters, that inhabit the dungeon are very difficult to kill. They are a combination of reanimated humans, and eldritch monstrosities, so fighting them directly isn't really an option. It's possible, but without planning, staging, and weaponry... it's probably not going to work. Once you have what you need, you can just leave, but if you don't have enough information you may do more harm than good, because each monster killed, each bit of info you recover, helps the people of the town more. Monsters will detect you based on scent, sound, and sight; with some monsters being more predisposed to one of those sense than the others. But, with each sense, comes means of limiting your exposure, and avoiding detection.

I've been working on the project almost exactly 2 weeks now. There are stand-in assets for the monsters and many items in the dungeon, while I have made original sprites for the Player character, dungeon scenery, and various other things here and there. I have programmed a lighting system, collisions, movement, and rudimentary monster AI. My primary goal at this time is to get the monster AI advanced enough to test and tweak those core mechanics.

Status

Now that we have you caught up...

Well right now I'm rather stuck. The game is coming together fine, and I got a more advanced version of the scent detection put into the game. The system is simple: the various objects will drop scent markers around the map. These scent markers are then zeroed in on by the monster, if they fall into his detection range. The monster will then follow the markers one at a time, until the markers run out or the monster detects their source. The markers themselves stick around for 20 seconds, so as to give the monster time to find them, and give the player character warning when the monster is on his trail. To avoid clogging the map up with markers, as the monster tracks, he'll delete markers he investigates. Because it takes time, you can throw the monster off by luring him into areas where the markers will not last (In water) or by confusing the monster by luring it into odoriferous areas of the dungeon.

Sight detection, is pretty clear cut, but has actually become the more complex of the two systems. If you fall inside the monster's sight cone, the monster will pursue you. The sight cone varies in size, based on the light levels around the monster. While standing in pitch darkness it will be 100% possible to avoid the monster walking just a few feet away from you (As long as you don't make too much noise, and stay still). Currently I have the detection system In, and it seems to work well.

So, if I have both systems in, why am I not testing? Well, everything works just fine on it's own. It's just once you try to fit each of the pieces together, it starts to fall apart. I've had a persistent problem for 2 days, where the states I have coded for the monsters, will not swap, or wont work as they should. My biggest issue, is my monsters move randomly, with a different direction being computed for them, every few seconds. The monsters moving randomly was a stand-in for the final system I wanted to add, where the monster would choose from a number of available routes to walk. My stand-in system, is now interfering with the logic that makes the monsters swap between the states that determine their behavior. I'm going to have to implement some form of my final system in for this to work. That said, I've already had trouble getting collision and monster movement to jive once before.

The AI is frustrating in many ways, and I may yet have to retouch my scent detection system after this, once I start letting multiple scent markers get dropped by various different sources.

So, what am I going to do? Well first, I'm going to take the time to sit down, and map out in detail the logic behind how state is swapped between. I hadn't mapped that out before hand, but I find I need to, before going any further. It's just getting too complex, and bits and pieces keep conflicting with one another. I mean I have just hit a brick wall with the sight detection. Despite the fact that I have a full design document for the feature that I know works... because of the monster's random movement system, I can't implement it, because the order in which I am recalling variables for one, conflicts with the order in which I need to recall variables for the other. I'm going to just implement the random path system I intended to use in the final product instead. I'm also going to reassign a few things to placeholder objects, that can be assigned as Parent objects. For example, I'm going to make a solid object, object... that is then assigned as a parent to all walls, crates, iron maidens, etc. that need to be avoided when collisions are considered. So far, these kind of tweaks and changes have already happened with the scent detection, movement, lighting and collision systems I am currently using, so I'm not too bothered that I have to do it again. Luckliy, each time I have to take time to do these kind of changes, it's improved performance just a little bit. Not that performance has been a Real problem, I mean it's a 32 bit pixel art game, but I'd rather not be bumping up against 60 FPS with my current rig, so watching it run at 80 - 100 FPS makes me feel good.

The big bug I'm going to look at tonight, is that if I am pushing the down and left buttons while standing against a wall below my character, I get warped to the top of the room. I THINK this is an issue with the scent markers, where they are spawning in the wall, or about to, and so the character is moved someplace, where the marker can drop and avoid collision. This has been a persistent bug for a while. I think, fixing it should just be as simple, as reassigning the center of the scent marker, so that it drops in the middle of the player character.

Conclusion

So, I'm already testing the individual systems, and I'm happy with how it's all coming together. I had budgeted 4 months to do this game, and as of right this moment, I think I'm not behind that estimate. Luckily, since there is so much to do, I'm also able to swap over to another job every once in a while, if I get burned out, while working on something else. For example, if the scent detection system is bugging me, I've always got art assets to work on.

Anyway, Hope this brought you up to date on what I'm working on. Feel free to ask any questions you want about the project, below in the comments.

Thank you for reading!

Hello!

Just thought I would put an introductory blog up about what you have stumbled across, who I am, and what to expect while you are here; you know, before I launch into a series of rambling post about rocks, game design, and/or history. So, instead I am going to ramble egotistically a bit, about myself! Well, just for a moment, and if you are only interested in what I'll be writing about, the two sections of this blog are clearly labeled, just hop down to the Content section (Though be warned, you'll be coming in medias res).

History

My name is Eric.

AKA: Ash87, Ash1987, SergeantAsh87.

I am (At time of writing) a 27 year old geologist. My hobbies, to this point have included hiking, camping, rock collecting, exploring, reading, building, writing, and gaming; but, the reason I am here, is that I have decided to try to design games in my free time.

I started designing games 2 weeks ago for a couple different reasons. The first reason, was that I'd always wanted to try to design my own games. I've always been somebody who followed game development, almost more than I did the actual games themselves. The personalities, the skill, the problems, and the results of game design are often a complex narrative all their own, something that can be more intriguing to learn, than the storyline of the product. The second reason is much less noble, I had a Caesar moment. History Lesson: When Julius Caesar turned 32 he had a bit of an existential crisis. He was already an up and coming member of the roman senate, but his ambitions were... well Roman, in scale. He said to himself: "By this point in his life, Alexander the Great had conquered his first empire." So, he set off to Gaul after raising an army, and proceeded to make a name for himself by killing thousands of proto-frenchmen. For me, this same kind of moment happened to me, when I was wiki-hopping one day. I came across Zoe Quinn's page on wikipedia and noticed that she and I shared the same birth year. So, in the same 27 years it took me to get where I was... She had made a video game and managed to spark off a colossal controversy, that garnered her enough notoriety (Positive or negative notoriety, I'll leave that decision up to you the reader) that she got to write on the Cracked.com! This, obviously, could not be tolerated, so... time to make some vidja games. I figured that would be easier than starting a controversy.

So, there was one problem though... I didn't know how to actually design games. I mean, I'm a generalist by nature, so I knew how to make pixel art, design levels, code on a basic level... But, I didn't know how to tie it all together. So I started doing a ton of research, got myself GameMaker and Unity, and got to work. In doing so I decided (Mostly imitating real life game devs) that I would keep a journal of what I was working on, a dev journal. I've always enjoyed writing, and this was a new, fun, and entertaining thing that I was trying, so I figured I would always have something to write about. Writing out my progress in the game I was working on, had an unexpected side effect though, it helped me puzzle through the problems I was facing with my game. I decided, after overcoming some rather major obstacles in my current game, that I would actually start writing this as a Blog, because I was already filling a notebook and a forum (This started out as a post on the Extra Credits forum) with my ramblings, why not inflict it on other people?

Content

So that is who I am and why I am here, so what can you expect from this? Well (Just to get this out of the way), despite my previous mention of Zoe Quinn inspiring me to game design... I am not here to be political. Honestly, I would be incapable of doing so. I have a decidedly middle of the road standing on most big issues, and while I can occasionally get riled up about something, I don't think it would be all that interesting to have you read me try to find a middle ground on everything. If something does effect me, and I feel I have to say something, I'll mark it clearly and make sure that you know it's a ranty political mess before you get too far into reading it. 90% of the time this blog, this will be a retelling of what I'm trying to muddle my way through in GameMaker or Unity. The other 9.95% of the time, on slow development weeks, or when I feel like it... we may get something about History, Geology, History of a Game's development (First blog about the history of game development going to be on Planetside 2, just going to tell you that right now), or maybe with time... tutorials on how to do things I found difficult to do.

So, there it is. Now that we are all on the same page, thanks for reading!