Unity store is a place where game developers can purchase and sell game assets for the Unity game engine. So, a coder can purchase character models and such. The purchase of an asset includes the rights to put it in a game. But the asset can be sold to any developer, so that asset is not exclusive to any one game. One could look at this as start up developers helping each other out. In spirit it is meant as a way to get aspiring developers to practice their methods and find creators that would be good to work with. If one looks at it in another light. It is non-exclusive assets mixed and mashed together. I would not pay more than $1.99 for a game that used Unity store assets. I feel that any price higher than $1.99 is not in the spirit of honing skills and relationships. And to be quite honest, even at $1.99, I would have to see some major promise in the developer to even want to bother with that price tag.Ima Lemming said:Bugga-wha? So, it's okay for an indie dev to steal stuff as long as it's from another indie dev?DoPo said:
I know that's hardly the most fucked up thing about all this, but still...
Jim Sterling Plays Terrible Game, Angry Dev Reposts Video With Response UPDATE 2
- Thread starter Nosirrah
- Start date
Ah, understood on the Unity thing. My bad.
I'd question the artistic integrity of somebody who cobbles together stuff from the Unity store, but eh, I guess that's not the brightest of the guy's red flags right now.
I'd question the artistic integrity of somebody who cobbles together stuff from the Unity store, but eh, I guess that's not the brightest of the guy's red flags right now.
I'm actually starting to feel bad for this dev; the first video alone just goes to show how in-over-his-head he is. His ignorance is almost endearing. Too bad for him that Jim isn't the type to let anything slide. Fortunately for the dev, he wised up and dropped it (sort of), but I can't help but point out that the damage is already done.
Maybe the guy doesn't get that Jim is TRYING to hinder his game because he's trying to save poor gullible saps from wasting their money on his piece-of-shit excuse for a "game"? If you make tripe like that and expect people to give you money for it you DESERVE to lose sales. Especially if you react like a complete and utter prick to any and all criticism, like this guy.DoPo said:
i'm on the dev's side. the game itself doesn't look that bad and jim is not doing the gaming industry any favors by ridiculing indie game devs who are doing this more out of love and passion, than money. game devs do have a right to defend their own games. jim was being extremely disrespectful.
I think it's highly likely this is the case.Arcane Azmadi said:
The game is bad. Like, technically bad. The thing I can say in favour of it, is that if this was somebody's major project, it would pass and could get them good grades. But that is also damning it with fine praise, as a lot of major projects don't quite work and it's the write-up that's really important anyway, in fact, having a project that doesn't quite work gives you a lot to write about. What went wrong, how and why it went wrong, how would you fix it, did you try to fix it, how would you prevent it in the future and what would you do differently if you were to start over all give you a lot to write about and would probably give good marks to redeem the project, too.OpticalJunction said:
This dev, though, seems to not consider the failings to be...failings. In fact, the dev seems to revel in sheer blissful dismissal of criticism. Valid criticism. The game has flaws and they show. Heck, Jim conducts one of the cheapest and best test any software can get - grab a random person and have him use your software. Jakob Nielsen suggests 5 for optimal results [http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/]. Well, also for more complex stuff probably more, but anyway...Nielsen also says to test regularly and often. The dev clearly has not done that - not only that, there seems to be little, if any, QA on this product at all. Furthermore, the manner in which the dev dismisses the complaints (e.g. "But sound can be turned off" or "Obviously, you only get ammo for the current weapon you're holding") shows clear lack of any thought for the players. Jakob Nielsen also has words on it...well, many and said on many occasions, also echoed by many, probably a conclusion reached by many, many, people independently (in fact, I'd say, most computer scientists I know, at least, would know a variation of it), but here is one particular instance:
(no modification was done on the text) Taken from the end of this article [http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/].
The dev doesn't do that. Moreover, the dev doesn't even acknowledge this rather basic tenet. This attitude goes beyond unprofessional well into not a good developer territory.
I struggle to see what the developer's "side" even is - the game was bad - it clearly needs more polish, yet it's sold, and sold for 10 bucks, with no acknowledgement anything is bad, no acknowledgement anything can, or should, be improved, just unfocused angry defence of faults which any developer worth their salt would recognise and would have been addressing instead of turning a blind eye on.
The game was rushed. It is clearly evident by both the developer's attitude, the game's state, and the release date. It only came out when it came out because the developer thought it was "good enough" to go for the Halloween sales market. Other games have done the concept and better and some of them are even cheaper. Or free, as Death Illustrated which I mentioned before.
Dude, if you're going to call Jim disrespectful, then you have to say the same for the dev. Jim may have been more than a little crass, but at no point did he call anyone 'idiot', 'moron', 'stupid' , 'negative worthless pile of shit', or 'developer of slaughtering fucking grounds, son'OpticalJunction said:
What was there to understand? The game has a UI. It shows how much ammo, health, etc you have. That is pretty self-explanatory. He'd just be reading what is already on the screen. Besides, the ammo-counter wasn't the problem, it was actually getting it replenished that was his problem.josemlopes said:
Really, what is there to explain? Besides mentioning a stable frame rate, what else is there to mention?
Oh, it HAS a UI (which turned out to be bugged).
Oh, at least it HAS basic game mechanics.
Oh, at least it largely seems to be working.
This is a finished product being sold at a price on steam and has other products to compete with and thus needs to give us a reason to play it over the others. This is not a high school student project. The game simply working does not warrant appraise. It is EXPECTED to work as a STANDARD.
Makes me think that the next few crops of gaming or games industry-related college programs could do with a Business Ethics primer, or how to handle PR responsibly. A lot of what I've gone through back when I was aiming for an ad agency/games studio career came complete with some handy pointers on how to handle criticism as a company or as someone representing a company.rcs619 said:
The short of it goes thusly: I don't give a crap if you mortgaged your house or went on sick leave for three years to fund this piece of shit game, I don't care if you divorced your wife or sold your unborn child to afford the engine licenses or the Art and Programming classes - keep your cool if your product is harshly criticized.
That goes for any creator, really. I've written short stories and novellas, and I've been taken to the curb on a few occasions. Being verbally smashed in the face by someone who clearly missed the point of your efforts really does hurt, I'll admit, but it's still an honest and useful thing to happen to any writer. Game devs, especially indies, should look for perspective anywhere they can get it, even if the source is actually scorching their ego.
If I'd been in the devs' position, I would've tried to learn from Jim's criticisms. I don't care how central the ammo counter is, if your interface is obtuse or too freaking big, it won't be legible at all. How does the average gamer react to something that can't be interpreted or contextualized in one glance? He dismisses it. Watching the original video, I felt compelled to ignore that huge freaking block of UI because it took way too much space.
There's a lot of obvious mistakes in that project, and there's nothing worse than a creator with an inflated ego who flies into a rage at the mere mention of potential improvements.
Yeah, there's far too many people complaining that it's not that bad. If this was someone's first experiment with software, I'd be sympathetic. When you abuse the greenlight system by promising keys to voters to get your shit onto the steam store where people might actually be fooled into buying it, that's when you become accountable. They're charging for it, they're asking for it. This shit embarrasses ACTUAL coders. It takes time and effort to learn to code, and it takes time and effort to learn to make a game, and this person did neither, and then added insult to injury by trying to drag devs in on his side. No-one who's ever done any serious amount of coding would want to be associated with that shit.DoPo said:
Yes. Yes it is that bad. I'm not sure that it'd even count for a major project, since it looks like it's in Unity, so apart from splaying some assets around, there really isn't that much that has been done. A counter for health, a counter for ammo. And these are misleading (The ammo counter is misleading for the two weapon system, and covers a large portion of the screen, for no reason). It's not like they had to code a physics engine or the vectors for movement, and all the maths involved (Arrays, Vectors, Trig, it's University level Calculus, applied in extreme depth. Most software does it automatically in simple to use devkits, because that was once the biggest barrier to entry), and draw their graphics by the pixel (Which was my major project in Java for a 1st year programming class, making a game. I made a 2d platformer inspired by Portal. A friend made Battleship. Another made Bomberman (With multiplayer.) If we wanted gravity, motion, physics, we had to code those in. If you wanted bombs, velocity, timers, you had to code those in. If you wanted graphics that wouldn't flicker incessantly on the redraw, you had to implement double buffering. If you wanted AI, you had to code that in. And at every stage, people gave each other feedback. We played so many broken games, and broke so many games, and that told the person making that what they needed to fix.
But the fact that the objectives are unclear, and posted in a box in font which doesn't blend with anything else, and has a lazy darkened transparency background is poor UI design, and poor game design. The box looks like a debug box. It doesn't match the rest of the (Ugly as fuck) UI.
The blood effects have been seperated from their background layer poorly, because they're a random item from a google search, and they're not actual assets with a transparency layer. The dev has taken no effort to fix this (Usually, you'd remove all the white, and applying a blur can fix the edges. Alternatively, just have the screen filtered with a red that gets darker, the same effect, less shitty, for no effort).
There is no indication that ammo pickups are only for the gun at hand, and no reason for this to be the case (It's not a feature, you can switch weapon to change it so it doesn't add difficulty). It's a result of lazy ass coding. It's a bug, that should be fixed. There's cash, but no indication of what it's for, and it lies on the ground, whilst the ammo seems to float. Health decreased below zero carries over, because the dev is too lazy to understand you can't just add 100 to the health to respawn, you have to reset the health (Either make it impossible to go below zero, or set the health to zero and then add 100, or set the health to 100. This is an embarrassing failure to understand WHAT A VARIABLE IS). The gun moves at a different pace to the fixed point reticule. There's no reason for that, particularly as there is no indication the game takes into account turn speed or recoil based on weapon position, like say, Killing Floor or Red Orchestra (The former being what the game looks to be ripping off.)
There are strange glowing particle effects which rise from corpses, for no discernable reason. These effects are not diffused, they occur specifically in visible pillars with a cutoff. The bodies continue to spasm and squirt blood, again, for no reason.
The music covers important audio cues, and is fucking annoying. The sound design in general blows. There's little in the way of feedback, when you collect ammo, or you run out of ammo, or take a hit.
The pause menu doesn't pause the game (Not because it's a feature, but because it's easier to bring up a menu than to pause the game). There are no control options in the menu, which is doubly damning because that can instruct players. There's an option to turn music off, but no volume option, so you can't balance the audio so that the game is playable with all cues.
The game includes features that aren't even working (If features aren't working at release, comment them out and put them in later. No-one wants to try to work out how your mines work).
And that's just basic errors in implementing graphics, and mechanics. These are the things that should come out the minute you test it (You, the DEV, should notice the problem with the blood. It's not working, so get rid of it, or fix it.) That doesn't even go to a direction for the game to go in, or even being fun. For instance, they game should direct the player to some objective to start, and they should have enough ammo that they won't run out so quickly and be forced to hunt for scattered ammo in stupid locations, running into Zombies, when the game so clearly wants you to kill large numbers of them. Is it DayZ or Killing Floor? Just being able to spawn some enemies and have them move towards the player, and giving the player the ability to shoot them is NOT game design. Give anyone a little while with an engine and they can have enemies stagger towards you for you to shoot. That is NOT a finished game. And this isn't someone trying to learn to make games, this is someone trying to make money off broken shit.
Yes, I completely agree with all of what you said. You went into more details into the failings than I had patience to. Kudos.Loonyyy said:
And yeah, I do think the game is fit for a major project. Although, it might depend on the university you're in and their criteria for one, but in general, I think it's sufficient. Sure, you'll probably lose some marks on the technical side but, again, write-up can save you. In theory. I imagine this developer's write-up wouldn't, though.
As something completely offtopic, but vaguely related to major projects and coding, here is a story: I had a friend in uni who realised quite late he didn't actually like or want to do a major in compsci - he couldn't wrap his head around programming and readily admitted it. His minor was in business and he really liked that. However, it was a bit late already to change over, so he grit his teeth and finished it. His major project relied mostly on the non-technical side - research, analysis and then a really thorough and good dissertation with minimal coding...or rather with an attempt to code something passable that ended up being futile. He did pass and with a good mark, too, however.
I guess it depends what year that project is, and what class. Their write up would have to be far harsher than what Sterling wrote, or what I wrote, because to nail a passing grade off that, every failure would have to be documented and suggestions for correction included. It would have a lot of trouble flying in any coding class, but perhaps there's a game design class he could get away with it in. I'm just not sure what it is that he's done, that he thinks is worthwhile, or that we're meant to be impressed by, since implementing health, ammo (I didn't see a reload), and placing enemies who run straight at you, in Unity, isn't that much, particularly as he's done it poorly. It's a series of counters, and he doesn't understand that in any programming environment, you can do things apart from add and subtract from number values, you can set them. It's clear he has little experience, and that he didn't ask for help, and that he didn't test it, or do any basic debugging, because these are simple compilable errors that are visible to the end user, and embarrassing in a finished product.DoPo said:
For instance, there were a bunch of guess the number games in my class, and they only got a bare minimum pass, if they wrote it up well and demonstrated basic competency in coding, methods, including loops, variable types etc. My friend made Battleships, and to bring that to the A standard, he had to implement an AI system, and various difficulties (IIRC, the lowest difficulty was random guessing, the hardest would occasionally cheat, and the medium one was where he put in most of his work, having the game play like a person, randomly guessing until a hit, and then testing around the hit to find the boat).
I guess the dev gets points for putting together sound, level, and animations, and maybe that's enough for an early enough design class, but my friend's boyfriend is currently doing 1st year game design, and working in Unity (Among a couple of other environments), and his stuff is much more impressive. I beta tested his last game for assessment, he combined bullet Hell with Helicopter, had randomly spawning enemies, power ups, and I think he eventually implemented a saving system for persistant high scores, based on his testers feedback. He made the assets himself in paint, and composed the music himself. It's a lot less advanced than an FPS, but it's working to his strengths, and allows him to demonstrate his work. Added to that, building an FPS in a standard Devkit isn't nearly as hard as building one from scratch, the hard part, the maths relating to 3D space, is all done.
With regards to your friend, the best programmers and designers know their limitations. Someone who works to their strengths and readily acknowledges where they're weak is much more valuable to a team, and they're much more capable of delivering on their goals. I started on coding fairly early, my first experiences were designing and programming lego mindstorms robots for "Robocup". In the first year, my team made it to 5th place, and would have placed higher if we didn't have some serious technical issues on the second day that I didn't resolve correctly (TV crews were in, and the lighting was completely different, and I tried to fix a specific part of my program instead of admitting defeat and removing it).
But we got so far by using basic programming, and using it well. We had some ambitious ideas and concepts, and we implemented them using incredibly basic code. The amount of over-ambitious robots, and over-ambitious programming, where the only thing that can be said for them is that they wanted X, but didn't attain it, is always extremely disappointing. People used custom electronics kits, custom boards, or programmed in C, or worse, only to make the same basic robot. It's admirable to fail at doing something new and unique, but you actually have to do have a unique, and new goal in mind, and do something towards that goal. There are people who seriously innovate, and they aren't always rewarded for that, but there's also always a bunch of hacks who can't put anything up there and are left making excuses.
It sounds like your friend is a pretty clever guy.