Easter Holiday

Since the last update, I managed to make an AI that I'm happy with, for something so small!

Here's a list of how it behaved;

If there's no player, loiter or patrol, there's a choice of the two

If the player shows up, use whatever weapon you have available (There were five, ranging from a pistol, shotgun, revolver, tommygun and a hatchet, each with a unique behaviour)

If the character doesn't have a weapon, run and hide for cover before thinking about combat

After hiding from the player, begin searching for a nearby weapon (Even the one the player has equiped)

Run up, pick up the weapon and fight!

After this project, it wasn't back to my own studies yet. I wanted to learn a little more about AI

A music student wanted a project with an enemy roaming around so that he could add in his own sound effects. I was happy to take it on, and 2 days ago handed him the project with a fully functioning AI.

Now I'm back to my own work, and after looking over everything, it's an absolute mess.

I have too many functions doing similar things, and a very lazy approach to making the AI work. In all honesty, it's amazing that it does!

Now I'm taking it back to the drawing board so that I can make the AI not only more efficient, but universal between different enemies. Not sure how, but that's the goal. I plan to get the most of it done by the end of the day, as well as lay in foundation for a levelling system.

Should be fun!

Okay, 3, 2, 1, let's jam

I need to learn AI. 

I know a decent foundation, but what if I want an enemy to run away and look for cover? What if I want them to consider how to attack you?

So I'm taking a week out of my usual practice to make a crude hotline Miami game, having 0 art assets implemented, just purely focusing on the AI and behaviour trees. I want it done by Monday if I can, but I'll update my progress on it soon.

Research, 2

I've been mainly posting about my practice on this blog. In fact, in the first semester, I posted almost nothing on research, leaving my blog dead for a few months.

Well, here I am, blogging about my research, letting you know it's all underway.

For it, I need to interview peers within the industry already and get their take on what I believe is the foundation of my practice. I also now need to use my notes of lectures from the past few weeks and write 1000 words on how their practice helps to inform mine.

So this is a "I'll see you later", the deadline for this is April 7th, so until then

Testing, testing

Over the past week I was challenged by my tutor to get 20 people to playtest my project so far. The wager was a box of 20 nuggets.

I will not lose for a box of 20 nuggets on the line.

So what has changed in my project after getting 20 different people to play my game? Well, the level has been scrapped for now, and the tone has taken a very dramatic shift. I've implemented an abundance of tutorial prompts, also.

As the playtesting progressed, and more changes were added, a dramatic shift in feedback happened. It changed from the majority saying something along the lines of "I didn't quite understand how to use the spells" to "I want more spells!"

This, however, now presents a new issue. People want more things to do, and although none of the 10 spells are locked, I can't be dumping people who have never played the game with 10 different spells right in front of them to try out. For the sake of pacing, it's just not great. Maybe I should just lock all the spells from the start? But then would there be fun in playing about with different combinations to try and cast a new spell?

I think back to Ocarina of Time/Majora's Mask. In those games, you had a magical Ocarina that can be played to access new areas, manipulate time and be a general fun thing to mess about with to get some nice tunes. When you played a song, though, if you hadn't learned the song already, nothing happened. I couldn't summon a horse, I couldn't make it daytime and I could open the Door of Time.

It never really phased, me, though. In subsequent playthroughs it gave me something to look forward to unlocking, something about the natural progression of the character. I also liked going out of my way to find songs that were completely optional, but helped make certain parts of the game easier, like the Sun's Song and the Redead's.

Let's see what happens.

Let there be less light please

So today I've been working on a new level; I want a serene night time setting, so a lot of thought will be going into the lighting.

One thing I thought would be nice is a particle spawning from certain points of the floor.

Oh boy.



So here's an untextured level with a particle effect. Notice how little lights float around just the character. Now notice how there's a million other lights dotted everywhere else.

Here's my issue.

The material is only visible when hanging around my character, but I've no idea how to tell the particle to put lights onto ONLY what's viable. I'm completely lost.

I'll carry on, but I'll probably have to pester a tutor for a solution.

Ready for the firing line

So I've managed to get a solid foundation of mechanics going, with a few still to add to, but I decided it was time to find out how crap my work is.

Short answer; Very.

When it comes to the mechanics, my playtesting has shown that they're solid in terms of the spells. They're horribly tutorialised, but aside from that, they work and are cool to execute. I've been asked to make more, and more spell combinations, and it's definitely something I want to do, although I'll probably strain myself coming up with them.

I've had a lot of whiplash about the level design. I designed a level I could complete easily, but not first timers. Thankfully a lot of time going into that level was just to make some art foundation, now I can focus on creating a new level that caters towards newer players.

I've also been given some ideas that I'll pick up and implement right away, mainly about tutorialising. As soon as most os the issues are addressed, I'll get it back to testing and find new ways to build!

To Catch a Bard

Over the past few weeks my design has been tumbling all over the place. One minute I fancy a control scheme that users button inputs to cast spells, then I experiment with using the right stick to input the spells via specific rotations and angles. But then something still wasn't right.

The sticks allowed for lightning fast reflexes to input spells instantly, but casting them was a mess. In the original scheme you had to press the right shoulder, then the right trigger to execute. My reason was to give the finger a strumming motion, although this, to be frank, sucked. Hands became very worn very fast. So I remove the right shoulder, and made the right trigger the only button to execute spells. STILL, it wasn't right.

After using a spell, an animation would play and then, after about a second, the spell would be cast. This wasn't good. 

Why bother having lightning fast reflexes if the game brings up a red light every time the player had the chance to prove their speed?

Unless something in the design reflected this, like the whip in Castlevania (NES) having a delay, then it would fit well. But again, everything until pressing the button was a mad dash to get the spell cast. It didn't work. So I made the spell cast as soon as the button was pressed, but then why have the button at all?

So here we are. The spells right now are, like I wanted at the start, input using a series of rotations and angles. However, there's now no toll gate between the stick and the game. The entire combat system, as it stands, takes place on the right stick.

I've recorded some videos, but they'll be up Monday to show how it's all progressed since the original scheme.