There's a lot of cool stuff here. Worked on a top down shooter myself a long while back and I'm a fan of them. Definitely going to be keeping my eye on this one. Great job so far!

You're pretty much on the right track. I don't know the perspective, sizes of graphics, or the amount of detail you need, but generally what you do is break the tree into smaller chunks and string it together. Two things that will help you do this:

- Using the origin points in sprite properties. In this case, you would want all of the pieces to have an origin at the bottom center. Say for instance your tree was 32x96, broken into 3 that's three 32x32 chunks, of which the origin should be 16x32.

- Going hand in hand with origins, use lengthdir_x and lengthdir_y to get the proper positions of the tree segments. The first part is the default position of x, y but the next segments all need to be joined using the last segment coordinates and those lengthdir commands.

If you never used any of this stuff before it might be confusing, but it's actually quite simple once you understand it. I could probably make an example fairly quickly if you are having trouble getting to grips with this.

Additionally, this is the very basic way of doing what you want to do. It wouldn't look great, but will put you on the right track to making such a thing. In an ideal system, you'd want a decent amount of segments, possibly variable for differing tree heights, as well as the leaves independent of the actual tree with some inertia to create a more realistic wave (otherwise the tree will appear to be made of steel).

To add to the whole "make the game you want" point, a lot of times what you want to make will change midway through a project. That's because, as also mentioned here, the game probably didn't start with a realistic or simple enough goal, which lead the project to drag on, and now you want to do something else entirely different.

One thing I'd say is that projects should be looked at in terms of doing the best with the time you have instead of making an overall great game. That's to say, if you make a game in a week, it probably won't be anything special in the grand scheme of indie games. The question is, how good is the game for something made in a week? That's what I would focus on.

If you look at something like the concept of Ludum Dare, none of the 48 hour games will typically be spectacular as stand alone games (unless you are a genius), but they are great displays of doing the most with the time they had. Build from that and you'll have no problem working on bigger projects.

Played the newest build. Got a bunch of notes but it's not too organized. I liked the Introduction a lot, but I wasn't exactly sure what to do in the conversation (scenario 3). What does Random Mood do? You could keep clicking it and I was never sure what it was supposed to mean. Here's my notes while playing:

- Thought it was weird how in the first house cinema the fathers body disappeared after tranquilizing.

- After waking up from the house cinema, I saw the mother in the living area but decided to go in her room quick before talking to her. After returning, she was gone from the living room and I couldn't see her again. This might have made sense because the room seems cleaned up after that, but throwing it out there in case it's some sort of bug.

- When buying an selling, the menus change automatically when you press left and right, but this is not the same behaviour in the start menu. Is there any reason why? I know that the start menu works a bit differently in that it has more menus and those menus have sub menus, but this is the one thing that makes the start menu feel off because you need to click to even see that segment of the menu. I imagine it would be quite a lot of work to rework the start menu to work differently, but it just doesn't feel right to me.

- When in the bedroom of the third scenario, I opted to skip the cinema and I was put into gameplay. Meaning, I could actually play the game beyond the point you limit the player in the demo (see the docks, explore town, and more). Obviously, there was not a lot to do after that point and this is probably something you didn't intend. The same applies for Corvallis and Angela, skipping the last cinema allows you to play still.

- Some of the doors in hourse are not as apparent. Corvallis' Dad's room is one example, and so is the INSTEC Lab No 1 room. You obviously know where the Lab Room is because you exit it near the start, but things like the Dad's room are hard to see. You do have depressions in the tileset to show these, but it's easy to forget this. Not really sure what you can do about this, it's just strange.

- When I talked to Thomas, I went through the table. When I tried to reload, I got this:

ERROR in
action number 1
of  Step Event
for object objTeleport:

In script scrCheckIncomingDir:
Error in code at line 7:
  
    if(lastStepX != x && lastStepY != y)
          ^
at position 9: Unknown variable lastStepX

Had this happen with the guy sitting at Mouth Wreckers and Sarah too. Most of the guys in that area, really. Every time this happened, the game would throw that same error when I tried to load through the menu and I had to quit.

- When I tried to load the game through the start menu, I picked the 3rd save but it loaded the 2nd save. The main menu seemed to work fine in this regard.

- After fighting a Wolf, Corvallis stopped following me, but as Corvallis Angela would follow. Could this be because Corvallis had less than 50% HP? It seemed to fix itself when I went to an inn.

- When I got to the Rabbit (first fight), he ran across the bridge and I couldn't fight him. Had to restart.

- Great idea on the treasure chests. I think I complimented you on this a long time ago when I was playing a super early build, but it's worth restating!

- The title screen music gets really great later on (2 minute mark?). Never would have noticed it if I wasn't taking these notes.

- It felt strange being graded on how my conversation (scenario 3) went in such a statistical manner. You can generally tell how good or bad the conversation is going while it's happening, and having some dialog at the end of the conversation to suggest your performance would work just as good I think (ie. the characters criticise each other / say it went smoothly / some kind of remark). In all reality I don't think most people playing would notice or care about this at all, but looking at it from a design perspective this struck me as odd.

- Good job on the cinemas. They're not spectacular in terms of CLOSE UP HIGH DETAIL shots or super animations, but you move the characters around a lot and clearly put a lot of effort into making them more enganging. This is something I see neglected a lot in other indie cinemas, where two dudes will stand next to each other and never move while talking (I'm guilty of this myself!)

EDIT: Oh, and one last thing. Awesome job on fixing all the bugs in the previous version. I did not encounter any of those and there's a lot of small improvements too.

It looks like I put the wrong directory. Should have tested it before posting. Here is the fixed link:

http://gzstorm.com/gmhelp/Hats.gmk

Is this free / the full version? By all indications it looks like it is. What's a little confusing to me is that I remember playing the flash version a while back and you could pay for updates or something to that effect.

Either way, I enjoyed the flash game and going to check out the HD version regardless. Great job with the game.

This is looking really cool. Great graphics and character design as usual in your games. I played the demo for a bit and things are already shaping up.

Check out this example I made:

http://gzstorm.com/gmhelp/Hats.gmk

The method I used is reasonably optimized and uses a more advanced method of doing things, but accomplishes what you are aiming for. The code is lightly commented.

In brief, I grow the collision box using the image_xscale variable and detect the hat by getting the plane of the hat (vertical or horizontal) and comparing it to my bullet coordinate (controlled by the mouse).

Yes. Would any of my games get accepted? Probobly not. So I'm looking at alternatives.

Good point, I hadn't noticed they had a filtering process. Mochi Coins and GamerSafe are the only two I know of. It looks like GamerSafe does not use filtering, but this is just my basic observation:

https://www.gamersafe.com

I'm not a flash developer, but I've heard these pop up during discussions about this kind of thing. Beyond that an experienced flash developer would know more than me.

I'd like a tutorial possibly showing how to do these things:

1. Placing a working donate paypal button in a Flixel game.
2. Some system for whenever the player has actually donated, (not clicked button) give the player some sort of credits.

Thanks!

Have you looked into Mochi Coins?

http://www.mochimedia.com/developers/coins.html

I'd say it's generally unnecessary to do something like this from scratch because I'm fairly certain there's a few services where player cash can be converted into virtual monies, this being one of them.

This sounds really odd. Why do you want this behavior? Can you explain what you're trying to do? I have a feeling you may be approaching the problem the wrong way because this is something I've never heard anyone need.

If you absolutely need to do this, you can simply calculate the origin effected coordinates yourself. So what you would do is set the origin to 0, 0 and scale and rotate it as normal. Then you just need to draw it at the origin calculated coordinates. Two functions I use myself are (adaptations of what I use in Game Maker):

public static double lengthdir_x(double len, double dir) { return Math.Sin(dir) * len; }
public static double lengthdir_y(double len, double dir) { return Math.Cos(dir) * len; }

So basically what you'd do is something like:

drawX = x + lengthdir_x(45.25, (Math.PI / 180) * 225);
drawY = y + lengthdir_y(45.25, (Math.PI / 180) * 225);

Further explanation:

45.25 = The distance to the coordinate 32, 32, the origin I use in this example. You'd need this to be the distance to the origin you want to use.

(Math.PI / 180) * 225 = This is a radian to degree conversion, and 225 points left-up, the opposite direction of 0, 0 to 32, 32 which is what you need to draw at the origin 32, 32.

You could also make functions to calculate distance and direction to a point to make things easier, but this is just a hard coded example so you can see how you'd go about doing what you want.

There's a number of ways you can do this. Two ideas off the top of my head:

1. Use path_get_length() on the calculated path to get how long it is. Get the distance you want your guy to travel (ie. 128 pixels). Do movement maximum / path_get_length() and don't allow the path_position value to exceed what that number is. Once it does, end the path.

2. Set some variables to count the moment your path starts. Let's say you just assigned the path to your enemy and you only want your enemy to move 128 pixels (on a 32x32 grid, that's 4 spaces). Set a value to 128, then decrease the path speed your guy moves at. So if you assigned the path to move at a speed of 4, reduce 4 from the tracking variable and when it reaches 0, stop the path.

On both of these methods you'll want to snap to the grid after the character is done moving. This is because the movement can exceed it's position by a few pixels on speeds that are not divisors of 32.

I'm sure there are other ways to do this, these are just two ideas.

I think IF needs to modernize and become a little more mainstream. Mentioned earlier, I think efforts like Digital: A Love Story are steps in the right direction and I think very few gamers these days are willing to work with interpreters. Something as simple as a map, very light graphics to accompany text (ie. low res / detail character portraits, item graphics when applicable), shortcuts to commands, sound effects, and anything else to make the game more accessible is what I'd like to see. I've looked into doing IF on the XBOX and this is a basic example of a slightly expanded approach (map, command shortcuts, sounds):

http://gzstorm.com/screen/papamock_30.png

Obviously there will be drawbacks to some features compared to classic IF, but as designers we can find ways to make up for this. I also think IF attracts a lot of people who are only writers, for obvious reasons, but I think a little graphics and programming knowledge could take them a long way to making more accessible games that still tell a great story.

I feel like I'm missing something here, because no one has mentioned the built-in GM system for path finding. In fact, there are multiple!

If you want to implement path finding the quickest way possible, check out the Motion Planning segment of the GM help file. In particular, there is an A* implementation that is fast and easy to work with:

The actual functions for the grid-based approach are as follows:


mp_grid_create(left,top,hcells,vcells,cellwidth,cellheight) This function creates the grid. It returns an index that must be used in all other calls. You can create and maintain multiple grid structures at the same moment. left and top indicate the position of the top-left corner of the grid. hcells and vcells indicate the number of horizontal and vertical cells. Finally cellwidth and cellheight indicate the size of the cells.
mp_grid_destroy(id) Destroys the indicated grid structure and frees its memory. Don't forget to call this if you don't need the structure anymore.
mp_grid_clear_all(id) Mark all cells in the grid to be free.
mp_grid_clear_cell(id,h,v) Clears the indicated cell. Cell 0,0 is the top left cell.
mp_grid_clear_rectangle(id,left,top,right,bottom) Clears all cells that intersect the indicated rectangle (in room coordinates).
mp_grid_add_cell(id,h,v) Marks the indicated cell as being forbidden. Cell 0,0 is the top left cell.
mp_grid_add_rectangle(id,left,top,right,bottom) Marks all cells that intersect the indicated rectangle as being forbidden.
mp_grid_add_instances(id,obj,prec) Marks all cells that intersect an instance of the indicated object as being forbidden. You can also use an individual instance by making obj the id of the instance. Also you can use the keyword all to indicate all instances of all objects. prec indicates whether precise collision checking must be used (will only work if precise checking is enabled for the sprite used by the instance).
mp_grid_path(id,path,xstart,ystart,xgoal,ygoal,allowdiag) Computes a path through the grid. path must indicate an existing path that will be replaced by the computer path. xstart and ystart indicate the start of the path and xgoal and ygoal the goal. allowdiag indicates whether diagonal moves are allowed instead of just horizontal or vertical. The function returns whether it succeeded in finding a path. (Note that the path is independent of the current instance; It is a path through the g rid, not a path for a specific instance.)
mp_grid_draw(id) This function draws the grid with green cells being free and red cells being forbidden. This function is slow and only provided as a debug tool.

It's simple, choose a grid size that suits your graphic tiling, create a grid the size of your playing area, and remove cells that intersect with solid objects (use parent objects to simplify this).

There's only one drawback in my mind and it's something that can't really be managed in a better way because of how GM works. Basically, all paths are returned as an actual path resource. This means you may need to change the way your characters animate or do certain things. Beyond that, it works well and I've yet to have problems using it myself.

Just posting to say that the game is looking really solid so far and is doing a good job of differentiating itself from the slew of other voxel based games out there.