Programming is Hard

Been awhile since I updated. There's a reason for that: My actual job has been keeping me busy. And by busy I mean working the crap out of me. I've been putting in overtime hours for the last few months.

I've kept plugging away at this programming thing, and understanding how DSE works. The original intention was to use this as a precursor for a gamedev blog - so people could get updates on progress. This is difficult to do when the most I can do is poke at the coding for a couple hours at most, and compounded by my working every day of the week.

Still, not an insurmountable task. I've learned quite a lot about many things, a great many deal regarding the DSE (and just how friggin' powerful it can be!).

Speaking to others about my not-so-secret project, I describe myself as less a programmer and more of a hacker. I don't come up with a lot of code myself, mostly I appropriate from others until I get it to do what I want it to. This has mixed amounts of success, but I'm really proud of how far I've come these last few months.

When last I left off, I was dealing with syntax issues, and understanding why the code wasn't recognizing my Day variables. Given tonight's little project, I think this is a nice time to review.

So, anything that occurs during the init line is not set in stone - those are the default values set in when the game launches. Any variables changed during the course of the game should be saved as a state when Ren'Py saves the game - meaning even if Day = 0 on launching the game, it will still be Day 39 when you load your game (rigorous testing concluded this functioned properly).

After much hacking, I've accomplished not merely setting up additional time slots for events to occur, but I've also locked choices during specific days of the week, removed them from the planning menus, and also set aside an option for these things to be overridden should the need arise (say, a holiday for example). The scope of the game is pretty large, perhaps too large to be reasonably accomplished, but I'm not one to let something like that keep me from progressing.

Today's project (or the project I started a few days ago really) involved a very simple thing: How do we make sure that events play out only in a specific location, at a specific time? For reference, the events are structured like so:

    $ event("library", "act == 'library'", event.only(), priority=200)

    $ event("garden", "act == 'garden'", event.only(), priority=200)

    $ event("cemetery", "act == 'cemetery'", event.only(), priority=200)

    $ event("dojo", "act == 'dojo'", event.only(), priority=200)

    $ event("workshop", "act == 'workshop'", event.only(), priority=200)

    $ event("laboratory", "act == 'laboratory'", event.only(), priority=200)

    $ event("office", "act == 'office'", event.only(), priority=200)

These are some of the placeholders I'm using for now, but they illustrate what I'm working with. Let me break down the code for you: The first part of the string is the event that is occurring (so I have for example an event named 'office'). The second part, the 'act', tells us that this event plays out when the current act is the 'office' option from the planning menu. So when you go to the office, the office event plays out. The 'only' descriptor states that this is the only event that should play out, and any other possible options should be pushed aside regardless of whether they are eligible to play out. Lastly, we have the priority, which tells us how important this event is in relation to the others. In this case, all of my events here are set at a priority of 200, which isn't too terribly important since 100 is the recommended default.

So I set up some testing events to play out, to make sure they occurred properly.

    $ event("tzan_intro", "act == 'cemetery'", event.only(), event.once(), priority=190)

    $ event("tzan_ar01", "act == 'cemetery' and period == 'late_eve'", event.only(), event.once(), event.depends('tzan_intro'), priority=200)

Once again, let's  break down what's going here. You can see that the event "tzan_intro" has a higher priority (lower numbers are higher priority) than the normal cemetery event up above. We can also see here that it only plays once. This plays out any time you visit the cemetery, but only the first time.

It worked just fine. The second one though, that took a bit of doing. Because for some reason, it just would. Not. Trigger.

I spent the last few days pounding my head against the wall figuring out why. Was it not tracking the period name? Or was it not referring to the variable correctly? After much running in circles, I realized the error of my ways, and also learned about something very cool I could do.

The problem... was the priority of the second event. Because it is lower on the list than cemetery, which as I noted has an event.only tag, it was being disregarded every time. As soon as it was placed on a lower priority, like with the first event, it played out correctly the next time I visited the cemetery in the late evening.

This revelation however opened my mind to how powerful this events system can be. Because you see, I can have multiple events play out, in order, so long as they are not pushing one another out.

So for example, I can have the normal cemetery event play, where a player arrives at the location and gets a brief description, and then it can load the next event, where they meet a character.

Needless to say, this is a pretty powerful revelation to have, and I really look forward to the day when I can openly share more about what the game is intended to be. But for now, I have to keep playing with code until the framework is solid. And also cobble together some art assets.

But so far, I'm rather proud of the improvements I've made so far, and the amount I've learned about how DSE, and Ren'Py in general, work.

Lessons learned: Syntax is everything

I may have mentioned this before, but I am not a very good programmer.

Back in high school, I learned the basics of HTML. Straight HTML, mind you. I could make some of the ugliest damned webpages you ever saw, all with the glory of friggin' Notepad. It taught me the basics of program logic, but beyond that I can't say I ever learned any useful programming skills.

That said, I am capable of sort of reading code. So transitioning to Python and learning the rules the hard way (ie: jumping right in with both feet) has been interesting to say the least. *laughs* I've made some real progress.

Ren'Py utilizes Python scripting, but it seems to have its own rules and shortcuts, which make things easier for guys like me who haven't bothered to learn programming via proper channels. What I do is much less programming, and much more like hacking things apart and trying to stitch it together into some sort of Frankenstein's Monster in the hopes that it works (it's aliiiiiiiive!).

Tonight I set some fairly simple goals for myself:

- Set up the class system, and create placeholders for all of the classes

- Ensure that only Attend Class shows up on the appropriate days

- Check to see that the correct class is being executed on a given day and time period

Needless to say, it provided me with a few challenges right off the bat. Chief of all: How do we determine when classes become available?

Because of the structure of the game, it is necessary to differentiate between morning and afternoon classes, as well as to differentiate 'Monday' classes from the rest of the week. This creates ten courses, all of which have their own set skill increases associated with them. Furthermore, if I feel the need to create actual events that take place during these classes, I need to find a way to have them all execute in the correct order.

The first idea that came to mind was to use the day counter that comes packaged into the DSE code. It looked a little something like this;

init python:

    register_stat("Strength", "strength", 10, 100)

    register_stat("Intelligence", "intelligence", 10, 100)

    register_stat("Charisma", "charisma", 50, 100)

        dp_period("Morning", "morning_act")
        if (day == 1 or day == 8):
            dp_choice("Attend Class1", "class01")
        if day == 2:
            dp_choice("Attend Class2", "class03")
        if day == 3:
            dp_choice("Attend Class3", "class05")
        if day == 4:
            dp_choice("Attend Class4", "class07")
        if day == 5:
            dp_choice("Attend Class5", "class09")
        if (day == 6 or day == 7):
            dp_choice("Something Else", "class05")
   
    # This is an example of an event that should only show up under special circumstances
    ###dp_choice("Fly to the Moon", "fly", show="strength >= 100 and intelligence >= 100")
        dp_period("Afternoon", "afternoon_act")
        dp_choice("Study", "study")
        dp_choice("Hang Out", "hang")
        dp_period("Evening", "evening_act")
        dp_choice("Exercise", "exercise")
        dp_choice("Play Games", "play")
   
        dp_period ("Late Eve", "late_act")
        dp_choice ("Twiddle Thumbs", "twiddle")
        dp_choice ("Stare at ceiling", "stare")

It makes perfect sense, except that when you try to run it, it throws an exception: "day not defined".

What gives? Day is clearly defined - it says so right down below in the start code! This was the first major lesson of the day - Day is not defined in the intro block, and you cannot define it in the init code because every time you load the game, it would force the day to become 0 - regardless of what the actual day was. This provides a problem, because you only want the day to become 0 at the start of the game! How do we get around this?

It took some finagling, but I found that placing the day planner code after the day code is initialized gets around this. Now the game properly only provides the correct option depending on what day number it is. Which led to the next problem: While the correct option was showing up, for some reason none of the events were playing out properly! The day progressed, and the correct placeholder for the class was showing up (proving that the correct buttons with the correct commands were being displayed). But for some reason, the execution of the day planner was skipping over my placeholders.

Eventually, I found the source, and it lay in the event planner's code.

    $ event("class01", "act == 'class'", event.only(), priority=200)

    $ event("class02", "act == 'class'", event.only(), priority=200)

    $ event("class03", "act == 'class'", event.only(), priority=200)

The problem lay in the act. The correct event (Class 01 for example) was being called. But instead of executing the correct event, it was attempting to jump to 'Class'. My mistake was in thinking that act meant a classification of an action - instead, that's the part of the code that tells it 'jump to this event name' (or 'when this action is called, jump to this event', I haven't figured out which yet). So essentially, I wound up breaking it completely by accident, but it wound up fixing itself once I corrected the error. So now the correct classes show up on the correct days I tell it, and the correct placeholder activates.

Unfortunately, this has presented a new problem that I didn't anticipate until I sat down to write my progress for the night: While the code works in execution, loading a saved game during the start of the day (when you would decide what to do for the day), everything breaks.

Why does this happen? Because when you load the game fresh and jump right into a save, the start-of-day code has already executed, meaning none of the day planner options have initialized, because they were not defined when the game loaded. Using the "roll back" option to step back to just before the day initializes causes the code to execute properly, but you should not be required to step back the first time you load your game because it hasn't figured out what Morning is.

I haven't found a solution for this yet, but hopefully tomorrow I can figure it out (if I don't manage it tonight before I go to bed).

So while I've hit my goals for the evening, I'm still left with one puzzle that I may leave for tomorrow.

Let's Make a VN!

It's been nearly four years since I last dusted this thing off. Well, this seems as good a place as any to talk about things, and I could definitely use an outlet to talk about my latest project. It may be interesting to keep a development blog for this, as I can remind myself of any lessons I might learn.

So, I'll just walk through my thought process. For so many years, it's been my desire to make a game. But I was always limited by something or other. I wanted to break into the video game industry somehow, but things always seemed to get in my way. It didn't help at all that the industry tanked, and I simply don't have the experience necessary.

The desire to create, however, has never really abated, and after a very long period of debate, I decided that there was only one way for me to get what I wanted. I would have to just take matters into my own hands. If I wanted to make a game, then by god, I was going to make a game.

Making games is hard though. I bounced between different engines and concepts, talked with some friends about one idea or another. Thanks to some collaborative projects I've done with one friend in particular, I settled on trying to deal with something that is well within my grasp.

I've come up with some pretty cool pitches before, all of which are rather difficult to implement the first time around. I may revisit those ideas at some point in the future. But the important thing, or so I have been told around the Internet, when getting started with game design is simply to make a game. It doesn't necessarily matter what kind of game it is, so long as it is a game. It probably won't even be very good. But if you can play to your strengths, and design around your weaknesses, you can create something that people enjoy.

Which brings me back to a thought I had nearly fifteen years ago: I should make a Visual Novel.

Over the years, I have continued running games, creating settings, and making characters. I like to think that in the last year or so, I've really been bringing my A-game. I've been thinking about how to make the most effective experience I can with the tools available to me. And I've also helped craft a few tabletop systems in the meantime too. So now, I think I have a fairly solid idea of what all goes into making a simple sort of game.

And let's just be honest with ourselves: If games like Go Go Nippon! can succeed, then by god I can do something at least marginally better.

I realized that a programmer wouldn't be very likely to fall into my lap, and my work schedule being what it is, I'd need a project I could work on in my spare time anyways. A VN seemed like the perfect fit. I have an art degree, I know animation and such, and there are plenty of tools available to me that I can use to craft the experience. Moreover, writing a VN should be a far simpler programming task to accomplish. But before anything can really be announced, I had to create the core game mechanics, and ensure that they worked.

This led me to Ren'Py - a game engine that was first conceived about fifteen years ago. I remember when it had just come out, and to my surprise it is still very much in development. So I began to poke around, and ask myself: How hard would it be to actually create a game in Ren'Py?

Not very, I soon learned. Thankfully my basic programming experience let me settle in pretty easily. I can read code to an extent, and while I'm no coding wizard, I can definitely read documentation and fumble around until I find the right answer, which is just my sort of pace. By proving that I could create even a very basic, linear experience within a couple of days of picking up the engine, it seemed much more likely that this could easily be done with a two-person team - with me assuming most of the workload, as it were.

I partnered with my friend, who had a pretty neat concept lying around, and helped her flesh it out. We created a basic world, and populated it with a variety of nations with which we could pull NPCs from. Within a week, we had a pretty decent background to set the game in, and I was beginning to consider how the game would actually function.

We had a setting, we had a game concept, and soon enough we had characters. But there was still one thing we didn't have: a working game engine. So with the background elements in place, I started working through figuring out how I could create something a little more complex than just a typical linear VN. I wanted to make something more like how I've set up some of my more recent tabletop games. I wanted a game that was a little more open-ended, that was more of an interactive story with multiple choices. A combination of the Mana Khemia series in terms of story - where things happen, and a plot progresses, but really the main fun is just hanging out with your friends for a year at school.

From there, the pieces just started to fall into place. I had a basic concept for how the game would progress, and as far as I'm aware, this isn't an approach many people take when trying to make a VN.

But of course, I know how I can be, and that I have a tendency to go a bit overboard sometimes. So I came up with some guidelines to follow, and once I've completed the playable demo, we'll see where things go from there.

The basic game itself (the demo, as it were) will only take place over a period of one month. 30-ish days, really. This cuts down on the work that needs to be done. But it's also very important to ensure that all of the game mechanics can be expanded to a full year if need be - since that is the original scope of the game. If this moves beyond the demo stage, I would like for players to be able to take their save data from the demo and pick up where they left off in the full game. It may be a small detail, but it's important to me, and it forces me to think further ahead as a result.

So I am left with the following problems to consider, as this is my first real attempt at making a video game:

- Creating core mechanics that are simple and engaging, which can easily be expanded if the game is ever moved beyond the prototypical demo stage.

- Keeping things simple enough so that my head doesn't explode from too many choices.

- Crafting an enjoyable experience where the choices the player makes actually influence the game, even if in subtle ways - I'm tired of skills being static things that don't really have an impact on how stories play out.

- Ensuring that no matter what a player does, the game is still somehow 'winnable' - whether they like the outcomes or not is besides the point. They aren't required to make friends with everyone, just to survive to the end one way or another.

- Letting the player's choices be dynamic and meaningful. The choice of what skills to progress during the course of the game should affect how the player progresses. Playing an angry warrior type should feel different than a laid-back artist, for example.

- Lastly, and perhaps most importantly: Make sure that all of these things remain simple enough for anyone to pick up and play.

They're fairly tall orders, but I think I can say with confidence that I can now achieve all of these goals. It will take a bit of time, but this is a labor of love, and if the demo is well received, that will let me know that I've done something right. In the event I've only managed to make a horrible trainwreck of  a game, well that's fine too - at least I'll have learned something along the way.

That having been said, here is what I have managed to accomplish in the day I've picked the project back up again:

- Implemented the skill system, imposed a class choice at the start (to determine your starting skills), and ensured that it functions as intended.

- Tested hiding certain choices if the player does not have the requisite skill - feature functions as intended.

- Tested conditional modifiers of choices - having skills at a certain level will cause the scene to play out differently. Feature appears to work as intended.

- Tested and confirmed working adding skill points as necessary.

All in all, I'd say this is a good start. Now while the core skill system is now in place, I need to consider the next major hurdle - implementing the class schedule, and ensuring that it plays out as intended.

Most of my work before today was poking at menus, figuring out how to adjust them as necessary, and moving them around to better fit all of the information I required. That was fairly easy work, I'm finding, but now I know which bits to fiddle with, and that makes this far more attainable.

Now comes the difficult part: working on the class menu, and making sure the schedule plays out as intended.

For anyone that cares, I decided to use the DSE (Dating Sim Engine) Day Planner and Event Manager to make my life infinitely easier. It comes with most of what I needed already built-in - skills and values for them, and most important an event manager that automatically checks to ensure sequences play out as intended. If you decide to go to the library in the afternoon and the lake in the evening, you can choose that at the start of the day and, barring something catastrophic occurring that would interrupt the next event, it will play out. (If you wind up passing out from an assassin's dagger in the library, well, you're clearly not going to be visiting the lake that evening.)

I'll wrap up this big long spiel with one last take on what I plan to accomplish in the coming weeks. I intend to ensure the core class mechanics work. Once those work, I can begin working out how to set up a rotating schedule for the five interactive NPCs with story arcs - as well as testing for events to play out in specific locations on specific dates.

I foresee the classes thing being a huge headache, but not nearly as troublesome as choosing which location to visit in the scheduler. Ren'Py doesn't support drop-down menus for some reason, so I will need to find some kind of workaround for that. One thing at a time though - first we focus on the class schedule, then we work out the rest.

It's going to be a fun project, and I suspect the biggest hurdles are now in front of me.

Wildly Inadvisable: Being Inadvisably Wild

More on the skills tonight, I suppose, since I really want to write something tonight. Progress on separation of the skills went by rather swiftly, but imagining how it would all work together is taking a bit of work. But here's the basic concept.

For the most part, I'm keeping the "Perfect 10" idea I had for the General Skills. It lends itself well, and it makes me think that maybe I might have a good thing going. Now that I've looked at what I've done, there's been some reconsideration on the level cap thing for the general skills. If I put a cap on it, perhaps it will be 20, and there are a few reasons for this (assuming I want a cap at all).

Based on some NPC drawings I did up, a good "villain", or at least one for this particular game, has a fairly high base for magic-based skills. Using this as a litmus, I decided to ponder difficulties and the benefits for taking points and specializing in certain areas. For instance, Mind Control, a specialty of the Advanced Spell Control skill.

Basically, any spell that falls into usage by this are things that take either little effort, or take preparation. A few of them might be usable at will - for example, Mind Control. Of course this all will eventually tie into making Willpower rolls, which is good, but as a base, I wondered how many ranks it would take to destroy or create memories in a person's mind, based on previously-written DCs, under the new system. Using one of my villains is a great way to test this.

As written, and by preparing to use the rules I set forth, in order to perform such a feat, it could take approximately 6 character points to achieve this level of mastery - and in fact, this could even be enough to allow total domination of a strong-willed creature. Here's how this works out.

For every CP you spend, you gain two skill points. For every two skill points, you can spend one on a Specialty. Specialties grant you a +2 bonus to their respective field. For example, Mind Control grants you a double bonus for that particular use of the skill. So, with 6 points, that gives you a total of 12 skill points. That's 8 ranks, and four specialties, which when added up, gives you a +16 to Mind Control (if you decide to take it all four times, mind you). Depending on your ability, this could mean that you can either remove someone's memories, create new ones, or just dominate them outright (subject most likely to a Willpower roll, of course).

That seems rather excessive, however - a powerful ability for only 6 CP spent. Of course, all of that progression is difficult to swallow in a single gulp. So either something is very wrong with my DC tables, or I need to adjust how skills works. Perhaps the main issue is that the DCs appeared fine when I was only dealing with a die roll for these skills. But when you are guaranteed the maximum result, it makes things considerably more difficult.

On the other hand, however, if we make the Difficulty for resisting Mind Control equal to the caster's Advanced Spell Control skill (which in the above example is 16), most people should be able to resist that - even the average Joe ought to have a decent chance at resisting that, since the average Willpower for any given person should be 7-9. Now, this only gives the normal person (or even PC!) a 30% chance of resisting the effect of what could essentially be a total mindwipe. This is both good and bad, because it gives a player few options at resisting an extremely powerful effect, while at the same time not entirely trivializing an extreme amount of specialization.

Of course, it also means that for only 6 CP, you are pretty much given the license to go fuck around with people's minds free-range. With only a one in three chance of failing, odds are in your favor that you will win - even better since your Magic skill will inevitably increase the difficulty. If the average Magic score grants a +3, then there goes any chance you ever had of resisting an effect.

I think that some DCs need to be reconsidered in light of this. Most effects should have their ability shifted up by at least five points or more. This way abilities will require more progression (another three skill points, which translates to two more CP), and which promotes a more balanced approach to increasing the power in one's arsenal.

Now, the negatives: This means it can be pretty easy for an enemy to be able to dominate even the PCs, which is a very bad thing. Of course, since the only thing that really sets a PC above any normal person is their choice of skill arrangements and Advantages, it can be difficult to find a good balance to this. Willpower was originally meant to be one of the few stats that was extremely difficult to increase - particularly due to the influence of Corruption playing a major part in the system.

Perhaps certain effects should be shifted up even further, to make purchasing the ability to control another person even more demanding. More consideration will have to occur on this point, and I think I have gotten away from the main topic at hand, which was that skills have new specialties available to them.

Some skills will allow abilities that can be used by a character, both inside and outside of combat. Such abilities include being able to create computer viruses, cast special spell rituals (summon SUV anyone?), or even the creation of magical items. I'll get into that some other time, but magic items are rare and should remain so - after all, they are very powerful and time consuming to make. We're talking days for something simple, weeks or months for something most players would consider "useful". But again, that is a topic for another time, the important thing is how this impacts skill progression.

Some skills have many specialties, some of which now affect certain attributes that are otherwise difficult to increase. Athletics has specialties which allow you to increase Health, Fatigue, Speed, or even your Stamina. Feats of Strength can now be used as a good determination of what kinds of objects a character can lift - and if they deal any bonus damage when throwing them at someone (or something!). Similarly, some specialties may in fact have their own branches of even further specializing. In the case of enchanting magic items, perhaps you can spend a point to lessen the time it takes to create an item.

Perhaps another 'fix' to this is to have the initial 'rank' of certain Specialties do nothing more than grant access to an ability, instead of also granting a +2 bonus to it. That would require 3 additional Skill Points in order to attain the same amount of power, while at the same time not overpowering the initial rank of a specialty. You can be a Jack of All Trades, but you will suffer as a result. But likewise, a well-rounded character will be more versatile than a one-trick pony.

A lot of things to consider, and I've taken up enough time typing this. I'll sort through it later.

Wildly Inadvisable: The purpose of skills

Behind on blogging again, but life's twists and turns keep me on my toes lately. I've some extra time tonight, and in order to get to sleep, I think I will muse on Wildly Inadvisable, since I'm back to running it and the skills system has been bothering me quite a bit.

What's the point of a skills system? Well, that is a difficult thing to answer. In broad terms, it is a measure of things your character can do. This can include things such as creating objects, remembering a piece of information, climbing a wall, or casting a spell. In simple terms, this is a pretty easy thing. But taken into gaming terms, it can get pretty complicated, especially since there tend to be two types of skills: Combat skills, and non-combat skills.

In 2nd Edition AD&D, there was a pretty clear divide here. You had a list of Non-Combat abilities, such as Seamanship which got you a host of things like bonuses to swim, and the knowledge of how to work on a boat, but not necessarily run one. It was like how Professions became in d20 Modern - a measure of things your character has done in the past to give them an edge of sorts.

But many systems attempt to lump skills into the same category, and force them to play by the same rules, which can make things quite messy. Therefore, I have come to the realization that my previous dependency on d20-like mechanics is actually hurting the way I have conceived of the skill system for WI. Let's examine this.

How Things Turned Out

The concept behind skills seemed pretty straightforward. You had your attributes, which each had key skills tied to them. From there, these skills had specialties, ranging from resisting a specific type of damage to being able to create a computer virus. In theory, it works great. In practice, it's pretty messy overall, and it is hard to actually find anything in there.

Not to mention the messy amounts of math involved. For every two ranks you place into the basic skill, you can apply a single point to a "specialty", which basically means you gain a higher benefit to a specific instance. For damage resistances or elemental affinities, this is kind of cool. But it makes for a very messy skill sheet, particularly for a game that is supposed to be simplistic.

Fixing The Problem

In order to address this, a few ideas have occurred to me. Instead of an overly-complex system like I have already had set up, one can easily just separate things into combat and non-combat skills. Combat skills are those which do not have a hard 'cap' on them, and are intended to be scaled up as high as possible. Non-combat skills, on the other hand, should have a 'soft cap'. Is it really necessary to have to roll over a 30 to hack a computer database for information that is likely vital to the plot? Not really. So instead, let's have the two follow very different rules, instead of attempting to shoehorn everything into a single category where all the skills play by the same rules.

For lack of a better term, the Non-Combat skills should follow a "pip" system. Let's just say that each of these skills has ten "pips", or ranks that you can put in. Spend a point, get a "pip", similar to how it runs now. However, for every "pip", or maybe every two "pips", you gain an ability tied to that skill. For example, leveling Athletics could grant you a bonus to climbing, or maybe even let you avoid most climbing-based rolls. Or, it could grant you a higher base speed, to reflect your training. Likewise, the computer-based skill can be overhauled as well, so instead of having to roll for the skill, you instead can either perform the requested action if it is well within your ability to do so. Alternatively, treat all non-combat skills as if they had a result of 10. This is important for a second reason, and that is clearing up the combat system, while laying the foundation for the next major thing: Status Effects.

One main issue I have with the system as it is now would be that attempting to add in status effects threatens to slow down game play immensely. Roll Spell Control. Roll Status Defense. Determine whether it beats the target's Defense. Apply Damage and resolve Status Effects. On start of target's turn, roll Status Defense to see if still affected.

This really puts a strain on the combat system, and reminds me of the clunkiness that plagued the d20 system. Instead, I want to apply the above-mentioned "perfect 10" defense, with a bonus caveat: You can have benefits to your status defenses. You can have increased resistances to certain types of Statuses, lessened Status duration, or maybe even mitigate the drawback a Status has on you - perhaps even to the point of an immunity to that particular status. This is a great boon for making good 'villain' or 'monster' templates, which will be very important if the game system is to actually go anywhere. Players will likely not wish to pursue these options, but a monster with nothing to lose might enjoy an immunity to being blinded, poisoned, or even set on fire!

So what determines a "Combat" skill and a "Non-Combat" skill? A "Combat" skill is one that is important in combat, and has no real cap to it. This includes skills such as Resist Status, Dodge, so on and so forth, and may require rolls for it. Non-Combat skills, on the other hand, never have to be rolled, and have a soft-cap, after which point putting more ranks into the skill are pretty much pointless.

I suppose that's enough musing for now, and I covered all the important points I wanted to remind myself of, so that's good for now.

As for modeling stuff: Not sure how much time will be available for this in the near future, but we will see. I may have a contracting job coming available, so time will tell how this works out and whether a change in career is just a pipe dream or a distinct possibility.

Tonight's progress cut short

No images, sadly, and very little time allotted to actually updating due to house findings and potential job offerings. All in all, important stuff. Here's what I did manage to touch on though:

- Attached ear to side of the head
- Attached hand to the body
- Mirrored and attached geometry
- Minor tweaks to base mesh


Unfortunately, it seems mirroring the geometry only worked to identify several key problem areas that will need to be addressed. Lots of strange geometry down the center of the model, and there are a lot more points with lots of vertexes meeting, and several Ngons that are aggravating me. Sadly though, I must be up early tomorrow in order to go to work, so that's about as much as I'm getting done tonight.

Also, odds are low of a game occurring this weekend it would seem: Friend Zeth is unfortunately back on the road again, due to Home Stuffs which I gather are greatly important, and sadly one of the group's other mainstays now has a night-time job, which will likely preclude him from any games. In addition, with the loss of Eyolo due to babies, things do not look very good this weekend.

From what I'm seeing, probably the best game prospect at the moment is Wildly Inadvisable, which I suppose isn't a bad thing. It's about time I got back into the swing of things with that anyways, and it will give me a chance to really sit down and take a second look at how status effects and the skills system works.

Anyhow, that's all for tonight. Perhaps tomorrow will see another update, but with the weekend looking to be a bit hectic, I may not manage another entry until late sunday. We'll see.

Not as much progress as anticipated, but progress nonetheless

As the title, not much progress has been made, but some progress has in fact been made. Worked for a little bit to try to find a solution to some strange oddness that was occurring when I would open the file, with any luck it should be gone now and I shouldn't have anymore errors when I open the model up in Maya. Did some tweaks on the legs, added some geometry for a knee, adjusted the ankles/feet a little, and promptly got to work on the next big ticket, the ear.

Ears are always one of the more difficult portions of a human model - not only does it have to look right, but you have to find a way to attach it to the head as well, which can make it difficult to get it to play well with whatever geometry currently exists. A lot of thought goes into ears due to their peculiar shape and strange way that they attach to the head.

I think I've more or less gotten that dealt with now, so all that remains is to finish working on getting the ear attached, then I can take the hand, place that on there, and the basic model will be more or less complete. Mirror geometry, and I can begin work on the next phase of the model, which is skinning it and preparing for ZBrush, or maybe Mudbox (which I have not yet had a chance to play with).

There is some oddness in the model which has me curious, however, but I unfortunately am unable to determine the cause of it. The oddness is that there are portions of the model which appear to be smooth-ish, but then there are other portions where the edges are clearly defined and extremely harsh, and I have no idea why it appears to have such a stark divide. Some experimentation before I sleep will be in order, but odds are I will be heading to bed shortly anyhow.

Tomorrow, perhaps some pictures of what I've been working on. In the meantime, that is today's update - tomorrow may see some gaming, or at the very least perhaps a bit of poking at Wildly Inadvisable.

*edit*

The answer to the oddness appears to have been solved - it would seem that I have to occasionally reset the normal angle for the model on occasion, as different portions of it seem to have different hardness angles set. Additionally, having a high angle appears to make things softer, while a lower angle would appear to make things appear extremely angular. Making a note of this as it could be interesting to play with later.