Sunday was spent mostly with architecture. Most of my game world is going to be grid based, so I'm setting up visibility calculations accordingly.
I hope to have something rendering by end of month.
January 14, 2013
January 6, 2013
Resolution #1: Discussion
There are generally two types of New Year's resolutions: those where someone tries to improve themselves by correcting a perceived failing of their own, and those where someone tries to reach a goal that has been eluding them for some period of time. Both require publicly talking about them because once you talk about a resolution with someone, you are more committed to the path.
I have one resolution this year, and it is one of the latter ones. Specifically, I want to design, create, and prepare for release one new game this year. I may not be able to release it (yet) due to a clause in my employment agreement, but I can create it, and talk about my progress as I work through it.
The reason behind this resolution is two-fold. First, I've been out of game development for six years now, and I've not been able to successfully complete any of my side game projects during this window, either due to time constraints from work or motivation issues. Second, I've had a fairly significant question since we released "SiN Episodes: Emergence" and since Valve released "Half-Life 2: Episode 2" that I've been struggling to answer.
The real question is: why is it so hard to successfully release an episodic first person shooter? I think I have an answer for it, and it's that answer I want to explore this year. Specifically, I think the issue is the toolset we have for developing shooters.
Levels in first person shooters are generally broken out into encounter areas and connecting areas. An encounter area is a highly polished, highly produced area, and a connecting area is usually a hallway or some simpler area designed solely to get you from encounter area to encounter area. Combat may occur in both areas, but the encounter areas are what people remember. Connecting areas are designed to be forgettable.
The issue is that we have the same toolset for both, this toolset is designed to make construction of encounter areas easier, and generally this toolset makes iteration expensive to do. The really sad part is that due to the standardized rules of video games, we have the proper tools for both, but this toolset isn't properly linked.
Look at the simple level designer built into "Portal 2" and look at "Hammer" in the Source SDK. Using the "Portal 2" editor lets people build amazingly complex levels, including ones with almost the exact same puzzles as shipped in the retail game in a fraction of the time, but they all look the same...there is nothing memorable. However, you can quickly iterate on the puzzles and get them to the point where the gameplay is there.
Trying to build the same levels in "Hammer" takes significantly longer, but you have significantly more flexibility, can make each level visually and thematically distinct, and as a result make them more memorable. However, iteration takes significantly longer.
I'm thinking of writing a toolkit to try to bridge these two worlds: a level editor that works mostly like the "Portal 2" editor so that you can quickly generate your environments and iterate on the gameplay, and then once you are ready to take an area and turn it into a proper encounter area, you can select that area, export it out as an encounter area in an editable format for something like "3D Studio MAX" or "Hammer" or "3D World Studio," and then edit it using the proper tool for the proper job. Once that is done, that encounter area acts just like a building block. You can move it around like a block in the initial editor and have all of the links properly wired up as the connecting areas get additional edits, and the encounter area can also be handed off to other people for concurrent work.
I only have Sunday's blocked out for this work, but I think I can get this done. I'm going to be using Visual Studio 2012 Professional as my development suite, with Visual C# used for the tools and Visual C++ used for the game code.
Today is all design and project setup. Next Sunday is code time.
I have one resolution this year, and it is one of the latter ones. Specifically, I want to design, create, and prepare for release one new game this year. I may not be able to release it (yet) due to a clause in my employment agreement, but I can create it, and talk about my progress as I work through it.
The reason behind this resolution is two-fold. First, I've been out of game development for six years now, and I've not been able to successfully complete any of my side game projects during this window, either due to time constraints from work or motivation issues. Second, I've had a fairly significant question since we released "SiN Episodes: Emergence" and since Valve released "Half-Life 2: Episode 2" that I've been struggling to answer.
The real question is: why is it so hard to successfully release an episodic first person shooter? I think I have an answer for it, and it's that answer I want to explore this year. Specifically, I think the issue is the toolset we have for developing shooters.
Levels in first person shooters are generally broken out into encounter areas and connecting areas. An encounter area is a highly polished, highly produced area, and a connecting area is usually a hallway or some simpler area designed solely to get you from encounter area to encounter area. Combat may occur in both areas, but the encounter areas are what people remember. Connecting areas are designed to be forgettable.
The issue is that we have the same toolset for both, this toolset is designed to make construction of encounter areas easier, and generally this toolset makes iteration expensive to do. The really sad part is that due to the standardized rules of video games, we have the proper tools for both, but this toolset isn't properly linked.
Look at the simple level designer built into "Portal 2" and look at "Hammer" in the Source SDK. Using the "Portal 2" editor lets people build amazingly complex levels, including ones with almost the exact same puzzles as shipped in the retail game in a fraction of the time, but they all look the same...there is nothing memorable. However, you can quickly iterate on the puzzles and get them to the point where the gameplay is there.
Trying to build the same levels in "Hammer" takes significantly longer, but you have significantly more flexibility, can make each level visually and thematically distinct, and as a result make them more memorable. However, iteration takes significantly longer.
I'm thinking of writing a toolkit to try to bridge these two worlds: a level editor that works mostly like the "Portal 2" editor so that you can quickly generate your environments and iterate on the gameplay, and then once you are ready to take an area and turn it into a proper encounter area, you can select that area, export it out as an encounter area in an editable format for something like "3D Studio MAX" or "Hammer" or "3D World Studio," and then edit it using the proper tool for the proper job. Once that is done, that encounter area acts just like a building block. You can move it around like a block in the initial editor and have all of the links properly wired up as the connecting areas get additional edits, and the encounter area can also be handed off to other people for concurrent work.
I only have Sunday's blocked out for this work, but I think I can get this done. I'm going to be using Visual Studio 2012 Professional as my development suite, with Visual C# used for the tools and Visual C++ used for the game code.
Today is all design and project setup. Next Sunday is code time.
Tags:
Game Development,
Games,
Resolution,
SiN Episodes
Subscribe to:
Posts (Atom)