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

Would be nice to know where the hell did you get this idea.

 

I've been a professional developer for 20 years. I've worked with hundreds of software engineers from every imaginable background. A huge percentage of them are terrified of their code being criticized or being seen as "bad". Many, many people take their code very personally, it's incredibly common.

I shouldn't have used the word "all" - so I apologize if I included you when I shouldn't have.

 

It would be interesting if we all developed the equivalent to @GarBenjamin's Space Invaders game and post them all in one place along with the code just to see all of the various ways different programmers approach development. It would be nice if we could all use the same assets as well so the end result is (more or less) the same game.

Edit: It would be kind of a nice repository for new folks to learn from as well. And hell, why not even allow anyone to recreate it in any language and game engine.

 

Just to clarify my minimalist version was thrown together this morning in between my complaint post #126 [5:15am] and #133 [9:39am].

In effect I am just using very light components sometime with a little bit of 'hackery' (e.g. Side), the singleton pattern and GetComponent<>(). To link the relevant elements together so they update each other.

This approach has served me well over many games and game jams.

But you are tightly linking your games mechanics to the Unity game engines API and feature set e.g. Physics2D.

@GarBenjamin OK I get this, but my game does have a GAME OVER state.

I don't think the original Space Invaders coin op had a GAME WON state?

My Minimalist Space Invaders Project in Zip File (17 Mb)-> https://dl.dropboxusercontent.com/u/19148487/SpaceInvaders/Space Invaders.zip

I will update my version with minimalist:

1. Sfx
2. Music
3. Particles Fx
4. Animation / Sprites
5. Menu / Tile
6. Juice
7. Pooling*

*I'm not convinced Pooling is needed in this instance, but it is a good way to avoid garbage collection spikes.

@GarBenjamin It will be fun to compare code.

 

I think that's kind of his point. Get 'er done, don't worry about fancy decoupling strategies.

 

.... well... now I have a good reason to be concerned about humanity's future.

 

Well in this case the one with the smallest but perfectly formed is the winner.

 

It's quite common knowledge, although at this point you seem to argue just for the sake of it. I've done it (unintentionally) and the one thing that sticks is nobody gives a damn what you think until you're so accomplished it create's an envy factor.

Some of the worst code ever made has been some of the most successful (like minecraft) and I see it all the time in AAA code bases where they rush to get things done (it gets very sloppy towards the end), it doesn't matter what language you choose or how you achieve it if it works right and many seem to forget that.

 

@Arowx - a big thank you for sharing your code, I am looking forward to having a look at it. He actually came up with a mini version and shared the code, that's a great spirit.

I am off till September and will think in this time of a mini programming challenge, I was talking about in an earlier post.

If anyone want's to help please PM me. It will need (1) super simple design script, (2) all assets, ideally free available, (3) a little price - I will chip in 50USD, (4) rules for code sharing (i.e. author picks license) - shared with whom (public or only participants)

This is meant to be super simple and rather a framework where people show how they implement it programatically.

Stay tuned...

 

Updated Space Invaders -> https://dl.dropboxusercontent.com/u/19148487/SpaceInvaders/index.html

1. Sfx - Added
2. Music - Added Chiptunes (Royalty Free for Personal Use)
3. Particles Fx - Added
4. Animation / Sprites - Added
5. Menu / Tile - Added
6. Juice - See above
7. Pooling* - ... Not implemented.

Note zip file not updated, left as exercise for developers.





Probably about 4-5 hours give or take a meal and some chores.

Does it need anything else to flesh it out?

 

Oops, doesn't have:

• Saucers
• GAME OVER when the invaders land!
• Waves that speed up and increase in size and difficulty.

 

I sense a Ludum Dare topic coming on.

 

Haha, yes but we should not forget that this thread is about @GarBenjamin being kind and showing how he does things and sharing with the community (because of people like me nagging) and not about who is the fastest, least lines of code, best oop. His is just one approach that likely finds a lot of sympathy from some old schoolers that grew up without fancy tools like unity (don't get me wrong, it's a fantastic tool).

But I am a fan of this little 'contest' idea to showcase how different people implement things, as long as it's kept simple, I think people are not too hesitant in sharing code and it's possibly of better quality than other competitions, that are kind of deadline based and less code structure based.

 

I get massive stutters in the 30 seconds or so. There are clearly some rough edges on the initialization or the particle spawning or something. I had to retry it 3 or 4 times to make sure it was consistent and it is.

I'm sure it's easy to fix, but for someone making a big deal about array sizing when dealing with an array length of like 30 elements...... tsk tsk.

 

Works fine on my system.
What's your hardware specs?

It could be the music files they top out the total file size to about 13 Mb, the previous versions was about 5 Mb.

 

Link to updated source?

I play like pc games on this, admittedly not graphically heavy ones, but stuff like xcom2. I should really not get frame skips on space invaders. AMD Fx 7500 laptop

EDIT: Also, would you really advocate going as extreme with all these like 1 or 2 line files? Or did you break everything down to the microscopic level for illustration?

 

LOL! I see @Arowx thought it was a race or something. That is cool stuff. Good work man.

I just threw a build up if someone really can't wait until it is done and wants to check it out.
No sounds and music in yet, you can die but the game does not end. Basically when you get hit and you don't respawn that is GameOver.

I was about to get back to work on this when my girlfriend said "I'm hungry" so as soon as I return from dinner I will get back to work on this thing.

Anyway, here it is: http://garsgames.com/Unity3D/ProgrammerOrientedDevInUnity/20160701/

Oh and @frosted I think you may well experience the same delays and such in my game. I doubt it is @Arowx coding doing it. It is just the way the Unity WebGL runs.

 

You win the internet!

 

No stutter. Could be the audio, who knows. I donno what code is better, but @GarBenjamin's version is actually fun. The mechanics are correct and complete.

 

Well that is because I am focusing on making an actual game with all of the playtesting and refinement that goes with it. Lots of balancing. Anyway I gotta get.

 

Minor update with reduced music size drops total file size down to about 10.6 Mb.

Not extreme just breaking down the games mechanics into small chunks/components that work with Unity.

Potential benefits the Shooter component fires bullets for the player and drops bombs for the aliens.

Potential negative impacts your game is dependent on the Unity game engines feature set and scene/prefab settings.

 

You ain't done until it's fun.

 

And you just made my 2016 signature quote.

 

So I took a look through @Arowx's codebase. Here are my thoughts:

+ There is very little code.
- There are tons of files, game objects and components.

Basically, the @Arowx approach splits the logic for the system fairly evenly between the code, the scene itself and the prefabs referenced.

The problem I have with this is not ideological or aesthetic. The problem is that if you don't know how the system was designed, there is nothing to guide you toward the important parts. When you look at the code, you see divorced one liners. This is disorienting and somewhat confusing as to where the actual logic is.

Code (csharp):

1.  
2. public class Stopper : MonoBehaviour {
3.     // only used by player
4.     public void Stop () {
5.         Controller.use.Stop();
6.     }
7. }
8.  

Uh... what? Why is this class here? You have a class with a one line call to a singleton that only gets called from one other class.

Code (csharp):

1.  
2. public class Side : MonoBehaviour {
3.     public void OnTriggerEnter2D(Collider2D c)
4.     {
5.         //Debug.Log("Hit Side "+c.gameObject.name);
6.  
7.         Mover m = c.gameObject.GetComponentInParent<Mover>();
8.  
9.         if (m)
10.         {
11.             m.HitSide();
12.         }
13.         else
14.         {
15.             Stopper s = c.gameObject.GetComponent<Stopper>();
16.             if (s)
17.             {
18.                 s.Stop();
19.             }
20.         }
21.  
22.     }
23.  
24.     public void OnTriggerStay2D(Collider2D c)
25.     {
26.         Stopper s = c.gameObject.GetComponent<Stopper>();
27.         if (s)
28.         {
29.             s.Stop();
30.         }
31.     }
32. }
33.  

This is simply confusing code. There's a class that exists as a single line wrapper on a singleton that only gets called from one other class and more or less that other class only exists to call the one line on the singleton. Should the Stopper class exist?

Admittedly, it's one line of code, but the real question is: does this approach taken to this extreme lead to these kinds of questionable decisions frequently? Do you just kind of forget where the actual code that does the actual work lives?

Most importantly: if you do forget where the code lives, is there an easy way to find out or do you need to go through a ton of different files in order to figure it out?

 

there's a lot of bad practises like single letter variables. i,k,j are pretty much the only accepted single letter variables.

 

I honestly think it goes way deeper. Why should I even need to call "Stop" at all? Why do you need boundary colliders at all with a scene like this?

I can see why you would use this kind of approach in a gamejam or something, but I can't imagine it's remotely maintainable especially as the scale gets larger. You just need to bumble around too much in order to pick out the full logic of how it works.

 

Really?? OK in the zipped version there are all in the Assets folder but now I've tidied it up a bit with some sub folders:

Anim/ 8 files*
Code/ 11 files
Prefab/ 9 files
Sfx/ 9 files*
Tex/ 6 files

Total project files 43.

*17 files are not even in the Zipped version yet!

I would not call 43 or even 26 files a Ton of files.

 

LOL No bad code is code that does not work!

 

I would agree that single letter variables are a bad practice in large code bases, but when your code base is only a few lines, I don't think this 'rule' applies.

 

I think you got a point. I actually went back and edited my post to be a little less critical and instead to explain why I find some of the decisions made questionable instead of being overly critical.

Overall, I just kinda wonder if it's hard to work with, especially when scaled up a bit.

 

Maybe I could have just done a layer test and then called Control.use.Stop() directly, but was in the flow re-using a single meme.

 

@GarBenjamin I like your game so far. Just played through a round and it's smooth and fun.

 

Adding some missing features and messing about a bit...





Does the CRT look work?

 

I still remember the first time I encountered @GarBenjamin's coding style. Get in, solve the problem, get out. While I don't go to quite that extreme in my own work, it has helped dramatically with some of my freelancing. Often its not about having the right structure. Its having a structure that's good enough for the job, and nothing more.

Kind of defeats the point of this thread if you aren't going to share 'production' practices.

 

I also had a glimpse at @Arowx 's code base but did not play the updated version (the screen shots look nice)

My first observations:
1- it's great that he participates, his coding style looks also like an extreme (and very different from what I expect us to see from @GarBenjamin )
2- Like some of the above constructive criticism, I found it a bit hard to see how to keep an overview of what exactly happens where, as the code is quite broken up. As long as the game is small it is of course not a big deal and quite interesting. Will study it more
3- I am mostly concerned about execution order, we already had some use of late update, physics (gravity, collision, add force, etc.) involved and some event calls. If you read my other post above (failed frogger attempt) this is exactly what got me there - using those systems made it easy to get something out very quickly and it would work pretty Ok, but just that. At least I lost control of that fine little something (frame) that is in my view so important to make a true good gameplay.

@Arowx - excited to see more from you. It's likely not a style, I will use but it's very different from how I do things and there is a good chance, I find something worth considering.

 

He actually shared the source code of an earlier version in a zip file --- good enough to see how things are done - I doubt much has changed when he added gfx and other effects.

See #154

 

Had a look through @Arowx's code. Ignoring the details, the overall structure is not that different from what I used when I first started developing in Unity. Every task has its own component. Every component is responsible for one job, and one job only. Its actually a pretty decent structure, it allows you to get things built quickly. It makes code reuse trivial.

The structure can lead to a component hell, where every GameObject has 30 odd different components, and logic needs to be traced through a dozen different classes. This can be managed.

These days I tend to rely more heavily on a systems (in the chemical engineering sense) based structure. Its still rather similar to the thousand components approach, but it has a little more rigor around what components are allowed to directly communicate with each other. I tend to find this structure fits nicely with how my mind is trained, and is reasonably easy to modify on the fly.

Most of my coding is now free lance work on clients code bases. In that case the object is to do as little damage to the existing structure as possible. I'm starting to appreciate the luxury of choosing my own structure. At the moment other people's games pay more then my own.

 

Updated with Saucers, CRT look and a couple of fixes and improvements.

https://dl.dropboxusercontent.com/u/19148487/SpaceInvaders/index.html

Managed to convert it from a Destroy and Instantiate system to a SetActive(true/false) one so a massive reduction in memory footprint without using a pooling system.

 

@BoredMormon - it would be interesting to see your approach, too. I enjoyed one of your tutorials a lot. It was very organized and straight forward. It looked like you had a good grip on both Unity specifics and coding principles...are you up for some Space Invaders ???

@Arowx : Played the updated version --- nice! (I like the look & feel)
@GarBenjamin : Played your version --- nice! (I like the speed / gameplay)

 

Ah, had a great dinner and then a bit of chill time (had to veg out because my belly was too full to do much of anything).

But then I "came to life" again and put in a 3-hour dev session. That's 15 hours now.

It is nearly complete at this point as we can see from the current Configuration


I haven't checked out @Arowx 's project yet other than the game itself. I definitely will once everything is complete though.

It sounds like he is going for a very compact program with the least amount of code as possible. Mine will seem very verbose in comparison because I like to spell things out and make it kind of like reading a book. I am sure you all probably figured that out by now from my posts on here.

Some things such as the EnemyManager are heavily documented and others are not. So probably EnemyManager will be the best one to check out.

Like I said, this is just throwing everything together in a very basic simplistic way with no fancy stuff. And I intentionally left in a huge number of opportunities to condense the code. In fact there are several instances of copy, paste, rename of methods across different managers.

Generally, I do a bulk of work like this then I refactor. Then I do a another bulk of work and I refactor. It works well for me. I haven't refactored at all yet. And I doubt I will. I figure I'll just throw it out there with the code in a bloat condition because that will likely be very helpful in understanding my dev approach.

Kind of the same way as I don't optimize unless I have a reason to. Honestly, I have always found this kind of low level coding compiles to executables that perform very well. And because I am handling nearly everything myself it means I am more in control of what is going on including the performance (well other than the ultimate rendering pipeline it is all running through).

But let's face it if a game dev "kit" in 2016 can't handle something like Space Invaders it's got way more problems than any of our code does.

Let's see what else... oh yeah I got the Title screen completed. And added the speech & music on the title and sound fx in gameplay. The saucer animation. The Game Won and Game Lost states.

Current version is at same place... Play Vampaders version oh about 0.95

Alright, that's it. I am not used to putting in so many hours straight on game dev in a night. About double or more of my normal.

Tomorrow I will finish it off. Little things like a sound for when the saucer enters the screen. And since I spent the time creating graphics for the Score display and the remaining player lives I will probably go ahead and do that as well.

Oh and a big thing... the enemies currently will keep on going down, down, down off the screen. Obviously that needs to be changed.

Oh @frosted since the sound fx are in now let me know if you encounter the same stutter / sluggishness. I am really curious if there is some issue with WebGL and playing audio. Thanks!

 

Oh I forgot to say I will have to change the sound fx and music too when I release the source.

Like a dummy I browsed through the Unity audio assets I purchased long ago and used those for the game. They are fine for the game build but I don't want to distribute them. I am sure the asset creators would probably want to hang me for that even if it was for a "good deed".

So basically what I am saying is expect those to be like me hitting a garbage can with a stick or making "pew pew pew" sounds with my mouth.

I originally added the credits screen to credit the audio asset creators but shortly after I started on that image it hit me "wait I can't use their assets for this" so then I just added some filler content like I did on the Learn screen.

I think when I throw the game up on Kongregate I will either remove the amount of time it took or add a 0 on the end. I don't think it is good to set such expectations for gamers.

 

@Arowx Hey I was debating putting a raster line overlay on my game too just to complete the retro aesthetic.

I think your game looks very good and with monochrome display and raster lines it definitely looks retro. Very cool wavy motion on the enemy shots too.

 

I was actually considering posting a version. But none of my numerous space invaders clones is ideal for showing off style.

I do have an old space invaders project that I built a while back. But it was built for a different purpose, the invaders are driven by neural nets and genetic learning algorithms. It's also tied heavily to parse and Facebook and a bunch of other services I was using.

I've also got another space invaders game built entirely with behaviour trees. Another learning project.

I'll see if I can throw something together specifically to demonstrate coding style.

 

I recommend to check this out:
https://docs.unity3d.com/ScriptReference/HeaderAttribute.html

Using header attribute makes configurations easier to read.

Also when I use configuration classes I sometimes store configuration as a nested serializable class, which creates foldout for it in unity editor. Something like...

Code (csharp):

1.  
2. public class MyBehaviour: MonoBehaviour{
3. ....
4.     [System.Serializable]
5.     public class Configuration{
6.           public int someInt = 0;
7.           ....
8.     }
9.  
10.     public Configuration configuration = new Configuration();
11. }
12.  

-------

I also thought about putting together similar game but at the moment I just can't get fired up about the idea.

 

I do that too and use it to organize different groups of variables that belong together in separate classes, like HealthStatus or FireData.

I think it's one of the most consistent and appealing art-directions I've seen in your games so far. I'd definitely experiment further with that approach for future games.

 

@Arowx By way of feedback, the CRT looks really good. I like the effect it does (lines but it also blurs, does it?) - nice effect, is it a shader?

 

I started to write a version, i spent about 20 minutes trying to figure out how to manage the camera and how pixel perfect works so I could scale the display and stuff... the effort pretty much ended there. I could maybe spend a couple hours on a little example, but it started to feel like it was going to turn into many more than a couple hours. Especially if the goal here is a fair level of polish and complete game mechanics. Even in a very small game like this, attention to detail and quality takes time.

@Arowx - whatever stutter was there is gone in this rev. I think it had to do with blowing up an entire row of aliens all at once at the very start of the game. Maybe too many audio clips / particles firing for the first time all at once?

I tried to profile it, but I couldn't figure out chromes insane and seemingly buggy webgl profiler.

I also really like the crt display, although you may want to tone the blur down just a notch. It's a cool effect though for sure.

@GarBenjamin, no stutter still. Smooth gameplay.

I appreciate the details there, the blinking after you respawn for instance, the small light change on the ship, etc. The different level of particle effects is also important and communicates what's happening. I think you really captured the 'feeling'.

Although the audio .... ehhhh needs work -- I would suggest dropping the modulated voice as I feel like this kinda breaks the illusion and feels out of place.

 

For reference, I looked up the original.

It's interesting how the more modern takes on the game differ from the actual original. Especially in the audio.

 

Good choice, you've got another game to finish first .


I'd be interested to experiment with hand drawn low res retro pixel graphics, with hand drawn "normal maps", but I can't spend time on that at the moment. I know it has been done before, but afaik in a more pseudo-retro style where the upscaled pixelated graphics move smoothly on the highres pixel raster of the actual screen resolution.