Links to previous weeks: [Week 0] [Week 1]
I spent the early half of the day trying to figure out how to implement Perlin noise. The plan was to implement it first in C#/XNA to get the code right and tweak the values to get it how I wanted. Then, I'd take the perlin noise algorithm and my tweaked settings and use it to procedurally generate terrain in Unreal Engine 4. Unfortunately, the terrain system in UE4 doesn't seem to support loading a procedurally generated heightmap during game load... or I'm just really ignorant on how to do it (very likely, considering my lack of experience).
Since I can't get that to work, I'm now thinking that I may have to come up with some alternative solutions. Perhaps having a procedurally generated terrain map isn't such an important feature to the game play. Maybe I can just create a sufficiently large terrain and let things like city locations and factions be randomized. Maybe that would give enough randomness to provide sufficient replayability? Or perhaps, I can pre-generate 20 height maps and randomly select one during the game start? Combine that with randomized locations and factions, and it might be "good enough", and allow us to hand build each terrain map. Maybe even 10 maps would be sufficient? It would certainly cut down on our future testing. Or maybe, I forget about the whole effort to generate random terrain altogether and create a fixed land (similar to how "Mount and Blade" does it). The focus of the game play isn't so much on the terrain features and rolling for a good starting position, is it? I don't know yet. Whatever the case, the playable prototype doesn't require it.
Designing a game is really, really hard! I think I have slightly underestimated the effort and work which needs to go into it. I had written a 15 page design document which was a bit specific in some important areas and vague in other areas. When writing it, I had sort of this lazy attitude of "Eh, I'll figure it out later when I get to it. This is good enough for now." But it's not good enough yet. My artist has read it carefully and is confused on what I'm envisioning. He then went in a wrong direction, and when he told me about it, I initially thought "Oh wow, that sounds really good! I like where this is going.". Except, it was wrong and didn't fit the vision and introduced some new game design aspects which I hadn't considered, and then we were both a bit confused about how it would all work together. This wrong direction suddenly starting turning into a really complicated beast and would take a lot of work, and wouldn't add anything of pertinent value to the player.
I spent the better half of the day drawing storyboards and user interface wireframes in adobe photoshop. After lunch, I needed to write up a detailed description of all of the races in the game, how their societies behaved, what their motivations were, what their strengths and weaknesses are, and a bunch of background lore. All of this should help my artist get a better visualization of the "theme" to use for creating the characters and architecture. I think, if I was going to compare designing to anything, it would be like trying to paint a dream as you're having it. You have a pretty good idea what the general picture looks like and how everything works together, but when you start scrutinizing a particular detail, it gets fuzzy really fast. The challenge is to coherently fill in those gaps so that the whole image still works.
To my frustration, I had spent an hour and a half writing up all of this lore and detail on each of the races in the game. I kept on saving my word document, but it wasn't actually being saved. I don't know where I was actually saving it to, or if it was even being saved at all, but as soon as I closed the word document, I lost all of my work. I spent a good 15 minutes looking for it, combing through my limited files for it on both computers. No luck. I could spend a lot more time searching for it and never find it, or I could rewrite it as fast as I can while all of the details are still fresh in my memory. It was an irritating setback. From now on, I'm not going to just press "Ctrl + S" and assume everything is saved properly. I'm going to have to save it as a new file, open it, and verify it saved correctly before closing the working copy. It could have been worse. I'm treating my lost work as a "First draft" so that I don't get too upset about it.
It's occurring to me that it's rather convenient to be both the designer and the producer at the same time. I don't have to have meetings with anyone to figure out which features I have to cut due to production constraints. That might come to bite me in the ass later on though in some unforeseen way. We'll see.
I'm also realizing that I'm not a particularly good manager... yet. I think I'm able to keep both of us productively busy throughout the day, but I'm a bit irrationally worried that we're already on week two and haven't started seriously producing a prototype. I'm mired down in all this design stuff, so I can't be spending my time learning the ins and outs of the engine we're using. Classic to me, I'm just going to say, "Eh, I'll worry about it later. What I'm doing is pretty important right now too."
Somehow, I spent the majority of the day rewriting the detailed descriptions for each race I imagined would exist in my game world. I turned out to be ten pages of formatted text. It's still a bit rough, but the gist of the game is starting to take shape. I showed it to my partner and asked him for feedback. Was I being crazy for including so much detail?
I then went on to detail the unit system within the game. I guess I have a love for component based systems, because that was my first instinct. I create the base human character, who has a set of base attributes. By giving him a pitchfork and a torch, he becomes a peasant. By giving him a spear, shield and some leather armor, he becomes a lightly armored spearman. etc. It's crazy micro management and customizability. This same system follows for every variation of human units, all the way to gryphon riders. I had to get a sanity check to see if I was going overboard with this and if it would entail too much work. The consensus was that we should go wild with our design and imagination. If we can describe how everything works in vivid detail and have enough time and resources to build it all, then that's great. If we don't have enough time and money, then we can cut some features or scale them back. But, regardless, we know with great clarity what exactly we're trying to build, what it should look like, and how it all should work together.
So, I'm a bit excited about this game we're building and I'd like to describe it a bit. It's a 4X wizard game which draws heavy inspiration from the following:
Merlin (BBC show): I like the idea of magic being illegal and the drama that creates. I also like the sense of shrouded mystery.
Harry Potter: The idea that spells can be countered with a bit of ingenuity, and the sense of wonder and discovery
Total War series: No game does large scale combat formations and tactics better.
Magic: The gathering: Their magic system has the deepest and most intricate spell mechanics I've seen.
Mount & Blade: The character creation process is innovative
Stronghold: I love how you can design your own castles and place buildings and have an economy going
Gnomoria & Terraria: Both have a fantastic crafting system I'd like to borrow from
Dungeons & Dragons: They have the second best magic system and lots of lore surrounding the various creatures.
So, the gist of our game is that you are a young person who has come of age and discovered that you are a magician. This is good, except for the fact that magicians are hunted and burned at the stake. You are suspected of magic and barely escape the clutches of an angry mob of peasants armed with torches and pitchforks. You escape into a secluded land and decide to build a shack for shelter. You spend your days exploring your magical abilities, and soon discover how to cast a bolt of magical energy. As your latent magical skills increase, you are able to summon imps who will do menial tasks, such as gathering berries, chopping trees, and other chores unfit for a wizard. You improve your shack into a respectable abode, and soon enough, a few human settlers are attracted to settle nearby. You've started a meager kingdom! They get to work building a home and gathering food stuffs, and eventually, more and more people are attracted to your kingdom. Meanwhile, you spend your days managing your humble village and researching the depths of your magical knowledge. A novice wizard wants to join you, so you establish a formal mage guild. He spends his time training and assisting you with spell research. Do you want to improve some of the existing spells you've discovered, or try to discover new ones? The choice is yours! However, you cannot rest easily. A nearby graveyard has started becoming restless, with villagers reporting undead wandering among the gravestones. Soon enough, a few skeletons wander into town and start attacking your citizens. Its up to you to fend them off! Do you create a peasant militia? Or do you use some of those magical spells you discovered? Eventually, your meager villa ge grows into a town, and then a sprawling city, and a great metropolis. You may choose the path of good and raise an army of human soldiers to defend your kingdom, or you can choose the path of darkness and kill everyone in your city and raise them as undead, conquering your neighbors and growing your undead army with their corpses. Regardless, you also get to choose the appearance and functionality of every single building in your city. You design them from the available resources you have on hand. Need a house to be built quickly and on the cheap? Build it out of sticks and straw. Watch out for fires though! The function of a building depends entirely upon the furniture and equipment you place inside it. If you place a bellows and an anvil in the same house, you have a blacksmith. Maybe if you make the house a bit larger, you can also fit a smelter in there. Voila, your smelter/blacksmith can now take raw iron or and create finished iron goods! Should your smith also sleep in the same house he works out of? Or should he sleep and eat in a separate dwelling? You are also a single wizard with limitations on what you can see and do. If you send an army into a neighboring kingdom to siege an enemy castle, you don't automatically see what the army sees. It goes into the fog of war. Your only communication with that army is by sending messages via messengers. How goes the siege? You send a message to enquire. Suppose an enemy agent captures your messenger while its enroute and they change the contents of your message. Rather than asking about the status of the siege, your message now urgently orders your army back home to defend the home capitol. They abandon the siege and rush home. Then, there's a lot of confusion on why they came back, until you find an enemy agent tampered with your messages. (one scenario of many possibilities).
Anyways, I feel that its easy to come up with these game mechanics but each one is going to be very complicated and difficult to implement correctly. Each one may add months of extra development time, depending on my proficiency with the tools. I think as far as project management goes, an iterative approach is the best approach. But hey, I'll worry about it when the time comes.
I met a buddy from highschool today for drinks and was telling him about my game. He asked me, "Who is the target audience for this game?" and without a second thought, I said "Myself!". I figure that if I build a game which I absolutely love playing, then I built it right. I assume that there are some people in the world who have the same tastes I do, and will immensely enjoy something like this as well. It might turn out to be popular, or unpopular, but regardless, let's not get ahead of ourselves... I have to build the game first.
Alright, the game design document is sitting at about 26 pages and is "good enough for now". I'm not going to spend much more time adding to it. This afternoon, we went to lunch with a nearby game designer who works two blocks away. After lunch, we showed him our game concept art, gave a quick overview of our game mechanics and design ideas, and got some good feedback. Most of the things he mentioned were things I had already considered, so it was good to get an affirmation that we were on track and doing things right. He did mention a few interesting things:
1. You don't want to have religious symbols in your game (especially Islamic stuff) because it will upset certain people and cultures. Make up your own religious symbology if you have to.
2. Be wary about having children in your game. Can the in-game children be killed? If not, how does that affect game play when you want to kill everyone in a village (see: Skyrim).
3. The game design document is mostly for pitching your game to publishers and investors. If you don't have to, don't spend a lot of time on it. Instead, spend that time building a prototype.
4. Don't underestimate the time it takes to balance an RTS game.
We also had a visitor drop by from upstairs. There's another indie game studio on floor 13 who are working on a web-based MMORPG using HTML5. They're a team of five who have been working on it for over a year, and they've finally gotten to the point where they can start building in-game content and creating a playable alpha. The guy running the place said that they have a big problem with the current build of their game: It's just not fun. Supposedly, their business operation involves paying workers in equity instead of a steady paycheck. I know I wouldn't like that if I was an employee there because you're taking a huge risk if the game doesn't sell well. I don't even know what their final business plan and marketing plans are and how they're going to make money, but that may just be because they didn't tell me. Regardless, I am very interested in learning everything I can about their project and progress in hopes of spotting traps and pitfalls they made so that I can avoid them in our game production cycle. I mentioned that we'd like to stop by some time, and maybe to do lunch next week. I'll have to make a note to stop by and pester them to see how they're doing.
Today I finally purchased Maya 2015 and Mudbox. The total price came out to about $4600. I was trying to pay by debit card but my purchase was being denied by my bank since I had a daily $2000 spending limit. I had to work with my bank to get that temporarily boosted. I went for a "download" option to get the software asap, but it seems that Autodesk takes up to 24 hours before you can download the software. Watch out for that if you're on a time crunch.
In UE4 news, I figured out how to create layered terrain (dirt, grass and snow). It's a bit more tedious than I expected since you have to use a paint brush to paint materials onto the terrain contours. So, I could foresee it taking a while to create some decent looking terrain.
I also figured out how to create a moveable player character and bind keys to different events. It was a bit ridiculous and unintuitive, but it only took me about 2 hours to figure out. Compare that to taking a week and a half to manually build my own robust input system, and that's a trade I'll take any day.
By the end of the day, I was shocked that it was already 6pm. The day went by so fast, I had no idea where the time went!
I spent $4500 (tax included) on the Maya download and I still don't have it. The Autodesk site said it may take up to 24 hours, but I haven't heard a peep after they took my money. WTF? Not cool. If I don't hear anything by Monday, I'll have to contact their support.
Today I focused on trying to figure out how to start building my game using Unreal Engine Blueprints. I detailed out how my camera controls should work and tried to start implementing them. I couldn't do it. I was perpetually confused and overwhelmed by how everything worked together. The unreal tutorials, documentation and samples are good for showing you the basics of the engine, but they don't explain the architecture of how everything works together. When it comes down to it, I think I'm really going to have to just look at the samples and do trial and error. An alternative explanation is that all of the documentations and tutorials make perfect sense but I'm just too dumb to get it. Contemplating that possibility and its repercussions on my project worried me and got me a bit depressed. Suppose it's true. Suppose I'm an idiot and I'm too dumb to see it. Suppose someone smarter was in my position doing what I'm doing? They'd succeed. If I fail, it's because I'm dumb. Think about it. If I'm a shit developer, and the project depends on me to be the technical expert, then the project runs a high chance of failure. *sigh*
I don't know that I can really call myself a shit developer though. I mean, I've been programming as a hobbyist and professional for 16 years. I worked as a senior developer in afghanistan (though, titles really don't mean anything) and have been able to build lots of tools and applications. I worked on my own game engine for 10 months without significant problems. So, objectively, I can't call myself a shit developer because a shit developer couldn't do all that. So... what's the conclusion? Learning the ins and outs of a new engine is going to be a slow and painful process full of frustration and self-doubt. I wasn't expecting that. I was thinking that I'd just download the engine, do tutorials for a week or two, and then be adequately proficient to start building my game and run with it. Nope! Apparently it doesn't work that way.
I don't know if its the blueprints themselves and trying to wrap my mind around it, or if I'm more accustomed to writing code. By the end of the day, I was half tempted to just abandon blueprints and go with a C++ scripted project. That would have its own frustrations as well, so I'd probably just be jumping out of the frying pan and into the fire. It's better to just suffer through the frustration and try to figure it all out. Small baby steps, little victories, one at a time. I can make this work.