jbluepolarbear

I’ve been a Game Engineer for 15+ years and there are many things that can help improve your toolkit. Experiment, learn new tech, and selectively copy. Experiment: make micro demos and test out features and gameplay you think of, try and find the fun. Learn new tech: new tech is popping up every day and it can give you more freedom to make what you want. Copy: if you see something in a game, movie, etc you think is cool, try and copy it and see if it fits what you’re trying to achieve.

I’d recommend YouTube channel Game Makers Toolkit to learn about game design and mechanics and Mix and Jam to learn about recreating existing features from games.

Most of all you need to make sure you pursue what you’re interested in and have fun.

What difficulties did you experience? I’ve upgraded many projects from ancient C# v2 and more modern versions. There are always some things that need to be addressed, but as long as you look at the changes from the one version to the next it’s easy enough to figure out what needs to be changed. Most modern IDEs will point out the issues in an upgrade report.

I know that a lot of companies (I’ve worked for and colleagues worked for) were asking Microsoft for an all-in-one solution like slack that would integrate with their office and share point systems. They didn’t like that Microsoft had similar products but as different apps.

What was the product? How did teams bundle kill your growth? Office already bundled Skype and teams was a natural progression for Microsoft in response to slacks and zooms growth in taking Skypes market share. I don’t think Microsoft is innocent in this, but still think it made sense from a business point and from what companies wanted from Microsoft.

In my experience, VR is hindered by a new “boys club”: a group of people that aren’t game developers, but invested early in VR tech. Issue being that this group of developers can build decent VR controls and mechanics, but don’t know much, if anything, about how games should be made. Too many VR games are plagued with clunky controls, poor gameplay mechanics, and uninteresting progression. And to top it off these VR companies refuse to hire veteran game devs because they don’t have VR experience.

IEnumerator is how Unity implements coroutines.

In a case like Unity, low latency stuff can be moved to the job/burst system. Coroutines are generally for gameplay logic. Things that need to be done overtime in a single context.

Where you getting this information that tasks and IEnumerator can’t be used for games? I’ve been using Unity for 10 years and tasks and Ienumerators are used as coroutines all the time. Recently worked on Hello Kitty Island Adventure and almost all game logic goes through an async coroutine library. Most memory worries are in graphics and object overhead, not coroutine stack allocations.

Buying preowned furniture can save a lot of money. I bought a 4 piece sectional couch, in great condition, for $600. The set originally cost $4500.

I have a lot of fond memories of Shoes and the project that spawned it Hackety Hack. I used shoes to make dnd character sheet creators, munchkin score cards, and guis for lots of board games. Hackety Hack was a fun way to learn Ruby and Shoes made it very easy to make simple guis.

I have 2 Vizio tvs and neither is connected to the internet. I don’t use built in tv functionality because they all perform terrible and show unwanted content. I use 3rd party streaming boxes without issue. My oldest Vizio is nearly 10 years old and still works as well as I bought it and still on the same smart software from 10 years ago.

Sorry, no one is gonna prefer to watch flag football over full contact tackling. This is an absurd article. And the fact that the Olympics are holding a flag football event is a joke.

The part where they had a poll was very unscientific, it left comparisons to random audio equipment on the listeners end. Results would be based on the listeners situation more than the source.

The article says otherwise. It says that many concerns were disregarded during that time.

That’s a bad process. The review of the feature should start before it’s merged into main branch, not after. It totally reasonable for people to be upset with a breaking feature in main branch without discussing it with the community at large. Changes merged in like this are how long standing tool lose community support.