next »

[ITS_Mike]

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 Mark Cerny's Method, so there will probably be four more real-level prototypes before we enter production.  The pre-production stage has a 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: 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 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

[ITS_Mike]

I've decided to start using Trello rather than whiteboards for project planning, so that you guys can follow along

I created three different boards, one for the game, one for the engine, and one for the documentary (video diaries).  I hope you find these interesting   Here are the links:
Game
Engine
Documentary

Unfortunately, it does not appear as though you can leave comments directly in Trello (although I suppose that takes care of any spam bot problem).  If you have any comments, please leave them here instead, direct them to me @ITS_Invisible, or post them on our Facebook page.  Thanks!

[ITS_Mike]

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 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!

[ITS_Mike]

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?

[ITS_Mike]

I have been working on the Bomb Screen Shake prototype since Wednesday, which is a whole day longer than I was expecting it to take

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 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 between FP.screen and the entity component system.

I'm shaking the screen by creating a "screen shake" entity from a Position attribute, Velocity attribute, Movement behavior, DelayedRemoval behavior, Shake behavior, and Screen behavior components.  The 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 removal priority to the components. Fortunately I was able to find a much simpler solution: The 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.

[habadash]

Haha I love the Live Action Prototyping (or LAP'ing™). I'm going to have a look at those game dev vlogs.

Good luck with the project!

[ITS_Mike]

Thanks, I'm glad you like what we have so far

[ITS_Mike]

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 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.

[ITS_Mike]

"... another couple days" he said

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, DoubleFine did a

for 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:

• 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?

[ITS_Mike]

All of the sound effects and music have been added to the content sheet, and GreyKnight and I have started estimating them

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 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 features   Thanks for reading!

[Swifty]

Nice, I love seeing all the planning going on here, I think it's really going to pay off in the end! (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

[ITS_Mike]

Nice, I love seeing all the planning going on here, I think it's really going to pay off in the end! (as long as you don't get too caught up in the planning stage  )

Thanks!  And yeah, that is a real danger here.  I have the planning stage set for 2 weeks (the first of which is nearly up) in the schedule sheet, so hopefully that will be enough to keep it from getting out of control.  I expect one of you guys to start nagging me if we are in the planning stage for longer than that though

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

You got me thinking about this a bit more...  And I'm liking the idea  Since the GUI isn't really part of the game's content, the artwork, sound effects, and music for the GUI should really go in a separate sheet, not to mention the actual designing and coding of the GUI.

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

A very good idea!  I have moved those two features into the "value level 3" group, so that will mark them as not required.

I'm also very impressed by GroZZleR and his Teddy Bear Picnic Massacre game, in that it has a two week development schedule...  This has me motivated more than ever to get this game done soon!

[ITS_Mike]

Well, it's a couple weeks late, but here is the first episode of the "making of" documentary for Warplane   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!

[ITS_Mike]

The planning stage is finished, and we are back into pre-production!

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 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

[ITS_Mike]

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 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 FlashPunk's procedural rotation code, I discovered that it would be insanely easy to implement, so I did

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.

[ITS_Mike]

During development you encounter unforeseen problems and questions; the little things for which you can't quite plan.  I like to collectively call these:


The Devil's Details

Last Tuesday GreyKnight and I were working on the weapon level prototype and we decided to replace the port, starboard, and aft machine guns with a turret.  The turret would automatically aim at targets, so the first thing we needed was a couple of enemy planes.  GreyKnight requested a single stationary target and one patrolling target, shown in the box on this paper:


So Wednesday starts, and I decide that this is the perfect time to get path following working; at that time, enemies could only fly in a straight direction so "patrolling" between two points was not possible.  I created the Trello card for the path following feature, and happily estimated it at 1 hour...  I really should have done a spike¹ first

I spent the first half of the day creating a nice path following behavior for the entity component system.  I was originally going to create an AI system for the engine and implement an actual steering system with a path following behavior², but I decided that this would work well enough for now.  By the way, if anyone wants a good path following steering tutorial, check out Understanding Steering Behaviors: Path Following.

I spent the next four hours trying to fix this little guy:

Devil's Detail: A steadily moving camera distorts what should be steady and straight movement in world-space.
When you have a top-down camera that is moving at a constant speed forward through the world, you can't use world coordinates to shoot a bullet left and expect it to move straight; the bullet will appear to curve backwards. You run into a similar problem with any form of movement done in world-space. If an entity moves forwards, it will appear to slow down, and if it moves backwards it will appear to speed up. If the thing that is moving is a tank, this isn't a problem since it will appear correct to the player.  However, if it is a plane or bullet, the player is going to expect it to move straight.

This was not a completely new problem for me; up until now I've "fixed" it by ensuring that the player's plane and enemy planes are always moving forward at the same speed as the camera, and warships move at a certain percentage of the camera's speed to account for parallax scrolling, and bullets always have the camera's velocity added to their own velocity.

However, those solutions did not work with the new path following feature. The nodes that make up the path were in world-space, as was everything else. The path following behavior would calculate the heading from the plane's current position to the next node, scale it by the plane's speed, and set the plane's velocity to that result.  Now usually I would solve that Devil's Detail by adding the camera's velocity to the plane's velocity...  But now we have a new problem: The plane is no longer heading in the correct direction.

The Solution
After examining multiple SHMUPs and taking a look at some arcade hardware specs to try and figure out what they had to work with, I decided to solve the problem by moving entities in camera/screen space³ rather than world space. I could not find support in FlashPunk for "disconnecting" the entities from world space, so I overloaded the entity's Render() method and copied the existing render code except without the camera reference.


Now that I have path following working correctly, and two enemies to target, I can finally add the turret   As always, thanks for reading!


¹A "spike" is a prototype to make an estimate more reliable.
²This "behavior" is not the same as an ECS "behavior"; this is a steering behavior which describes a certain aspect of how the entity should move.  An ECS behavior describes a much broader behavior of the entity.
³In FlashPunk, camera space and screen space are the same.

[ITS_Mike]

I've decided to try and make more and shorter devlog entries; who wants to read through a wall of text?  

So I've been researching scan lines and exactly what causes them.  I'll have a list of some of the resources I found at the bottom of this post.  It's been really bugging me, and we might use it for the game, so I figure it's the perfect thing to research while my team and I are still in pre-production!

On the note of pre-production, we are in our fourth month of pre-production which only gives us a little over a month and a half left!  Things really need to start coming together soon if we are going to have a playable demo by Halloween.

While researching scan lines and how to implement them in the game, I discovered a 3D rendering API from Adobe called Stage3D.  This could provide significant performance and flexibility improvements for the game, so I will be researching the technology and attempting to create a graphics engine based on it.  I have a decent amount of experience with creating 2D graphics engines ontop of a 3D API, so I'm hoping there won't be very many surprises; our Halloween deadline certainly cannot afford very many unexpected issues!


Researching Scan Lines

Scan line - Wikipedia
A THG Primer: CRT Guide
Scanlines Demystified
The Gamer's Graphics & Display Settings Guide: Graphics Settings - Resolution
In Search of Scanlines: The Best CRT Monitor for Retro Gaming
Recreating CRTs
Opinion: CRT Emulation For Pixel Art
My analog A/V setup - 240p goodness

[goob256]

Awesome! 1942 was one of my favorite games growing up, is this going to be similar? What I liked about it was there was not an entire screen full of bullets to dodge, but enough to make it fun. Will be following this when I see it come up!

[panicBarn]

Looks great. I have fond memories of 1942 and i'm interested to know if you have any specific features planned that will be unusual for the genre? or is it more of a straight replica of the classic arcade shooters?

[gamepopper]

Hey man! Your game is looking good so far. I'm a big fan of shmups like 1942 so I can't wait to hear more from you guys! =D