ITS_Mike







Programmer





Level 3Programmer Codename: Warplane - Classic Arcade-Style WW2 SHMUP « on: July 29, 2013, 12:31:10 PM » Warplane [codename]



The goal is to make a small, but fun, classic arcade-style vertical shoot-em-up that you can play in your web browser using the Adobe Flash Player. I personally love this kind of game, and I wish there were more of them



The game will be set during World War II in an alternate universe. I want the game to have a shallow learning curve with steep difficulty; easy to learn, hard to master. I also want this game to have a serious tone and be a bit dark and gritty; there are enough satirical/whimsical SHMUPs out there.



My team and I are currently two months into pre-production and have already completed the first real-level prototype. We are using maximum duration of five months to help ensure that we are not in pre-production for eternity (this has sadly happened to us on most previous projects).



We are also creating a "making of" documentary for this project. You can find the list of currently created episodes over here:



The old 12-episode devlog series can be found here if you are interested:



You might know us from our



I think that's all I have to say for the moment... If you have any questions, comments, or suggestions, please leave a reply There are also some other ways of following this project at the bottom of the post.



1st Real-Level Prototype Screenshot







Twitter - Facebook - YouTube - Website - Trello

The goal is to make a small, but fun, classic arcade-style vertical shoot-em-up that you can play in your web browser using the Adobe Flash Player. I personally love this kind of game, and I wish there were more of themThe game will be set during World War II in an alternate universe. I want the game to have a shallow learning curve with steep difficulty; easy to learn, hard to master. I also want this game to have a serious tone and be a bit dark and gritty; there are enough satirical/whimsical SHMUPs out there.My team and I are currentlyintoand have already completed the first real-level prototype. We are using Mark Cerny 's Method, so there will probably be four more real-level prototypes before we enter production. The pre-production stage has aofto help ensure that we are not in pre-production for eternity (this has sadly happened to us on most previous projects).We are also creating a "making of" documentary for this project. You can find the list of currently created episodes over here:The old 12-episode devlog series can be found here if you are interested: Game Development Vlogs You might know us from our previous devlog for a game codenamed "Areum". We started this project as a sort of morale boost; we want to release a finished game soon, and then get back to work on "Areum". "Warplane" should succeed where the original attempt at "Areum" failed because it is smaller in scope, we are using easier/simpler tools, and we are setting deadlines.I think that's all I have to say for the moment... If you have any questions, comments, or suggestions, please leave a replyThere are also some other ways of following this project at the bottom of the post. « Last Edit: April 22, 2014, 09:35:07 PM by Michael Grand » Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Prototyping! Also a Boss « Reply #2 on: July 31, 2013, 06:07:57 AM »



So far, I really like prototyping!



Some have expressed concerns that prototyping is wasteful, but so far I don't think it is. Creating a prototype to test one specific aspect of the design is invaluable to me as the designer. It gives me the flexibility to experiment with ideas and nail down specifics without needing half of the game finished and slowing down the tests. It also allows me to experiment without worrying that the experiments will cause all of our hard work on the game to be scratched, since the prototype is using throw-away code and assets anyways.



But that is just one prototype We'll see how things go during the rest of pre-production.



On the topic of prototypes, they don't always have to be software-based! Here's a photo of GreyKnight explaining to me how one of the bosses will work (this counts as a prototype as well):





Thanks for reading As always, if you have any comments or suggestions, please feel free to leave a reply! My team and I just finished a prototype to figure out how the screen should flash when a bomb is dropped ; we decided that flashing orange, white, and then orange would look the best. This was our first "real" prototype, since we did not use them from the start of development (two months ago).So far, I really like prototyping! GreyKnight (the artist, and he is also helping with designs) tells me that he had been wanting to do something like this, but he didn't know it was possible.Some have expressed concerns that prototyping is wasteful, but so far I don't think it is. Creating a prototype to test one specific aspect of the design is invaluable to me as the designer. It gives me the flexibility to experiment with ideas and nail down specifics without needing half of the game finished and slowing down the tests. It also allows me to experiment without worrying that the experiments will cause all of our hard work on the game to be scratched, since the prototype is using throw-away code and assets anyways.But that is just one prototypeWe'll see how things go during the rest of pre-production.On the topic of prototypes, they don't always have to be software-based! Here's a photo of GreyKnight explaining to me how one of the bosses will work (this counts as a prototype as well):Thanks for readingAs always, if you have any comments or suggestions, please feel free to leave a reply! Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Research! « Reply #3 on: August 01, 2013, 06:25:36 AM » Who said research can't be fun!







The player's warplane will be carrier-based, which is why I selected the F4U-1 Corsair. But we don't want to use the exact same warplane models that fought during World War II, so I would like to research (reading, creating models, drawing, etc.) multiple carrier-based warplanes and create our own from what I learn.



Wings of Prey is not set over the Pacific, which is a slight problem for research since that is where the game I am working on will take place. I've been having some trouble finding a good WW2 warplane simulator that is set over the Pacific though... Does anyone have any suggestions? I spent yesterday researching WW2 warplanes, and by that I mean building a model F4U-1 Corsair and playing Wings of Prey Who said research can't be fun!The player's warplane will be carrier-based, which is why I selected the F4U-1 Corsair. But we don't want to use the exact same warplane models that fought during World War II, so I would like to research (reading, creating models, drawing, etc.) multiple carrier-based warplanes and create our own from what I learn.Wings of Prey is not set over the Pacific, which is a slight problem for research since that is where the game I am working on will take place. I've been having some trouble finding a good WW2 warplane simulator that is set over the Pacific though... Does anyone have any suggestions? Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Fixing a prototype bug « Reply #4 on: August 02, 2013, 11:15:12 AM »



Before starting work on the prototype, the main risk that I figured I would be tackling is that I did not know how to go about shaking the screen using FP.screen and the



I'm shaking the screen by creating a "screen shake" entity from a Position attribute, Velocity attribute, Movement behavior, DelayedRemoval behavior, Shake behavior handles the actual shaking logic (which direction to move in, for how long, how fast, etc.). The Screen behavior makes sure that the screen shake's Position attribute remains in sync with the position in FP.screen .



The bug I've been trying to fix since yesterday was that after the screen shake entity was removed from the game, the screen would stop shaking like it was supposed to, but it would become stuck at an offset position. This was happening because the Screen behavior was being removed from the entity before the Shake behavior, and the Shake behavior was responsible for resetting the position on removal from the entity.



I created multiple technical prototypes to try and find a solution to the problem. One of the ideas I considered was adding in a Screen behavior, not the Shake behavior, should be responsible for resetting the screen's position on removal from the entity. As usual with bug fixes, it seems obvious now



In other news, I've started estimating the cards and tasks, and defining how valuable each card is. This will be useful later when I need to estimate how long an entire feature will take to implement, and even how long the entire project will take to complete. I have been working on the Bomb Screen Shake prototype since Wednesday, which is a whole day longer than I was expecting it to takeBefore starting work on the prototype, the main risk that I figured I would be tackling is that I did not know how to go about shaking the screen using FlashPunk . The funny thing is that it was not much of a risk at all due to a really easy to use FP.screen ; what I ended up getting stuck on was a synchronization bug betweenand the entity component system I'm shaking the screen by creating a "screen shake" entity from aattribute,behavior, Shake behavior, and Screen behavior components. Thebehavior handles the actual shaking logic (which direction to move in, for how long, how fast, etc.). Thebehavior makes sure that the screen shake'sattribute remains in sync with the position inThe bug I've been trying to fix since yesterday was that after the screen shake entity was removed from the game, the screen would stop shaking like it was supposed to, but it would become stuck at an offset position. This was happening because thebehavior was being removed from the entity before thebehavior, and thebehavior was responsible for resetting the position on removal from the entity.I created multiple technical prototypes to try and find a solution to the problem. One of the ideas I considered was adding in a removal priority to the components. Fortunately I was able to find a much simpler solution: Thebehavior, not thebehavior, should be responsible for resetting the screen's position on removal from the entity. As usual with bug fixes, it seems obvious nowIn other news, I've started estimating the cards and tasks, and defining how valuable each card is. This will be useful later when I need to estimate how long an entire feature will take to implement, and even how long the entire project will take to complete. « Last Edit: August 02, 2013, 11:30:45 AM by InvisibleMan » Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Bomb Screen Shaking Finished « Reply #7 on: August 06, 2013, 04:38:48 PM »







The only purpose of this prototype was to test the screen shaking, so most of those graphics are temporary The artist tells me I did a surprisingly good job with the art... I'm not sure what to think of that



We are currently working on getting a more solid plan put together, so prototyping has been put on hold for the moment. I'm only expecting this to take about another couple days, so we should be back to prototyping soon. The Bomb Screen Shake prototype has been finished! Here's a video from after we finished tweaking the values:The only purpose of this prototype was to test the screen shaking, so most of those graphics are temporaryThe artist tells me I did a surprisingly good job with the art... I'm not sure what to think of thatWe are currently working on getting a more solid plan put together, so prototyping has been put on hold for the moment. I'm only expecting this to take about another couple days, so we should be back to prototyping soon. Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Planning « Reply #8 on: August 14, 2013, 08:35:45 AM »



Planning has turned into a bigger project than I was anticipating, but so far I do not think I've entered into the territory of "wasted work hours".



For a while I have been thinking about actually planning out a time and money budget for the project, which is something we haven't done before. I'm hoping that it will help "solidify" the project, so that we actually finish it; scope creep and endless architecture changes have plagued our previous projects, so we need a way of keeping them reined in.



A couple weeks ago,



for their



I didn't have any experience with spreadsheets when I went into this, so I had to learn how to use them. It actually reminds me of programming, specifically functional programming, so it wasn't too bad.



There are currently 4 spreadsheets that make up the plan:

Schedule

Expenses

Features

Content

Schedule contains a list of all the different jobs GreyKnight and myself have to do, and shows how much each job will be "working" for each week during the project. The spreadsheet automatically calculates the total workload percentage each team member has per week, and highlights it in red if the percentage is not 100%. This is not exactly what they showed in the Teamstream, and we are not using it for the same reason; IfThen Software is a very small (2-3 man) indie game development company, so we each have multiple hats/jobs to worry about. I created this spreadsheet so that we can properly allocate our time to the jobs which need it most. Speaking of which, here is the list of jobs:

Artist

Animator

UI Designer

Sound Designer

Lead Game Designer

Game Designer B

Programmer

Public Relations

Marketer

Web Designer

Lead Quality Assurance

Quality Assurance B

Documentary Producer

Producer

Technical Artist

Expenses contains different costs related to development, such as ongoing weekly costs and one-time costs.



Features contains a list of features that the game will have. Each feature is given a value of 1-3, where 1 represents a feature that is a minimum requirement for the game and 3 represents a feature that is not required. Each feature can also be given multiple levels of quality, which controls things such as how complex the feature is. You can also set the quantity of that feature, which would be used for things such as setting how many battleships need to be programmed. Each job gives an estimate for how long the feature will take, and those estimates are used to figure out the total time-cost of the project. Each feature also has a notes section, if more information is needed than can be given in the other fields.



Content has the same set of fields that the Features spreadsheet has, but it is specifically for content that does not require a programmer. This separation allows for more flexibility, such as being able to easily adjust how many different enemy warplane sprites there are without messing up the programming estimates (quantity will be multiplied by the estimates in order to give a rough total estimate). This spreadsheet contains mostly artwork at the moment, and a couple game design things. I will be adding music and sound effects to it today.



Each feature can also be placed into one or more feature packs. There are also content packs, which are exactly like feature packs. Each feature pack has separate quantities, qualities, and estimates for each feature. I will be making an additional spreadsheet which calculates a total cost for each different value level (1, 2, and 3) and for each different feature+content pack at each of those levels. This should make it easy to compare different combinations of features and content.



Sorry for the huge wall of text I have more to say on the matter, but I'll hold off for now.



How do you guys budget your projects, or do you just wing it? "... another couple days" he saidPlanning has turned into a bigger project than I was anticipating, but so far I do not think I've entered into the territory of "wasted work hours".For a while I have been thinking about actually planning out a time and money budget for the project, which is something we haven't done before. I'm hoping that it will help "solidify" the project, so that we actually finish it; scope creep and endless architecture changes have plagued our previous projects, so we need a way of keeping them reined in.A couple weeks ago, DoubleFine did afor their Massive Chalice project. Their method of keeping track of expenses and development time was very interesting, and involved multiple spreadsheets working together to create a project plan. This was exactly what I needed.I didn't have any experience with spreadsheets when I went into this, so I had to learn how to use them. It actually reminds me of programming, specifically functional programming, so it wasn't too bad.There are currently 4 spreadsheets that make up the plan:contains a list of all the different jobs GreyKnight and myself have to do, and shows how much each job will be "working" for each week during the project. The spreadsheet automatically calculates the total workload percentage each team member has per week, and highlights it in red if the percentage is not 100%. This is not exactly what they showed in the Teamstream, and we are not using it for the same reason; IfThen Software is a very small (2-3 man) indie game development company, so we each have multiple hats/jobs to worry about. I created this spreadsheet so that we can properly allocate our time to the jobs which need it most. Speaking of which, here is the list of jobs:contains different costs related to development, such as ongoing weekly costs and one-time costs.contains a list of features that the game will have. Each feature is given aof 1-3, where 1 represents a feature that is a minimum requirement for the game and 3 represents a feature that is not required. Each feature can also be given multiple levels of, which controls things such as how complex the feature is. You can also set theof that feature, which would be used for things such as setting how many battleships need to be programmed. Each job gives an estimate for how long the feature will take, and those estimates are used to figure out the total time-cost of the project. Each feature also has asection, if more information is needed than can be given in the other fields.has the same set of fields that the Features spreadsheet has, but it is specifically for content that does not require a programmer. This separation allows for more flexibility, such as being able to easily adjust how many different enemy warplane sprites there are without messing up the programming estimates (quantity will be multiplied by the estimates in order to give a rough total estimate). This spreadsheet contains mostly artwork at the moment, and a couple game design things. I will be adding music and sound effects to it today.Each feature can also be placed into one or more. There are also, which are exactly like feature packs. Each feature pack has separate quantities, qualities, and estimates for each feature. I will be making an additional spreadsheet which calculates a total cost for each different value level (1, 2, and 3) and for each different feature+content pack at each of those levels. This should make it easy to compare different combinations of features and content.Sorry for the huge wall of textI have more to say on the matter, but I'll hold off for now.How do you guys budget your projects, or do you just wing it? Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Sfx & Music Planning « Reply #9 on: August 15, 2013, 01:44:24 PM »



I added the following categories to the content sheet so that we can find things easier:

Screen Artwork

Levels

Warplane Artwork

Ship Artwork

Sound Effects

Music

I might add categories to the features sheet, but it's so short that they aren't really needed.



I noticed that some of the features, such as path following, are actually engine features rather than game features. So I created a new Engine sheet to separate the "tech" features from the gameplay features.



UI seems like it should have its own sheet, but I don't really know if that would be a good idea or not... I'll have to think about that, and see what UI features and content we have.



I also added a couple new features which I had forgotten about: Attract Mode and CRT Effect. The Attract Mode feature would kick in if you idle at the start screen for too long, and would run through a recording of the game being played. The CRT Effect feature would distort the game screen as though it was being displayed on a CRT monitor. Thanks to These two features might be cut from the game due to time constraints, but it's good to have them in the plan.



So, now my brother (GreyKnight) and I need to finish estimating the content and features Thanks for reading! All of the sound effects and music have been added to the content sheet, and GreyKnight and I have started estimating themI added the following categories to the content sheet so that we can find things easier:I might add categories to the features sheet, but it's so short that they aren't really needed.I noticed that some of the features, such as path following, are actually engine features rather than game features. So I created a newsheet to separate the "tech" features from the gameplay features.UI seems like it should have its own sheet, but I don't really know if that would be a good idea or not... I'll have to think about that, and see what UI features and content we have.I also added a couple new features which I had forgotten about:and. The Attract Mode feature would kick in if you idle at the start screen for too long, and would run through a recording of the game being played. The CRT Effect feature would distort the game screen as though it was being displayed on a CRT monitor. Thanks to Borundin for giving me a tip on how he did it in his game Cave Dweller These two features might be cut from the game due to time constraints, but it's good to have them in the plan.So, now my brother (GreyKnight) and I need to finish estimating the content and featuresThanks for reading! Logged Twitter - Facebook - YouTube

Swifty







Must Keep Walking.





Level 2Must Keep Walking. Re: Codename: Warplane - Classic Arcade-Style WW2 SHMUP « Reply #10 on: August 15, 2013, 03:27:23 PM » (as long as you don't get too caught up in the planning stage )



Adding UI as a separate sheet could be handy; as you'd list all the splash screen, menu, game-room, game-over, highscores GUI items on it



Definitely watch feature creep! I'd say put the Attract Mode and CRT Effect as Polish items, which at the end can be added in if you have time, but i'd work on the current gameplay and content features first Nice, I love seeing all the planning going on here, I think it's really going to pay off in the end!Adding UI as a separate sheet could be handy; as you'd list all the splash screen, menu, game-room, game-over, highscores GUI items on itDefinitely watch feature creep! I'd say put the Attract Mode and CRT Effect as Polish items, which at the end can be added in if you have time, but i'd work on the current gameplay and content features first Logged Twitter | Tumblr

ITS_Mike







Programmer





Level 3Programmer Building a SHMUP - Episode #1: Introducing the Team « Reply #12 on: August 27, 2013, 10:14:41 PM » I hope you enjoy it







We just came back from a week long vacation, which is why there haven't been any new updates recently. We went to an air museum, which was awesome considering our current project is a WW2 SHMUP. The F6F is way bigger in person than I thought it would be! Well, it's a couple weeks late, but here is the first episode of the "making of" documentary for WarplaneI hope you enjoy itWe just came back from a week long vacation, which is why there haven't been any new updates recently. We went to an air museum, which was awesome considering our current project is a WW2 SHMUP. The F6F isbigger in person than I thought it would be! Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Prototyping Returns! « Reply #13 on: August 29, 2013, 02:16:31 PM »



Yesterday GreyKnight and I started working on designing the cannon, which is one of the player's weapons. However we discovered that it had too many dependencies on the machine gun, which we haven't fully designed yet, so we switched over to that weapon instead.



I didn't know how many machine guns you should start out with (it will be upgradable so you'll get more as you play) or where they should be mounted, so I started the process by researching some WW2 carrier based warplanes. I did most of my research on





I discovered that most of the other warplanes used variations of those, so I decided to stop the research there. I then handed it over to GreyKnight so that he could design the first and final machine gun levels. He has done this before, so we decided he was the best choice for the job. This is what we ended up with:





GreyKnight and I aren't sure how well it will play in the game though, so our next task is to create a prototype so that we can try them out The planning stage is finished, and we are back into pre-production!Yesterday GreyKnight and I started working on designing the, which is one of the player's weapons. However we discovered that it had too many dependencies on the, which we haven't fully designed yet, so we switched over to that weapon instead.I didn't know how many machine guns you should start out with (it will be upgradable so you'll get more as you play) or where they should be mounted, so I started the process by researching some WW2 carrier based warplanes. I did most of my research on Wikipedia , using Google Images to get more photo examples where I needed them. I was interested in where the guns were mounted, and also the relative size of the different warplanes. This is what I ended up with:I discovered that most of the other warplanes used variations of those, so I decided to stop the research there. I then handed it over to GreyKnight so that he could design the first and final machine gun levels. He has done this before, so we decided he was the best choice for the job. This is what we ended up with:GreyKnight and I aren't sure how well it will play in the game though, so our next task is to create a prototype so that we can try them out Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Final Weapon Level Prototyped « Reply #14 on: August 30, 2013, 12:58:33 PM »







The artwork is all temporary, but the mechanics are accurate.



The machine guns fire in bursts when you tap the attack key. This will allow the cannon to be more easily controlled later on, since it will share the machine gun's attack key but you might not want to fire it every time a machine gun fires.



We were originally using circles to represent the bullets, but it felt too choppy. GreyKnight suggested adding motion blur to them, which is what you see in the video. I think it turned out pretty nice if I do say so myself To do the "motion blur", the bullet was just stretched out and made to face in the direction that it was traveling.



One engine feature that I've had on the list for a while is procedural rotation, so that GreyKnight doesn't need to draw sprites at different angles. I originally considered this to be a high cost feature, because origins would need to be centered and that would break a lot of code in the first real-level prototype. Now that the first real-level prototype has been scrapped though, there isn't very much legacy code to worry about. After experimenting with



If you were wondering what sort of on-paper designs a programmer might do, here is a photo of some paper-thinking I did for this latest prototype:







Now that the final weapon level has been figured out, GreyKnight and I will be prototyping the first weapon level. This will also require adding support for easy weapon level switching (so that we can go between the final level and the first level), but that shouldn't be a problem. Prototyping for the final level of the player's machine guns is finished! Here is what it looks like:The artwork is all temporary, but the mechanics are accurate.The machine guns fire in bursts when you tap the attack key. This will allow the cannon to be more easily controlled later on, since it will share the machine gun's attack key but you might not want to fire it every time a machine gun fires.We were originally using circles to represent the bullets, but it felt too choppy. GreyKnight suggested adding motion blur to them, which is what you see in the video. I think it turned out pretty nice if I do say so myselfTo do the "motion blur", the bullet was just stretched out and made to face in the direction that it was traveling.One engine feature that I've had on the list for a while is procedural rotation, so that GreyKnight doesn't need to draw sprites at different angles. I originally considered this to be a high cost feature, because origins would need to be centered and that would break a lot of code in the first real-level prototype. Now that the first real-level prototype has been scrapped though, there isn't very much legacy code to worry about. After experimenting with FlashPunk 's procedural rotation code, I discovered that it would be insanely easy to implement, so I didIf you were wondering what sort of on-paper designs a programmer might do, here is a photo of some paper-thinking I did for this latest prototype:Now that the final weapon level has been figured out, GreyKnight and I will be prototyping theweapon level. This will also require adding support for easy weapon level switching (so that we can go between the final level and the first level), but that shouldn't be a problem. Logged Twitter - Facebook - YouTube