I'm sure that there's a learning curve to any particular programming language. I wouldn't really know - I'm barely fluent in HTML, and I have a very loose grasp on Python as it is.
That said, I've started to get pretty good with using Ren'Py, and recently came across this little tidbit that makes my life so much easier now that I understand it correctly.
Today, I'm talking about the difference between a jump and a call.
When making any project in Ren'Py, you could theoretically place everything into a single file... but doing so is a nightmare in practice, especially when it comes to finding particular scenes. So you split the script up into different files. Not every Visual Novel (or game in general) needs to have a linear progression, but it's usually nice to allow some amount of player agency, or to offer branching paths. Even if it's just something as simple as letting the player choose which scene plays out next, you need to be able to make that happen in the code somehow.
So, you use the jump command to go over to a label. This is telling the code "look for this thing I defined and run it immediately". Most of the time, this works really well, but then sometimes, you need something just a little bit more complex.
Let's pretend that you're like me, and you want a game with some kind of a day planner. Or has a hub menu that you make choices from. You make selections and scenes play out. But how do you get to return to the hub? Well, you could jump to it, but that's not always the ideal way to go about matters - especially if you've got a previously-running script that needs to keep executing (like a day planner). You need some way to return to where you were when executing your code, and a jump command just won't do.
In these cases, you use the call command instead. One way to think of it is putting a bookmark where you just were, so that at the end of your scene you can use the return command to take you right back to where you came from. You could think of it as inserting a new block - whatever is inside runs, and then returns to the previous block (unless you make a new block inside of that one).
So, what happens if you use the jump command, and then end your scene with return? Well, if you do that, you go back to the main menu. This is not the ideal way of doing things, especially not if there's more game planned after that!
The reason is because, as I mentioned above, using the jump command treats everything as though it were running in the same block of code. If you're in the main block, then when you return, there's nothing left to go back to except the start of the game - meaning your main menu.
In a lot of simpler games, jump is more than enough to get you where you want to go. But if you need something a little more involved, call will become your best friend.
Hopefully this helps someone better understand these tools. It's taken me awhile to get this far, but I've got to say it's really rewarding to finally understand these things.
Video Games and Tabletop RPGs ruined my life. But so have movies and computer graphics. These are my musings on them...
Showing posts with label video games. Show all posts
Showing posts with label video games. Show all posts
Sunday, May 7, 2017
Monday, April 17, 2017
April 2017 Progress Report: Project Cranberry Jam
It has been several months since I last gave any indication as to where we stand for Project Cranberry Jam. This is unacceptable so here goes.
All of the character and background artwork has been completed, though not all of the assets have been converted just yet. Being a one man operation in a lot of respects slows some of that progress down. (Not to mention the attending hardware/OS failures that initially delayed progress, combined with a rather troublesome bug... ugh.)
In what time I've been able to find, work has been slowly progressing on getting the scenes into the engine so that work in other areas can finally begin. The scenes for the demo itself are about 60% completed at this point - the scenes required for Week 3 are about 30% finished by now. A number of them are fairly short, so that shouldn't be too difficult to deal with, provided I have the time.
UI design still hasn't been touched. Again, one man operation, UI work will come after I get the scenes taken care of. Also, no audio has been completed yet - though work has commenced on some of the music. If the stars align, this is something that can be taken care of within another month or so.
There's still a good amount of editing which needs to be done as well. For now, my focus is on getting the scripts into the engine, so that they can be more easily adjusted - I'll have to go through them all again anyways when it comes time to put in the audio.
So as it stands, we're at about 50% completion for the demo, I feel. Getting the scenes all put in is the biggest part of the game - it's the core of the experience, really. Once those are all finished, the demo can be considered about 75% complete - the rest is getting in the audio, fixing any other weird bugs that might pop up, and finishing the UI (and assembling some credits? That's probably important for a full release!).
All told, still a lot of work to be done, and while it's not where I hoped it would be by now, having all of the artwork finished is a huge step forward.
This has been your not-regularly-scheduled break in silence. Back to work.
All of the character and background artwork has been completed, though not all of the assets have been converted just yet. Being a one man operation in a lot of respects slows some of that progress down. (Not to mention the attending hardware/OS failures that initially delayed progress, combined with a rather troublesome bug... ugh.)
In what time I've been able to find, work has been slowly progressing on getting the scenes into the engine so that work in other areas can finally begin. The scenes for the demo itself are about 60% completed at this point - the scenes required for Week 3 are about 30% finished by now. A number of them are fairly short, so that shouldn't be too difficult to deal with, provided I have the time.
UI design still hasn't been touched. Again, one man operation, UI work will come after I get the scenes taken care of. Also, no audio has been completed yet - though work has commenced on some of the music. If the stars align, this is something that can be taken care of within another month or so.
There's still a good amount of editing which needs to be done as well. For now, my focus is on getting the scripts into the engine, so that they can be more easily adjusted - I'll have to go through them all again anyways when it comes time to put in the audio.
So as it stands, we're at about 50% completion for the demo, I feel. Getting the scenes all put in is the biggest part of the game - it's the core of the experience, really. Once those are all finished, the demo can be considered about 75% complete - the rest is getting in the audio, fixing any other weird bugs that might pop up, and finishing the UI (and assembling some credits? That's probably important for a full release!).
All told, still a lot of work to be done, and while it's not where I hoped it would be by now, having all of the artwork finished is a huge step forward.
This has been your not-regularly-scheduled break in silence. Back to work.
Labels:
game design,
game development,
gaming,
homebrew,
programming,
storytelling,
video games,
writing
Sunday, January 8, 2017
Jan 8 2017 - Displaying images sanely
I think one of the most difficult challenges I face with not having a strong programming background is not knowing exactly how syntax is set up for different languages.
The gist here is pretty simple: By declaring a show command with a colon, you can apply transformations such as scale, zoom, rotate, whatever. It does NOT work like the following:
So lessons learned once again, and if you ever need to flip an image in renpy quickly, this is how you do it. (You can also use yzoom -1.0, that works just as well but with the other axis.)
I'm sure I'll figure out other ways I can use this to my advantage in the future.
Case in point: Renpy. You would think flipping an image is a simple thing. Spoiler alert: It is. But figuring out how the heck the engine expects you to do it with the spaghetti documentation that exists is kind of a nightmare in my experience.
I have a picture, and I want to be able to display it facing left or right. This isn't a difficult thing to ask. But there are a lot of ways to do this, some of which are more trouble than others. It's possible to declare the image transforms upon initialization, but when you could potentially be flipping thousands of images, you need a much better solution. Same with exporting duplicates of every image that could be flipped and hoping you remember the naming conventions.
It's a nightmare, and while it might work for a one-off instance, it DOESN'T work for my project at all (or most projects, I'd wager).
Fortunately, there's a much easier solution, one that isn't covered in ANY of the documentation at all.
I present to you the xzoom command.
scene black"This here is just a test scene meant to play around.""We're going to play around with some images right now."show tzania happy at right:xzoom -1.0
The gist here is pretty simple: By declaring a show command with a colon, you can apply transformations such as scale, zoom, rotate, whatever. It does NOT work like the following:
show tzania happy at right with xflipDespite the fact that the documentation seems to indicate this should work. (It doesn't because it has no idea what xflip is. Or xzoom. Or a lot of other things for that matter.)
So lessons learned once again, and if you ever need to flip an image in renpy quickly, this is how you do it. (You can also use yzoom -1.0, that works just as well but with the other axis.)
I'm sure I'll figure out other ways I can use this to my advantage in the future.
Labels:
animation,
art,
creativity,
fun,
game design,
game development,
gaming,
homebrew,
programming,
rpg,
video games
Tuesday, December 13, 2016
Dec 13 2016 Devlog: Cracking the code
Tonight I'm going back to the usual tone I've set lately, and delve into some of the programming issues I've been wrestling with. It comes with a surprising revelation: I'm actually sort of okay at this thing it seems.
I still feel like a hack when assembling things, but tonight was one of those nights where I made a plan, followed it through, then came up with a better way to do it immediately after. So I'm going to be talking about that.
I still feel like a hack when assembling things, but tonight was one of those nights where I made a plan, followed it through, then came up with a better way to do it immediately after. So I'm going to be talking about that.
Labels:
art,
creativity,
fun,
game design,
game development,
gaming,
programming,
rpg,
storytelling,
video games,
writing
Monday, December 12, 2016
How do you make a game?
Today I'm going to take a break from what I've been writing about lately to talk about new lessons I've learned as an indie game developer (and why it feels weird to call myself that). While I won't be talking about programming issues (at least not directly), I'm going to instead discuss some of the other lessons I've learned the last couple of months.
So hopefully someone out there finds this useful. I need a break from the usual thing anyways.
So hopefully someone out there finds this useful. I need a break from the usual thing anyways.
Labels:
creativity,
fun,
game design,
game development,
gaming,
programming,
video games,
writing
Monday, November 28, 2016
Ren'Py, the DSE, and How Events Work
So, I have mentioned in the past that programming is hard.
What a surprise, right?
Well, today's bit of weirdness comes from the way the DSE framework in Ren'Py handles events, the way it processes those events, and the way that it determines when to execute an event.
So here was my issue: When setting up the core events for my game, I came across a truly strange interaction where the game began to execute a specific event, despite the fact that it was in neither the correct location, nor the correct time, or even the correct day within the game.
My first instinct was that maybe it was a typo. I was visiting the laboratory, but for some reason one of the character's generic events was playing out that occurred in the library! So maybe I'd just made a spelling error in the event.
Turns out it wasn't so simple. Or rather, it was simple, but not in the way I had expected.
After turning it over and over, I finally managed to hammer down what was going on, and in the process learned something about how it processes variables.
See, here's what the event code looked like:
Turns out, what I was doing was totally wrong, because none of those conditions was actually causing the event to play. What I should have typed was this:
Instead of triggering the events when all of the conditions were met, it seemed more than happy to select the events based on their priority, totally ignoring the variable block.
All because I didn't use the word 'and' to separate my variables.
Hopefully someone finds this useful someday. In the meantime, it's back to the grind with me. There's so much work left to do, but this seemed like one of those major things that was really just a minor thing. Really though, I felt proud when I figured it out on my own, and without needing to consult the Internet for help.
**EDIT**
I AM AN IDIOT AND YOU SHOULD IGNORE THAT STUFF ABOVE BECAUSE IT'S STILL WRONG.
So after spending almost literally my entire night, here's the way the code blocks should really look:
LESSONS CONTINUE TO BE LEARNED!
What a surprise, right?
Well, today's bit of weirdness comes from the way the DSE framework in Ren'Py handles events, the way it processes those events, and the way that it determines when to execute an event.
So here was my issue: When setting up the core events for my game, I came across a truly strange interaction where the game began to execute a specific event, despite the fact that it was in neither the correct location, nor the correct time, or even the correct day within the game.
My first instinct was that maybe it was a typo. I was visiting the laboratory, but for some reason one of the character's generic events was playing out that occurred in the library! So maybe I'd just made a spelling error in the event.
Turns out it wasn't so simple. Or rather, it was simple, but not in the way I had expected.
After turning it over and over, I finally managed to hammer down what was going on, and in the process learned something about how it processes variables.
See, here's what the event code looked like:
$ event("cyn_base_library", "act == 'library', tod == '3', dow == '3'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library', tod == '1', dow == '1'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library', tod == '1', dow == '7'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden', tod == '3', dow == '2', day >= '5', cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden', tod == '3', dow == '6', cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_lab", "act == 'laboratory', tod == '4', dow == '4', cyn_rel >= '1'", event.only(), priority=175)
Turns out, what I was doing was totally wrong, because none of those conditions was actually causing the event to play. What I should have typed was this:
$ event("cyn_base_library", "act == 'library' and tod == '3' and dow == '3'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library' and tod == '1' and dow == '1'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library' and tod == '1' and dow == '7'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden' and tod == '3' and dow == '2' and day >= '5' and cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden' and tod == '3' and dow == '6' and cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_lab", "act == 'laboratory' and tod == '4' and dow == '4' and cyn_rel >= '1'", event.only(), priority=175)
Instead of triggering the events when all of the conditions were met, it seemed more than happy to select the events based on their priority, totally ignoring the variable block.
All because I didn't use the word 'and' to separate my variables.
Hopefully someone finds this useful someday. In the meantime, it's back to the grind with me. There's so much work left to do, but this seemed like one of those major things that was really just a minor thing. Really though, I felt proud when I figured it out on my own, and without needing to consult the Internet for help.
**EDIT**
I AM AN IDIOT AND YOU SHOULD IGNORE THAT STUFF ABOVE BECAUSE IT'S STILL WRONG.
So after spending almost literally my entire night, here's the way the code blocks should really look:
You will note that the variables have been moved outside of the second block. It's because the 'and' statement may or may not work. But it probably won't, so don't use it in that context.
$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 3", "dow == 3", priority=175)
$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 1", "dow == 1", priority=175)
$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 1", "dow == 7", priority=175)
$ event("cyn_base_garden", "act == 'garden'", event.only(), "tod == 3", "dow == 2", "day >= 5", "cyn_rel >= 1", priority=175)
$ event("cyn_base_garden", "act == 'garden'", event.only(), "tod == 3", "dow == 6", "cyn_rel >= 1", priority=175)
$ event("cyn_base_lab", "act == 'laboratory'", event.only(), "tod == 4", "dow == 4", "cyn_rel >= 1", priority=175)
LESSONS CONTINUE TO BE LEARNED!
Labels:
game design,
game development,
gaming,
programming,
video games
Wednesday, June 29, 2016
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:
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.
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.
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.
Labels:
creativity,
fun,
game design,
game development,
programming,
video games
Thursday, March 3, 2016
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;
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.
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.
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.
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.$ event("class01", "act == 'class'", event.only(), priority=200)$ event("class02", "act == 'class'", event.only(), priority=200)$ event("class03", "act == 'class'", event.only(), priority=200)
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.
Labels:
fun,
game design,
game development,
programming,
video games
Wednesday, March 2, 2016
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.
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.
Labels:
creativity,
game design,
game development,
gaming,
storytelling,
video games
Monday, January 9, 2012
Getting on Track
Because I seem to have done too many titles beginning with the word "Let's" lately, I suppose I ought to change up things a bit.
On occasion, my curiosity gets the better part of me, and I look at things, like if places like Bethesda are hiring. Also on occasion, I find out "oh wow, looks like they do have some positions open."
Even better are when they seem to have posted things that I actually mostly qualify for.
How awesome would it be if they hired me? BRB, moving to Maryland would probably be the first words out of my mouth. But it really makes me think about what I am capable of doing, if I apply myself hard enough.
I really want to break into the games industry. Not because I want the money - if I was in Animation for the money, I'd be focusing elsewhere. Games provide an immense challenge, with tremendous personal reward, I think. Yeah, so you can spend days or weeks rendering your beautiful images. So what? I want them rendered in stunning detail sixty times per second. That's a true challenge, in my book, and it is one I know others like myself share.
I want to do this because it is something I love, and something I believe holds great value. I want to be a part of making some of the greatest entertainment on the face of the planet. To be a member of a group whose creation makes it to millions of people, that makes them smile, laugh, cry, or maybe even frustrated in a good way. But this is nothing new.
So a realization dawns on me as I look at the job posting. I could actually *do* this. I am fully capable of doing something relatively amazing. I just need to brush up on skills.
First things first, I need to finish the human model I've been poking at. I've lost a lot of steam on it, but I think I have what it takes to finish her. Will she look good? Probably not. Will she look passable? Most definitely. It will look like a human woman. Probably not attractive, but then again the model itself isn't very attractive. The original goal was to throw her into zBrush and have fun from there, but I think I'm also going to rig and animate her, for shits and giggles.
Of course, if I want the zBrush mesh to work well, then I'm going to have to export the zBrush model back into Maya before I make my changes - that way all I have to do are fix the textures.
But then, that might also mean I will have to have completed the zBrush model of the character *before* I decide to do any mucking about. But that is part of what experiments are for, I suppose.
So, I want to try to set a goal for myself this week, with perhaps a bonus objective. I have thought about perhaps attempting to reward myself for good behavior, as a way to incentivize my actions. Also, I don't care if that's not a word, because it is now.
- Complete basic Andrea model by the end of the week; This includes basic eye and mouth parts
--*Bonus*-- Skin model for texturing
- *Bonus* - Import into zBrush and begin sculpting process to create a new base mesh, to be taken back into Maya
- *Bonus* - Begin work on rigging character by adding a basic skeletal structure and re-learning the process of rigging.
It's work, but then again, that's work for you. These things take forever, but if I don't start working on them bit by bit, then I'll never get anywhere, will I? As of right now, the Andrea model I have still needs to have a foot created and attached, the hand completed and attached, and a breast region defined to look breast-like. In addition, I still need to complete the head by creating and attaching an ear, and also creating an actual mouth plus eyes.
I've also been thinking a lot about how Bethesda approaches their model designs, and I really wish there were better ways. I like how efficient some things are - such as not completely attaching hands to the rest of the body, neck/head regions not attached to the rest of the body... that kind of thing. It is something I think I would like to find a way to do. Perhaps create my own "base mesh" sort of thing that I can then tweak, like a character creation engine - throw in some sliders, that sort of thing. It's a highly-advanced character rig, but I think it would make for an interesting project at some point, personally.
But for right now, I should just stick to basics. Another thing I would like to do would be to use this model to create a high-poly bust model in zBrush. Those seem to be rather popular, and are a decent way to show one's skill with modeling and sculpting.
I'm not even going to worry about texturing, because that's a whole other beast entirely. Although, I suppose that I *do* need to make sure I skin the model before I can animate it. So I'll add that to the list up top. It should be a higher priority than other things, I think. Or I can just let zBrush deal with it. We'll see.
Splitting the model into different sections is another reason I think that it would be more "efficient", at least from a texturing perspective. That way one can focus on having a few high-resolution textures (or even medium-resolution) to comprise a complete model. Of course, a single texture is the most efficient, but one must also balance making something look good as well as making it workable. So if every character model utilizes four or five different texture regions, that would be highly inefficient. Most likely the same thing for complex items as well.
I keep trying to see if I can find a way to import the model information in Skyrim to work in Maya, and I keep finding issues with it. I'd really love to see how everything fits together, and take a peek at how they do their texture maps... but I guess that will just have to wait until I can actually figure out how that is supposed to work.
By this point, I believe I have written more than enough, so with that, I bid you adieu, and with any luck I'll have another post perhaps by the end of the day with any progress I've made. Additionally, I will make efforts to attempt another post by wednesday, in attempting to keep with my 'normal' schedule.
We'll see if we can get this thing off again properly again, and with any luck I may be able to get some games running off the ground as well once more.
On occasion, my curiosity gets the better part of me, and I look at things, like if places like Bethesda are hiring. Also on occasion, I find out "oh wow, looks like they do have some positions open."
Even better are when they seem to have posted things that I actually mostly qualify for.
How awesome would it be if they hired me? BRB, moving to Maryland would probably be the first words out of my mouth. But it really makes me think about what I am capable of doing, if I apply myself hard enough.
I really want to break into the games industry. Not because I want the money - if I was in Animation for the money, I'd be focusing elsewhere. Games provide an immense challenge, with tremendous personal reward, I think. Yeah, so you can spend days or weeks rendering your beautiful images. So what? I want them rendered in stunning detail sixty times per second. That's a true challenge, in my book, and it is one I know others like myself share.
I want to do this because it is something I love, and something I believe holds great value. I want to be a part of making some of the greatest entertainment on the face of the planet. To be a member of a group whose creation makes it to millions of people, that makes them smile, laugh, cry, or maybe even frustrated in a good way. But this is nothing new.
So a realization dawns on me as I look at the job posting. I could actually *do* this. I am fully capable of doing something relatively amazing. I just need to brush up on skills.
First things first, I need to finish the human model I've been poking at. I've lost a lot of steam on it, but I think I have what it takes to finish her. Will she look good? Probably not. Will she look passable? Most definitely. It will look like a human woman. Probably not attractive, but then again the model itself isn't very attractive. The original goal was to throw her into zBrush and have fun from there, but I think I'm also going to rig and animate her, for shits and giggles.
Of course, if I want the zBrush mesh to work well, then I'm going to have to export the zBrush model back into Maya before I make my changes - that way all I have to do are fix the textures.
But then, that might also mean I will have to have completed the zBrush model of the character *before* I decide to do any mucking about. But that is part of what experiments are for, I suppose.
So, I want to try to set a goal for myself this week, with perhaps a bonus objective. I have thought about perhaps attempting to reward myself for good behavior, as a way to incentivize my actions. Also, I don't care if that's not a word, because it is now.
- Complete basic Andrea model by the end of the week; This includes basic eye and mouth parts
--*Bonus*-- Skin model for texturing
- *Bonus* - Import into zBrush and begin sculpting process to create a new base mesh, to be taken back into Maya
- *Bonus* - Begin work on rigging character by adding a basic skeletal structure and re-learning the process of rigging.
It's work, but then again, that's work for you. These things take forever, but if I don't start working on them bit by bit, then I'll never get anywhere, will I? As of right now, the Andrea model I have still needs to have a foot created and attached, the hand completed and attached, and a breast region defined to look breast-like. In addition, I still need to complete the head by creating and attaching an ear, and also creating an actual mouth plus eyes.
I've also been thinking a lot about how Bethesda approaches their model designs, and I really wish there were better ways. I like how efficient some things are - such as not completely attaching hands to the rest of the body, neck/head regions not attached to the rest of the body... that kind of thing. It is something I think I would like to find a way to do. Perhaps create my own "base mesh" sort of thing that I can then tweak, like a character creation engine - throw in some sliders, that sort of thing. It's a highly-advanced character rig, but I think it would make for an interesting project at some point, personally.
But for right now, I should just stick to basics. Another thing I would like to do would be to use this model to create a high-poly bust model in zBrush. Those seem to be rather popular, and are a decent way to show one's skill with modeling and sculpting.
I'm not even going to worry about texturing, because that's a whole other beast entirely. Although, I suppose that I *do* need to make sure I skin the model before I can animate it. So I'll add that to the list up top. It should be a higher priority than other things, I think. Or I can just let zBrush deal with it. We'll see.
Splitting the model into different sections is another reason I think that it would be more "efficient", at least from a texturing perspective. That way one can focus on having a few high-resolution textures (or even medium-resolution) to comprise a complete model. Of course, a single texture is the most efficient, but one must also balance making something look good as well as making it workable. So if every character model utilizes four or five different texture regions, that would be highly inefficient. Most likely the same thing for complex items as well.
I keep trying to see if I can find a way to import the model information in Skyrim to work in Maya, and I keep finding issues with it. I'd really love to see how everything fits together, and take a peek at how they do their texture maps... but I guess that will just have to wait until I can actually figure out how that is supposed to work.
By this point, I believe I have written more than enough, so with that, I bid you adieu, and with any luck I'll have another post perhaps by the end of the day with any progress I've made. Additionally, I will make efforts to attempt another post by wednesday, in attempting to keep with my 'normal' schedule.
We'll see if we can get this thing off again properly again, and with any luck I may be able to get some games running off the ground as well once more.
Labels:
3D,
animation,
art,
blogging,
creativity,
game design,
gaming,
modeling,
video games
Monday, September 12, 2011
Things you can do with d20 Modification
The d20 Modification project, which was originally designed as making the d20 Modern system compatible with Pathfinder, can be used for a lot of interesting things. Like the old Modern system, it still tends to favor the high-intensity action hero sort of game. Unlike the previous system, low-level combat is even more deadly, thanks to firearm overhauls - all guns have a minimum damage modifier, meaning instead of a handgun dealing 2-12 damage, it deals more like 4-14. At low level, that makes a huge difference.
Part of it is because, especially with massive guns like the Barret Light Fifty, the reality is anyone even in the vincinity of one of those rounds tends to turn into a fine mist. But according to the book, those guns 'only' deal 2d12 damage. That means one of the most powerful firearms in existence *only* deals 2-24 damage. At least this way the minimum is brought up some, and it gives more power to people using them. On the other hand, they also tend to come with accuracy modifiers, balancing that out.
With the introduction of the updated magic system, things are slowly falling into place allowing for a variety of interesting genre mixes. One of those mixes I've always had in mind was a Star Ocean-esque setting, where futuristic characters are learning to use magic - something that always fascinated me. But it occurs to me that there are other genre-types one can emulate with a system this versatile. For one thing, it is one step closer to being able to emulate something you can see in the Marvel Universe, where science and magic tend to exist side by side (but don't seem to play well together, usually, and occasionally blurs the line between the two). Or you could even attempt something in the vein of Disgaea - all kinds of craziness can occur there.
Urban Arcana could be re-envisioned - or even Urban Arcana Evolved (which is sort of like the future version of that). Sliders is another possibility, where characters may not always be existing in the same world from one game to another - which could make character choices even more interesting.
All of these things would require little-to-no modification of the system, really, and that was my main goal from the very start. When I was running a future campaign of mine many years ago, I thought it would be fun to pit the group up against some wizards, just to see how they would fare. Needless to say, the results were rather interesting, and the group perservered - of course, they also had far greater weapons than most fantasy characters often wind up with. But on the other hand, fantasy characters tend to get more awesome class abilities, so there is a balance there as well.
Overall, I'm rather pleased with the possibilities this system can offer, and hopefully I'll be able to get the rest of the magic system laid into stone. I don't think I'll be touching on the psionics or other FX abilities... but then again, maybe I might just at some point.
I wouldn't really bet on it though.
Labels:
d20,
d20 Modification,
fun,
game design,
game mastering,
gaming,
homebrew,
pathfinder,
rpg,
tabletop,
urban arcana,
video games
Friday, September 9, 2011
Online Piracy - Hidden Threats, or Hidden Opportunity?
The internet has changed the entire world - a pretty big feat, considering it's age relative to how long it's taken to make such sweeping changes. Sure, the net itself was first invented back in the sixties, and didn't really start to take off until the boom in the nineties. But since then, it has transformed everything we do. I can remember a time ten years ago when it was impossible to watch movies online - when animated gifs were all the rage, and trying to download a file 300 mb in size could take an entire week.
Shift your thinking, and beat your competition. Look at those pirates as competitors, who are offering your very same product at a much better price. Give customers incentives to purchase your product as opposed to downloading for free (bundled extras help!). Special little extras available only online also work. But don't punish the people who just want to try your product out for a test drive - who knows, if you make it more available to them, they just might be interested enough to plop down the money for it - and then share it with their friends, who will also buy it.
But things are different now, and the culture that has begun to evolve on the internet has also changed the people who use it. Obviously, people resist change, and many battles have emerged over it. One of the biggest topics of debate: Piracy, or online file-sharing.
To be honest, file-sharing has a pretty spotted history. Back in the day, it was pretty hard to download anything directly - it was kind of illegal, after all, and nobody wanted to risk putting anything up for risk of being shut down (because, y'know, it was sort of illegal). But some people wanted to share whatever it was, for whatever reason - and someone found a rather ingenius workaround. Of course, it required a bit of technical knowledge (not too much, but enough to stump computer illiterate), and it also required a great deal of time. There were no filters on these early Peer-To-Peer (P2P) networks, so half the time you might get porn. If you were looking for porn, it might even work. If you were looking for porn in the first place, it probably came with a plethora of viruses that would make your desktop explode with popup windows from hell. Or reformat your hard drive.
Obviously, this high-risk situation made a lot of people leery about using these sorts of things, and so the culture thrived, as well as it could. Networks were "attacked" by companies after awhile, and the RIAA and MPAA started realizing that people were downloading their entertainment for free, and no one was getting compensated for it. Lawsuits were filed, and a lot of people were hurt as a result, due to complete ignorance of how the internet worked, or due to blatant disregard for the fact that it is stupidly easy to change one's IP address.
Meanwhile, at this time, social networking was starting to take off in the form of Myspace, and eventually Youtube began to emerge - a cool place to show the world whatever videos you wanted. Over time, the RIAA and MPAA started aiming their sights there as well - but at one time, it was possible to watch full movies on Youtube, for free, and technically, you couldn't be held liable for it at all - it's not a crime to watch such material.
The Internet had started what can only be described as a 'sharing culture'. Nowadays with current social networking like Twitter, Reddit, Facebook 'Likes' and Digg, the internet is all about sharing things. Saw something cool on the internet, gotta share it. It's just like with anything else - when you see something cool, you want to tell as many people about it as possible. Saw a new movie? Gush about it to your friends who haven't seen it yet - make them want to watch it. Heard a new CD or bought a new video game, and are eager to tell your friends? Invite them over to play it or listen to it and hang out. It's the sort of culture that's always existed, but on the internet, it is magnified - now you don't have to leave the bathroom to access this awesome video your friend saw on Youtube - he'll just tweet you a link you can pull up on your smartphone to enjoy.
Is this culture of sharing a bad thing? It's hard to say, because there are a lot of divisions on that topic. On the one hand, it shouldn't be a crime to want to tell/show people something that is awesome - on the net, you can put pretty much anything just a single link away. On the other hand, making these things takes a lot of time and effort on the creator's part, and every album/DVD/movie ticket not sold hurts the industry that produced it.
I was lucky enough to have an actual comic-book industry-based teacher by the name of Pat Broderick at my school. Some real hard nerds who actually pay attention to credits might recognize him as an inker and penciler for both Marvel and DC from way back in the day - and trust me, he still does a lot of that stuff and it looks amazing. But the best part were some of the conversations I had with him, particularly some of his insights into the whole 'piracy' thing.
To him, and this is something I see echoed many other places by many other artists, reading his comic books online (or anyone's, for that matter) is theft, plain and simple. He does this for a living, and every time you read a new book online without having paid a single penny, he is being denied that which he's worked a lifetime to earn. Which is kind of understandable. In so many words, he may have described the people who upload these things as having needing something particularly violent and disparaging occur to them. Which, again, is understandable.
On the other hand, if we take a look at some of the older stuff - bronze or silver age comics, whose value is quite measurable - those things are pretty hard to find - particularly some of the truly rare ones, such as some of the original Uncanny X-Men comics. Is it wrong to want to share those as well, with other people? The true value of these comics has long since exceeded what the original companies have done - after all, those books were already paid for and sold - now it is their very rarity that keeps people scrambling after them. Is it a 'lost sale' when you re-share something ten years old on the internet that didn't get a lot of popularity back in the day? If you share a long-extinct comic book series that was fated to ten-issue obscurity?
There is the same argument with movies and music. Is every single download/view a lost sale? That is how the RIAA and MPAA and other companies view it. Is this right, though? That is one of the primary arguments out there - each download does not constitute a lost sale, and the market is slowly changing to embrace this, but still there is that divide present.
Why is this all important to know? Because in the last few years, there have been a lot of concerned messages popping about the internet, about how certain companies would like to 'run' the internet, and take away its freedom to share anything, out of fear of lost profits. Youtube is already there, with people's videos being removed just because they used a song from a particular recording label, despite the actual content of it being more than just a song - fanmade compilations of shows, or 'fan music videos' being one of them.
Is it truly wrong to want to do these things? Some companies would say yes, and would prefer to force everyone to pay them money to enjoy themselves. But is that what's really right?
Being someone who wants to move into the entertainment industry, I look at this objectively, and I see where both sides of the argument arise, and wonder if maybe there isn't some form of compromise that can be reached. Anime in particular is one industry that has slowly started to accept what its fans want - streaming episodes of series shortly after or the same time as the original air date in Japan, with full translations, for free. Is that wrong? Technically, when you see something on TV, you don't have to pay for it (unless it is Pay-Per-View, of course). The money comes from the advertising that occurs during that show, and if no one wants to watch it...
Because of this, I think the entertainment industry as a whole needs to wake up and realize the world has changed. We are no longer using casette tapes, and VCRs are a thing of the stone age. This is the digital era, and we have come to expect things much differently. When people make these televised shows, really they are trying to pull viewers in to see the advertisements that companies pay them insane amounts of money to televise. The more people tuning in, the more likely they'll see those advertisements, and the more likely they will be to want their service/product.
The real money for these studios comes in after the fact - it's not the televising, it's the products that come along with it. The Anime industry is a great example of this - the real money isn't in the shows themselves, it's all the related merchandise: the limited edition DVDs, the figurines, the toy deals, the lunch boxes, the art books... all of that is where the real money comes in. Lately the gaming industry has started taking note of this as well - nothing makes me more likely to plop down extra money for a game if it includes an art book or something.
Why can't other entertainment industries attempt to follow this model as well? The point shouldn't be to force people to pay as much as possible for the initial product - it's everything that comes afterwards - the director's cuts, the limited editions, the posters bundled into the comics. Insanely cheap to make, but mass-produced and kept limited in quantity, you can make a real bundle off of those things, by making them hard to get - and people will gladly pay for them, because unlike something they can download on the internet, physical products are still something that cannot truly be replicated.
You can copy a video, but you can't copy an original figurine. And you can make that figurine cost three times what a single DVD is, or more if it is high quality and large-sized.
Seems to me that the logical way for the entertainment industry to take advantage of the digital age, maybe they should start looking at their own products as a form of advertisement. For bands, they see it as invitations to come see them in concert - can't duplicate that either. Sometimes you can watch them on TV, but is it the same as being there in person? No.
In the end, is piracy a good thing or a bad one? There's no good answer to that, and there's as many answers as there are people in the world. But I think I can safely say this: attempting to punish the world because a few people are jerks is kind of unreasonable.
Shift your thinking, and beat your competition. Look at those pirates as competitors, who are offering your very same product at a much better price. Give customers incentives to purchase your product as opposed to downloading for free (bundled extras help!). Special little extras available only online also work. But don't punish the people who just want to try your product out for a test drive - who knows, if you make it more available to them, they just might be interested enough to plop down the money for it - and then share it with their friends, who will also buy it.
Labels:
3D,
animation,
art,
comics,
creativity,
fun,
movies,
rpg,
television,
video games
Wednesday, September 7, 2011
Role Playing Games: Or RPGS?
There is a difference between RPGs and Role Playing Games. RPGs are more computer/console-based, and tend to waffle between one of two different tropes: you wander around randomly fighting things to gain experience to unlock greater powers, or you go from one battle in a 'chain' to the next until you reach the next portion, gaining amounts of XP along the way that you can then use to purchase whichever skills you like.
Sounds kind of familiar, right? But these games can be very different from Role Playing Games. Or, maybe even better, Tabletop Games.
Tabletop games evolved from old wargamers wanting to add a little extra something to their weekly war sessions - stories of how their figurines had gotten where they were, eventually evolved into something different from the norm - the Role Playing Games we know and love today.
It has since inspired entire generations of games made in similar veins, but there is still a distinct divide between what we experience on computers than what we experience at a table (or even virtual tables, if you will). Much of it is often attributed to not having an active gamemaster who can make up rules on the spot, or being able to change the game or even completely reinvent it as needed. But that's not the only place this divide comes into play: the design philosophies can often be different as well.
Now, many times people will argue that they are 'just the same'. But let's not lie to ourselves. There's a tremendous difference in the design philosophies between Final Fantasy X and our tabletop experiences. Take any random-encounter RPG - yes, old-school D&D has random encounter charts, just like most other RPGs. But those RPGs, you expect them, because they go by so quickly. Tabletop, however, is far more immersive - yes, you can have those random encounter charts, but you are in that area for a reason, and then suddenly TIGERS EVERYWHERE. What do you do?
There's a good point to understanding where this divide comes in, because as a GM, it's not just your job to set up a random encounter chart and go wild with it. It has to have a purpose and a reason. Let me share with you one of my experiments from my post-apoc future game, Roguelife.
The group was going to explore an abandoned city, looking for Quest Item X. Of course, X was something they had no idea where to find! It being a big city, I wanted it to be somewhat more old-school adventure - a bit of a departure from the traditional 'hallway segments', where the group goes from one battle to the next until they finally reach the end.
I set up a very large spreadsheet, which worked extremely well. It listed different building types, different creatures that could appear in those types, and depending on the sort of building it was (and it's size), you could expect to find a predetermined amount of loot within those buildings (if you were clever enough). This was awesome because it could generate some truly interesting things - in one building, they stumbled across a group of mutants who were being 'purified' by extremists - realizing they couldn't fight such a large battle, the group wisely opted to try looking elsewhere. In another building, they went all the way down to the ground floor, only to find an entire *herd* of Dire Caribou defending themselves from zombies. Successfully, I might add (they were, after all, DIRE Caribou).
Things like that can make for amazing gameplay sessions, but half of it is being able to know how to read those charts and react to them on the fly - how can you pull these elements together to create a similar scenario that the group may have already encountered, but adding some kind of twist to it? Another one had them trying to get into a gas station that was surrounded by zombies and... a DIRE BEAR. Oh man that bear almost tore them up, but they managed to bring it down and save the man inside.
Of course, since I made the chart, I already had an idea how these things could fit together. All in all, it was an attempt to make a tabletop version of a Roguelike - one that worked amazingly well.
So consider the type of game you are running, and the feel you want to give it. Is it a high-stakes game, where there is a clearly-defined goal and maybe even a clearly-defined path to achieve it? Or are your players looking for something more adventurey, where the destination is not as important as the journey to reach it?
Think it over. Talk it over with your group even. You might be surprised at what you can learn.
Labels:
d20,
fun,
game design,
game mastering,
gaming,
rpg,
tabletop,
video games
Friday, September 2, 2011
Deus Ex: On Design Philosophies and How The Market Has Changed
Once upon a time, long, long ago (yes, ten years is really such a long time anymore), there was a sudden boom in the video game economic model. It almost literally exploded, and people games were spreading like wildfire. It was an amazing time, and probably had a lot to do with the economic boom in the late '90's. Game companies were cropping up all over the place, and things were good.
Sure, you still had a lot of shit games. Daikatana, may you rest forever in eternal agony. There were also a lot of games that really stood out on their own, and re-envisioned what games could be. Myst, Fallout, Starcraft, to name a few. I would place other lesser-known games too such as Descent, and the spinoff series from the same team called Descent: Freespace (which later came known simply as Freespace - one of *the* best space combat sims ever, go look it up if you don't believe me). There were other games too - Homeworld, Baldur's Gate, the list goes on and on.
Some were critically-acclaimed hits. Others went softly into the night, only to be rediscovered a generation later as the gaming industry started shifting gears. One of those titles, however, was Deus Ex.
Few games offered what Deus Ex did. Even by today's standards, it's pretty amazing. Deus Ex was really an open world game which had as many solutions as you had ideas for getting around. Ion Storm really threw away the idea of having a single linear path to a goal. This was a game whose entire design philosophy was based upon the simple statement "This is where you are, that is your goal, and these are the things that are between you and it. Figure it out." It's a design philosophy I have always utterly adored, because it really speaks to the heart of what a game should be. It's not a matter of needing to have a certain item to perform a task, or needing to do X, Y, and Z in order to move forward. You could kill enemies, or you could stun them. Or you could bypass them entirely and just focus on your goal. Metal Gear Solid was pretty well acclaimed for this, but Deus Ex... that was just something else entirely. These were not closed-in environments - some goals had you crossing entire city districts, with all manner of obstacles and other things to find along the way. This was a game that really put you into an environment - these were not rooms simply for the sake of being rooms, these were rooms that had a very distinct purpose to them.
There was no wrong way to play the game. Morality played only a small part in it - money was necessary to survive - would you do everything in your power to conserve what resources you have, or do you abuse your power and hack every ATM you come across, stealing everyone's money? When you were in a town environment, you were in a *town*. If you failed an attempt to hack something, alarms would go off, and the police would come running. If you tried to just shoot someone in broad daylight, hell would break loose and the authorities would be on their way.
This was a game that really hammered into you that there were consequences to your actions. The fact that it had a pretty solid story and multiple endings really helped to seal the deal. The gameplay was great, and the graphics were passable for its time. This was a game that had a lot of substance to it.
Flashforward to now. Deus Ex: Human Revolution has hit the shelves, and by this time many people have completed the game (myself included among them). The game is truly designed like its predecessor, and while it did fall flat in many respects, overall the heart and soul of the game remained intact.
I can hold this game up to any other that hits the market, and you can see how very different the design philosophy is in them. Most other games are designed with a very linear approach: go to point A, perform task E, so that you can go to point B to complete objective F. In most FPS games, the goal is "Get from this hallway to the end of the next hallway, and shoot everything in your path." Crysis 2 did a pretty good job attempting to tackle this, but still fell flat in that as open as things seemed, there wasn't a lot of actual area to explore. Crysis 1 was great because you had an open-world island, and you could bypass entire villages if you wanted to in order to get to your goal.
Why do we use such flat design philosophies in our games? Because a lot of it deals with graphics and story costing so much more now. Final Fantasy XIII is an amazing example of game design failure. Don't get me wrong, it's a great experience for the most part. But as a game, it fails horribly. XIII fails because there is a distinct lack of actual gameplay taking place, and it doesn't feel like an RPG should. RPGs in particular are about exploration and adventure - but XIII is pretty much one long, endless corridor, with the occasional branching path that goes absolutely nowhere. The entire game is one long, drawn out tutorial until you get right up to the very final chapter - which it is kind enough to inform you that hey, this is the end of the game, better go back and see if there's anything else you want to do before you complete this, and also by the way, if you're looking to max out your bestiary better fight everything in this dungeon because after you beat the game they'll all be gone.
I don't play a game because I want to be coddled all the way through. I play a game because I want to play a freaking game. I want to challenge myself sometimes, and if challenging yourself isn't for everyone, I'm cool with that. But don't force me to be coddled the entire way.
That's the other reason that Deus Ex: Human Revolution is so refreshing right now. Because you *can* choose to do things the easy way. Or you can choose to do them the hard way, and try to play the game the way it's supposed to be played - with stealth and careful tactical choices. Yahtzee put it best in that the original let you simply bypass entire boss fights if you didn't want to do them - why can't more games let you do this?
Because some games are too full of themselves, and they've spent far too much money on the 'story' to let it be changed in any way, shape, or form.
Maybe this is one reason I love Star Ocean 2 so much. There's so much to do... two ways to play through the game, and how characters turn out at the end can vary drastically depending on who you picked up in the game, and who likes whom the most. The core of the story itself doesn't really change... but how things play out, that can change, all depending on the choices that you make.
I'd think this was an important thing developers would be taking notes on. But then again, I also like to think that people care enough to want to improve their methods, and that they want to do what is the right thing to do, as opposed to the easy thing. Or the same thing.
There's a game coming out relatively soon, and one of the main villains asks, "Did I ever tell you about the definition of insanity? It's doing the same fucking thing, over and over again, expecting the result to change. That is the definition of insanity."
Somehow, I think this is possibly a jab at the industry itself, and I sure hope that it's listening.
Monday, August 29, 2011
Let's Get Creative
Doing anything creative takes a lot of time and energy. It's a lesson I keep forgetting myself, growing disheartened because something is taking "too long". But really, what is that determining factor when something takes "too long"? Does it really matter how long something takes, so long as it gets done?
I like to think this is a hurdle all of us face at one point or another - particularly with creative types. Modeling anything in 3D takes ages, but the gaming industry makes it all seem like it's effortless. Week after week we are bombarded with new things - some industry powerhouses manage to produce new material week after week - and when it comes to trying to compete with that, it can be overwhelming. How can we ever hope to be that good?
I like to think this is a hurdle all of us face at one point or another - particularly with creative types. Modeling anything in 3D takes ages, but the gaming industry makes it all seem like it's effortless. Week after week we are bombarded with new things - some industry powerhouses manage to produce new material week after week - and when it comes to trying to compete with that, it can be overwhelming. How can we ever hope to be that good?
But here's a few things to remember about those places: one, they have a highly talented staff (usually) who are super-motivated to create things. Two, they've got sometimes upwards of a hundred people working on the same project, making the time it takes to complete anything far shorter. Lastly, these people working on these things are working on them every single day.
It's no wonder it's hard to compete with such a thing. Really, I believe that people thinking along these lines are maybe looking at the puzzle from the wrong perspective. The point here isn't *just* to make something awesome - it's to make something you enjoy. To do something for yourself that you are also willing to share with other people.
Art is supposed to be fun. But in today's uncertain times, it's harder and harder to justify that kind of fun - especially if it doesn't even feel like it is productive fun.
So today's short post is just a helpful reminder to myself, if no one else: make something for you, and then share it with other people. It'll matter to all the right people, and if it only matters to you? That's fine too - because that's the most important person it *should* matter to.
Labels:
3D,
animation,
art,
creativity,
modeling,
movies,
television,
video games
Wednesday, August 24, 2011
Initial Impressions: Deus Ex Human Revolution
For those of you who may not have had the chance to play this yet (and I'm sure there's a sizable population of that), I'll attempt to keep this as spoiler-free as possible - but as is true with any review, some things may or may not slip through that you may wish to come to you as a surprise - if you're a purist like that, I suggest you stop reading here and just move on.
So, since I've started playing this game, I've already managed to put an impressive 20+ hours into it, and I am still not at the end of the game yet. Now, if Achievements are any indication, odds are I'll likely be seeing that end within the next 5-10 hours of gameplay. With that having been said, let's just go right into this thing.
Having been a huge fan of the original Deus Ex, I've been using that as my meter stick of comparison, and for those of us who have played it, the number of parallels are astonishing - both protagonists have a similar detached attitude, both have similar character designs including shades, and both work for a powerful organization in which they both have offices that can be maintained. In fact, one could even go so far as to suggest that Human Revolution may be nothing more than a simple reskin of the original game - lord knows they probably wouldn't be that far off the truth. But there are some things that seem to strike me as strange, and I guess I'll start to address that now.
I'm one of those guys who loves to explore the game, and this is one of those gems that really tries to reward you for doing it, both in the form of usually giving you something to find but also giving you EXP every time you find or do something. But if there's one thing that aggravates me so far, it's the cities. On the one hand, looking at the map the cities feel rather small - everything is so crammed together, it's difficult to get a good bead on much of anything. On the other hand, though, it's still possible to get lost in these places - god knows I've run around in circles in Detroit for an hour trying to figure out where I was making a wrong turn, or mistakenly walking past where I wanted to be, or hell, even forgetting where that stupid manhole cover I wanted to jump down was.
But much like the original, these places feel *alive*, and that is one thing I think Human Revolution has gotten really right. The thing that struck me as soon as the game started was the amount of *stuff* that's everywhere. No, it doesn't do anything, but it really helps to set the mood to make you feel like "holy crap, this is a place where people eat/work/live". It's not pristine niceness that we see so often in games, and it's not the assorted 'random clutter' that we see in Fallout - all of it has a purpose and makes sense for the areas in which they reside. The laboratories look fantastic, and walking through them was a real treat.
The level design in this game is absolutely outstanding as well. Though I feel that because some of these areas may not be large enough there aren't enough options, I still find myself looking around and realizing "huh, there was another way to do this? Neat." Options are always abound, and this is not a game with a single 'right' path - it's a game that says "here is your goal, and here's everything between, put it together yourself."
Implants are rather well done too, though I must say I am rather disappointed in their execution. Praxis points are required to upgrade your Implants, which I'm okay with, but when you start out there are only a select few abilities that are available to you, and you must prioritize which are the most important upgrades. Add in that while XP is not hard to come by, but the large amounts you need to quickly obtain the next Praxis is, you've got yourself an aggravating early game - because there's sometimes no way to really achieve your goal until you've unlocked that one augment that lets you do what you need.
The other disappointment stems from the fact that only a couple of them really feel necessary - the rest, while neat and certainly useful in their own right, aren't really needed. I feel that I can take on the rest of the game as I am now, without needing to upgrade further - and I'd probably wind up with about 8-10 Praxis I hadn't spent, if not more. The only augment I've found important to max out is the Hacking Stealth implant - otherwise, Hacking anything becomes a tedious nightmare.
Which brings me to my next complaint - the Hacking system is rather obtuse at first, and while they pretty much explained everything you need to know, it doesn't really tell you all the rules around it - like not being limited to interacting with a single node at a time - for example, you can be hacking three nodes and working on fortifying five all at the same time, with no real penalty - the only limitation is how quickly you can click the right options.
Then there's the character models. I love the character modeling, don't get me wrong. It's absolutely amazing. The animation, however, is a little jarring at times - some characters just flat out will *not* stop moving their damned heads or keep waving their arms in the exact same pattern for minutes on end while they are talking with you. Once in awhile, I can see this just being a character quirk for an individual or two. But with several key named NPCs? That's just aggravating, and I really wish they had paid a little more attention to that, considering that you are looking at those characters for practically the entire conversation.
The social mod only seems to come in handy in a few instances so far, which is a little disappointing, but considering how few named NPCs there are in the game, I suppose it is hardly surprising. What is surprising, however, is that there are no more ATMs in the world! I remember back in the days of Deus Ex that a great way to get money in a pinch was to hack an ATM machine, and hope nobody caught you. Which actually brings me to my next gripe...
Nobody in the world seems to give a shit. Say what you will about the economy, but you would think that someone would be a little bit angry if you broke into their home, stole all their beer, and took all the money that was sitting right beside them. You'd think, wouldn't you? But no, literally you can be hacking terminals right in front of people, and unless you are hostile to them, they won't care at all. Including the police.
Not to mention that failing a hack (unless you're in a secure facility) no longer causes alarms to go off. I remember going to Shanghai in the original, and those guys would be on you like white on rice if you so much as looked like you were going to hack something.
So to wrap all of this up: Overall I am very pleased with Human Revolution. They've done a number of amazing things, and managed to pretty much recreate the atmosphere of the original, while even adding a 'side quest' distraction to help flesh out some extra gameplay. Unfortunately, this extra gameplay only extends a little bit, and there's only something around 8 total side quests to do - which makes things a little boring when you realize there isn't that much to do in the city aside from find things and punch thugs in the face.
I'm pleased with it, and looking forward to at least trying one more playthrough, possibly where I shoot people in the face as opposed to all of this not killing anyone thing. The game itself doesn't clearly explain all of the rules when you first start playing - but with a little experimentation, and several retries from doing the wrong thing, you find out what the limitations of the game are, and how to pretty much abuse the ever living crap out of the game to reach your objectives. This is not a complaint, however, but I feel it helps add to the atmosphere and central theme of the game itself, which is one of taking advantage of a situation.
If you liked the original, go play this. Or at least rent it. I'm sure you'll be pleased with the end product - I know I am.
Labels:
3D,
animation,
fun,
game design,
gaming,
video games
Thursday, August 18, 2011
Looking For Schedule
One of the main problems plaguing me is this whole creative process. It's hard to get into the swing of things when your life is so turbulent, and when you don't bother to set goals for yourself in order to accomplish anything.
When I started this thing, I thought I'd have a lot to talk about (which I do). The problem being, mostly, that I write when I feel in the mood - and most of the time, I'm not in the mood. Thusly, everything suffers - this blog, my creativity, and everything else surrounding that.
So, starting from today, I am going to set a schedule - at least three updates a week, monday, wednesday, and friday. I will do my best to talk about something going on - be it one of the games I'm playing in, what I think went well and what could have gone better, or any projects that I am working on (which will hopefully inspire me to see some of those further along the lines to completion).
So for this week, things are already quite behind. I'll have to go ahead and fix that, starting tomorrow (because what better time to start than on the next scheduled day?).
Tomorrow's topic will likely be musing upon either my homebrew tabletop system, Wildly Inadvisable, or it will be musing on my Apoc game that's just started. Maybe even both, who knows.
Sometime next week, I expect to be picking up Deus Ex: Human Revolution. And I am sure I'll have quite a bit to say about that as well.
Sometime later that week, I may even have some things to say about modeling as well - because I'm trying to pick that back up again, as a means of getting better at that thing I went to college for, while at the same time trying to bone up for a project I probably shouldn't have put off for as long as I have.
Since this post has been kind of short, I'll go ahead and talk about that just a little bit. For many years, I've had an idea burning in my skull. At first, it was just a simple little roleplaying thing for me - but over time, I realized it had evolved into something quite incredible, even though I really had no clue how to properly express that awesomeness.
I tried to start things with it - flash animations that never went anywhere, drawings that never really materialized, and half-written stories that just stopped going anywhere. But now that I have this degree in Computer Animation (a Bachelor's of which I am rather proud of), I should start working for myself to start seeing some of these dreams to completion.
I want to start small, of course. I want to model the main character that this revolves around, so I can finally visualize him well. (Drawings would help this, of course). But to do it in the way I wish, I'll want to utilize cloth and hair simulations, two things I am very unfamiliar with. Additionally, I want to try to push my high-resolution texturing skills to the test - which means I've got quite a bit of work ahead of me.
So my first step for now is to continue trying to get back into the swing of things, and to get modeling people! Following online courses from the ever wonderful Digital Tutors is a great step in the right direction - but of course I need to set goals and guidelines for myself so that I can make the time to actually sit down and do the damn things.
As of recently, I've finished up the first part of a modeling humans tutorial, which has helped immensely. Now the real test begins: can I recreate what I learned by using my own reference images?
With that having been said, I'm starting where the best place to begin is: the head. I've got a rough model already sketched out for the head - a bit more work and I can move on to roughing out the torso, then the arms, hands, legs and feet. And of course the bobbly bits (since in this case I'm attempting to model a female reference).
That's where I'm at right now. Some more practice with that stuff will do me quite a bit of good - and putting to practice those skills I've learned recently will go a long way, I feel. In the near future, I hope to be going over some fur/hair stuff, and then cloth simulations once I get that far as well. The end goal here is to attempt to make a very short animation of the character in action, so we shall see just how far that gets me.
In the meantime, I guess I'll just be moseying along. Tomorrow's post: It's The End of The World (or Doing Something Advisably Stupid). We'll see which I decide to go with tomorrow. One deals with game design, the other just running games. Such tempting little topics.
Labels:
3D,
animation,
art,
creativity,
d20,
fun,
game mastering,
gaming,
modeling,
rpg,
tabletop,
video games
Thursday, August 4, 2011
Entertaingineerment: Or how I made up an important-sounding word
Welcome to Entertaingineering. What the heck is this? Well, for one it's an attempt to get myself to put out goals and deadlines for myself, to finally get around to doing all those "fun things" I keep saying I'll get around to. Additionally, it's also a place for me to share all the fun gaming-related stuff I make, such as house rules for various P&P games, or just odd little dissertations on something even tangentially-related to entertainment.
That means I'll occasionally ramble on about some awesome new movie or show I saw. Or horrible movie or show. On occasion, it may even be both.
So what's this guy who types things like? My name is Ed, and currently I am 25 years old, living in Florida. You'd think this was a great thing, but honestly, I can't wait to get out of here - between the job market and the humidity, I'm ready to pack my bags and call this whole thing done.
I came to Florida for one major reason: to go to school to learn Computer Animation. I succeeded, and after four years of study (the last year repeating the same class over and over), I'd like to think I learned something. The initial hope was that I'd go off to do some grand things.
Except I realized that I had no money to move, no jobs in the area, and uh... not enough connections to land a job anywhere else. So far, I've managed to tread water, and things have improved. With any luck, I'll be looking to move out to Texas sometime next year, and we'll see how things develop from there.
Enough of that crap though, that's not why you're here (I hope!). The important thing is fun! Because that's what this blog is all about - attempting to document my chronicle through learning new artistic abilities, and expanding on ideas that have been bounding about the inside of my skull since I was a child, and letting them out to play for a bit.
Ever since I was young, I had a couple of dream jobs. The first one was a rail-road train track switcher. Then I wanted to be a conductor on a train. When I grew up a little and hit maybe four or five, I got it into my head how awesome it would be to become an astronaut. Then I grew a little more and decided I wanted to be a writer.
Well, I think that about settled it, really. I was huge into cartoons growing up, and TV shows were awesome. I used to read quite a bit growing up. I never really lost that writing bug, though after a traumatic childhood event early on nearly stopped me from ever writing again, it did take me eventually. In early High School, I got into drawing a bit, but never really thought a whole lot of it... despite having tried to create webcomics on three different occasions. One of which actually managed to see the light of day at some point.
As for gaming.... when I was a wee tyke, I was hooked. Five years old, we went to my aunt's to visit our cousins. They had an NES. I remember very distinctly staying up late to play games... I also remember another time that we went to visit, they were renting an SNES, and had such amazing titles as Road Runner's Death Valley Rally. I remember it clearly because I was somehow more awesome at it than my older brother OR our older cousin. I was hooked on those. Next Christmas, our parents got us an NES and an NES Entertainment System to go with it, and a few choice titles.
From then on, we got our games mostly from pawn shops or the like, but I was hooked. Zelda, Double Dragon, Megaman... those were the worlds I longed for, and as a child I would often dream of how awesome it would be if the 'cartoon world' and the 'video game world' and OUR WORLD were combined. Needless to say I was a tremendous fan of Who Framed Roger Rabbit? Next to Princess Bride, it's still on my list of top favorites.
Moving along, the other game that help shape my childhood was a little board game called Hero Quest. It was described to me as a lighter version of D&D, which sounded awesome to me growing up. After all, it has Dungeons, and it has Dragons, so how the hell could that be anything *but* awesome? Obviously, despite my parents somehow owning an original Red Box, I was never allowed to play it. Didn't keep me from staring at it for weeks on end, wondering to myself if it was worth climbing the shelf to take it down and take a peek inside.
But Hero Quest put it into my mind how awesome tactical board game combat could be. I was hooked, and I didn't even yet know at the time just how badly addicted I was to this stuff.
My first initiation to D&D was much without my parents blessings. They didn't know for many years that I was gaming with my older brother (who had come back from the military by that time). They never knew their son was going out to gather together with people mostly 8 years his senior (and then some!) to pretend he was some badass from another world, where magic reigned supreme. Within the first year, I wanted to Game Master.
And boy was I terrible at it, but over time I started to get better, and now I think I can safely say I'm at least halfway decent at it.
I love to say that I've played more games than most people have even heard of. From CCGs to Tabletop to freeform-forum-posting. I've played Magic, Lord of the Rings, Deadlands, Star Wars, Star Trek, Pokemon, Yu-Gi-Oh!, Legend of the Five Rings.... and probably some others I've forgotten over time. I've played AD&D, D&D 3.0 and 3.5, Pathfinder, d20 Modern/Future, and recently I've played some 4E as well. I've played GURPS, RIFTS (don't get me started on that), and made a few characters for various iterations of Shadowrun. I've ventured from Rogukan to Eberron to Greyhawk and beyond - I've tasted Spelljammer and been left wanting more.
I think it's fairly safe to say that few people know entertainment quite the way that I do. Because quite frankly, I've made it a tremendous part of my life, because I feel that it too is a medium for artistic creativity to blossom.
As a child, I always wanted to go and make people feel something. As that same child, I was influenced by the books and television shows and movies and games I played, and I always desperately wanted to give something back.
So here we are today: Entertaingineering. Or learning how to create something entertaining.
I hope that you are better understanding the sort of person I am. And if you are thinking that I tend to ramble on an awful lot, you're probably correct. But I only ramble because I feel it's the only way to properly convey all of the information I wish to impart, because for whatever stupid reason, I feel that it's important.
So with all of that said.... here's what I hope to convey on this blog:
- Things related to my gaming group - materials, settings, or other awesome things that occur. This can range from gaming mechanics to just general table play, or plot hooks I think are kind of neat.
- Inspirational images, movies, television shows, books, whatever it is I come across. For some time I was doing movie reviews and such on another blog of mine, so I may continue that trend here on occasion.
- Plans for moving forward with my artistic career - either works that I am currently working on modeling or animating, or talking about webcomics or my plans to create a series I feel has never been matched in the world.
- Stuff relating to the previously-mentioned comicry/entertaining medium. Because I've never decided where I wanted to put that thing.
- And occasionally, things pertaining to writing, because it is an important creative medium nearly as old as painting itself.
So with all of that said, I hope and pray that any other entry I write will never be this long. Unless it is super important. Or super silly.
Hope you stick around for the ride.
Labels:
art,
blogging,
comics,
creativity,
fun,
movies,
television,
video games
Subscribe to:
Posts (Atom)