next »

[aeiowu]

love to play it when you get the demo going.

one suggestion just off the cuff. smaller buttons/UI pill thingies. though that's peanuts compared to getting the demo ready and etc. save it for phase 2 

[Montoli]

one suggestion just off the cuff. smaller buttons/UI pill thingies.

Definitely could wait on that, but on the other hand, it's in flash, and they're just symbols, so changing their size turns out to be the work of about 30 seconds and 2 lines of code.  I tried them smaller just now, on your suggestion, but I'm not sure if I like it or not.  I may not be the most objective observer though, since I've stared at it one way for a while now and probably find any deviation slightly jarring at this point.

I have a feeling though, that since I don't know what you're aiming for with that suggestion, that I might be making them too small/big for what you had in your head when you suggested it.

Could you maybe elaborate a little?  Are you thinking "Smaller, so there is more white space", "smaller so there is more screen real-estate to make the play area bigger", "smaller just so they don't touch each other, that feels cluttered", or something else alltogether?  (UI design is very much not my strong point, so I'm very open to suggestions.)

Of the sizes I tried, here's the one I ended up liking the most.  Is this what you had in mind?

[mokesmoe]

I think it looks better, but you should lower them a bit so they don't collide with the options/reset buttons.

[aeiowu]

well i guess it depends on what you're using them for. Are they actually buttons that are clicked on? Do you play the game with the mouse and keyboard? If they aren't clickable I think they oughtta be like half that size since it's just a HUD at that point. it looks like you have them assigned to numbers, if they _are_ buttons do they need to be? I'm guessing it'd be easier to use 1-4 number keys to cycle through different abilities.

So I guess I can give better advice if I know what they're used for. If they are purely there to show what powerup you have though and not actually switchable by the player i think you could probably scrap the whole thing in favor of just showing what is active at the time.

[Montoli]

Ahh.  Context.

So:  Yes, they are clickable.  You can select them via number, or click on them directly.  They are large, because clicking on them during the fight is often a hectic affair.  Using numbers (or even the mouse wheel if you're feeling crazy) are definitely "better" ways to select things, and it is the hope that more experienced players will gravitate towards them.  However, I am a strong believer in the theory that "if the user tries something they think should work, it should work, even if it means there are redundant controls".  And since they are on-screen representations of possible user choices, users are used to being able to click on that sort of thing.  So I allow mouseclicks as an additional means of selection.  (Think of them like the powers in Diablo 2 or most other blizzard games - you COULD select them all via button, but once you get good and learn the ropes, hotkeys are the way to go.)

They also need to all be on the screen because they are part of a display.  there is a bar that charges up to power them, and you can't use power X until the bar has climbed past it.  So their position serves as a visual display of what is available, what will soon be available etc.  (and more than that, when parts of the ship get blown off, corresponding powers will disappear, and the ones above them will fall down to take their place, effectively becoming cheaper.)  So I definitely need them all onscreen to convey my power selection model.

A few other (rather arbitrary) reason they are big include:

• I wanted to keep the controls and on-screen elements to a minimum so they didn't feel cluttered.
• I wanted a target screen size of 640x480.  (Just because it's a nice and standard size.)
• To fit with vertical-shmup convention, I wanted to make the actual "play area" be no wider than it was tall.  (Which in this case meant that it was 480x480)
• I didn't have anything else I wanted to put there, so they just sort of became the size needed to occupy that space?

Hmm.  So yeah.  Rereading these, some of them are probably not great reasons, but I think I stand by the "big buttons are nice in the middle of a fight" and "I have that much space there, and nothing else to stick there, so why not?" ones.

Thoughts?

[PureQuestion]

Glow-y...

Anyway, visuals are sleek and nice looking for something that has so much laziness behind it's creation. Looking at a couple of the images, I can definitely see the inspiration from Touhou. It's certainly nowhere near as ridiculous, however.

Anyway, looks to be good.

[Montoli]

Wow, last week wiped me OUT.  Had a frantic "lets get a pitch together for a client" sort of week, with minimal time to be spent on other things.  I am feeling behind now!

On the brighter side, am also now finally in synch with my audio guy, and getting ready for the final audio integration pass.  I'd post screenshots, but audio is hard to screen-capture. :D

Anyway.  Onward!

[aeiowu]

ah, i dropped the ball on this. sorry.

given your reasoning i think what you've done make sense. it's always tough working on usability and this is most certainly a usability issue. My best advice to make sure you're doing what's intuitive to the player is to sit down and watch them play (without saying anything), see what they get hung up on or how they interact with your game and evaluate that against how you _want_ them to interact with your game.

[MaloEspada]

Wow, I'm loving the graphics and Touhou-based gameplay. Keep it up!

[Loren Schmidt]

if the user tries something they think should work, it should work

[Montoli]

ah, i dropped the ball on this. sorry.

No worries man, I soldiered on without you.   You probably have at least 6 things more important/interesting to do besides compulsively hit refresh on the devlog page to see if anyone has specifically asked you a question.

So anyway, bleah, spent today writing ui screens.  I HATE ui screens.  And I even get to do them in Flash, which is arguably one of the better tools for setting up mouse-driven UI screens.  They still suck.  Bleah, I say!

Today's adventure was the "options" screen, home to such wonderful and exciting buttons as "Low, Medium and High Quality graphics" and "Sound/Music On/Off"

Thrillsville!


Still, necessary, I guess.  This is the 2nd to last screen I need to do.  (The last one being the end-of-game results screen, which is currently a woeful example of placeholder programmer art.)  I was hoping to knock both of them out today, but I got distracted putting in some custom hooks so that a boss could, hypothetically, take over the background generator and radically change the colors, if it wanted to do something epic looking.  Hypothetically.  If, you know, I had a boss that I thought was super awesome, that seemed like would benefit from some dramatic spice, to make things seem more epic.  Hypothetically.


I'm worried at this point that my dislike of writing UI is actually to the point of endangering good [I think they're good at least] game ideas.  Example:

Player feedback has suggested that having short-term goals would be nice.  (The normal game mode is just "survive until it gets too hard and you die")  So I was thinking "it would be fun to make up some "challenge modes", sort of like the challenges in, say, Smash Bros.  Short, timed games, with a particular objective or restrictions that are not normal.  "Survive for 30 seconds with no guns".  "Last 1 minute without letting the ship collect a single power up."  "Last 1:30 against TEN ships!".  "Kill the enemy at least 3 times in 2 minutes by squishing him against your ship"  Etc.  Weird little challenges that would spice up the game a little, for if you got bored playing survival mode, and want some short term goals and structure.

And, upon reviewing the code, I realized, they would be REALLY REALLY EASY to make.  I already have a code abstraction for something I call a "rule".  "Rules" are basically global effects applied to the game, and a lot of things in the game are handled by rules.  Things like "Power ups spawn every so often", or "if the enemy ship has blown up, spawn a new one after a short delay".  It would be trivial to set up a bunch of challenges as rules that I could mix and match.  (Since rules aren't mutually exclusive.  I can have as many running as I want.)  Things like "End the challenge in success/failure in 60 seconds."  "disallow the player from shooting."  "End in failure if the enemy ship collects a power up".  Etc.  Once I did that, I could represent any of the challenges that I brainstormed fairly trivially, as a combination of rules.  "Survive 60 seconds without letting them get powerups?"  Just a combination of "Game ends in success after 60 seconds" and "game ends in failure if ship powerup level is ever greater than zero".  Etc.

And it would be even more awesome because I have a bonus boss all set up and ready, that I need to hook in to some kind of unlock.  And it would fit perfectly as a reward for someone who completed some large percentage of the challenges and was looking for some payback.

All around it's a win!


Except...  It would require writing up a new UI screen for the player to select the challenge they wanted, and to have text describing what the challenge was.  And the sad part is, that, coupled with my aforementioned dislike of writing UI, was almost enough to make me not want to make it.   (Epilogue:  I think I've talked myself into it now.  There are just too many "wins" I get out of it.)

So yeah.  UI.  Hate it!

But we do what we must.  I'll be looking forward to getting back into the fun part of gameplay tweaks as soon as possible, however.


-Montoli

[Montoli]

Still going!

Was trying to figure out why my AI code was having trouble with a particular bullet pattern.  (two interlocking spirals, moving in opposite directions as they expand)  Rather than dodge like it should, the ship kept pressing itself against the wall trying to get away, before eventually getting shot.  Further exploration revealed that this happened ANY time two bullets approached it at the same speed and distance from different angles near the edge.

Eventually, I realized that when I revamped the AI a week or two ago, I neglected to inform the AI about the invisible walls that keep the ship on the stage.  (It had been assuming it could dodge by moving further backwards, and the rules system was not letting that happen.)

After I fixed that, it handles those much better now!  It's downright annoying to kill, in fact!

In fact it generally even survives things like THIS: 


Right now, I'm doing the UI task I talked about last post, and after that I think it's time to start adding audio.  Since I have a delivery here waiting and everything, and it sounds awesome.  After that...  Done at last?  (Or at least "time to put up on FGL and roll the dice"...)

[mokesmoe]

Maybe you could add different difficulties to the game, That just change how good the AI is.

[FranticPandaKev]

This looks too cool

[Montoli]

Maybe you could add different difficulties to the game, That just change how good the AI is.

Was seriously thinking of doing exactly that!  Using the old AI model it was easier, but the new one is a little more finickey, so I may have to put that idea on hold for a bit.



In other news, I found out today that you can hook up your SWF to google's webpage analytics fairly easily.  Which, as it turns out, rules, if you want to do something like, say, track player metrics across a wide playerbase during a playtest, or keep track of things like, say, how many people completed level 1, or how long it takes people on average to beat boss #2, or whatever.

I wrote a wrapper layer for it today, and have started putting it in my game, since I'm hoping for a final round of playtests soon.  And this feels like solid gold for prototyping.  I wish I'd found out about this earlier in the development process, but at least I can get some last minute metrics in, and get the kinks worked out so I'm ready for the next project.


Had a weird moment yesterday.  Spent all day writing python scripts for automatic code generation, so I could use a plaintext file with a little markup as the definition for my challenges since they'll be text heavy and it's handy to be able to run it through a spell checker, etc.  Basically I wanted to be able to write them out as a list of descriptions, with a few keywords thrown in for rules, and have everything... the menus, the game rules, the descriptions... just magically work.

So after I finished, I tried hooking this complicated system up to my UI and game code.  (Which is also a complicated system.)  And somehow... it magically worked.  On the first try even.  Now I'm all spooked.  That sort of thing just doesn't happen.  I'm waiting for the other shoe to drop, when I find out what I broke in the process, because that seemed... easy.  TOO easy.

[mokesmoe]

Don't worry, the more you suspect somethings wrong, the more likely it isn't. It's like anti-jinxing or something.

[Havok]

This looks fantastic! I hope to be able to play it soon.

[aeiowu]

yo, the skull enemy looks pretty neat.

we we're looking at .swf trackers and all that and ended up going with mochibot. you have some kind of documentation on hooking up that google analytics into the .swf? We'd prefer to use that anyway... PM me or GChat me (i think you know mine right?) if that's more convenient.

[Montoli]

Right on, aeiowu, I emailed you most of what I know so far.  If anyone else is curious, here's the quick and dirty summary:

General info:
http://code.google.com/apis/analytics/docs/tracking/flashTrackingIntro.html

Specific project page:
http://code.google.com/p/gaforflash/

Sample Code:
http://www.insideria.com/2009/02/using-google-analytics-within.html

A nice blog post talking about the same thing:
http://philprogramming.blogspot.com/2009/07/how-to-use-google-analytics-in-flash.html

It looks pretty sweet so far, but since I've only been playing with it for less than 24 hours, there could still be some surprises down the road.  Maybe if there isn't one already there by the time I feel more informed, I'll write up a guide in the tutorials.

-Montoli

[Montoli]

I'm still alive!

I got sort of swallowed up this past week, so while progress has been steady, updates have been fleeting.  Also, a lot of what I was working on was boring UI stuff, polishing up the user interface, adding menus to get to some of the various modes that previously required changing constants in the source code by hand, etc.  I. e. stuff that is both boring to write, and makes for boring screenshots to share.

Still, getting tantalizingly close to finished!

....

This would feel more awesome if I hadn't been telling myself that I was "tantalizingly close to finshed!" for the past month or so.  But so it goes.  My goal on this project is to get it to "awesome", and sometimes that requires looking at it after I've written something and realizing that it plays all wrong and needs reworking.

I've seen a quote recently, something along the lines of "after you finish the first 90% of the game, all you have left is the other 90%."  This is a good quote!  It is very true!  But I'd like to add to it, that after you finish the 2nd 90%, there is often a third 90% hiding behind it, also needing to be done.

Anyway, enough self-pity.  The end is in sight!

I spent tonight working on the last boss I plan to add to the game, and have been having a blast putting him together.  It really is a fun part, when you're at that stage of development where you've already paid your dues and done all the low-level drudgework of setting up the game systems, and can just focus on (and quickly create) high level ideas like "Ok, now I want something that acts like THIS!".  I'm at that stage now, and I think it's my favorite part of a project.  (Made significantly more fun by the fact that unlike some of my projects, I haven't collapsed under the weight of the accumulated hacks I needed to put in to keep everything working yet. )

Specifically, I'm at the point where I've got the AI working for dodging arbitrary patterns, and a bunch of boss classes that make it really quick to describe a boss, and a scripting setup for describing bullet patterns easily.  So I spent most of today doing some rapid iterations on, as I mentioned, one last boss.  Here, I even took a crappy screenshot for you guys!



It's not completely done yet, (and this shot doesn't really do it justice) but the fundamentals are there.  This one is a little different style than some of the other ones I did. (The look is less segmented, and more animated, for one.)  I suspect this will be one of the two "bonus unlockable" bosses.  As you can probably tell from the screenshot, this one is weather themed.  I'm really happy with how he's turning out, but most of the parts that are neat about him aren't easily conveyed via screenshot.  (The short version:  His attacks all interact with each other in weird ways.  For example, the whirlwind scatters the [otherwise fairly orderly] raindrops.  And there's an ice attack that changes all the raindrops into snowflakes, which move differently.  And the sun attack (pictured here) melts them back into raindrops.)

Funny story.  Originally I was planning on one boss, or maybe 2.  Three tops.  Then I realized "I spent all this time and technology making it easy to make bosses.  Why am I not leveraging it?  Why am I stopping at 3?"  So... yeah.  This one, (again, the last one I'm adding) brings the total up to around six and a half.  (There's one really complicated guy, that's really worth at least one and a half normal bosses.)

Anyway.  Onward I go, I guess.  The end is in sight!  Shooting for [finally] having it up on FGL by end of next week!  (For real this time!)

-Montoli