I'm saying for the standard squished diamond isometric shape, which does require a half-height grid to snap properly. Here's a CAP showing what I'm talking about:

Diamond Isometric Grid

Somehow I didn't see this when I posted earlier. Nice example, guess there's really no need for changes in the grid system.

Then adding more options to grid edits would solve that problem? Maybe adding an option to "rotate" the grid and whatnot.

[quote:2ya97dku]Now as to the 3d box model, dunno this might be the simplest, and most efficient way to get an iso type of game, especially when talking z order like karlmagus was talking about, and getting different heights on the map, like in the tactics types of games where landscapes themselves had a z order.

Yep, what I did back there with Game Maker 5 was an isometric system that worked pretty much like a "tactics" game.

There was a small ramp that I used for testing, the goal was to use the ramp to gain height and get to the top floor, the idea was that I could put an object inside the grid like I would normally do common 2D games, but it would have some 3D values, that way I would not need to worry with "warping" collision boxes that much when building a complex map. So I used a warped isometric grid as reference for depth values and attached height values to objects that were supposed to work like a second floor. The ramp was a height modifier that used the depth to adjust it so I could get a character to said second floor.

As a side note, I think it would be nice to have the option to choose between perspective and isometric in the plugin.

Back when I used Game Maker 5, I built a small isometric game using the same model I used for another small "beat'em up" fighting game (like Final Fight or Streets of Rage). Basically I used grids like you suggested and on each object I defined a Depth variable that would gain or lose value depending on it's position related to each grid box.

An example: if a game object moved up the grid it would gain depth value and downwards it loses value, but on the isometric "engine" the trick part was to place the collision boxes in a realistic way, so If there was an isometric bush above the isometric character, but the character was taller than the bush, then the collision box proportion would have to be adjusted for each.

I'm still getting the hang of Construct, but I'll see If I can make this example with it.

EDIT: I know this thread is not about how it can be done, but more in the sense of having this feature integrated in Construct. Perhaps if we find the best/simpler way to achieve it, it will make it easier to create the functions for it.

That's true, a donation should not even implicitly be for anything in return - a chipin style system is more of a collaborative payment for a service rather than a simple donation in the true sense of the word (ie, not expecting anything whatsoever in return). If people expect a certain feature to be finished or worked on after contributing to a fund, that's not a donation, it's a payment, because naturally the contributor would expect to see some kind of result.

I'm not totally shooting down the idea; I think it's worth bearing in mind, but maybe to overcome this donations/payment split, it could be hosted on a different site as a more commercially oriented project. Then there would be no confusion whatsoever as to which is which.

The idea is that you have an alternative that is true to the collaborative spirit of open source when it comes to get paid for your work.

Choosing whether or not to split from the main project is just an option. I can see it working independently from this site, I just don't know how it would be better. Say you wish to gather funds to pay for your time working on a Linux port or whatever that is related to the main project, how could you do that in a way that would really detach you from the main project? Somehow I can't see that happening, nor if it did happen that it would be better than being an option within the site. You're not shutting down the main project, you're just giving the option to get paid for your extra work in some related programming, I fail to see how that can be bad for the project.

Let me elaborate on that: So you have a project that you mostly maintain it on your free time because it is in fact your "free" time. Now say you wish to dedicate a larger portion of your time to it, but it would obviously affect your life budget. You keep working on the project on your "free" time and gather funds to work on it some more. In the end it's not that simple, but what's really stoping you from trying?

As an observation, I agree 100% that the priority must be the windows port to get to 1.0. I just wanted to point to an option that might come in handy after that.

FYI we're not rolling in donation cash; in the past it has covered things like upgrades to the UI library (which we have to pay for), hosting and the domain name, but we haven't personally pocketed any of it yet. It's nice to cover the project's own costs without us having to pay out of our personal pockets, though, and it's still a nice motivational booster when we do see a donation.

If this statement was towards me, then I should say that it never crossed my mind the chance that you're rolling in donation cash. The principle of a chipin model is to promote incentive of what is lacking to a donation model. In other words, kinda like "Hey I get this really good idea that you might be interested, care to help? But if you don't, it may never be completed." when donations feel like "The project is doing fine but if you spare a change or two it might get better.".

ChipIn probably won't be necessary for the near future - we need to finish the 1.0 Windows branch before we think about any other porting. It's an interesting idea but I think it would have to be dealt with extremely carefully. If done wrong, we could end up looking like a commercial venture or something just for financial benefit of the developers, rather than a public open project.

Most likely not the near future, after all the project got this far without it. You may know that the open source community is filled with paradigms, I know that some or perhaps many might see a chipin model as some sort of treason to it's principles, the same people that will curse you if you ever decide to close the source for lack of time/money to invest in it. In my mind is like choosing the lesser evil. New ideas never lack criticism and protest, once they are in place the early critics often look back and say "Wow, that actually works!".

Selling extra services, asking for donations, doing merchandise works to some extent with larger projects, but not with smaller and medium projects, especially with those related to gaming. Open source gaming might need a new direction to be viable in the future and I believe a chipin model is a step in that direction.

I also think that this project would have a larger user base if it had a Linux port, seeing as how the open source community tends to lean towards it (Linux) for obvious reasons. I might be so bold to say that what the Linux needs right now is a good toolkit for quality games and this project shows a lot of potential towards being it.

Just consider it, discuss this idea with others, try to filter empty criticism and let the critical thinking take place as it should. A healthy discussion will not harm anyone.

How come these threads never start with " I just made a huge donation to the project, and I'd like to share a few things I'd like to see happen."?

I'm not sure what "these threads" you're referring to, but I just found this project, I'm very excited about it but I really wish for a Linux port of it for it to be that much important to me. Like I said I only donate to projects that really help me in a way or another in my life. In time if the project grows on me I'll probably donate a few bucks from time to time.

However with the amount of open source programs I use daily, I have to be very careful with donations, and I really prefer when I direct my money towards something I really want or appreciate, hence the ChipIn model, which gives exactly that feeling to those who contribute.

It'd be cool if we could create a pot where everyone can donate and the guy who actually delivers gets the money - is that model possible using chipin?

It is, though it requires some level of quality administration. For the chipin model to be used as a replacement to a commercial model it must have a very good planning and sometimes touches the very same problems you can find within those. It usually requires a good understanding of your user base and what are their needs, what can be charged and what must be charged. My advice is to take the chipin model with the same seriousness as you would take a commercial one.

I stumbled on it while searching open source game making tools on google (after a very long search).

It still amazes me how good this project is and yet it's so difficult to find it. I was searching for quite some time for an open source game creation tool and none were up to the quality I was looking for. Poor choice of keywords? Perhaps, but I still wonder how many people like me still can't find this project.

I have seen this model working with a very good success rate on content sites and project sites. On open source projects it's still not widely used, but those who use it, usually never touch "closed source" ideas again to fund their projects. If done right this can usually pay for every project cost, including the developers life budget eventually becoming their main source of money, however I would not count on it to be used to pay for Ferrari's.

It's an interesting idea. It raises some questions in my mind though. How would we determine the "cost" of a feature like a Linux port? I guess we could estimate the hours work and the hourly wage, but what if we turn out to be way off the mark? Do we collect the total cost upfront or work as we get funds? What if we start work and donations dry up half way through, do we just give up on the work we've already done or what? What if we collect upfront but then run out of time because we're only spare-time developers and may have other commitments? Will we have angry users who donated but arent getting results as quickly as they wanted?

I can see things potentially getting ugly whichever way we organise this. It needs some careful thought. What do you think?

It really needs some careful thought. Which is why I said that you should discuss with the community which side projects would be worth paying for. It's also a good a idea to try to increase your user base by being active within the internet and open source circles, promoting in a respectful way your project.

You should start with something small and increasing the budget and time of each chipin overtime as you get the feeling of how your user base is reacting to it. Not defining a $1 million chipin on the first try nor something smaller than $500. Also it's up to you to create a policy of refunding a % of each contributor if a ChipIn project goes wrong, this might ease the bad feeling generated by a failed project.

EDIT: The project is Open Source so you don't need to deliver every advanced feature in a month. I'll give the example of a Linux port, it surely requires a great deal of planning and features to be implemented, so the first chipin would cover a "0.1" version of it, with it's short term and long term roadmap explained. You can launch 0.1 version of the port and release it as the chipin is nearing it's completion or choose to keep the progress open for everyone to see and perhaps let them help with the coding. There are many ways to do it, so it's pretty much up to you to find the best one.

I'm new to this forum but I have been using makers for quite some time and I'm really impressed by the amazing quality of Construct. I'm also a huge fan of open-source projects and as much as I wish to donate money to all of them, I have to spare to those I really like and help me in my life.

So, my suggestion is to improve the quality and rate of development of this project while allowing developers to earn some money by replacing the "donation" model for a "chipin" model of development. Here's how it could work: The bulk of the program continues being developed as always, but side features (such as Mac, Linux ports, and other extra) could be listed in a page with ChipIn ( http://www.chipin.com/ ) links and meters to gather funds for their development. The amount required for each side project could be discussed on forums and also their viability before setting up useless or less important side projects ChipIn meters.

The idea could be expanded to the main program later. I believe it's a neat way to keep everything Open Source while adding some incentive for people to help fund the project and other things.

Anyway, if you care to discuss this idea any further feel free to do it, that's why I posted it here.

PS: Btw, I'm really interested in a Linux port of this program, I would gladly pay for it under a "ChipIn" idea to be developed. My suggestion for a Linux port is to use OpenGL for graphics, KDE for GUI and Autopackage ( autopackage.org ) for content distribution.