Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Heres a short film I did on Saturday for a small online competition. With UNREAL this took me like 6 hours in total - from thinking of the idea to the final piece. Obviously its rough around the edges - but it shows the power of the engine for an artist. I legit don't think I would have been able to even render ONE of these shots in the same amount of time it took to put the whole thing together.
I just checked the screenshots, and of course it has cartoony art style. UE is good for cartoony, but once you go for something more photorealistic, seams start to show.
(Unless you're inXile who can't even make cartoony look good in UE)
Watched a clip on YouTube. Static backgrounds and char models are fine, but environment textures have the characteristic UE soapiness to them. Especially in bright light e.g. from fires that looks pretty horrible to me.
The competition itself was just to take a 3D model that was provided (the skull with the crown), and remix it into your own piece of work. As the skull was labeled as a 'gift' to the art community, I thought I'd take that literally and have something centered around giving thanks for the gift.
I did it more as a way to experiment with my ideas and things I've learned with Unreal for the past few weeks I've been learning it! I always find I learn best when I have a 'project' on!
The competition itself was just to take a 3D model that was provided (the skull with the crown), and remix it into your own piece of work. As the skull was labeled as a 'gift' to the art community, I thought I'd take that literally and have something centered around giving thanks for the gift.
I did it more as a way to experiment with my ideas and things I've learned with Unreal for the past few weeks I've been learning it! I always find I learn best when I have a 'project' on!
I thought it looked great, especially once I knew the timeframe you were working with. The *way* you painted with light was very convincing. You did something that so many others seem to get wrong too - you had the specularity of the material dialed in well. Things didn't look plastic, there was enough matte.
I think a big thing is that I've been using PBR materials for years, so Im sensitive to the setups and know how to adjust them to get it to look 'right'. I'm still in the early days of learning Unreals shader systems - so I'm sure I'll get better as time goes on! I started out in Architectural Illustration - so getting surfaces to look 'real' was probably 90% of the job!
Thanks mate! We are on right in the early part of the show - if anyone wants to watch.
Small side note - just before I did this, my car battery died just before I was leaving to drive to Nic. As I opened up my car to jump it - I noticed that a whole lot of snails had taken shelter on my car engine a while ago... and my driving had heated up the engine and pretty much baked them into the engine cover. So tomorrow, I'm cleaning whats left of the snails from the engine.
If anyone wants to try their hand at some game writing:
We are looking for awesome writers for Bone Totem. If you would like to submit a quick sample, please complete our exercise here: 100-200 words; describe a horrific surgical procedure from the point of view of either the doctor or the patient. Please use this form only: https://www.thebrotherhoodgames.com/studio/writing-application/
If anyone wants to try their hand at some game writing:
We are looking for awesome writers for Bone Totem. If you would like to submit a quick sample, please complete our exercise here: 100-200 words; describe a horrific surgical procedure from the point of view of either the doctor or the patient. Please use this form only: https://www.thebrotherhoodgames.com/studio/writing-application/
If anyone wants to try their hand at some game writing:
We are looking for awesome writers for Bone Totem. If you would like to submit a quick sample, please complete our exercise here: 100-200 words; describe a horrific surgical procedure from the point of view of either the doctor or the patient. Please use this form only: https://www.thebrotherhoodgames.com/studio/writing-application/
If anyone wants to try their hand at some game writing:
We are looking for awesome writers for Bone Totem. If you would like to submit a quick sample, please complete our exercise here: 100-200 words; describe a horrific surgical procedure from the point of view of either the doctor or the patient. Please use this form only: https://www.thebrotherhoodgames.com/studio/writing-application/
Cliff Harris wrote a great article here: https://www.positech.co.uk/cliffsblog/2021/10/14/common-mistakes-by-indie-game-developers/ and I’ve made my own list:
Pick a software tool and stick with it. We used Unity 5 for Beautiful Desolation, only upgrading to 5 when we had hardware compatibility issues and we have now moved to the 2019 LTS branch and don’t intend to move until the game is shipped. We use 3D Max 2019 and only just moved from 3D Max 2014! We pay for a subscription every year but we always use an older version and only upgrade if there are performance or plugin benefits. Don’t use the cutting edge tool/plugin/lighting solutions, stick with the tried and tested methods. if you need to test fancy solutions, do it in your spare time or as a reward (see finishing early). Don’t get sucked into the technology paralysis loop – use what works!
Use the assets store, sound sample websites, and pre-created graphics whenever possible. You can retexture a model or tweak a sound effect but it is a hundred times cheaper than commissioning it or doing it from scratch. You can always replace assets later if really needed. Don’t listen to the neigh sayers who have never shipped a game. I swear by the A* Pathfinding Pro asset on Unity store. I’ve written pathfinders and they don’t come close to this asset – so why would I waste time trying to reinvent the wheel. All the C# scripts are provided, so I can check how things work under the hood. That goes for a host of other amazing premade scripts and tools.
Don’t get sucked into the pre-production, over design stage of game development. Do a basic outline of what needs to happen in its barest form – no-frills and make it. Then iterate from there. Once you have a basic gameplay loop you can start planning out the story, puzzles etc.
Register on Steam EARLY, pay the fee and build often, you don’t have to make the page public, keep it private. We use Steam to distribute our internal builds, if you batch this it takes minutes to disseminate. You can then test the game in the Steam environment and pickup errors early.
Backup, repo and version your work! Use GIT with some kind of offsite solution or at the very least work from a Dropbox folder. Use the 3,2,1 rule. 3 Copies at all times, 2 local, 1 off-site (online is fine).
Automatically track your build versions. You can run a post-build script automatically that increments a counter that shows in your main menu, this goes a long way in the early and late testing phase.
Build often. Initially, during your vertical slice, it should be daily, then when you are adding content at least weekly. In crunch, you will be doing it a few times a day. Issues WILL pop up in a deployed build that do not show in the editor environment.
Stick with your script framework between games and iterate, there is no need to reinvent the wheel each time. After hundreds of thousands of players have tested our games we would be nuts to start from scratch. It takes a day between games to rip out the old assets, clean up the repository and get into the next game. Don’t reinvent technology each time, the idea is to make and finish the game.
Design your framework with future games in mind. Be mindful of folder structure, proper script naming, etc. As an Indie we need to use ever single trick in the book to get our games done faster and in budget.
Set a daily goal. If you are indie and working from home, set yourself a goal on where you need to be at the end of the day. Be realistic but make sure it’s done before you leave. If it’s done in half the time, then use the rest of the time constructively in the pursuit of the game. Reward yourself by working on a different aspect of the game or researching a new technology but don’t do something YOUR-non-indie-game-productive like watch a movie or play a game during ‘work hours’.
Pick a test machine that is your mid to lowest-tier pc and stick with it. I have the same test build machine that I have used for 3 games. I know that if it runs on this machine it should run on almost anything. I do try and keep Windows updated because we can assume most players do.
Pick one platform to launch on and make sure it’s Windows. You can add others later. We launched a game on Windows, OSX, and LINUX on day one and it was massive stress that could have been avoided. Players don’t mind a staggered release if you are honest about it. Get the bugs ironed out and players, playing.
Don’t get distracted by Streams or the latest drama on Twitter/Discord and Reddit. These are a waste of time and suck your creativity. Do it on your lunch break or in the morning or after work.
The translation of your game should not be an afterthought, so don’t hard-code any text strings.
Translation files should use .csv – avoid JSON or XML – they are hard to debug and hard for casual translators to work with.
Translation files should NOT contain logic. I am guilty of this, don’t be me!
Don’t over plan. Just get the bare minimum on the screen and see how it feels. I always start with the player movement and build out from there.
Think about save/load mechanisms early, this should be next on your list once you get your gameplay loop done. Don’t leave this to last! You need to think about how states and variables are stored.
Save game states should be version-independent! Make sure your saves will load regardless if you make changes to the scene or code. When you serialize data be very sure you can make significant changes and unserialize successfully. Test this early!
Savegames should work across platforms!
Build a debug tool early, you should be able to get feedback in a full build, check variables in-game. There are loads of pre-built solutions for this or doing your own is trivial. It doesn’t need to be fancy or look amazing. Just give you feedback on what is happening under the hood.
Allow super quick access to your game for artists or scene/level assemblers. They should be able to jump in quickly to test out an art asset or design. Don’t make them wait 5 minutes each time, if they iterate quickly the game will look better.
Optimize early, don’t leave performance to the end of the production. Game developers will often tell you not to pre-optimize. As an indie, ignore this advice. Write as good clean code as possible and always keep poly counts, garbage collection, and so forth in mind. You should ALWAYS watch the FPS, Tris, Render count, etc. Build from asset bundles when possible, don’t use the resource folder, etc. Read up on how the stack works and how to manage memory…If you have to optimize at a later date you will have a headache. You can iterate later if needed and trust me, your old code will be garbage a year down the line but that doesn’t matter. If you wrote it performant to start then it should be fine!
Pool everything. If you don’t know what pooling is then google it. A decent programmer should be able to whip up a solution in a few hours or use a prebuilt asset if you must.
Keep an eye on your frame rates in real builds, not the Editors. See BUILD OFTEN!
Once you have some kind of gameplay that you intend to take to completion, tweet about it. Shout about it, Discord about it. This is hard and we are still learning as well but you need to market early and consistently.
Pyke I love your games man, but the scrolling on your website makes me want to punch someone in the face. Just use the default browser scroll behavior, you don't need to be cute with it. Right now one click of the scroll wheel is moving at least 1/2 to 3/4 of a page of text at once. I have never observed this on any other site...
