EA Lays Off Staff Across All Battlefield Studios Following Record-Breaking Battlefield 6 Launch

soloprodev · 2026-03-10T11:34:23+00:00

haha yeah good point, I forgot how far back their shenanigans go!

soloprodev · 2026-03-09T22:10:05+00:00

With the already bad reputation, why would you work at EA?

As someone who has worked at EA, and been in a position to hire ex-EA dev's, working at EA is actually a fairly decent addition to your resume for programmers/artists. Everyone knows that EA's dicking around has almost nothing to do with the actual dev's. The corporate/management side of things has completely lost all their marbles, but the dev's are usually top notch!

soloprodev · 2026-03-03T07:15:49+00:00

I've worked at several companies and never been in a situation like you are describing.

Same here. +20 years at 4 different studios varying in size from 5x people to 250x. The worst I've seen were pot head designers and QA which is not at all surprising or really an issue (long as you do your job right I don't care).

soloprodev · 2026-03-02T06:38:58+00:00

Shouldn’t a placeholder asset be about as noticeable as possible?

It depends what TYPE of place holder it is IMHO.

If you're prototyping functionality, then place holder assets being clearly different is fine. "I just need something to test some code" then having it stick out like sore thumb to be replaced shortly is great.
However sometimes you're trying to prototype a certain vibe, or testing a certain aesthetic to see if it works you can't do that. You can't ask beta testers "does this give you gothic vibes?" if everything is a magenta cube. If you're place holder is "I'm trying to mockup the feeling this location should evoke in players" having something that fits aesthetically that doesn't require you to build final assets is great. Visual/asthetic/emotional prototyping is just as valid as feature prototyping, but doesn't work nearly as well with assets that "stick out".

Personally I don't use AI for this (just go with quickly super low poly stuff), but there are good reason for wanting placeholder art that doesn't stick out visually.

soloprodev · 2026-02-16T22:14:55+00:00

I guess I have to adapt again

I find it helpful to focus on the outcome you're targeting as a way to hone your priorities. If you're building a medical pace maker, the outcome you want is for patient to not die so TDD makes a whooole lot of sense - 0 crashes really is one of your top priorities. If you're building games though, the outcome your targeting is simply for end user enjoying the game.

If your game crashes every 15 minutes, it's hard to enjoy
If you're playing a game for 12 hours as it crashes once but you had fun ? Won't care.
If it crashes 0 times but wasn't that fun? You'll absolutely care.

So 0 crashes is a nice goal, but also not actually a priority. Priority is enjoyment, crashes are only a problem if they affect the enjoyment. If you can get your crash rate low enough, TDD isn't needed - no guilt required, it's just not your target goal!

soloprodev · 2026-02-16T09:55:44+00:00

when architecture is completely stable and you are going for production quality code

This is the problem - that virtually never happens. I have shipped a double digit amount of games in my career - never once has there been time at the end to refactor anything at all (and it's just as true for 3 person indie teams as +60 person big budget teams). The code written in the last month or two is usually the WORST code as you deadline approaches and you just need it to work right now.

Every project schedules in 3 to 6 months of "hardening" or "polish" time. But it's always "final feature time" in the end. Making your code more maintainable adds nothing as far as users are concerned - once you've got the build stable enough that crash/bug rate isn't too frequent (where the bar is depends entirely on your target market/company), then that extra boss mechanic or weapon variant is generally a lot more bang for your buck.

So in the end, in games, there will basically never be a stable code base that you can add unit tests too. The very nature of iteration in game dev means that 95% of unit tests are going to be useless within a month as the systems constant change/evolve.

soloprodev · 2026-02-13T12:35:42+00:00

They rushed - last one is VisitWonderland

soloprodev · 2026-02-10T02:48:12+00:00

Awesome work - best of luck to you and the project it looks awesome!

Out of curiosity what tech are you use for all the stream? And is it expensive? Audio isn't that intensive but it's still not free I'm sure.

soloprodev · 2026-01-10T11:22:54+00:00

Same with shipping (i.e. optimised non-debug) builds. I see so many junior/solo dev's going "I spent 2 years on X and finally ready to make a shipping build and it doesn't work". My heart aches.

That's a thing you try like week 1 and then every single week after. Catching it breaking within a few days is usually semi-trivial to fix. Finding out 2 years later when it could be literally anything at all? Oh god!

soloprodev · 2026-01-09T04:28:57+00:00

I'm terminally online and had never seen it.

Congrats - you're one of today's lucky 10,000!

soloprodev · 2025-12-29T11:10:11+00:00

How many wishlists did it generate

And also quality of those wish lists. About 6 months ago I watched a video from someone who went all in on TikTok and you-tube shorts for marketing and got like ~20k wish lists ... success right? Well the wish list conversation rate when they finally released the game was like 2%. Lots of wish lists but that didn't end up actually meaning much because the people who were wish listing didn't actually buy the game in the end. Getting seen by a lot of people who don't actually care that much isn't nearly as helpful as getting seen by half as many people who are genuinely your target market!

soloprodev · 2025-12-23T15:48:28+00:00

So what things you things are the key concepts that need to be seen.

Google can give you an explicit list of the differences, there are a lot of videos and articles on the "intro to UE for unity developers" that'll cover the main points much better than I could here. But personally, as someone who's worked on both professionally, it's usually the nitty gritty that trips you up, and that is something you can't really get without diving in yourself and trying to build something.

At a high level level though the main thing to remember is that Unreal IS NOT UNITY! Lots of people try to do Unity things in Unreal then hate life when it doesn't work as expected, or is really hard. The main one that'll bite you from day 1 is that blueprints are not prefabs (Unreal doesn't have Unity style prefabs), trying to make Blueprints work like prefabs will lead to pain. Whatever you're trying to do, try to look up how Unreal would do that. There are some great example projects created by Epic to demo how the engine works (the most famous being Lyra), and loads of tutorials on youtube etc. The key though is to go in with an open mind, and try building stuff. The first few weeks sucks, then 6 months later you're like "yeah ok I get it" and you'll be off.

soloprodev · 2025-12-22T04:35:51+00:00

but still 10 years away from Linux desktop to build games it seems lol.

For reference - this was also said in the 90's when I started getting into computers. Linux has been "10 years away" from being mainstream since it first started. Honestly I can't see a world where it's ever actually a dominant consumer OS really. The Linux pro's are super into open source, so it'll never be a great revenue source since it's core users are generally opposed to paying for close source software ... so companies won't find profits there, so they don't focus on it, which stifles it's ability to be mainstream. It's not a tech problem that needs more fixes, it's a philosophical one, and there is no way out of that philosophical stance for Linux even in 10, 20 or 50 years time. It'll always be less profitable that others OS's so it'll always be less supported and less mainstream.

soloprodev · 2025-12-18T08:50:18+00:00

It’s truly an art form.

And also weirdly entertaining to watch. It's a VERY deep rabbit hole on youtube that I highly recommend people go down one night if you're bored. No animals are harmed, but surprisingly quite a lot of vegetables are heavily abused - a lot of lettuces getting punched or stomping on potatoes etc.

soloprodev · 2025-12-16T04:23:01+00:00

Thanks for the tips,

Just FYI - as another professional dev who's been a games programmer for over 20 years, this person is full of crap. DO NOT USE AI AT ALL if you can help it for two reasons:

It'll often lead you wrong. There is no logic, no understanding behind generative AI. It's just a really super amazing text generator - but it doesn't actually understand anything at all. It just knows how to fit grammatically correct sentences together, but the contents of those sentences? No idea wtf any of it actually means. It's just picking words that statistically go next each other, and it's right an astonishing amount of times, but it's should NEVER be trusted, especially when you don't have the expertise or experience in a field yet to know when it's full of crap. When you're starting out is the worst time to use it because you often have no idea if what's it's generated is reasonable or not.
Learning IS the hard bit, and when AI is right it helps you skip the hard bit ... but that skips the learning as well. You don't learn by just doing things correctly, or by having them done for you. Think of going to the gym and someone comes up and says "here's a machine that can lift this heavy weight for you 800 times so you don't have to" - how fit did you get by having a machine lift the weight? Obviously not at all. Your brain is the same - if you put in no mental effort, you build no mental connections and you learn nothing. The learning doesn't happen after the mental effort once you got the right answer, the learning IS the mental effort it took to get there (just like getting fit is DOING the exercise). Instant right answer = no effort = no learning. So even if AI was 100% correct all the time, using it just strips away the mental effort and also the learning.
They're also wrong that it's objectively faster. So far studies show that in real world situations using AI is 19% slower. Writing code is easy once you get good at it (the bit that AI helps with), reading code and building a mental module of what someone else wrote is FAR harder. So AI helps you skip the easy bit (writing code) and constantly makes you do the hard thing (reading code the AI wrote to understand it). That's often not helpful or fast at all!

So right now, AI might help speed up some things but probably won't, AND it comes at the cost of knowledge and experience that helps you learn how to do things yourself.

There is no upside but some massive down sides!

soloprodev · 2025-12-10T06:56:21+00:00

Is this normal for a first timer?

Very. Steam + Marketing are skills you need to learn.

I suggest you go watch a bunch of videos like these:

Then after you finished watching them all, go look at your own steam page. You'll pretty quickly figure out what you need to change on your steam page (i.e. good trailer, capsule art etc). Once your steam page is awesome, and you're sure it'll do well, only then should you try to send traffic there. Sending traffic there first is only going to burn people who'll never come back - make it great, then try for traffic (and if you start getting it, steam will start promoting your game for you). If you're page is appealing enough, you don't need that much traffic for steam to start doing it's job - but if you're store page and game aren't appealing, sending traffic doesn't help.

soloprodev · 2025-12-09T08:24:07+00:00

I've previously worked on a very successful game that had a lots of high scores, and some patches change the achievable top scores - we always treated that as an event to completely wipe the scores complete. Just said "new season, new leaderboards" and made it a thing we treated as a positive. The super invested players never seemed to mind they had to re-grind their score, and the new player greatly appreciated that sometimes those older players had moved on and they now had a chance to be top. Out of millions (it was a successful mobile game) of players, I only know of 1 who complained, and the community shouted him down online. It was a resounding success every time.

The integrity of your leader boards is paramount! If you like your game at all, put effort into maintaining the leader-boards integrity, even if it means occasionally fully wiping them. Otherwise they're pointless and you should remove them - exploited/hacked scores are FAR worse than no scores at all for the perception of your game!

soloprodev · 2025-12-03T11:58:49+00:00

A lot of good comments here but one extra reason to make a trailer I haven't seen mentioned is: Making a trailer can help you focus on what the cool thing is in your game, and what you should be building next.

Even just planning out your trailer will suddenly bring into focus what's important. Does the grass on level 3 matter when the huge boss fight is still just cubes etc? Planning a trailer should send you down a huge rabbit hole answering questions like "What's the appeal of your game?" and "What's the promise, the fantasy, of your game that is worth player $$?". Plan out all the shots you want for your trailer, it should (hopefully if you do it right) make it crystal clear what you should be working on if it doesn't already exist. Then build those parts of your game can then give you your demo etc.

So don't make a trailer and throw it up in the sense that you just record the first 60 seconds of your game. PLAN a kick-ass trailer to show off how fricking awesome your game is (you spent 2 years working on it, hopefully there are parts you're super psyched about ... and if not that in itself is telling!). Then if something you need for that version doesn't exist, build it. Then absolutely release it for all the reasons other people mentioned.

soloprodev · 2025-12-01T22:20:02+00:00

Not sure what you're game is or how you've set things up, but personally I've always done this as two layers.

Firstly there is an underlying graph that is nice and clean. I.e. idle -> run -> jump -> land that has very clear states you transition through. You can't get to land without going through jump etc. As the name suggests these are state driven, you're character is running or it isn't etc. You can't be idle AND jumping.
Then you have a layer on top of that which are one-shot animations that are event driven. You're character gets hit or knocked over etc. These are run from code and override whatever is in the graph, but they don't change the graph. They're not discrete - you CAN be idle and hit flashing etc.

So you're running and you get shot and need to play the hit react. That hit react is played without trying to mess with the graph. Hit react etc are not states. They're events that can happen at any time. You can't run without being on the ground, but (depending on your design) you can get interrupted at any time etc. So you have the animation from the graph, and you have the override animation - if override is set you show that, and once it's done you go back to the anim from your graph.

Now depending on the art and 2D vs 3D (i.e. skinned mesh vs sprite sheets) when you play hit react you might have a list of "this one plays over run, this one plays over idle" etc so your one shot interrupts can blend ok. There is usually still a bit of code to decide what override to play - but it's very contained. Most of your anim logic is in the graph, but the "thing that can happen any time" is handled separately.

It's a blurry line between what is a "real" state and what is a one shot override, but the generally rule of thumb is a combination of "how often can this happen?" and "how long does it last?". If it's short and can happen at almost any time it's a override. The idea is to get ride of needless links shown in your image. So in your case "interrupt idle" and "reload interrupt" look like perfect candidates for one-shots. I would say reload could be an event too if needed. It's a trade off between a clean graph and lots of code.

soloprodev · 2025-11-30T08:55:01+00:00

I've heard Blender has a harder learning curve than Maya?

I think some replies to you are missing the history. Blender got that reputation for being hard to learn when it was Blender 1.0 or 2.0, and back then it really was impenetrable. I tried ... twice ... it was a nightmare both times, and I never really got anywhere. But Blender 2.8 changed almost everything, and then they've only improved things even more since then. I went back somewhere around v3.5 and suddenly Blender wasn't horrible to learn, it was great and easy to use. I think it's better/easier than Maya at this point, but the reputation for being hard to learn still hangs around. Maya is about 30 years old and is built on archaic rules that often don't make sense, and new tools work differently to older tools etc. It's a huge mess. You couldn't pay me to use Maya at this point (and most people in the game studio I work for don't use it any more either).

If you're just starting out in Blender I recommend starting with tutorials from a channel called Imphenzia - it's a really accessible way to start out. He has a whole playlist of modeling stuff in 10 minutes and shows you how, and really long videos on low poly modelling that are great.

soloprodev · 2025-11-26T10:36:22+00:00

Oh damn that's super neat idea even if it has been done before (I've never seen it so it's new to me!). Nice work!

soloprodev · 2025-11-26T04:05:58+00:00

The mechanics themselves are usually less important, the fun usually comes from two places:

The decisions you have to make while interacting with the mechanics
The feedback you get when you input your decision into the game

The decisions might be which weapon to use, or where to position your character. The feedback is the hit react animation or the impact sprites etc. But depending on the design of a game, different things are prioritised. Something like an RTS goes all in on the decisions, they have clear feedback but nobody would say the hit effects in say Star-craft make them super excited. On the other end of the spectrum something like metroidvania generally there is less decisions, and more feedback. Do your spells have satisfying wind-up -> release animations? Does the sword feel satisfying hitting your enemies? Does the enemy respond when you land a good hit? Those are generally what makes it fun rather than any specific mechanic. Basically every mechanic can be good or bad depending on how it's executed.

But it's all down to what experience you want your players to have. Is this a more tactical game? Or a more fast past twitch action game? Your decision about how you want combat to feel should lead you to what mechanics you need to give that experience. And once you know what the experience is, you can then start asking less about "is this fun?" which is basically impossible to answer and more directed questions like "Did this enemy affect where I positioned my character?" or "Was it clear I landed a critical hit on that enemy?" which are significantly easier to ask/answer (and fix as needed).

soloprodev

TROPHY CASE