Advance LMMS, episode 5

Well here it is:

School vs LazerBlade

School won this round.

School has really been eating up almost all my time. I didn't even have time to write this out until later in the day, and this day is almost over. I should theoretically still be able to have Advanced LMMS ready by Saturday, but I don't have time to write about something entertaining right now. Sorry about the lack of content today.  :(


        --LazerBlade

The first-person shooter

A genre that once ruled the industry is being attacked non-stop by reviewers and gamers alike, although still enjoyed my many gamers out there. People look around, and they see that they've been playing FPS games for more than fifteen years. Gamers want something more than the same old "buff dude goes around blowing supposedly scary things up in a gory way in first-person with the same guns" kind of game. This can often lead to the rushed conclusion that the FPS as a genre is either dying, or already dead.

For one thing, no matter what new directions games take, people are still going to like the concentrated doses of immersing fast paced action and competition that is hard to find elsewhere. So unless an alternative is provided, FPS games will probably never die. It is true though, that FPS games are starting to make up less and less of the average gamer's diet. I myself have a relatively small collection of games, mostly preferring only games that I think stand out somehow. I also usually only play through games one time, and those are only the best games. If I think a game is terrible, I don't usually finish it.  On track, what games do you spend most of your gaming time on? You probably play some game like WoW that eats up most of it, then you have filler for new SP games that come out, and then finish it off with some kind of deathmatch game like quake.

So while FPS games don't dominate your diet, you still have them. Provided, this is a huge, exaggerated, overgeneralized blanket statement stereotype, but as a designer this is probably what a lot of your audience will look like.

Does this mean that the first-person perspective is doomed to either slowly die out or become just those deathmatch games you play to kill time? Probably not. The advantage of the first-person perspective is that it immerses the player and helps to merge their personality with the protagonist's personality. This is very useful, and is not only limited to shooters. However, I think the best game probably has some action in it somewhere.

I think that game designers shouldn't be afraid to use the first-person perspective. Game reviewers usually don't really care all that much about that, it's just what most people do with it. Granted, the best game designer doesn't fear reviewers. Ideally, you should be able to create whatever game you think your audience will enjoy, and not fear what the reviewers will do to you for it. But you have to get your money somewhere, plus the reviewers often times have a pretty good idea of what your audience will like.


          --LazerBlade

Advanced LMMS - Episode 4

Yay for another episode without incident. Let's see how long this lasts. ;)

Videogame characters

Most of you are probably used to me rambling on about the interesting facets of game programming and philosophy. However, being a one man show encompasses a good deal more, and this time I'm going to talk a bit about story and characters in games.

Often times, games suffer from something not too different from programmer art. This something is what I call programmer story. I will be honest, someone who can specialize well enough in programming to make an entire game on their own, probably won't be as good at story writing as a specialist in that area. However, we aren't trying to do perfect stories, we just want good stories in a fairly reasonable amount of time. Coming up with a good story is a complex task, and a rather daunting one at that. I'm just sticking to characters for now.

Some say you should NEVER ever EVER reveal the main character's personality. That way the player can then connect with them better by coming up with their own. Then you have just as many people saying that you absolutely MUST give some background and expound a little on the protagonist's character. If you want my perspective on it, both of these positions are equally viable. You can do it either way and make not only a successful game, but a good game.

As a rule, you should pick your race, gender, age, birthplace, and everything else that isn't part of the personality, very carefully. It's a bad idea to say "We better make this character African so that people won't rap on us for being racist." But at the same time, it's a bad idea to say "What? Another protagonist? Just grab another one of those dudes with blonde spiky hair and a five o'clock shadow." One thing I hate about creating characters for your story is that any game designer will feel like they're only trying to line up with the reviewers ideas of what's fair and what's boring. In my opinion, you should ONLY pick these things because it helps you better express the character's personality. Granted, reviewers will probably eat you alive for not having the perfect white-black-man-woman ratio of characters in your game, but who cares anyway?

That said, I think it's best to work out the characters personality and then choose things like race to explain or express that personality. So first get your personality all fleshed out. Give every character some flaws, some places where they aren't sure what they think, that kind of thing. Once you have that down, you can start picking things like gender. Then you can move on to choosing experiences that shaped these characters in the past. If they don't trust anyone, throw in some betrayal or have them grow up on the street or something.

Now that you have a character that has personality, past experiences, and natural character flaws, don't go screwing it up by having them do or act in a way they wouldn't. Don't have somebody with a trust-no-one attitude decide to trust the protagonist. And don't EVEN THINK about making up some excuse like "You have no choice," or "I know you well enough," or "You're the protagonist so you're just the kind of person that everybody trusts." You shouldn't have to explain your characters personalities, they should be manifested in their actions. So have your characters stick to their personalities.

This article is starting to run a little long, so I'll try to finish up by saying that not every character in your game needs a personality. The random person who rides by in a skateboard doesn't need all that work. You must decide for yourself how deep you need to make each character. Some characters just need to show up and do their thing, others need to communicate with the player.


       --LazerBlade

Infiltrator - Season 2, Part 4:

This session has been one of the most annoying and yet most rewarding yet. Let's just hop in with some of my favorite features:

You may not be able to tell without checking twice, but that's actually an old school enemy pile-up. I finally initiated the base enemy framework as well as simple enemy objects for each type. I even have nifty little spawn and kill functions, and let the level spawn enemies wherever it wants. Granted, all it does is load the proper mesh, turn it into a rigid body, and fling it at the wall, but at least it's a start.

Development of this certainly did not go without incident. Walk up to a programmer and say the word "pointer," then say "void pointer," then say "deleted pointer to a pointer to another void pointer being referenced again in some obscure piece of code." If they aren't laying on the floor crying at this point, they haven't been doing enough programming.

Now if you are a programmer, you can probably understand some of the frustration introduced here. To make things short, I needed to be deleting a pointer but it was crashing every time I did. Debugging showed me that the program was actually crashing after the function I was deleting the pointer in had ended. I moved the deletion to a different function and the problem went away. To this day I don't know what the problem was, and I can't figure it out. Programmers can also relate to the amazing annoyance of a problem you solved and don't know why.

Anyway, once I finally got the enemy structure intact, I set about doing some level parsing. I parse levels by first using the config file variable loader to read the number and type of enemies that will appear in the level. I use this information to create enemy arrays big enough to hold all the enemies. Then I go on to read those enemies one at a time and spawn them at the indicated location and heading.

The file format isn't the most user friendly or readable by humans, but it shouldn't have to be anyway. I'll theoretically build a level editor once I get the level object setup properly, so I should only have to write a few of the files by hand. Only the really hardcore modder's will be looking at the format, and they'll be used to handling convoluted files of garbage, so they might be a little forgiving. ;)

Note, that I'm not finished setting up this level parsing thingy yet, as I'm still playing around with it.

I need to start on the real enemy coding. I need the enemies to be more than inanimate pieces of metal laying around. It will take some serious work to work out AI, enemy firing, and things of that nature. Even after that, I need to setup things like doors, keys, powerups, other weapons for the player, and more.

This session took longer than previous ones, punching in at 9 hours. That leaves me at 16 hours total. We'll see how long my optimism lasts. ;)

        --LazerBlade

Advanced LMMS episode 3

Despite a rather chaotic week, I still managed to get this week's episode together in time. I'm covering a hardstyle screech:

This is actually the first recording, I didn't have time to re-shoot at all. You'll have to live with it and ignore the mistakes. This time. ;)

Enjoy!

Digging up the dead (projects)

I just love digging up projects I once had on hold. You may have guessed based on the last post that I revived my movie project. You are correct. I dug out my old 3d computer lab and started working on it in Blender again. I posted it on BlenderArtists to get some critique so that I could know what to improve. Here is the latest version at the time of this post:

It's the same old lab but you can probably tell I've been working on it. There's still a lot to do, but that doesn't mean it hasn't progressed. I'm also trying to get some good looking droids together in Blender, but that's apparently quite hard when you have nothing but your imagination to guide you. Maybe I should dig up some free concept art or write some out myself. I dunno...

As for the script and storyboard, those are secret. I'm hiding them until after I finish. If I fail first, THEN you can see them.

I have zero work done on the protagonist, but I have some idea's. The idea I've given the most thought to is not showing their face. I'd have to have them wear a motorcycle helmet or something sometimes, but it would really help set the mood. It would also help me get around the problem at being really horrible at facial modelling...

So anyway, this project is no longer on hold. No guarantee's that I'll move very fast, I'll probably actually end up only posting every once in awhile because of how slow it will be. And no, I'm not setting up a time budget because my estimate would either be way to huge or way to tiny. I don't really have experience with such large projects.

        --LazerBlade

What makes a hacker's paradise?

I must admit that I really enjoyed the last couple weeks or so. I started out working on Infiltrator(more on that in a later post.) I added in some basic enemy structure, and went about trying to implement spawn/die system. Everything went perfectly, before the evil monsters of pointers in C++ arose from the pits. I couldn't get the application to stop crashing on me. I worked late into the night drinking more and more coffee.

I was pretty much out of ideas. I needed a break, a new look at the code and problem would probably help. I decided to do a little 3d modelling for the movie I'm working on:

That got boring after awhile, so I did some kung-fu, and then some music. Then I played around a bit with my new Linux Mint system, and decided to burn down the house of the person who decided we didn't need ~/.bashrc anymore.

And you're asking, what makes a hacker's paradise? I'm telling you. It's a world full of fun and interesting little(and big) problems to play around with. Oh, that and coffee and pizza. That's why we techno-geeks came to planet Earth, we didn't have coffee and pizza on our home planet. There has been no shortage of fun stuff to do for me, and that's what made things well... fun.


          --LazerBlade

Advanced LMMS - Episode 2

Yes I'm calling them "episodes." Yes it's now officially a webshow, with a simple intro and some spiffy outro music. Just watch and enjoy okay?

I'm starting to settle into the role a bit more, but I still need practice.

Infiltrator - Season 2, part 3:

Some developments, but no huge improvement this time around. You can probably tell from the screenshot that I have it running on Linux Mint. It's actually a bit of a pain to develop, since I keep the source code on an NTFS partition on my Terabyte drive and Linux won't let me execute the files. I have to copy/paste the executable from my Terabyte drive to my internal drive every time I make a small change.

I guess I'll be developing it on Windoze, but I can port to Linux in the snap of a finger once it's done. This is because I don't use platform dependent code. What kind of knucklehead does anyway? Oh yeah...

So on top of figuring out how I'm going to do cross-platforming, I also put a lot of the plans I made previously into effect. For example, a lot of values like how fast the player and lasers move, and other game data like that is now loaded from config files instead of being hard-coded.

I also fixed up that nasty object structure, it now makes a lot more sense. I'm glad I made those changes while there's still a fairly small amount of code to move around. It would have been a nightmare to do that after I'd been coding for awhile longer. I still need to add some kind of enemy base-object, but now I have a solid base to build that object on.

This session took two hours again, mostly because I had stupid IrrBullet linking errors to fix, but I was ready for 'em. Seven hours down, I don't seem to be having time budget problems just yet. Stay tuned next time where I will hopefully stop clowning around and get down to setting up some enemy objects.


        --LazerBlade

Infiltrator, Season 2 part 2

Yes this project is all but dead. I don't have screenshots for you, but it's still not dead. And the reason there are no screenshots is because most of the changes are internal.

Firstly, and of course, most importantly, I've improved the laser system. You can add collision objects which will kill the lasers on impact. The new system searches the set for an open data slot and sticks the new laser in it. This way, you can fire an infinite number of lasers but only have up to 30 on the screen at a time. 30 being the number of data slots for lasers.

I've also vastly improved the config file setup, allowing any object to open a config file and load data from it. I now store all the config files in their own directory. So far, only the player and base load config files.  This setup allows for an infinite number of config files and an infinite number of variables within the files.

I do have a problem though. My objects don't exactly interact with each other the way I want them to. They just float around bumping into themselves. Here, let me draw you an example of what it's like:

See what I mean? They don't communicate with each other properly at all. I have far too many global variables, mostly due to this same problem. I want things to be more orderly and actually work together in a way that makes sense. I end up with a mess that will cause even more trouble than it's causing now. I want something more like this:

It's not all bad though. I did fix some of that. For example, there's no longer a global config object. Something more important I think, and probably almost necessary for this anyway, is to setup enemy objects. This poses quite a few design questions.

Most of them are asking how I intend to do this. Do I have a base enemy object that specific types derive from, or do I have a single enemy object that can be different kinds of enemies? Will the enemy objects belong to the level or will they be independent, just as part of the game like the player? Now we can see that this may get involved.

Anyway, I haven't put either of these plans into action yet. Those are just the plans. The action will probably be in the next session. I've only spent about five hours now, which isn't too shabby for how far I've progressed up to this point. That's only a hundredth of my total budget. Don't worry though, once I get going I'm sure I'll have no problem eating my whole budget out from under myself.

That's a good thing right?


        --LazerBlade

Advanced LMMS, part 1

I'm starting a video tutorial set about making advanced music with LMMS. If this goes well, I should be posting every Saturday with the next episode in the set. Here is the first episode:

For those of you who are wondering, no I haven't given up 3D or programming. Things are moving pretty slow though, so I've started this series to keep the content rolling. Enjoy!