So OK, first thing to note is that you shouldn't write Constructors for your Unity components. They aren't called when you think they are and just generally don't do what you want. If you think you want to use a Constructor (for example because you're having trouble with the ordering of Awake() calls) you're still probably wrong. I'd strongly recommend getting out of the habit.

With that said, you do make clear you've tried using Awake, so the Constructor may not be the source of your problems.

What I'd recommend is adding Debug.Log lines at the end of your function which print the values of the fields you've tried to assign. I'd bet good money that either these lines are never reached or they print correctly assigned values. Whatever your problem is, it's not here.

I haven't reviewed the code in detail, but I suspect you're getting a false positive here.

The reason the presence of FollowPath() causes the crash is, I suspect, because that's the only way for reached_dest to be set to true. If so, it isn't really this function that contains the problem, it's just that you were narrowing down the cause in an overly simplistic way.

As far as I can see you never perform any operations on closed_list itself which even have the potential to throw errors. As such, I think the first step should be to do as quantumpotato initially suggested and attempt to obtain a stack trace. Make sure "Error Pause" is selected in the Editor (it's a tab on the Console panel). If necessary put try...catch blocks around things for debugging purposes. If even that doesn't work, try adding some assertions in code to make sure things aren't null and have sensible values, etc.

I don't have ADHD, but my memory is terrible. Having been a programmer for over 30 years now I've never once memorised even a significant fraction of any language. (At least not if one includes libraries. Writing assembler on the Acorn Archimedes I knew the whole instruction set... all 16 operations!)

It just isn't an obstacle at all. What matters is having a sense of roughly what's possible. Then when you want to (eg.) play an audio clip you can search for the necessary APIs and some example code and start from there.

Looks like that section isn't being rendered at all. There are lots of possible reasons. A good way to debug the problem is to separate the question of what the camera's seeing from the render-to-texture process. Run the program in the editor and use (a copy of) your render-to-texture camera to render the screen so that you can see what it's seeing. Set the Clear Flags to "Solid Color" using some colour that doesn't appear in your scene anywhere so you can easily spot sections which aren't getting rendered.

Assuming you followed the submission guidelines they'll send you an email (see point 4 on the list).

Quick warning: Reddit has strict rules against self-promotion. Tread carefully or you'll get banned. TBH that site isn't really a "community" anyway. Small subreddits can be, but because they're small they're not getting you much. The big ones that get you serious traffic care mostly about funny GIFs. If your game has cows with rocket launchers then maybe it can help, but otherwise...

My recommendation would be to start with C# and Unity.

Two reasons:

1) C# isn't some narrow, special-purpose tool, it's a pretty good example of what modern programming languages look like and how they work.
2) Unity lets you get to the interesting stuff quickly without months of engine work and/or configuration and works fairly similarly for both desktop and mobile deployment.

The first thing to ask yourself might be: Does open-sourcing a game significantly increase piracy?

I think the answer might well be that it doesn't. For very popular games pirate copies are easily obtained. For less popular games, only a tiny fraction of your potential players will even be aware the source has been published and most of those will be principled enough to pay for the game if they plan to play it.

Also, the open sourcing itself might be newsworthy, which could generate additional sales.

generate hype or interest

Indeed not, but if you look at the analytics no games "generate hype" in a way that translates to Greenlight votes. That implies people linking to the page virally and I literally can't think of a single game on Greenlight that's happened to.

(Interest levels seem fine from people who've actually got as far as watching the videos. It's getting them that far which is the problem.)

And for devs here. As long as you're having a "solid" "worth money" project, your project will be greenlit even it takes +1 month.

That hasn't been my experience so far. Got a lot of upvotes (and a decent "yes" rate) when my game's page first went up, but after a few days the traffic dropped to zero and stayed there.

Now obviously I can get more votes by other means, but so far the traffic I've generated myself has been far too small to ever get the game Greenlit, so unless I can get press to link to it (failed so far - apparently they prefer covering Steam launches) it's going to take a lot longer than a few months to get through.

Whilst I sort of agree with ghosted's answer, there's some really good stuff on maze generation here (scroll down to "Maze Creation Algorithms"): Maze Classification and Algorithms

Somewhat mystified about how the press side of things is supposed to work. King Machine went up on Greenlight three days ago (http://steamcommunity.com/sharedfiles/filedetails/?id=646326910) and although I only contacted about 50 press/YouTubers/streamers I was a bit surprised to get zero coverage and zero replies.

The problem really is the complete lack of feedback. I followed the advice of various guides, included links to all useful resources (itch.io page with demo, code for full version from itch.io, trailer on YouTube, game homepage with presskit() etc.). And presumably I got something wrong, but what? I would assume that the trailer wasn't good enough, except that the Greenlight users seem to like it. Was getting votes pretty fast until it dropped off the Greenlight front page.

Useful thread, thanks for taking the time to post it.

I'm just setting up the Greenlight page for King Machine (the game I'm been working on for approximately forever). The way Greenlight's launch/front page momentum works is basically the exact opposite of what I want. I'm pretty confident the game has an audience, but not a huge one, so getting the word out fast enough is going to be tricky.

Emails to press are for next week, though. Now I'm off to make my page look prettier with your handy image tag tip.

How easy this is to fix depends on whether you need to support multiple sizes of sprite and whether your map has places which are passable to some sizes but not others.

If you only have one size of sprite then your basic problem is that your navmesh is wrong in the sense that it doesn't reflect the places the character can actually go. The fixes qMopey suggests will work, or it might be easier to just fix the mesh, depending on how you generated it.

If you need multiple sizes then the problem is you need a different mesh for each. However, if there are no narrow passages (passable only to smaller sprites) you can hack around this requirement by generating the mesh for the largest size of sprite and then letting smaller sprites take shortcuts if they can "see" their destination node early.

Very true. OOP and Components are not competing concepts.

Unity being both object oriented and component-based, I've been working using both together for some years now. It can be quite powerful, but there are a few traps for the unwary.

One mistake I've made several times now is to break up a class into multiple components simply because I can. Why this can be bad is that you end up with a lot of clutter to handle:

* Caching pointers to all the different components on an object to avoid lots of GetComponent calls.
* Lots of "if (<this component exists on this object>) {...}" checks.
* Serializing objects (eg. for a save system) can get messy and complicated if components reference each other.

Another trap is making lots of objects into entities (or "things") just because you need an instance of something that happens to be a component. Often such objects shouldn't have been components in the first place.

A good exercise to start with is writing a (tile based) maze generator.

Step 1: Any arrangement of walls that doesn't leave unreachable empty tiles is OK.
Step 2: Output mazes must be non-trivial in the sense that exploring randomly won't get you out easily.
Step 3: Start thinking about what makes mazes interesting to solve and output only good ones!

It's a good exercise because it gets you thinking in terms of procedural content not just in terms of structured randomness (like Perlin noise) but also in terms of smart algorithms that produce interesting output.

Do you have Unity Pro? If so (and assuming I'm understanding you correctly) you could do this with a Render Texture: http://docs.unity3d.com/Manual/class-RenderTexture.html

The idea would be to have the render texture larger than the screen, have a camera following the player's character around, but then scroll the render texture to put the rendered character back in the centre of the player's screen.

I think you'd need a texture roughly twice the size of the screen in each dimension to make all positions possible.

<applause>

That's awesome!

[isTrigger = true]

There's some very odd advice in this thread...

Unity's 3D collision system is event based. What this means is that instead of asking whether two objects are overlapping as you would in FlashPunk you instead add one or more of these methods to a script component on the GameObject you want to test collisions for. (It must have a Collider component.)

Code:

OnCollisionEnter(myCollision:Collision) { ... }
 OnCollisionStay(myCollision:Collision) { ... }
 OnCollisionExit(myCollision:Collision) { ... }

Try to avoid using OnCollisionStay unless you really need it, because it generates an awful lot of calls in a busy scene, which may hurt performance.

If you don't want Unity itself to apply forces when things collide then you can set isTrigger = true on the Collider. You then have to use a different set of methods to receive the events:

Code:

OnTriggerEnter(myCollision:Collision) { ... }
 OnTriggerStay(myCollision:Collision) { ... }
 OnTriggerExit(myCollision:Collision) { ... }

With all six of these methods it's perfectly possible to hack things to work more like Flashpunk by setting a flag when a collision occurs and clearing it in FixedUpdate() each physics cycle. However, that's not usually the best way to do things. I'd recommend learning to work with event callbacks directly. Even if you ultimately decide it's not right for your game, at least you're then making an informed decision.

Ray-based collisions can be useful for some cases, but it tends to result in very hacky, approximate 3D collisions, which is fine for some games but not others.

There is an additive shader here: http://pastebin.com/xCw0i6f3

(Not my work, it's by PurulentExudate on Reddit.)