How a longtime programmer develops in Unity... Me and my unorthodox way

I think there is a lot of potential in such things. At their heart basically a sort of micro rpg / roguelike.

---------------------
On another note.... I hope folks remember this is not a WIP thread about making the greatest SI style game ever. Far from it. This is focused on the dev style I am using.

I could have used solid rectangles for the visuals but thought it'd be good to make a fairly decent attempt and see just how much time it takes.

It would be great if someone else used the more traditional Unity dev approach and created a SI style game from scratch graphics and all see how much time it takes.

Well not just effort and time but more importantly make a thread on it covering how it works and include the full project source.

From the assets I have bought on the store I have the impression that many of the people making templates (and also the folks making articles and videos around the web) are beginners themselves. Which could lead to a case of the "blind leading the blind"

On the other hand, if someone with a lot of game dev experience and maybe at least 4 to 5 years of Unity game dev experience made a Space Invaders style game and released that source I think it would be a huge benefit to many people. Especially if they jacked up the game a bit to include some more stuff maybe something showing how they handle communication between a couple different object and stuff like that. Nothing major.

 

this is how I AI as well. *high five*

 

*highfives*

 

I'd like to see a (sanitized) example of how you guys do it, especially if it's middle-ground between @GarBenjamin's "AK-47 coding" and my "Evil Scientist*" style.

*: The fact that I'm about as evil as Fluttershy notwithstanding.

 

For me:

ACTOR component for what the character can do (pathfind, run, climb, fart, etc)
DRIVER component for driving it - feeds actor inputs

Only the driver needs to change, and the driver code is so small and light that it's ok to have a few, like the one for the player pretty much just announces this is the player and feeds input. In the case of an NPC it will just feed inputs as if it was a player. Same for cutscenes, network, anything really.

A far bigger problem is how you break actor up into small systems and behaviours with the idea it will be fed just inputs and commands. I don't see why AI should be a whole bunch of code that low level, AI should stay as high level as player. This is way less buggy, you don't code multiple things that far down, choices should remain high level.

 

Basic summary.

Vehicle controller has about 3-4 entry points.
SetAcceleration/SetSteering/SetBrakes.

All functions take a value between -1/1 or 0/1

AiDriver code knows this, figures out where its going and uses same functions to drive vehicle. Vehicle has no clue who's driving. Just receives inputs from source (either ai, or keyboard),

The main difference between human/ai, is that human will be full value on, or full value off, where as ai can send any value within range, so it might send 0.5f to steering to only make a half turn. This does require a bit of investigation into limits by the ai driver, but thats a one off check.

 

Despite a tiring day I managed to put some time into the project tonight. The invaders are moving.
Left, Down, Right, Down... oh joy!

Tomorrow, I will update it so when all enemies are inactive on the extreme left or right edges the boundary for movement is adjusted. Then will add enemy firing.

I'd expect by the weekend even working at a very relaxed pace this thing should be ready to post. All depends I suppose on if I do some of the ideas I had. Like occasionally an enemy breaking formation and attacking. Another idea is that when the enemies reach the bottom the game does not end. Instead, the game switches to a Space Harrier type of pseudo-3D stage where you have to battle those remaining enemies.

And thinking about it... I guess I won't do much beyond the basics because it is just not needed. I guess I kind of forgot I am not trying to make a great game. Just throwing together a game to show how I developed it. Big difference.

Yeah I will get focused on knocking it out. Tomorrow. Going to sleep now.

 

Actually that's similar to what I usually do. I tend to end up with "Combatant" class which is controlled by either "PlayerController" or "AiController".

You have "bottom" behavior that handles basic movement and has "controls" exposed. "Walk forward/backward" "strafe left/right", etc. Basically the controls for buttons player can press, pretty much. This class would also handle hitpoints, "in pain", "stun", "death" animations and the like, AND it will play reactions to attacks. I tend to call this one "Combatant".

Then you add two more classes that send commands to the that "Combatant" and implement high level control. ONe class will be "Player controller", another one will be "AiController". Ai controller will need sensors/etc, but both classes will be pretty much pressing buttons on "Combatant".

 

Yeah, I follow that "mostly same components, apart from input/AI controller" pattern too. Turn-based goes without a per-unit "brain", but keep the movement components.

I prefer to call the individual actors "Actor" or "Unit", depending on what sort of game it is. Still pretty much the same structure either way. Real-time or not doesn't really matter. RT is just turn-based with shorter turns and no pause.

 

You mean create it and post to this thread, or start a new thread for it? Better the second option, right?

All these people speaking "Actor" and "driver/input/controller", and I'm here thinking "nah, can be simpler than that"

So I think I'll work on it later, to see what you guys think.

 

Yeah in it's own thread. Kind of be like examples of different ways to develop in Unity.

Well I can understand the desire to use an Actor and then a separate behavior specific Driver, etc. I used to like things like that too. It's fun engineering little systems. So I am not knocking it just more like what you said... testing using a more straightforward approach. Basically I am wondering if spending so much time on engineering was more because I enjoyed it than it actually being necessary. So looking at it like it may be a solid opportunity to "cut the fat". Been using this more straightforward approach the past few months and so far I do like it a lot.

Interestingly, that FPS Adventure I put up on GameJolt for the game jam back in January was developed using the standard approach of all GameObjects having monobehaviours, component-based design, etc.

It's basically just repackaging things. Packaging the same basic functionality in a different way.

 

I could see this being a wiki page with branching paths for different architectures.

 

Honestly, I think that most code exists because the developers enjoyed writing it more so than it was needed. Well, that and 'code aesthetics'.

I've cut more fat from my coding process in the last year than in my entire career (20 years) in development. The difference is the sheer quantity of work needed doesn't allow for waste, and there is no time for boredom. Just write the bloody code, make the thing work, move on to the next.

 

Yep that's it exactly! And I think this is actually the key difference between my two states of mind. At my job I have a different mindset. Of course, productivity is high on the priority list. But after the job ends and I work on this stuff efficiency becomes an even greater priority. I see it like it's all about getting the most done in the least amount of time. Especially if someone is trying to do this for a living. If you can knock something out in 2 hours by just "getting it done" or spend 10 hours building an elegant solution a fine engineering example.... which makes the most sense from a business perspective? If that is applied across the entire project scope... well the one way has increased the cost of the game development by 5 times. The game needs to bring in 5 times as much money for it to have been a good decision.

I've also noticed a lot of beginners seem to complete more games quicker than many of us experienced people. Sure scope likely plays some part in that in some cases. But I think another reason is their minds are not filled with all of these modern software engineering best practices.

 

So in an effort to speed things along I spent most of my lunch break today working on the project. Obviously I came to the forum a couple of times as well but it all evens out in the end so I'll count the full hour. That makes 9 hours so far on this. Getting close though. I have the player shooting and collisions in, enemies destroyed (well simply disappearing) and the enemy wave adjusting the horizontal movement limits based on the enemies on the edge being "removed".

I'll try to get a solid 2 hours on it tonight. Maybe more but girlfriend deserves some time and I have a birthday bbq to go to. Still I think I can wrap up the player getting destroyed and respawning if lives are remaining. Maybe get a proper explosion done (recently made a particle system so that will be super easy to repeat just need to set up the stuff in the editor).

Speaking of which I guess I should do another write-up tonight. Explain the config and how more of the stuff works. Such as communication between the enemy projectiles and the enemies.

 

I see where you're coming from. But I don't think dogmatic statements on what is the best way to go about it make much sense here. Imho the answer is rather "it depends". The MVP or scattershot approach certainly has something going for it, but there also are a lot of players who expect a certain quality and will ignore everything that fails to deliver.
Personally I'm often not able to enjoy things that fall below a certain amount of polish, both as a consumer and as a creator. So to take your example I'll certainly lean towards taking the 10 hours instead of 2. Not because I'd refactor the code to "look nice", but because I iterate so long on how the final result of that work looks. At the end I might have 20 commented out lines of code where I tried stuff for 2 lines of code remaining that actually do the thing in the best way that I could find, from a player perspective. At the end I'll likely have spent more time on the code that aligns the foot of a mech to the ground, than you need for the entire movement code of the enemies. But that's ok, as long as we're both happy with how our things turn out.
I suspect the full spectrum from MVP to AAA must have several vague "sweetspots" for optimal ROI. But I can't know for sure of course.

 

@Martin_H If that came across as an absolute concrete solid fact I'd say that's just because after a lot of time thinking about this stuff over the years it's the conclusion I came to. Obviously, others may arrive at a different conclusion a different belief system.

I'm not suggesting that no thought and time should be put into things. No effort made. I'm just suggesting there is a point where more time spent is just not a wise decision. Not during the active development of a game that has to be released because you are relying on the income. Sooner or later whether the code can be improved or not it needs to be released.

That doesn't mean you can't devote certain times just to play around and improve skills. Game programming skills. Art skills. I definitely think it is important to continue to improve. I'm not so sure the time to do that is when you are trying to complete a game. Although I suspect most people will improve skills to some degree as a side effect of making the game.

Of course scope plays a big part in it too. I have little interest in big games. That doesn't mean I don't like quality games. I see size and quality as two very different things.

 

Me three or four or five etc.. Seems the way to go. Let one ring rule them all..or vice versa.

 

But..do/does your girly pal/s agree? *(now I am trying to figure out what do divided by does equals)

 

Personally I find myself mostly using a light component based approach, and only adopting a manager based approach when performance is needed.

With light components you can make a toolkit of very simple elements that work together to make your game.

So for space invaders if you break it down into light components you might end up with:

Destructible - When hit is destroyed, launching a particle effect.
Destroyer - Triggers Destructible on collision used on bullets, uses the physics layer mask
Mover - Moves the invaders
Invader - Shoots at random intervals
Controller - Moves the players ship

Shields would just be a block of destructible's.

A Game component to setup the levels and maintain the score/lives.

Pros: Benefit of this approach you can in theory end up with a toolkit of reusable components you can move from game to game.

Cons: Potentially lots of update calls so for larger more complex games could bog the game engine down, but use of managers can mitigate this issue.

Your game logic and mechanics end up being tightly integrated with the way Unity works, e.g. layers, physics.

Also I tend to have to write AI controllers and player controllers that have to interact with the other components. There can also be a level of complexity when components have to interact with one and other e.g. a health component might need to trigger a destructible component when it hit's zero.

I presume the next level up from this approach would be using dedicated events the components can respond to.

Not sure if this is the best way to work with Unity or Game development but it seems to be the way Unity was made.

However it should be noted that some developers build a game then use Unity as little more than the display/UI/sound engine bypassing it's gameObject based component system.

 

Are you going to give the game some juice or do something different with it rather then making space invaders 9 million

 

LOL not going there. But I will say my girlfriend plays Super Mario Bros 1 and 3 a lot. Also Diablo 3.

 

This isn't about making a game. I can't imagine anyone really following a thread specifically focused on making Space Invaders clone 9 million and 1. The game was just chosen because I needed something to make to show how I develop in Unity which should be helpful to people just coming to Unity who have a C and Assembly (or C# and XNA, etc) programming background. Basically just shows another way to do things.

If I was making it to try and sell it or otherwise release it then it'd be a completely different story.

On the bright side I've been able to get an hour in on this project so far tonight. Birthday BBQ was way longer than expected. I'll probably put another 30 minutes on it.

Getting close. Enemies explode now. Waves can be cleared and advance to the next.

I'll probably add the enemies firing right after this beer.

 

You have to shoot space aliens who are firing after our beer? That's a game that would get American's dander up playing.

 

Wouldn't be the first time that I've seen beer be part of a video game level.

 

@GarBenjamin Just looked at some of your code and I'm not impressed, your using Find by name, and traversing lists to find the next bullet.

You are using a lot of boilerplate code to do what could be completed a lot simpler and quicker. E.g. the player could have a component that is a static singleton, so your init function would not need to search to find it.

Code (CSharp):

1. public PlayerObeject GetPlayerObject()
2. {
3.    PlayerObject oPlayer = PlayerObject.use;
4.    return oPlayer;
5. }

And with a Player component on your player it already has a reference to a transform and rendered.

You seem to be writing more code than you need, duplicating Unity's data (more memory) and making things more complex in the process without gaining any benefits.

IMHO this looks like a bad approach to using Unity.

I can understand an approach similar to yours could be very efficient but to do so it would probably have to bypass Unity's default components and just use lower level graphics API calls.

Can I also ask how does your game handle collision detection?

As you would either have to add colliders and a component to capture the OnCollisionEvent, use a homespun 'grid test' or do 2D Physics casts every frame?

For anyone new to Unity this is not a good way to Utilize the power of Unity, please consider a light modular component based approach, it's what Unity does well, up to a point*.

*Lots of components or objects with components can have a performance impact, but the key to optimizing and any development is not to spend too much time on things you probably won't need.

In this example it would be easier to move the invaders as a block. One Mover component in the hierarchy above the invader sprites could move all the invaders in a block.

An edge trigger could tell the mover it has hit the edge of the board regardless of the number of invaders left.

If you work with Unity as opposed to duplicating it's data structures and re-working it's in built features then the code needed and time taken to build a game should be reduced.

Apologies @GarBenjamin if your are a AAA game developer, but if you could enlighten me on what benefits your approach provides that I cannot grasp?

 

Ha ha. I imagine many people will find my code to be as crazy as I find most "normal" Unity code I've seen.

All I can say is it makes way more sense to me. And yes indeed the entire batch of invaders is moved around simply by moving the parent GameObject.

Granted I am doing a little more code/work than is absolutely necessary because I am intentionally trying to do different things in different ways to illustrate how things that we did in other languages can be duplicated basically the same in Unity. The idea is I think any person familiar with those other game dev frameworks should find it very straightforward.

As far as getting the reference to the Player and everything else by scanning the scene I see absolutely nothing wrong with that. It is done one time in the Init of the Gameplay state. References are cached and always readily available from that point on. I *could* do it differently for different cases but prefer consistency. So every GameObject is pulled from the scene using a Find or a Find and iterating through children. It's just establishing a pattern that can be used in all cases.

As for scanning a list of available game objects to use for the current bullet being fired that is a pretty standard thing I've done for a long time. It's just pooling as is often used only represented differently. There is a pool of bullet objects. When a bullet is fired the pool is searched to find the next free slot. Not sure why you'd think that was a bad approach unless you are saying you prefer to instantiate a new GameObject instead of using pooling?

Anyway, it will be wrapped up this weekend and people can check it out who are interested. Also not sure how that idea ever came across but the point of this was never that "my way is better than your way!" lol Some people were interested and I don't like the "normal" way so am using the same way as I used to in Assembly, Blitz and so forth. Basically it is sharing how I have been able to map that same kind of dev approach to Unity development. Of course, I expect most folks around here will absolutely hate it. And that is fine if they already like the normal Unity dev then certainly stick with it!

 

That right there is why I rarely share my code. My games work nicely, players love them, they sell well, and... I'm good with that.

 

How do you keep track of exact measurement points of movement in Unity world space?
For instance, just to move my camera, and work with my mouse, I have to work from my own vustom origin. this is a headache, but then I just realized, to even compare simple overlap of objects. I have to compare actual vectors?

Or lists of vectors?

ehhhh.

If I am used to working with SDL surfaces for instance, or 2D screen surfaces, that just use pixels which go into infinite, how do you suggest I approach these problems which I can more easily in other frameworks/engines within Unity?

 

That's pretty standard practice, what do you see wrong with it?

 

@GarBenjamin Any chance of a link to a git repo? If its not too much to add to your process. I'm curious to see the entire code base in action.

 

Why not have two lists one for in use the other for unused, then you can just pick the next ready to use bullet.

 

OK here is my minimalist Space Invaders -> https://dl.dropboxusercontent.com/u/19148487/SpaceInvaders/index.html

Using the following light weight components:

Controller - Controls Player (75 lines)
Destroyer - Bullets / Bombs do this (16 lines)
Destructible - Anything that is affected by a Destroyer (16 lines)
Mover - Moves Invaders (53 lines)
Side - Stops things moving off screen (36 lines)
Ship - Detects when the players ship is destroyed (9 lines)
Shooter - fired bullet or drops bomb (16 lines)
Stopper - prevents player from moving off screen (13 lines)
Game - UI, Waves and Game Over State (99 lines)
(total code about 333 lines including spaces)

Note: most code has about 7+ lines of boiler plate e.g. using/class/brackets/spacing.

Interested to hear how much code your approach needs.

Current version lacks Sfx / Music / Particles / Animation / Sprites / Menu / Juice / Pooling

 

Iteration is faster than constantly resizing lists.

 

If you set the default size of the list on construction it pre-allocates a given size, so will not need to be resized.

Or you could just keep an index pointer to your arrays next available bullet, but you would have to ensure the array is long enough to always have unused elements.

 

When you remove stuff and then add stuff it'll still get resized. If you just null the indexes or something it'd be a headache keeping track of that and you'd still have to iterate . Getting the first free thing from one list is just much simpler than managing multiple ones.

 

@Arowx I've heard that before about not wrestling with Unity and working with it. This is my solution to doing that. This approach removes the need to wrestle with Unity-specific things and makes everything straightforward although sure there may be some more typing. So that is one big benefit... I can focus more time on the game itself yet I can still use any of the Unity specific stuff that I want to.

The other goal here is to just simplify using procedural programming instead of component-based design. Not using events. Or interfaces. Or delegates. Or any other thing beyond simple programming basics. Instead of relying on some "fancy" / "clever" approach that hides details and does the work in 5 lines... in a sense I am unrolling that to be the 15 to 20 lines that represents exactly what is happening.

There are several benefits from doing that. First of course it just keep things highly simplified and "spelled out". This pays huge dividends going forward because you don't code yourself into a corner or otherwise find yourself wasting hours of time trying to find and eliminate bugs. These are things people introduce when they try to be clever or more complex or more compact than is needed.

Simplicity is a huge benefit. I don't care that something takes 5 lines instead of 20 lines. That tells me absolutely nothing about skill, the true scope of work that lies ahead, and so forth. There are a lot of people who think the opposite. We've all seen cryptic one-liners and tiny programs of 10 lines that do more than expected. I've done that before too. But it is a hack basically.

Of course another great benefit of this kind of approach is optimization. Things are already pretty lean &mean when using simple code. Even bettter because it is all "unrolled" it becomes very easy to focus on to optimize it. However, no time is spent specifically on that unless it is needed... other than some brief period of thought on overall design of the task.

 

Have you ever actually read up on the Capacity and Count properties for a List? Capacity can be set to a certain amount and unless it goes above that amount the List will never grow bigger. It won't shrink either unless you manually tell it to do so with the TrimExcess method or by manually setting Capacity lower again.

If you need to know how many items are actually in the List you simply check the Count property. You don't scan for nulls.

https://msdn.microsoft.com/en-us/library/y52x03h2(v=vs.110).aspx - Capacity property
https://msdn.microsoft.com/en-us/library/27b47ht3(v=vs.110).aspx - Count property

 

Ok, I admit it, before I actually finished my "first" tiny project (the 'shape logic' game, I posted somewhere else about), there was actually a real "first" project I worked on, a "frogger" clone. I am still learning Unity, don't have much time but want to learn it a bit. My background is 6502 assembler some 25 years ago (very good) + various other languages after (beginner level).

Frogger sounded about right, sprite sheet available online and straight forward mechanics, I thought I would spit it out in a day or two. And I did, but some things bothered me. One issue was that I wanted it pixel perfect and I wanted to use a few things Unity offered like colliders / physics, etc. (the objective is to learn Unity)

Oh was I wrong, got it to work pretty fast but pixel perfect was a nightmare (I.e. Camera, movement of sprites, Animation, ended up writing it myself like in the old days) and I ended up with one frame of physics collider error. I basically binned the project because I did not understand what exactly was done by the Unity engine. It was hard to debug, find where the issue was. Script execution order, etc. It was unfortunately also at a time where every other week a new unity patch would break some things that worked before. Maybe it was bad luck...things only went uphill afterwards...

But this was my first experience and I decided to take more control from there and only use "things" I understand how they work, "worst case" write them from sketch. I am still trying to find a way / style to utilize some of the features Unity offers while keeping some control.

I think I will end up somewhere between @Arowx and @GarBenjamin

It would be really interesting to write a simple design spec for space invaders, ask gar to make his sprites available and then have a "mini contest" (no winners only participants) on implementation (i.e. Only the code should be different) and share code.

 

If you create the list with a capacity large enough to hold the max number of items it will *not* resize, ever. The only time it would resize is if you insert items beyond the capacity.

From the C# documentation for List:

Edit: Haha, should have refreshed before posting.

 

That's okay. I'm terrible at writing things in a way that is quick and simple. I tend to go overboard when making a post.

 

Ha, yep I was dead wrong. Lesson learned, just assuming things leads to embarrasment and reading docs even on basic things can avoid that.

 

"Embarrassment is the catalyst of change." That's what I always tell my kids anyway. It really makes new knowledge stick though doesn't it?

 

That's pretty much what led me to this approach. In fairness, I'd been having this growing view of questioning these modern best practices for software engineering for a while now. It just all came together when I made my first attempt at a Unity game using the Animator state machine and everything else the normal Unity way.

After that I worked on other game projects and relied on my programmig experiene to create solutions for the various things I had run into which resulted in a Messaging system, relying heavily on Interfaces, Delegates and so forth. I think the last thing I threw out on the forums was a simple scrolling shmup. That all used component-based design, interfaces ,the messaging system and whatever else I had found a need for but I replaced the animation system with just coding it myself.

The carrot player control script issued a broadcast event of its position, the enemies (tomatoes) all subscribed to that event. This allowed them to receive updated intel on the player's position without tight coupling. These kind of messages were used all over as needed. By the time I got to the end of stage boss I took a look at it all and thought in many ways it is a fine job of software engineering and yet at the same time and most likely directly due to that... it seemed overly complex for a simple game. So that was another push toward the direction where I currently am at.

This thing will be wrapped up before the end of the weekend. I probably should have just gone ultra simple but wanted to make a complete proper game with title screen, gameplay, gamewon, gamelost and so forth with actual graphics (instead of just colored rectangles), sound FX, speech, particle hit and explosions, etc. So that is of course adding to the scope of work to a large degree. But I think in the end it will be a better overall example.

I get tired of seeing little snippets of code for examples and ultra basic "games" without even a title->gameplay->game won/lost sequence in place as examples around the Internet. I don't want to contribute to that.

It's coming along well. I've spent 12 hours on it so far. Still haven't added enemy shooting but that is next on the list for when I get off work today.

Last night I implemented the little destructible barriers and tested with the player being able to obliterate them chunk by chunk and the required RebuildBarriers method to restore them, etc, etc. Oh yeah, also added that special enemy going across the top of the screen

In my code I use a sort of hybrid approach to gain some of the flexibility of the modern best practices while still keeping everything straightforward. Sometimes that is just little things such as naming an object SpecialEnemy instead of Saucer. And of course at one point I had considered making some kind of weird alien or other bizarre object instead of the saucer.

 

@neginfinity it's a combination of lazily working, making everything from scratch and the order I chose to do it.

I am not quite sure how you arrived at that conclusion? I could have added enemy shooting at the very beginning and pushed something else back. Any one thing is easy to add but everything takes time. Adding the enemy shooting is ultra simple. I can't see it taking more than 15 to 20 minutes to add including handling the scaling difficulty and tweaking it to feel right. Granted probably an hour of my time at least is from playing the game. I played through all 10 levels last night a few times when I perhaps should have been working on it. But I am not rushing on it figure there is no major hurry. Saying that... there is more done than can be seen just not all hooked up yet. Things like graphics for Game Won and Game Lost, the Title Screen, etc.

I guess I could make a web player version after work just to give an idea of it. Nothing spectacular but more time spent on things than people may be expecting. I wanted it to be something that when done is a pretty solid foundation that can be released to web game portals or enhanced and released on mobile or Steam as a retro game.

 

I nuked my previous post a while ago, before you responded to it.

 

Also - List<T>.Count is O(1), as List<T> is an ICollection<T> - any ICollection<T>.Count is O(1). Using Something.Count() - the method call - is O(n). I learned that from trying to implement an IEnumerable<T>.IsNullOrEmpty method.

Edit: IsNullOrDefault can be a bit redundant. I meant IsNullOrEmpty. Oops.

 

Sorry about that man. I started writing right after I saw it. Hopefully this will at least serve its purpose to help out the folks who are at the same place in their journey now as I was back at the end of 2013 having just found Unity. As long as even one person gets something out of it I think it was time well spent. Even though I will be doing things that are not the norm. Well for Unity dev anyway. The other side is I can throw it out on a web portal and also use it as a foundation to build a Steam retro game.

 

Where's the code?

This thread has way too much english and not enough c# links to repos or zip files or whatever. But more webgl builds and stuff is definitely cool.

Actually being able to compare and contrast different approaches and look at actual code is really interesting. I am pretty happy with my own approach, but I love seeing examples of other people's work, and something like space invaders is a great example.

EDIT: I know that all programmers are terrified of their code being criticized, but I think that in the interests of sharing and learning we can all benefit from seeing real code. Hopefully we're all mature enough to not completely rip eachother apart.

Nobody is perfect, no code is perfect, everyone has space to learn. Please don't turn it into a competition or a dick sizing contest.

 

Indeed...it's good to see other techniques and processes. I've said before "It's easy to say, 'I think [stuff]. It's easier to say 'You should believe [stuff].'" What we're doing here is showing all of our own paths side-by-side, it's doubtless that at some point, one or more of us will take each other's techniques and apply them.