Tuesday, December 31, 2013

Real-Time re-rendering plasma-glow

This is what I did this new years instead of party. While somewhat lonely, I think this is the mark of a prosperous year.

What is it all about?

I've been thinking about what Matthew Griebner 
said a while ago about, "What is our game about?"

There are some things I've realized 
I've known it was about, but never 
really explicitly said.

Beyond Exploding bombs. 
The game is about PREDICTABLE chain reactions.

I was taking a look at the game "escape goat" 
which I just purchased off of steam. 
I was told it was a lot like our project.

Except one big difference that sets us apart 
is that it is possible to visualize what will 
happen before it happens. If I do add any other 
features related to mechanics, they will fall 
within this rule.

What else?

Right now I am still working on lighting.
Tyler Woods and some others brought up that the 
light fixtures do not look like light fixtures. 
They do now. After a week of coding up in a cabin 
with no internet access, I finally fixed a lighting 
module that I am using for "White Hot" glowing effects.

Because of the optimizations I've painstakenly made, 
this extra "ooh shiny shiny" will not slow down the game.

Note: In case my spaztic mind forgets:
Bound Function:
var isGoodTimeToReRender:Function. Returns Boolean.
Also, flag, "isInNeedOfReRender:Boolean" checked before calling
function. As function calls are slower than checking Booleans.

I am still not yet happy with the lighting. 
I want it dramatic and very noticable,
yet at the same time, I do not want it to interfere 
(unintentionally) with people figuring out the 
layout of the current level.

Last note, I need to visit Tyler as he showed up for a meeting 
that I organized, that I ended up showing to late. 
I am sorry about that. I'll take the time to make that up to you.

Tuesday, December 17, 2013

Using Deviant Art as a marketing tool

I have decided to put up an animated GIF of every single level of my game before it is released.
How popular a given animated GIF becomes on deviant-art will let me know how much visual impact a designed level has.
The GIFs with the most views will make it into the game.

All levels will be given a "level name" / "room name"
We will name our submission on deviant-art with that "level name".

Not only will deviant-art submissions help improve the visual impact of the game, it will also help build hype for the game.

Friday, December 13, 2013

Directional Bomb Animation Indicators

Today: I did everything on my checklist:
1. Hard Reset (Keep original full file path along with the level in order to hard reset)
   This makes it so my level designer can edit levels while being played.
2. Watermark. More classy for "let's play"
   Game is almost ready for a let's play... But I need to fix up all the levels I botched
   since the last time I released the game now.
3. Animated runway light bomb mockup.
   Bombs now have animations that give a clue to their directionality.
4. Some game-design doc literature.
   Working on game design docs for the level editor pipeline.
   This way my level designer wont need to always ask me what does what.
   But, of course, I will offer my assistance if needed.

1. Fixed a glitch in my invisible tile collision that was causing invisible tiles to be auto-tiled.
2. Looked up lectures on S.C.R.U.M.

Here is a screen shot:
1. I should have a sample-level on my deviant-art. One sample level showing off some improvement I have made to the game.
2. Ted Talk that basically said there are only lame jobs, or great jobs. There are no good jobs.
   I want to apply this mindset to making a successful video game.
   Either your success is lame, or great. But no gradient in-between.
   This game will not be released until I feel it is polished to an acceptable level.

Sunday, December 8, 2013

Re-writing an old gallery slide-show class

I ran into some glitches with some old code I wrote.
I am going to re-write the class.
But instead of making a version that is "hand-tweened" (which makes it easy to pause in place by simply not calling the update() method)
I am going to build it on top of GreenSock's TweenMax engine.

Here are my notes:
I had a hard time figuring out what I was going to do, so I wrote down different ideas for how to code it till I hit
something that made a lot of sense and wasn't too abstract.

I'd say a good use of my time, as I am too tired to program. Yet not tired enough to sleep.

Though I really should do this more often. Taking the time to think about what you are going to program, instead of programming
right away, can be very valuable. And this is coming from someone who is a "straight ahead" coder.
I usually code as I think.

new conveyer code design:

//Diagram of conveyer with 3 items in it that are all on screen at the same time.
//[p] stands for portal. if animating left-to-right,
// v2 will smoothly animate to [p1], then TELEPORT directly to [p0], then continue to animate to old position
// of [v0];

//how do you handle tweening it, but stitching it back together gracefully?
//idea1: Programmer "trip itineraries" for each object.
//       Problem: Seems unecessarily abstract and complex.
//idea2: Animate [p1] to [p2] travel, but make the object being animated .visible==false.
         Problem: leaves spot [v0] empty.
//idea3: Helper Object manages it's own "flight" to a destination.
         The main class it belongs to just changes the destination. But the helper is responsible for the details.
//idea4: Each static "check-point" has a "prev" and "next variable.
//       in addition to this, each check-point has a "youCanStayHere" variable.
//       [p0] and [p1], as points OFF the screen, have "youCanStayHere == false".
//       in addition to this:
//       if(youCanStayHere==false, but .next == null,
//       then we are on [p1] moving forward. Teleport object at [p1] to [p0];
//       CONVERSLY:
//       if(youCanStayHere==false, but .prev == null,
//       then we are on [p0] moving BACKWARDS. Teleport to object at [p0] to [p1];

/** Value from negative INF to positive INF that represents shifting the array of points forward or backwards. **/
var _arrayShiftOffset:int; 

/** A vector of the points we are targeting. We want to CENTER display objects on these points. **/
var _staticTargetPointVector:vector.;

var _helperHolderSpriteVector:Vector.;

Saturday, December 7, 2013

UI Work. Refactoring years old code.


When I first started learning flash, I made these two classes. Which now I can use to make
a menu where the selection items scroll into and out of place.

They will require some refactoring, and some hunting down, as my old code base is disorganized.
I basically scrapped my old code base and only use things from my old code base on a need-to-have basis.

Using anything from my old code-base requires me re-factoring the version in my old code base and
putting the refactored copy in my NEW code base.

By refactor I mean:
1. Give the class a more descriptive name.
2. Place the class in package/location that makes sense.
3. Add comments to code. (Its been over a year later, if you read over your code while refactoring and go "WTF is this for?" Then you need to add a comment and possibly refactor your statements.

Right now, I am working on adding a difficulty select menu to my game.
I've already mapped out the menu layout, now I need to code it.

Tuesday, December 3, 2013

sonic smash

Idea for new power:
When you hold down in air, you can smash through the floor tiles.

Upgrade: Shock waves.
When you smash down on the ground, you emit shock waves that will break blocks in the vicinity.

Maybe the shock wave goes straight down. Maybe the shock wave is circular around your body.

Shock wave would NOT kill the green and blue angle tiles.
The isBashable rules would still apply to the shock wave.

But, you could pound down on a non-bashable blue floor, and your shockwave could break bricks below that blue floor
if the bricks under the blue floor are bashable.

Add crouching fixes to emulatable sprite to make it easier to fall down holes that are 1 tile big.
Level design to make you learn you can do this?

[     ]
[     ]
--------------------------- Platforms only. Must crouch. (You know how to crouch by now )

[ ]-[ ]-[ ]-[ ]-[ ]-[ ]-    Alternating platforms and blocks. Making you press crouch instinctively to go through.

[ ] [ ] [ ] [ ] [ ] [ ]     Alternating empty-space and blocks. Maybe you'll try crouching to get through now.

THEN, the level will have some time based thing where if you have not learned to crouch through holes, you will not survive.

Beta Tester FeedBack

Today I added 5 Beta Testers to Newgrounds to test my game. I got a lot of feedback.
Also. I just played "Tiny Dangerous Dungeons" on newgrounds...

I am thinking I need to incorporate some type of upgrade element to my game design...
My Thought:

Possible powerups:
1. Brick bashing with head. (Helmet Accessory)
2. Smashing bricks with feet. (Steel Boots) Maybe jump land SFX changes when you get upgrade?
3. Smashing charge (Break bricks on side)  (Steel Shoulders Accessory)
4. Invulnerability shield to a certain color of bomb?
5. Maybe incorporate the flare boxes into puzzles???

What am I currently working on at this very moment?
Support for easy,puzzle-hard, twitch-hard, and hell-hard level versions.
I want 50 of each type, for a total of 200 levels... That's a lot of levels.
If I spend 30 minutes per level... 100 hours.. Oh my. I want them all done in less than a weeks time.
I will tweak them after.

I may need to write a level categorization tool that creates a .JSON file to categorize my levels.
As renaming levels to re-order them could become quite a pain...

Before I start making more levels... It might be wise to plot out the flow of what I want to be learned when.
Because the story arch of all difficulty modes must be parallel if I want the dynamic difficulty adjustment
I have in mind to work..

Oh another thing. Implementing the collection of coins to in a level could help me gauge how good a player is.
If a player gets 100% of the coins in a level, I kick up the difficulty one level.
If the player gets ANY COINS but not all, I keep the difficulty where it is at.
If the player gets NO COINS, the difficulty is dropped.

How do I encourage people to collect the coins?
Because I like challenging levels.. But I am not one for coin collecting in games. 
I personally don't like it.

So... As a player.... I would get demoted to easy, unchallenging levels unfairly...

Hmm... Also have a time benchmark. If they dont collect any coins, but hit your time benchmark,
Then increase the difficulty. If they hit the time-failure lowmark, then decrease the difficulty.
But only if they have not collected all the coins...

Hmm... I will have to think over how to balance the coin metric and the time metric.
But I've got a good decent concept right now. I'll get to figuring that out when I have needed things programmed.

Anyways, here is the feedback I got. Post it here so I don't lose the message on newgrounds:

Overall, I'm pleasantly surprised at this game and I think this would be a well-received game once you're completely finished. I know the cons section looks kind of long but that's just because I explained the criticisms. ^^ Because I think this game has more positive than negative points going for it.
- Nice graphics & soundtrack. Its a very nice looking and sounding game. Also the game flows really well, no lagging at all. And the bomb blasts are cool looking.
- Really fluid motion/controls. The character is very easy to control and I had no problems with making him move.
- Unique game/gameplay. It doesn't feel like a game I've played a hundred times before.
- I didn't run into any potential glitches (that I know of) so the game seems very well-designed.
- Fun! I really like the direction this game is going, I pretty much sat and played through all of the levels in one sitting.
- I liked the fact that there were so many levels and didn't stop at a lower number. I think if you added more it wouldn't hurt either but if you decide to keep it at 40 I think that would be just fine.
- I feel really slow on the uptake considering the game is called 'MakeChoice' and I didn't realize this until playing through the first few levels again, but I like the fact that there seems to be more than one way to clear the levels, or that only one choice is the right answer. That's a neat feature.
- Lack of 'how to play' or 'controls' screen. It was easy to figure out what to do as you only needed the arrow keys, but I can see some really picky people complain about that. I know you probably will put this in the final product but I felt like mentioning it. I didn't know that the character could break blocks by jumping until around level 10 so that could be something to add to a pre-game explanation. Also it'd be nice to maybe explain the bomb types. I noticed that each bomb exploded differently and some could even be triggered by touching them, and that determined the order I would set them off in order to complete the level.
- Some levels seemed REALLY easy even after I cleared more than half the levels. The difficulty levels weren't really consistent. One level would be moderately challenging and the next would be a cake-walk. Maybe change the order of the levels around and make them get gradually tougher. If you make tougher levels then maybe you could implement an auto-save feature so people could come back to it later.
- The flashing/shaking when bombs go off can be a little disorienting in some levels. I actually like this effect, but sometimes there is some rapid flashing that I think you should at least mention in the description. I think toning it down is up to you.
I think my biggest nitpick about the game is the inconsistency in the difficulty between each level. It's still fun to play and I enjoyed it so I think if you do this it'd make the game more solid. Hoped this helped and thanks for giving me the opportunity to try out your game! Good luck with the rest. If you still need anymore feedback or have any questions let me know!

Alright. I had to check out some NG stuff to figure out how to access the beta area. Once playing the game, I found no serious bugs or anything that made the game unplayable, aggravating, or generally seem unprofessional. Some solid work indeed on the programming side of things.
Here's a list of smaller notes I took while playing the game. I feel some of these test the boundary between "player giving feedback" and "backseat developing", especially since a lot of my review process is mechanics based and is based on some stuff like "what would I do in their position". Feel free to ignore, think about, or consider these as you see fit, but this is just stuff that came to mind. A lot of these things also revolve around the idea that at its core, flash does things very abruptly and mechanically, and experienced NG'ers tend to spot this and feel like the experience is lacking a manner of polish. A few things in the game seemed to give me this vibe, but please don't take it personally.
-Level 16 feels copied directly from 15, too little change, could definitely be intentional as many puzzle games do this.
-Clarity is low, especially in explaining or diagramming the way various bits interact, although some learning along the way is good.
-Most of the UI transitions seem very quick and choppy, or a better way to put it: overly logical. It seems when I see really dynamic effects done for lighting or flare they seem more thrilling and "polished" due to their lack of predictability.
-I think I'm seeing the player rectangle keep moving a split second after level ends over the black background. Feels quirky.
-Retry screens posted after failure seem more instantaneous and less blended, in addition to reading "next level: (level number)" makes it feel more like resuming from a set point in time than retrying the same point in game.
-The solidity of the giant buttons seems questionable in the scheme of physics. The way they occlude player movement, overlap with geometry, and a few other points make them seem slightly inconsistent with their tangibility.
-31 seems very similar to 30, once again can be rather intentional, as many puzzle games do this.
-Players can run over gaps quite easily. This is sometimes used to their advantage and sometimes to disadvantage, as intentionally squeezing into a one block gap can prove a bit tedious. This could be done intentionally or it could be something worth tweaking, like say making an option/ability to "walk" or slow down to make the process easier; just pitching ideas.
-SFX Turning off does not include the sound of the player jumping.
-Not sure what's going on with keys, there are 2 distinct banners on either side that seem to say "BLAS" but then seem cut off. I could very possibly be misinterpreting.
-The lack of on-sreen text for anything such as hints, level descriptors, or certain menus seems somewhat ambiguous. A miniature text prompt or line area would seem to increase clarity and user friendliness as it is very familiar.
-Player sprite seems oddly low-definition compared to the sprites of the surrounding terrain.
-Soundtrack felt a bit linear, but definitely supplied to a full-spectrum "rave" feel when combined with the colors, flashing lights, and general ambiance of the game.
Overall I would review this one in at 7/10 and probably (although it feels very borderline decision) 3/5. It kept me interested, playing, and thinking a bit... but failed to supply "wow" or intense "fun". I think if this was polished over a bit more and decreased in the choppiness I felt, I would be inclined to rate this an 8 and 4 accordingly. You did also explicitly mention that this is one of many testing various mechanics, so considering the role I think it accomplished that quite wonderfully.
Hope this helps, and hope the game is received well upon release. If you make any considerable changes I would be more than happy to re-analyze this and supply fresher feedback. ~WCCC