Month 2: Prototyping

Published July 30, 2014
Advertisement
For the first half of July, I was on vacation in northern europe visiting family and friends. As expected, that put a big speed bump into progress. That's okay though, I don't really have a hard due date to hit (yet).

It's always tough to pick up work where I left off after getting back from vacation. I at least had the sense to leave some detailed notes for myself on where I was at and what needed to get done, and just picked a few easy tasks as a way to get back into the code. One thing I'm thankful for is my code commenting and descriptive variable names.

As far as the prototype goes, I've slowed down on progress as I fix a bunch of problems and try to figure out how things should work. I'm a bit unsure on what should and shouldn't go into a prototype. The purpose of a prototype is to quickly test things out to see if they work before spending a lot of time on it in production. My initial thought was that this means you create a quick mock-up of your tentative game design and see how the mechanics work together. But, what about some of the technical challenges I don't quite know how to resolve yet? In my case, I've got up to a few hundred creatures on a battlefield in box formations. Writing the code for the formations isn't as straight forward as it would seem. How does the formation change when members die? How does the formation move from one location to another while maintaining cohesion (cue some flashbacks to bootcamp)? When should a creature attack an enemy creature? If attacking a nearby enemy creature causes the creature to leave formation, how do you determine when its appropriate to break ranks? What about creatures with a ranged attack who can see and target an enemy creature, but doing so requires a change in orientation which is different from the formation orientation. When does a ranged unit reorient themselves from their formation position to attack a nearby enemy? How important is it for a creature to value a command, such as a move order? How much can the creature deviate from that?
Player: "Move over to this position"
Creature: "Okay, got it."
*time passes*
Creature: "Oh hey, there's an enemy creature close to my current position. I'm going to go attack it before returning to my original order!"
Creature: "Hey, that enemy creature is running away and I'm getting pretty far off track. When should I abandon my attack and resume my original orders?"


My principles on prototyping has changed slightly. While the prototype is all going to be thrown away, it's a good way to find these problems and answer them. The exact code/solution discovered by prototyping and play testing can then be copied almost verbatim into the production version of the game and then polished. The uncertainty will always linger though: what is important enough to be included in a prototype vs. what is "just polish" and should be added in during production?

My tentative answer: "If the feature adds significant impacts to how the game is played, it should be included in the prototype."
Example: my creatures reorganize themselves in formation to fill in any gaps when a member dies. It looks pretty and pleases me, but also has tactical significance to the way the game is played because it keeps the front lines unbroken. If a creature dies, its position is filled by the back row, so the fighting continues and it's harder for enemy units to get a "surround" situation.

I ran into a significant challenge earlier this week. I had decided to use my Octree implementation. It was really buggy and causing lots of crashes. That meant that I needed to go back and rethink the code on it. I spent a good day and a half working on trying to get it to work as initially planned -- to update intelligently -- but that was way too complicated. On the train home yesterday, I was reflecting on what a show stopper this challenge was becoming. Once again, I was becoming a victim of premature optimization. Why exactly do I have to be intelligent about what part of the octree I update? It was just a part of an overly engineered wet dream. The whole purpose of an octree is to reduce collision checks to a manageable time, so that when you have hundreds of objects, you're not choking your CPU. I realized that there was no good reason not to just completely trash and rebuild the octree every single frame. The CPU costs of that are negligible and satisfy "prototype quality" code. If I was actually using my octree in production, it would be worth it to get it 100% correct, provided my existing solution is showing performance problems. Again, I know not to optimize prematurely and yet I do it anyways. To avoid that in the future, I need to periodically to a check on myself and think about what I'm doing for at least two minutes. If it costs me two minutes to realize I don't need to do two hours of work, it's worth it.

I have started working on rudimentary artificial intelligence for my creatures. Initially, my approach was very crude (prototype appropriate) but it wasn't robust enough to handle the changes I needed to add. I was creating a few scripted behaviors using if statements and math. If I needed to extend it, I had to dig into this mess of spaghetti code and it was daunting. On many occassions, it got too confusing and complicated and I ended up scraping it and starting over again, only to repeat the same thing. Today, I had a genius idea. Rather than creating a ton of spaghetti code or a large state machine with a massive switch statement, I would create a bunch of "Behavior" functions to handle every possible scenario I could dream up, and then write some code to look for a "situation context" when that behavior should be triggered, and then I use a function pointer which hits the appropriate behavior. It is so much more elegant, much less complicated, and much more extensible.

I also spent a lot of time writing the back end game mechanics infrastructure. To my own surprise, I'm starting to get to the point where all of these detailed game mechanics are coming to life and it is quite thrilling to see it all in action. At this point, my archers use their equipped short bows to shoot arrows at enemy targets which are within their cone of view and in their area of attack. The arrows fly and deal damage to the enemy units, provided they actually hit. Dead units turn into skulls and their positions are filled by surviving members of a unit. I almost have everything done on the tactical battle mechanics front. The last bit is a morale system. Then, it's moving on to letting wizards cast spells on the battlefield, adding additional spells, adding additional units, adding additional weapons, more game mechanics, and trying to keep things balanced and most importantly.... FUN!

If the prototype isn't fun, it's not worth going into production until it is.

I signed my team up to go to a day long game dev conference at Digipen being hosted by Intel. They have some sort of indie game challenge for indie game devs. The top prize is some marketing exposure or something. I certainly am not ready to enter anything into that, but I'm hoping I can get my prototype into a stable, working state by then. If I can, I'll plop it onto my laptop and shop it around informally for some feedback. We'll see. I hope the conference is worth all of the opportunity costs I'll be incurring. I still haven't thought of a game title or company name. That's surprisingly difficult. When people ask me, "Who do you work for? What's you're game called?" I don't really have a good answer. That's going to turn into a problem as time progresses.

Next update in a month! I hope to work hard and bring you something tangible to look at by then!
5 likes 9 comments

Comments

Navyman

The formations could have the ability to be set by the player.

Options like "Hold", "Rush", "Defensive Stance", "Assault" could allow the player to control the possible options and minimize some of the natures you have to setup for creatures in formations.

August 02, 2014 07:48 PM
slayemin

Yeah, I've been thinking about formation commands / orders and they're mostly inspired by the Total War series. At the moment, I have implemented three out of four formations:
-Tight interval formation
-Loose interval formation
-Mob formation
Todo: Wedge formation

I was also considering a creature "discipline" rating. Undisciplined creatures will be more likely to charge without orders and be more likely to 'misbehave' in some way. I'm also looking at a morale system where morale is more of an emergent property based on battlefield situations rather than a 0->100 scale. It could lead to some interesting game play mechanics and strategies (like buffing up the fear rating of a creature so that weaker willed creatures will all run away, and using that super scary creature to fear away opponents, thus keeping your ranged units safe and able to shoot arrows with impunity).

August 03, 2014 02:36 AM
Orymus3

I like to think of the difference between prototyping and pre-production as this:

Prototyping tests whether a mechanic is fun.

Pre-production tests how you'll do it, covering corner cases that could have a drastic effect on design.

It's always good to make sure its fun first, and then check for feasibility/planning and cover the unknowns. There's always time to go back to prototyping is pre-production returns issues that can hardly be circumvented and require drastic design changes.

You seem to be caught between these two at the moment and that's perfectly understandable. It's an organic process and there's no magic moment when you switch from A to B.

I think your reflex to make things work first and avoid tripping on the octree is good. Keep checking yourself when necessary :)

August 03, 2014 03:43 AM
Navyman

I like the fear idea. Sounds like there would be more than a single way to play the game.

August 03, 2014 01:06 PM
3DmodelerMax

This is good stuff. From an artist's POV, it's helpful to see the kinds of questions a programmer or developer has to face and the decisions resulting from those questions. The discipline rating sounds like an interesting idea.

August 07, 2014 05:08 AM
d000hg

I don't think I agree with "build one to throw away" prototyping. I used to, but when you tot up the number of man hours that have gone into things you'll be reimplementing, I rather suspect refactoring would be a better bet.

August 07, 2014 12:37 PM
slayemin

I don't think I agree with "build one to throw away" prototyping. I used to, but when you tot up the number of man hours that have gone into things you'll be reimplementing, I rather suspect refactoring would be a better bet.

I'm building the prototype in C# / XNA using 2D sprites. It's super fast and easy.

I'm building the game in Unreal Engine 4, which is 3D, uses blueprints, and uses C++ on the backend. It's a lot slower, but much higher quality work.

There's no way to directly copy the C#/XNA stuff directly to UE4, though the game mechanics, architecture, and designs can quickly be recreated. The number of man hours required to plan and build the prototype should also act sort of like a canary in the coal mine. Use it as a 10x multiplier to figure out how long the production process will take, and schedule, budget, and trim features as necessary.

August 09, 2014 01:12 AM
Navyman

I built a rapid prototype in a few days for my project. Sadly after testing decided to covert the prototype into the real deal. I have spent hours correcting artifact code pieces. Therefore, having to translate a "clean" version over to your UE4 project probably saves you dozens of hours.

August 09, 2014 02:15 AM
Orymus3

I don't think I agree with "build one to throw away" prototyping. I used to, but when you tot up the number of man hours that have gone into things you'll be reimplementing, I rather suspect refactoring would be a better bet.

I'm building the prototype in C# / XNA using 2D sprites. It's super fast and easy.

I'm building the game in Unreal Engine 4, which is 3D, uses blueprints, and uses C++ on the backend. It's a lot slower, but much higher quality work.

There's no way to directly copy the C#/XNA stuff directly to UE4, though the game mechanics, architecture, and designs can quickly be recreated. The number of man hours required to plan and build the prototype should also act sort of like a canary in the coal mine. Use it as a 10x multiplier to figure out how long the production process will take, and schedule, budget, and trim features as necessary.

That's production time only right? Remember that putting to market takes nearly as long as the project itself. Always better off not spending everything on production and not being able to ship it.

August 21, 2014 02:49 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement