For myself, I was more productive at home in my 20s. I recall spending 5-10 hours each week working on personal projects. The engineering work I did at home was very different from what I did in the office. So it was fun, at the time.

Things have certainly changed for me in the last few years though. I'm 34 right now, and average something like 0-3 hours of project work at home. And the idea of spending a significant amount of time doing any engineering work repulses me.

The reasons why are multi faceted. I'm older (long term partner, no family though). I really enjoy getting away from screens, and prefer spending my time cooking, running, or socializing with friends. Adding to all of this is Covid, of course. Working from home for over 2-3 years was not fun. And I learned to get far away from computer screens and my apartment the instant the work day was done. It was the only way to cope.

My role in the workplace has shifted into engineering management over the last year. So it has very little to do with being burnt out of programming.

So, who knows why. But I've had to seriously temper my expectations with engineering work I get done at home. And not beat myself up too much for enjoying other things in life.

I do really want to put small stuff on Newgrounds though. And whatever other site. We'll see.

I've enjoyed using your work in some of my projects. It's really good stuff. If anything get released released, you'll have full credit of course. Keep up the good work.

Make Canada Great again! More international music performances! And less snow!

I've been deep in software development for about 10 years now. I'm not entirely sure that it suits me though. The pandemic may have messed with my head a bit. I've been considering a change into teaching some day. This is partially because I am getting older, and the desire to spend my life in expensive tech cities is starting to wane. Teaching in a smaller community sounds like a much more relaxing way to spend my 40's or 50's.

Obviously, I have no idea where your head is at. But keep an open mind.

As for the original line of questioning. I feel like Gimmick was giving some good advice. Although, the available technology largely depends on the surrounding job market. Work From Home has certainly opened the market up. But it's all still settling right now. And can be a bit of a crap-shoot.

You've pretty much nailed Unity's issues as a product. I'm personally tired of them launching all kinds of new engine products like networking and lobby, and dropping them when they don't reach certain profit margins. It's no way to build a platform, in my eyes.

But, when considering a 10 year timeline, I don't see major changes. Mobile markets are massive. Game's like Genshin Impact keep Unity relevant into the near future.

I do want to give Gadot a shot though. Release some small ideas that I can build quickly. It'll be Unity in this weekend's Global Game Jam though.

Unity has lot's of problems as a company. But they've got a strong product that continues to see wide adoption.

Unreal engine dropped mobile initiatives internally, and focused on AAA as a market. In large part due to Unity's success. I think both products have found very successful markets.

In 10 years time, Unity games will be selling everyone NFT's real estate in the Metaverse. And Unreal will be responsible for the destabilization of western democracy via real time deep fake technology.

I'll be back here in 10 years to see how it all went.

There could be a general lack of polish t the entire experience due to uninspired product owners and an incapable workforce. Meta is not traditionally a game development company. I wonder if there are skills gaps within the company. Either from a management, engineering, or art perspective. And convincing experienced people to join the cause might be challenging.

More likely, this is simply the best way for the product to reach its goals. Meta might have plans to run it on very low spec hardware, as a way to keep the product reach far. That is, further then the competition. Hense why it might look worse then the competition.

Hello fellow kid.

If we knew the language you were trying to write this in, you might get a more specific solution.

But there are lots of ways to accomplish this. Check if the variable changed each tick inside of a loop does not sound processor intensive at all. It would be a single equality check. So you initial idea is not so crazy.

Beyond that, languages like Actionscript, JavaScript, and C# have event systems that can be used. So, you dispatch an event when the variable changes, and your algorithm (which is listening for this event) is listening for this event.

As stated already, Java has an implementation of the Observer pattern that can be used to accomplish this as well.

Another very simple solution is to wrap changes to the variable in a method call. So instead of changing the variable directly, you define a method to do the work that can trigger additional processing.

public void SetVariable(int newValue)
{
this.variable = newValue;
DoMoreWork();
}

Those are just ideas. There are many ways to accomplish this kind of thing. We would need to know more about your program before we could give a better solution.

I remember this name. In my head, it was always pronounced "snitch".

I started poking around the site again in the last year (what would have caused that, I wonder).

When I first made my Newgrounds account, I cared so little about it that I chose random numbers as quickly as I could. I had no idea that the site would be responsible for guiding my personal development as a teenager, and laying the foundation for my entire career. I am currently helping launch Halo: Infinite, one of my favorite franchises. I simply would not be here without the influence of Newgrounds. Thanks to Tom and friends. :D

It looks to be available in Flash AS3.

https://help.adobe.com/en_US/as3/dev/WS065D20A7-F721-4a0c-8581-4D188E6FD606.html

I did not get any hits on AS2 though.

And again, there is the Ruffle layer. AS3 is in early stage development, and this sounds like it would be a lower priority feature.

The art looks great! I am very fond of Into the Breach. Look forward to seeing more.

Interesting. I did some googling for a few minutes, and it look as though WebAssembly only got thread support in the last few years. Fairly recent, in some respects. Good to so it all supported now though.

At the end of the day, this only means Browser support for workers threads is available. As for the Ruffle project, I still presume there will be no threading supported. This means no threading in AS2.

I highly doubt Ruffle can support multithreading.

Ruffle is primarily designed to preserve Flash games. AS2 and AS3 did not have any multithreading support, and it makes little sense to add new functionality.

Additionally, Ruffle primarily runs in browser (and desktop). Browsers do not support multithreading for plugins such as this. For example, if developing a Unity game (which has significant threading support itself), you cannot utilize any C# asynchronous utilities when deploying to a browser. Because the browser does not provide this kind of support to the plugin.

That is my understanding of the issue, anyway.

Nice work. I did a quick search on the Unity Asset Store, and did not find any significant solutions available. Which is good! It means you have something that people might not have solutions for already.

Overall, you should focus a little more on documentation. The video was far too long. If I am considering purchasing (or using it at all), I do want to understand it's capabilities very quickly. Maybe try again. Design it to be less than 10 minutes maybe.

The text posted in this thread was also hard to follow. The English seems fine. It's just a little too complex. Large areas of text. I would want to see very simple concepts explained with examples as you introduce them. And very simple code examples spliced throughout.

I also feel like the Cases are not being communicated properly. Game Object is not a case. Modifiers is not a case in of itself. In my mind, cases would sound like:

1. Simple : .....
2. Weighted: .....
3. Filter Items Based on game state: .......
4. Global Modifiers: .....
5. etc.....

So, now more specifically. I might be a little off on the feedback, because I do not understand it 100%.

The drop table scriptable object.

• I'm not a huge fan of writing a description into the object. Feels like wasted memory that should not be loaded at runtime. This is not valuable information to have at runtime.
• What is Drop Table Kind? Again, I did not see it in the video (skipping around). And do not see it explained here.

Logic:

• I think this needs to be broken down more. Loot Tables are very much a designer centric feature. And designers would want to tinker with the logic of a drop. There should be facilities provided by your Plugin that can build logic. Leaving it open for programmers to add more complex logic if needed.

Modifiers:

• I see code that can add modifiers. But no facilities to tinker with them at the scriptable object level. I imagine designers would want to mess around with modifiers. But it looks like it is mostly code driven. At least, there are no additional tools setup to manage it.

I think there are some features missing.

• Odds. Modern loot games are required to communicate Odds for anything that is paid. There should be facilities in the API to pull Odds out of a loot table.
• How odds are calculated will highly depend on how the code is built. And it might be very challenging to produce odds for the table. For instance, if your logic works like this: Roll -> Pull item from table and place into bag -> Remove this item from the table -> Roll again to select your second item -> place in bag. Sampling With Replacement / Sampling Without Replacement. Depending on how you are pulling from tables, it may be very computationally complex. This is why some Gacha games have a website to get odds. Instead of calculating on the fly.

You could also consider debug tools at runtime. Sometimes engineers/designers/QA will see a strange drop, and have no visibility into WHY it was weird. It would be great if there were facilities that could record drop information, and it can be viewed after a drop occurred. This would not be enabled for a production build of course, but might be helpful during development and support for Gacha games post launch.

Also, when working with Unity and serialized object, I recommending having a robust interface layer. Scriptable object are great for data input in Unity. But at runtime, it is better to work with interfaces. All of your functionality should be built to expect an interface, and never require a GameObject or ScriptableObject. This also includes any class that extends either of these classes. In theory, we might want to dynamically create a look table at runtime and have it integrate smoothly into your Plugin. This would be done via interfaces.

Overall, it's a cool project. Look can be complicated, and this could save time for anytime working on this kind of game. Good luck!

For game development, it will entirely depend on the company. In my experience, larger companies engineer their games very "deliberately", whereas smaller companies will engineer by "coincidence". That is, build features as quickly as possible and hope it all comes together at the end.

But at the end of the day, if you don't have a strong interest in entering game development, then I recommend looking for work elsewhere.

Cross platform app development is a good place to learn. It sounds like Flutter might be a good choice for development. Microsoft has Xamarin. Android apps will run on Windows soon (?). There is a ton of choices out there for cross platform development.

If you have a goal of being a native app developer, then go ahead and start in Android Studio or XCode (for iOS).

So, think up some things you might want an App for. And start developing one. You will learn how to work with data, interfaces, and platform API's. Even if it is dead simple, you will learn and have examples on your GitHub profile.

I feel like answering this question is very hard. The answer depends entirely on what you want to do with your professional career. Do you want to make games? Then your github should be filled with games. Do you want to work at Amazon? Work with thier toolsets. Build open API's using AWS Cloud infrastructure and share them with people. Do you want to work in AI? Contribute to open source projects on Git.

What do you want to make?

There must be a way to do a code review through GitHub. An easy way for people to make comments in the code that can be threaded. Create a pull request? Something like that. Maybe try and figure that out for next time. For now, I can look at some of it.

NPC.hx line 99

for(sound in _painSounds){
	                if(sound == null){
	                    die();
	                    return; // don't play sounds that don't exist
	                }
           }

I'm not certain I understand this look. It looks like the getStabbed has multiple ways to call die();, and will do it multiple times. This line of code in particular, I do not see a reason for it.

NPC.hx line 106

switch(_random.int(0, _painSounds.length - 1)){
	                case 0:
	                    _painSound01.play(true);
	                case 1:
	                    _painSound02.play(true);
	                case 2:
	                    _painSound03.play(true);
	            }

Having a list of pain sounds was a good idea. But the idea is lost when you use a switch statement like this. This can probably be reduced into a single line if you wanted.

_painSounds[_random.int(0, _painSounds.length - 1)].play(true);

NPC.hx line 124

new FlxTimer().start(3, finalDeath);

I would certainly recommend a bit of safety code around this to prevent multiple timers and deaths from occurring.

if(alive){
alive = false;
acceleration.x = 0;
health = 0;
new FlxTimer().start(3, finalDeath);
}

NPC.hx line 142

_painSounds = [_painSound01, _painSound02, _painSound03];
	

	        for(sound in _painSounds){
	            if(sound != null){ // TODO: this is only here because I don't have death sounds for the cops yet
	                sound.volume = FlxG.sound.volume;
	            }
	        }

You should try to find a way to filter out any 'null' sounds when creating your list. Only populate it with valid sounds. Then you will not need these extra 'if' checks. And the game should be more stable.

Player.hx line 57

MAX_WEAPONS = _wep_names.length - 1; // what even are constants? GoKritz clearly does not know...

I think this might just.....not be a constant. Not if it is based on a list that can change at runtime.

Player.hx line 60

hasRifle = false;

There is a cleaner way to manage this kind of work. The primary issue is you have multiple sources of truth. You have a list of '_heldWeapons', which may not have a rifle in it. At the same time, hasRifle could be true. Does the player have a rifle? Depends on 'who' you ask.

In programming, you really want to avoid this kind of structure. Make sure there is always a single source of truth.

First, add constants for the weapon ID's:

// === CONSTANTS ===
var WEAPON_ID_RIFLE:String = "rifle";
var WEAPON_ID_PISTOL:String = "pistol"
var WEAPON_ID_NONE:String = "none"

Then, create your list of weapons using these ID's:

_wep_names = [WEAPON_ID_NONE, WEAPON_ID_PISTOL, WEAPON_ID_RIFLE];

Then, we can create some new methods to work with these:

public function HasWeapon(weaponId:String)
{
for(weaponIndex in _heldWeapons)
{
if(_wep_names[weaponIndex] == weaponId) 
{
return true;
}
}
return false;  
}

And now we can replace that bool hasRifle with a proper function call that uses a single source of truth (held weapons)

public function HasRifle()
{
return HasWeapon(WEAPON_ID_RIFLE);  
}

Player.hx line 207

function cycleWeps(){
			if(current_weapon > _heldWeapons.length - 1){
				current_weapon = 0;
			}else if(current_weapon < 0){
				current_weapon = _heldWeapons.length - 1;
			}
		}

I feel like this code could be cleaned up. I understand you are incrementing the value above. But there really should be functions for this.

function nextWeapon()
{
setCurrentWeapon(current_weapon + 1);
}

function previousWeapon()
{
setCurrentWeapon(current_weapon - 1);
}

function setCurrentWeapon(weapon:int)
{
current_weapon = weapon;
			if(current_weapon > _heldWeapons.length - 1){
				current_weapon = 0;
			}else if(current_weapon < 0){
				current_weapon = _heldWeapons.length - 1;
			}
		}

You can take a look at installing Visual Studio.

https://dotnet.microsoft.com/platform/tools

And maybe try looking around at the tutorials that Microsoft has written.

https://docs.microsoft.com/en-us/visualstudio/get-started/csharp/tutorial-aspnet-core?view=vs-2019

I think this is good advice. Saving progress for example is a huge part of game development. Data serialization is a complex problem and is integral to the technology that runs games. If you are only ever making prototypes that hold everything in memory, you are not really building something that people can play.

Overall, I would recommend to build games from start to finish. But keep your scope as stupidly small as possible. Release them as complete (if not very small) products that can be played by players in the wild. As you get better at game development, you can drop in more complex code and more ambitious designs.

Try not to put so much pressure on yourself. Programmers are constantly looking things up and feeling lost, at every level and quality of product. Practice your craft, solve problems, be pleasant to work with, and most of all, have fun. You can't ask for any more than that. And it sounds like you are off to a good start.

I think this pretty much nails it. Regardless of how good you are at making games, you will always fall into the trap of creating too much scope and never finishing your game.

For myself, I am a much stronger game developer than I was 10 years ago. Which you'd think would result in games getting completed. Instead, I just make more complex games. Raise my standards. And toil away at half finished projects for my entire life.

If you only have 5 hours a week to spend on development. Pick a game that you can finish in 3 months, given that amount of dev time per week. As you get better at making games, stick to the same (or similar) development cycles instead of becoming more ambitious. Your games will naturally get better over time. You will actually finish things. And you will have a very satisfying hobby.

It is not a question of 1 versus the other. They are fundamentally different.

When you navigate to a website, a request is sent to their servers. These servers are just regular old computers (essentially). These computers will run PHP, ASP, Node JS, etc. These are considered back-end languages. Most importantly, they are not run on your computer.

Conversely, HTML/CSS and JavaScript (React JS, Angular, etc) are all considered front-end languages. These scripts are returned by the server (as text files essentially), and get computed on your own machine (PC, phone, etc).

Back-end languages can generate HTML/CSS/JavaScript in very dynamic ways. But at the end of the day, it all just get's sent to the users machine to be rendered by the browser.

C++ is not so much the "father" of C, and is instead the cybernetically enhanced super language of C. C++ was build directly on top of C, and the syntax of C++ is build directly on top of C. For better or worse. Sometimes this backwards compatibility can force language features to be implemented in very strange ways (eg. mangling).

With C and C++ you are working directly with system memory. That is what it means to be "close" to the hardware. Another very important note about these languages is that there is no garbage collection. GC is the method in which an application will free up memory that is no longer in use (automatically, in the background). In C and C++, if you instantiate a class, you must ensure that the memory associated with it get's cleaned up. The relationship between C languages and their interaction with system memory make them hard to write effectively without learning how these things work. Which make them difficult languages to learn.

C#, on the other hand, has no real relation to C or C++. It is not a "C based language". C# is:

1. A compiled language, just like C and C++ (which means that it get converted into machine operations before it is actually ran as a program)
2. Has garbage collection.
3. Cannot interact directly with memory like C based languages can.

All of these languages differ greatly from things like Javascript and Python, which are not compiled languages and get interpreted as runtime.

Thank god for that. After 15 years, I can finally sleep peacefully know that he is in fact, alive.

I'm not certain how it compares to other services in terms of price or features. But I moved from Godaddy to Name.com years ago. No real issues. Lot's of good tools for hosting. Maybe you could check them out.

Good god. Those poor servers.

My workplace has me learning c++ right now. I suspect I will be making a great deal of dumb mistakes myself.

Happy you figured your issue out. glhf.

But if that happens, where will go to sustain my nostalgia fueled lurking habits? Without it, I might grow up or something. Nobody wants that.

Beyond all that. Yes, testing is important. But as game developers, we all have to be very familiar with the concept of incentivization. And what incentive do people have to look at your game? When larger game companies do user testing, they will put out incentives for the testers. Free games, money, etc. And it does not take much, really. Even large AAA game studios could just give a free game. Very small investment. Maybe you put up a 30$ steam gift card. Get ~3 people to give feedback. Small cost to get useful information from people I think.

You really just need to work with the profiler. It's unfortunate that you can't get it working with the browser.

It might be worth investigating other platforms to try and understand what your particular bottleneck is. Add more zombies, and try to reduce the framerate on a standalone build. Something you can profile. If you find the bottleneck here, and you solve for it, then it could resolve any issues you are having in WebGL. There is always a chance that the two platforms perform so vastly different that this would not give you accurate insight. Can't say for sure.