My current programming project

[Godskook]

Alright, I've been working at teaching myself flash by working on a video game with the end goal of publishing it on kongregate. I'm starting this thread as a place to keep notes and maybe recruit some community members in helping in areas I'm not great in.

Roles:
Coding - I'll be doing most of the coding myself, but if someone is willing to hang around as an 'expert' for me to consult on programming in Flash/AS 2.0, I'd appreciate it.
Game Mechanics - The game outside the code, as it where. Anyone that wants to collaborate is welcome, but primarily, this'll fall to me and a RL friend of mine, known as ogre1 @ kongregate. Currently, the game's looking to be similar to the battle engine from the Star Control series.
Graphics - This is where I really need help. I'm not a visual person, so my stand-in graphics are just simple polygons or similar. I need someone familiar with graphics in a flash-based environment. Since you'll be doing it, you're free to choose your 'style', provided it doesn't make the coding harder(Anyone caught advocating game art that makes the coding harder will be added to the lists in the crack pairing thread).

A copy of compiled program will be made available to anyone who becomes involved with the project.

'Steps' to do(11/30/09)
-Code enemy ships to move 'properly' with new offset motion.
-Code collision detection between ships, and between bullets and ships.
-Design ship fighting styles for both player ship(s) and enemy ships.
--Research ideas: Star Control, Bubble Tanks, Space Pips
-Create screen background so that ship isn't flying through white space.

Goals
-Develop menu screen(s) and pause screen, and figure out how to make them work.

[Ashtar]

For the screens (menu and pause), the usual technique is to implement a game state / screen stack (but I store it in a list... to iterate through it), allowing you to stack screens one on top of the other while pausing (or not) the one below. For example, the menus are a state on top of the game (which for example allows you to play the game in "demo" mode in the back à la Mario without resorting to a fixed pre-recorded animation), Pause is the same. In an action game, the select item screen could for example not pause the game below.

Shamelessly stealing an image to illustrate http://www.innovativegames.net/blog/wp-content/uploads/2009/10/gamescreen_stack.jpg from an XNA game tutorial at http://www.innovativegames.net/blog/.

A sample of a very simple Flash based Space Invaders (http://code.google.com/p/mongitime/ (code) and http://lab.miguelmoraleda.com/mongitime/ to try it out). Might help you with the basics of flash and games?

Anything else, feel free to ask.

[Godskook]

Update: 'Steps' to do(11/30/09)
-Code enemy ships to move 'properly' with new offset motion.
--basic enemy ship now moves 'properly'. That was a lot of nasty math to solve.
-Code collision detection between ships, and between bullets and ships.
--Probably next.
-Design ship fighting styles for both player ship(s) and enemy ships.
--Research ideas: Star Control, Bubble Tanks, Space Pips
--Time to harass RL buddies on this one.
-Create screen background so that ship isn't flying through white space.
--So far, no graphic artist help, need to search harder.



For the screens (menu and pause), the usual technique is to implement a game state / screen stack (but I store it in a list... to iterate through it), allowing you to stack screens one on top of the other while pausing (or not) the one below. For example, the menus are a state on top of the game (which for example allows you to play the game in "demo" mode in the back à la Mario without resorting to a fixed pre-recorded animation), Pause is the same. In an action game, the select item screen could for example not pause the game below.

Yeah, I've read about that technique, but implementing it is a little confusing to me. I've not yet gotten to that point in the code, so I'll see how it goes when I get there.

(While I appreciate the tutorials, coding samples not written in english are going to be wasted on me)


Anything else, feel free to ask.

Thanks, man, will do.

[Cedrass]

-Code collision detection between ships, and between bullets and ships.

I can't help much (busy with coding of my own. Competition in March!), but this I can. (I don't know if you know how to do it, so I'll say it, just in case)

When doing you ships, push them in an Array. And when want to acces those, for the hitTestObject or hitTestPoint, you can just write:


for each(obj in yourArray){
if(yourCharacter.hitTestObject(obj) == true){
//Your code here
}
}

How it works is it takes each entry in your array, and allows you to acces it using the defined variable (here 'obj'). Now the only thing left is to detect collisions using your main character (or bullets or anything really) and compare it!

It's late here, so it may be unclear. I'll try to check back if you understood or not tomorrow. I've got a meeting and a bunch of classes, but yeah.. I'll try!

[Godskook]

It's late here, so it may be unclear. I'll try to check back if you understood or not tomorrow. I've got a meeting and a bunch of classes, but yeah.. I'll try!

You've(and Ashtar) been clear, but I haven't, I don't think. Perhaps it'll help to explain a little. I've had several programming classes already, but it was all Java-based and......I'm not sure how to describe it.....programmer-controlled(I guess?). What I worked on was more like 'pure math' to this project's 'applied science'. Principally speaking, I have two major road blocks with the coding. First, it is in understanding the language syntax of AS 2.0, as it differs from Java(my home language). On this point, I'm used to being able to create random classes to do just about anything in Java, but in Flash, I've not quite figured out how to utilize this for non-movieclip classes(for instance, custom stack/queue classes). Secondly, it is the 'quirks' that appear in different places for no particular reason whatsoever. The current example of this is the fact that currently, my game engine won't recognize more than 2(or sometimes 3) keys held down at once. For a keyboard based game, that's unacceptable, but I have no idea why it is doing it, nor what the best way of fixing it is(I've got ideas, but nothing with solid code, yet). Also, I'm quite rusty, since I've been spending most of my time dealing with job hunting lately.

As said before, though, I really do appreciate the assistance.

Just musing a little before I hit the hay, my main concern with collision detection is making it more precise than the flash's default, which really, really sucks at dealing with the false-positives I've seen it give. Also, Cedrass, you mention .hitTestPoint(), but what is that? I'm totally unaware of that method.

Actually, here's a good question. Is there a place to freely host a flash movie? If so, I'll just keep an updated version of the current flash engine. Hopefully I won't cause eye-bleeding in any of the viewers from my simple graphics.

[Brother Oni]

The current example of this is the fact that currently, my game engine won't recognize more than 2(or sometimes 3) keys held down at once. For a keyboard based game, that's unacceptable, but I have no idea why it is doing it, nor what the best way of fixing it is(I've got ideas, but nothing with solid code, yet).

From a game design point of view, you could make the ship have autofire or give it an autofire toggle option, as I can't think of any situation in a side/top scrolling shooter where you wouldn't want to have all guns blazing at maximum RoF.

[Godskook]

Update: 'Steps' to do(12/01/09)
-Code collision detection between ships, and between bullets and ships.
--Ship to Ship detection is up and running.
-Exposed issues with enemy flight patterns.
--Enemies suicide into hero ship. Also, flight seems too 'fast'. A playtester or two is probably already necessary.
-Design ship fighting styles for both player ship(s) and enemy ships.
--Research ideas: Star Control, Bubble Tanks, Space Pips
--Time to harass RL buddies on this one.
--*See table.
-Create screen background so that ship isn't flying through white space.
--So far, no graphic artist help, need to search harder.

{table=head]Ship|Thrust|Rotation|Firepower|Playable?

Lancer1|8|5|2 standard, side mounted|yes
Runner(e1)|9...11|3|N/a|no
'Heavy'(e2)|5...7|10|N/a, at present|no, currently
[/table]



From a game design point of view, you could make the ship have autofire or give it an autofire toggle option, as I can't think of any situation in a side/top scrolling shooter where you wouldn't want to have all guns blazing at maximum RoF.

I can:
1.The game counts accuracy, which means autofire equates to a bad score.
2.Limited ammo
3.Cooldowns
4.Recoil/barrel cool-down issues
5.Multiple weapon-types, each with a #2 #3, or #4 attached.
6.Bad RoF, making aimed shots better than auto-fire.

Besides, there's also the factor that a '2 keys at a time' rule limits the design space in annoying ways, as well as hindering game development, as I'm already putting a few 'me-only' keys into the game(one summons additional waves of enemies).

[Godskook]

Update: 'Steps' to do(12/01/09)
-Code collision detection between ships, and between bullets and ships.
--Ship to Ship detection is up and running.
--I can now shoot down enemy ships, and they 'die' when they hit the PC ship.
-Exposed issues with enemy flight patterns.
--Enemies suicide into hero ship. Also, flight seems too 'fast'. A playtester or two is probably already necessary.
-Create screen background so that ship isn't flying through white space.
--So far, no graphic artist help, need to search harder.

Pressing:
-Find a graphic artist(cross-posting @ kongregate (http://www.kongregate.com/forums/8-collaborations/topics/67344-need-help-on-space-fighter-game))

[Brother Oni]

Besides, there's also the factor that a '2 keys at a time' rule limits the design space in annoying ways, as well as hindering game development, as I'm already putting a few 'me-only' keys into the game(one summons additional waves of enemies).

I meant that by giving the ship an autofire option, you can eliminate another key to be pressed.

However it seems clear that you intend your game to be somewhat different to the usual danmaku shooters I tend to play (which mostly revolves around trying to find a safe spot for your hit box and going "AAAAAAAAHHHHHH!!!!!!" a lot). :smallbiggrin:

[Godskook]

I meant that by giving the ship an autofire option, you can eliminate another key to be pressed.

However it seems clear that you intend your game to be somewhat different to the usual danmaku shooters I tend to play (which mostly revolves around trying to find a safe spot for your hit box and going "AAAAAAAAHHHHHH!!!!!!" a lot). :smallbiggrin:

(That made me smile:smalltongue:) Actually, I was more just pointing out generalized reasons for wanting better keyboard control. As for danmaku style, yeah, I'm probably going to avoid reaching all the way into that extreme, due to fact that I'd expect there to be added challenges with that many onscreen movieclips.

[Godskook]

Alright, there's a beta version available on Kongregate, if anyone's interested:

http://www.kongregate.com/games/Godskook/dogfighter

[Zovc]

The current example of this is the fact that currently, my game engine won't recognize more than 2(or sometimes 3) keys held down at once. For a keyboard based game, that's unacceptable, but I have no idea why it is doing it, nor what the best way of fixing it is(I've got ideas, but nothing with solid code, yet).

In my experience with computer games, most keboards won't respond to the user(s) pressing more than three to five keys. I know back in the day, my computer would beep if I'd press too many keys. I remember trying to play a fighting game with my friend, he'd just press keys that would 'disable' mine.

I'm pretty sure (and I have no real understanding of electronics or circuitry) that there are "groups" of keys, and only so many keys in each group can be pressed without 'overloading' a particular section.

[Mando Knight]

Alright, there's a beta version available on Kongregate, if anyone's interested:

http://www.kongregate.com/games/Godskook/dogfighter

I can get it to circle clockwise while thrusting and firing, but not counterclockwise.

[Hunter Noventa]

I can get it to circle clockwise while thrusting and firing, but not counterclockwise.

I don't have this problem. How interesting.

Smooth so far though, the control feels pretty spot-on.

[Godskook]

I can get it to circle clockwise while thrusting and firing, but not counterclockwise.

Yeah, that's a known problem, and as others have mentioned, it might be out of my hands.

[Godskook]

Worklist(general): 12/04/09
-Enemies suicide into hero ship. Also, flight seems too 'fast'.
-Found solution to keystroke issue.
-Enemy ships need weapons
-Additional stats beyond speed and rotation
-Better name for the game
-Menu screen(s)
-Pause screen
-Better 'HUD' screen
-Momentum for hero ship(i.e., physics)
-Wave progression

Worklist(graphics): 12/04/09
-Artist obtained
-Currently in the works:
--Various ship graphics
--Background images
--Discussions on possible animations involved with ship graphics
-Things still needed:
--Bullets
---Might change dynamically, as weaponry is implemented
--Title Screen
--Buttons
--Explosions

Alright, this one is for any tom/****/harry out there.
Worklist(playtesting): 12/04/09
-Tweaking speeds on current ships
-The only way I've found to avoid the key logging issue is to use certain keys that don't conflict with each other on the game interface. I need comments on how players will react to the unusual key configuration. Its not up yet, but will be before the end of the day.
-Comments on the difficulty of the waves. Which do people find harder.
-What's the current record wave people have attained?(Screenshots please) Mine is ~12.

The current key set is: arrows used to maneuver, and then "C", "S", "A", and "Left-Shift" are available as 'weapon slot' buttons. These 4 buttons are the only set of 4 that are compatible with pressing 3 arrow keys simultaneously. Currently, "S" summons additional waves, but that's a temporary feature that will not be in the final release.

[Godskook]

Dogfighter 0.03 is now uploaded.

[Evilfeeds]

Hey Gods, Eugene here (HCO)

Im working as an AS3 developer these days, so I'll try and help you with what I can.

For what its worth, I suggest using AS3 rather than 2. AS3 is (imho) a decent language (and more like Java), whereas AS2 is a smoldering pile of poo.

Re: Multiple keys. Zovc is corrent, keyboards are bunched up into "groups" of keys, and unfortunately the spacebar is often (but not always) on the same group as some of the arrow keys. The easiest way around this is to bind fire to something other than space (or have both keys do the same job).

The way I normally do intro screens / main game / etc is as follows: (Note: im aware this isnt how everyone does it, but sod it, it works for me).

Messy pseudocode


Main game class

var currentgamemode= 0; // 0 = intro screen, 1 = credits screen, 2 = game
var introscreen:IntroScreen;
var creditscreen:CreditScreen;
var game:GameEngine;

function update(){
switch (currentgamemode){
case 0: introscreen.Update();
//etc
}
}

function switchScreen(newScr){
currentgamemode = newScr;
}

[Godskook]

Hey Gods, Eugene here (HCO)

Dude!


Re: Multiple keys. Zovc is corrent, keyboards are bunched up into "groups" of keys, and unfortunately the spacebar is often (but not always) on the same group as some of the arrow keys. The easiest way around this is to bind fire to something other than space (or have both keys do the same job).

Yeah, I went the hard way and figured out which keys are compatible with each other(see 2 posts above yours), but if differrent keyboards have different compatibilities, I'll probably need to include a key-change sub-menu(ugh, more work).


Messy pseudocode

Huh, uh, um, yeah. That looks like exactly what I'd do if I knew AS better, but its going to take me a sec to digest the thought.

From what it looks like, the logic is:
-using 3 subclasses(GameEngine,IntroScreen,CreditScreen)
-currentGameMode as a control flag
-and a 'main' class

Right? Sounds elegant, if so.

[Evilfeeds]

From what it looks like, the logic is:
-using 3 subclasses(GameEngine,IntroScreen,CreditScreen)
-currentGameMode as a control flag
-and a 'main' class

Right? Sounds elegant, if so.

Basically, yeah. Obviously, you need a "main" class to start the program, then you just switch between states as necessary. I use that format in most games. Actually, let me go rip code from my latest project:



package {
import flash.display.MovieClip;
import flash.events.*;
import Screens.IntroScreen;
import Screens.LevelEditor;
import Screens.LevelSelectScreen;

public class Main extends MovieClip {

public static var SoundOn:Boolean = false;

var currentScreen = 0;

public var iMode:IntroScreen;//0
public var gMode:GameEngine;//1
public var eMode:LevelEditor;//2
public var sMode:LevelSelectScreen; //3


public function Main() {
iMode = new IntroScreen(this);
gMode = new GameEngine(this);
eMode = new LevelEditor(this);
sMode = new LevelSelectScreen(this);
addChild(iMode);
stage.stageFocusRect = false;
stage.focus = this;
addEventListener(Event.ENTER_FRAME, Update, false, 0, true);
stage.addEventListener(MouseEvent.MOUSE_DOWN, mouseDown);
stage.addEventListener(MouseEvent.MOUSE_UP, mouseUp);
stage.addEventListener(MouseEvent.MOUSE_MOVE, mouseMove);
//stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDown);
}

public function Update(e:Event) {
if (currentScreen == 1) { gMode.Update(); }
if (currentScreen == 2){ eMode.Update(); }
}

public function mouseDown(e:MouseEvent) {
if (currentScreen == 1) { gMode.mouseDown(e); }
if (currentScreen == 2) { eMode.mouseDown(e); }
}

public function mouseUp(e:MouseEvent) {
if (currentScreen == 1) { gMode.mouseUp(e); }
if (currentScreen == 2) { eMode.mouseUp(e); }
}

public function mouseMove(e:MouseEvent) {
try{
if (currentScreen == 1) { gMode.mouseMove(e); }
if (currentScreen == 2) { eMode.mouseMove(e); }
}
catch (errObject:Error) {
trace("error:");
trace(e);
}
}

public function SwitchScreen(newScreen:int):void {
switch (currentScreen) {
case 0: removeChild(iMode); break;
case 1: removeChild(gMode); break;
case 2: removeChild(eMode); break;
case 3: removeChild(sMode); break;

}
switch (newScreen) {
case 0: addChild(iMode); break;
case 1: gMode.resetLevel(); addChild(gMode); break;
case 2: addChild(eMode); break;
case 3: addChild(sMode); break;
}
currentScreen = newScreen;
stage.focus = this;
}

}

}


Note that you pass in "this" to each of the classes, so that when you need to switch screen, you can call (for example) main.switchscreen(1) to actually change screens.

Theres a lot of ways to do it, but I use that, and it works for me.

Edit: Also, i wouldnt worry too much about multiple key setups. The only issue I know of is that generally, space is on the same "cluster" as some of the arrow keys. Just add Z or something as alternate fire.

[Godskook]

New features(developer's copy only, currently): 12/08/09
-Radar
-Eugene's game mode logic(well, the game engine end of it, had to debug an entire dynamic library to make that thing work, grumble grumble).
-Art! That's right, art. My graphics guy has put down some assets in the game, and we now have art.(Can you tell I'm excited about this one?)
--New ship images
--Background
--Moving background!
--Health meter built into the ships!!


Worklist(general): 12/08/09
-Enemies suicide into hero ship. Also, flight seems too 'fast'.
-Enemy ships need weapons
-Additional stats beyond speed and rotation
-Better name for the game
-Menu screen(s)
-Pause screen
-Better 'HUD' screen
-Momentum for hero ship(i.e., physics)
-Wave progression

Worklist(graphics): 12/08/09
-Things still needed:
--Bullets
---Might change dynamically, as weaponry is implemented
--Title Screen
--Buttons
--Explosion
--HP meter art

Since the developer's copy is a few versions ahead of the open beta, no real need for playtesting at the moment.

[Godskook]

New features(developer's copy only, currently): 12/13/09
-New ships
-Mild ship AI
-Ship weapons
-Upgraded collision testing for a smoother experience(and it was a necessary upgrade for some of the enemy's weapon systems to work properly).
-Working pause feature, but without any fanfare.

Worklist(general): 12/13/09
-Additional stats beyond speed and rotation
-Better name for the game
-Menu screen(s)
--Once finished, integrate preloader
-Pause screen
-Better 'HUD' screen
-Momentum for hero ship(i.e., physics)
-Wave progression

Worklist(graphics): 12/13/09
-Things still needed:
--Bullets
---Might change dynamically, as weaponry is implemented
--Title Screen
--Buttons
--Explosion
--HP meter art
--Preloader art