• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.
When I first started developing GunWorld 2 I knew I wanted to do a Boss Rush at the end of the game, but I had this crazy idea that you should be able to fight multiple bosses at the same time during the Boss Rush.

So from the start I had to develop some of my bosses with the idea that they would eventually be paired up with another boss, and that encounter needed to be both fun and challenging on its own, yet still fair and manageable when paired up with another boss.

It ended up being a lot more fun to solve that problem than I expected. I just finished tuning up the Boss Rush at the end of the game now, and I think it came together super well.
That has to look crazy! Make like a 5 second GIF!
 
That has to look crazy! Make like a 5 second GIF!

This is the Boss Rush phase that combines Sala-Man-Der and Buff-Alo (Buff-Alo's animations aren't finished yet).

Both are projectile based bosses with different movement patterns. I specifically tuned each fight to be fun and challenging on its own (for their appropriate part of the campaign), but also their movement and projectiles line up in such a way that you can fight them at the same time and (at that point in the game) it *shouldn't* be overwhelming to the player.

They occupy completely different portions of the screen to each other, so you don't have situations where they box you in, and their projectiles are lined up well enough to mix with each other and provide more than enough options to dodge.

giphy.gif


There are two other bosses, Nightmare and Mi-Crow-Wave, that are designed to work in this same way.
 

Labadal

Member
What made you interested? Graphics or gameplay?

A bit of both. Graphics was what made me stop and look. The name had a hand in getting my attention. Then I watched the trailer and thought, this looks like something I might get if I don't have anything to play.
 

jarosh

Member
Yeah, I've been thinking about a PC version and greenlight. Not sure how much people would really be into a runner on PC, but it's worth a shot, right?

There's quite a lot I'd need to add to accommodate for the PC audience, so it won't be until after I drop 4.0 onto iOS at which point I'll probably branch between mobile and PC.

We'll see :)

I don't really play mobile games and I'm not really into runners either. But I would definitely play this even if it was just a straight port. It looks really fun from the video I've seen and, again, I am just in love with the Game Boy aesthetic. It looks great in motion too. Of course it would be awesome if you could extend the gameplay and interactivity somewhat for a PC port, but I'm not sure what that would entail, since you obviously can't just give players free movement. Either way, I'm definitely gonna keep it on my radar ;)
 

bumpkin

Member
I know there's a hundred and one ways to do everything and there's always staunch defenders or opposition to everything, but in general, what is the consensus on using Singletons for "systems" like rendering, sound, input, etc. around these parts? Good? Bad? Whatever works?

I'm having this challenge where my game object hierarchy is like so:

Code:
Engine
    Scene(s)
        Layer(s)
                Game Object(s)
                        State(s)

I'm having this challenge when I need a Game Object (like a character) to be able to create new objects (like bullets), but the place the trigger for this could happen is inside of a given state.

Making all systems Singletons and creating a game object factory system seems like the easiest approach, I just don't know if that's a terrible idea or not.

What say you, Indie programmer GAF?
 

Blizzard

Banned
Making all systems Singletons and creating a game object factory system seems like the easiest approach, I just don't know if that's a terrible idea or not.

What say you, Indie programmer GAF?
I have a "resource library" factory for things like this. It's not technically a singleton, but I've only been using one resource library thus far so it's effectively a singleton.

WARNING: For something that could produce a ton of objects like bullets, you may want a specialized factory so you can recycle them. The "flyweight" design pattern may relate to this but I've never done much reading on it.
 
I know there's a hundred and one ways to do everything and there's always staunch defenders or opposition to everything, but in general, what is the consensus on using Singletons for "systems" like rendering, sound, input, etc. around these parts? Good? Bad? Whatever works?

I'm having this challenge where my game object hierarchy is like so:

Code:
Engine
    Scene(s)
        Layer(s)
                Game Object(s)
                        State(s)

I'm having this challenge when I need a Game Object (like a character) to be able to create new objects (like bullets), but the place the trigger for this could happen is inside of a given state.

Making all systems Singletons and creating a game object factory system seems like the easiest approach, I just don't know if that's a terrible idea or not.

What say you, Indie programmer GAF?
You don't need to go the singleton route. You could always make this part of an event system. When a bullet should be added, throw out an instantiation event and then you have an object that listens for these events and adds new bullets as needed.

I implemented something like this for a school project a few years ago. I could probably do it better now, but my approach at the time was quick and simple.

The basic idea is that you have a central message dispatch class (think of it as the postal office), and when objects want to hear about certain types of messages, they register themselves with this message dispatcher basically saying hey, I care about these types of messages, so please let me know when they come in. Then you just publish messages to the dispatcher from anywhere in the code and the dispatcher will then notify all objects that have registered for that particular type of message. This results in you having a fairly significant decoupling of code. No direct instantiation in areas of code that really shouldn't need to care about such things, and if you need to change how a message is handled, the objects that care about said message don't really need to know (unless you're just straight up removing it or changing who will care about said event of course).

I did it in C++, so I made messages a struct consisting of an enum and a void*. When some object went to handle a message, it would take a look at the enum value and based on that enum value it would cast the void* to the correct type and then use the data from there.

There are other ways of doing such things in other languages, but that's just my example for a simple C/C++ based approach.

With respect to all systems as singletons - don't do it. It's easier now, but the type of code that singletons allow is insidious. There is a reason that singletons are known as code smells. The best description I've read of them is that 'Singletons are the politically correct name for global variables in OO".

I made the mistake of making the systems singletons, and I paid for it dearly with all the stupid shit my classmates did with the code. It was a bloody horrible idea. I was working in a group of 4 other students, and by the end of the project, there was all sorts of shit in places where they didn't belong. If you ever plan to work with somebody else, you don't know their level of competence. You don't know if they understand the long term cost of code with a lot of dependencies on other classes. If you make your systems all singletons, and you work with others, you bet your ass that somewhere along the way someone will do something ridiculous like create methods in the rendering system that are called in the physics system. This happened in spite of me doing my best to provide an architecture that allowed the separation (via the messaging system). The second those singletons come in, all bets are off. You completely lose your ability to reason about the separation of code. It makes it harder to track down bugs since everyone can access everything.

The central dispatch system may end up becoming a singleton (or global - same shit, different name), but at least the global state is contained to that single class, and all it's doing is dispatching messages. The implementation of how you handle said messages can vary - either immediate calls (IE - a call to an object where you essentially go 'object->handleMessage(message)') or you can just have each object have a mailbox that they check at certain points in time.
 
Yeah, the new 2D stuff looks amazing, but they keep pushing back the release. :(

They have a lot to fix before they start releasing new stuff. Every new build seems to break everything for no good reason. It's not that they deprecate things, either. Stuff just breaks.

Like, a few of my weapons have a trail renderer attached, but if I spam the hell out of it - which is needed - the trails just randomly disappear for no reason. If i go slow - they stay. I've tried this with empty scenes and simple objects but once i hit a threshold they all go away. It's weird.
 
I'm trying to build out a population list for the town center in my game, and I'm struggling to find the right balance of NPCs. The more of them I have the more fleshed out and full the town will feel, but also it'll be a lot more work and difficult to distinguish between them. I'm shooting for kind of a Majora's Mask feel here, except since the game runs indefinitely instead of only three days then the characters will have the same routine every day.

Current count is fifty-one NPCs. Some of these play much more important roles than others, including two that are also boss fights, but I'm wondering how many should stand out on their own. At what point does it get too noisy? If I think of a game like Dark Souls, there's not more than a dozen stand out characters. But then a game like Psychonauts has somewhere around fifty different unique and interesting characters. I realize with the latter that's mostly a tribute to Tim Schafer and Erik Wolpaw's writing ability, and I don't want to pretend I'm on their level, but I'm still curious to hear opinions on the matter.
 
I forgot how much fun it can be making AI for stuff sometimes, especially 'bots': Attempting to capture and mimic a lot of the subtler traits that players tend towards, so the bots feel more 'natural', can be oddly rewarding :D
Especially when the testers point out those little quirks you've put in when they're playing :3

We're not on Steam.

Still in the Steamworks process.

I am literally fucking serious when I tell everyone that I may write a book about making this game. It's been such a ridiculously slow process. So many things we learned from doing them completely wrong. But it's all experience.

Never let anyone tell you that experience is worthless.
Definitely. As long as it's learned from experience is always valuable. Some things just need to be seen in motion or experienced before you truly understand them :3

Thanks, means a lot. Been poking at this for quite a while. Started to feel like nobody cared anymore :p
Aww. I guess I never posted about it but I've always been impressed by the presentation on it in all the gifs you've posted. It has all kinds of neat lil touches and I tend to envy anyone who can really pull off aesthetics suited to stuff like the gameboy or whatnot :D
 
I'm trying to build out a population list for the town center in my game, and I'm struggling to find the right balance of NPCs. The more of them I have the more fleshed out and full the town will feel, but also it'll be a lot more work and difficult to distinguish between them. I'm shooting for kind of a Majora's Mask feel here, except since the game runs indefinitely instead of only three days then the characters will have the same routine every day.

Current count is fifty-one NPCs. Some of these play much more important roles than others, including two that are also boss fights, but I'm wondering how many should stand out on their own. At what point does it get too noisy? If I think of a game like Dark Souls, there's not more than a dozen stand out characters. But then a game like Psychonauts has somewhere around fifty different unique and interesting characters. I realize with the latter that's mostly a tribute to Tim Schafer and Erik Wolpaw's writing ability, and I don't want to pretend I'm on their level, but I'm still curious to hear opinions on the matter.
I personally prefer fewer standout NPCs. Its nice to have a bunch of NPCs that all have a purpose or stand out, but that takes away potential for the player to really engage and click with a few if there's a lot of noise in the mix. Having fewer might up the story arc a bit if relationships can be forged with one or two.
 
I know there's a hundred and one ways to do everything and there's always staunch defenders or opposition to everything, but in general, what is the consensus on using Singletons for "systems" like rendering, sound, input, etc. around these parts? Good? Bad? Whatever works?

I'm having this challenge where my game object hierarchy is like so:

Code:
Engine
    Scene(s)
        Layer(s)
                Game Object(s)
                        State(s)

I'm having this challenge when I need a Game Object (like a character) to be able to create new objects (like bullets), but the place the trigger for this could happen is inside of a given state.

Making all systems Singletons and creating a game object factory system seems like the easiest approach, I just don't know if that's a terrible idea or not.

What say you, Indie programmer GAF?

I'm a fan of the Singleton pattern for things like this. Specific managers (audio, in particular) rarely ever need to have more than one instance, so they're set up for Singletons nicely, in my opinion.

Personally, I use an auto-instantiating prefab with Unity. That way I can have a single manager that'll get auto-instantiated from a prefab the first time I access any of its methods. Basically a kind of hybrid lazy-load.

I don't really get all of the general hate for Singletons. They're super-userful, if used correctly (and not overused), so I think that the main pain-point for a lot of people is working out how to use them effectively without making everything a Singleton because it's easier to access.
 
I personally prefer fewer standout NPCs. Its nice to have a bunch of NPCs that all have a purpose or stand out, but that takes away potential for the player to really engage and click with a few if there's a lot of noise in the mix. Having fewer might up the story arc a bit if relationships can be forged with one or two.

That's how I'm leaning right now. Most of the characters can be observed and studied if the player so chooses to, and maybe with a few throwaway lines of dialog if you choose to interact with them, but otherwise only focus strongly on a handful of the characters.


I'm a fan of the Singleton pattern for things like this. Specific managers (audio, in particular) rarely ever need to have more than one instance, so they're set up for Singletons nicely, in my opinion.

Personally, I use an auto-instantiating prefab with Unity. That way I can have a single manager that'll get auto-instantiated from a prefab the first time I access any of its methods. Basically a kind of hybrid lazy-load.

I don't really get all of the general hate for Singletons. They're super-userful, if used correctly (and not overused), so I think that the main pain-point for a lot of people is working out how to use them effectively without making everything a Singleton because it's easier to access.

Yeah, I don't understand the aversion either. I'm fine if there are people who prefer to program without them, but I've never had a problem. The game I'm making right now has three singletons. One for the player character, one for the level editor, and one for the general runtime controller.
 

jrush64

Banned
Thought I'll show a character for my game. Finished this afternoon. I made a base female face that I can modify into other faces, Maya's sculpting tools will be helpful. The hair was difficult to make but I might have to redo it cus it's pretty high poly for now.

It's a school uniform with long socks and loafers. I'm a little worried the skirt is too short, so I made 2 versions with one reaching her knees.
 

senahorse

Member
Is there anything stopping me using Unity personal addition on multiple computers (not simultaneously) along with all the assets I have bought from the store? I am considering bringing a laptop into work and doing some dev on my lunch breaks.
 
Is there anything stopping me using Unity personal addition on multiple computers (not simultaneously) along with all the assets I have bought from the store? I am considering bringing a laptop into work and doing some dev on my lunch breaks.

Not really. There's nothing preventing you from installing the non-pro editor on multiple machines, and most Assets are per-seat, so you should be fine (as long as you're the only one using the Assets).

I'd be more concerned with doing your development at work. Some places have contract clauses that any work done on-premise or on company-owned property (including computers) is owned by the company, so you may want to check on that if you currently do something like this professionally.
 

senahorse

Member
Not really. There's nothing preventing you from installing the non-pro editor on multiple machines, and most Assets are per-seat, so you should be fine (as long as you're the only one using the Assets).

I'd be more concerned with doing your development at work. Some places have contract clauses that any work done on-premise or on company-owned property (including computers) is owned by the company, so you may want to check on that if you currently do something like this professionally.

Thanks for your reply. I currently work at a university which is very open minded about such things, and as long as I am not using their equipment or doing it during my work time (lunch breaks excluded) it's fine to do.
 

Lautaro

Member
So I decided to give a try to the artistic side of gamedev and I gotta say is a PITA. Here's what I'm currently trying to make:

gg3WpM3.png


I tried to make a simple spaceship but I think I fucked up the UV. What should I consider when making UVs? every face should be as square as possible for quicker painting?

I did enjoyed modelling in Blender but the unwrapping and the painting in GIMP have been really tiring... any tips to speed up a Blender -> GIMP -> Unity workflow?

Programming is way easier IMO.
 
That's how I'm leaning right now. Most of the characters can be observed and studied if the player so chooses to, and maybe with a few throwaway lines of dialog if you choose to interact with them, but otherwise only focus strongly on a handful of the characters.




Yeah, I don't understand the aversion either. I'm fine if there are people who prefer to program without them, but I've never had a problem. The game I'm making right now has three singletons. One for the player character, one for the level editor, and one for the general runtime controller.

If you program a sufficiently complicated game within the framework of team (so not just yourself), you'll quickly see the downsides of singletons. You spread dependencies throughout the code, compile times go up, coupling goes up, and things become harder to change. Objects all over the place end up doing things they shouldn't really be concerned with doing. If it's just yourself, you can use singletons fine as long as you maintain some discipline in how you're utilizing them, but we should really call a spade a spade. Singletons are globals. If you've never had an experience with global variable hell, then it's harder to see why this is a bad thing.

I work as a software developer and deal with some fairly entangled code bases. Every single day I deal with the cost of global state in a codebase with millions of lines of code. The number one reason that I find global state to be bad is it makes it very hard for you to reason about changes that you're making. If every object has access to and depends on the state of a bunch of global variables, it gets hard to understand all the implications of code in any given method/function. You may not realize when some random method/function is going to change the state from underneath you.

Lets say you have the following (arbitrary) code:

...
someObject.someMethodThatDoesSomething();
someObjectTwo.someMethodThatDoesSomethingElse();
// Some other code that relies on the state of global variables modified above
...

Now you wrote these two methods a long long time ago, so you may not remember what they do, but on the surface they look harmless. Now assume that someMethodThatDoesSomething() modifies a global variable, and assume that someMethodThatDoesSomethingElse() relies on the value of that global variable. When you come back to read this code 6 months later, and you forget that relationship, and you start changing things and reordering code, you may end up introducing bugs until you hunt down the fact that this relationship exists again.

This is a VERY simple example, but if you abstract the general idea to real code, and the messy nature of real code, I think it's a fairly intuitive step to see how this could be very bad.

Now you can make the situation even worse: assume your codebase is multithreaded. If you have a bunch of different places in code all modifying the same global variable, and the project is small, you might still be able to reason about the state of that variable and the code depending on it. Make it a large project, or even medium sized, and add multithreading to the mix, and you're in for some awful, awful heisenbugs. Bugs that, when you try to debug or observe the behaviour, disappear. Bugs where adding a print statement sufficiently changes the timing in order to make it no longer occur, or even causes a different bug to show its face. Dealing with bugs where you can't rely on a debugger or a print statement due to timing changes is truly maddening. I've seen cases where bugs existed in a release build but not in a debug build simply due to the extra optimizations that compilers do when compiling code for a release build.
 
If you program a sufficiently complicated game within the framework of team (so not just yourself), you'll quickly see the downsides of singletons. You spread dependencies throughout the code, compile times go up, coupling goes up, and things become harder to change. Objects all over the place end up doing things they shouldn't really be concerned with doing. If it's just yourself, you can use singletons fine as long as you maintain some discipline in how you're utilizing them, but we should really call a spade a spade. Singletons are globals. If you've never had an experience with global variable hell, then it's harder to see why this is a bad thing.

I work as a software developer and deal with some fairly entangled code bases. Every single day I deal with the cost of global state in a codebase with millions of lines of code. The number one reason that I find global state to be bad is it makes it very hard for you to reason about changes that you're making. If every object has access to a bunch of global variables, it gets hard to reason about the state of that global variable since you never know when some random method is going to modify it.

Lets say you have the following (arbitrary) code:

someObject.someMethodThatDoesSomething();
someObjectTwo.someMethodThatDoesSomethingElse();

Now you wrote these two methods a long long time ago, so you may not remember what they do, but on the surface they look harmless. Now assume that someMethodThatDoesSomething() modifies a global variable, and assume that someMethodThatDoesSomethingElse() relies on the value of that global variable. When you come back to read this code 6 months later, and you forget that relationship, and you start changing things and reordering code, you may end up introducing bugs until you hunt down the fact that this relationship exists again.

This is a VERY simple example, but if you abstract the general idea to real code, and the messy nature of real code, I think it's a fairly intuitive step to see how this could be very bad.

Now you can make the situation even worse: assume your codebase is multithreaded. If you have a bunch of different places in code all modifying the same global variable, if the project is small you might still be able to reason about the state of that variable. Make it a large project, or even medium sizes, and add multithreading to the mix, and you're in for some awful, awful heisenbugs.

Meh. Bad organizing is bad organizing no matter what tools you use. Singletons aren't the problem here, it's insufficient labeling and inadequate structure design.
 

Razlo

Member
When I first started developing GunWorld 2 I knew I wanted to do a Boss Rush at the end of the game, but I had this crazy idea that you should be able to fight multiple bosses at the same time during the Boss Rush.

So from the start I had to develop some of my bosses with the idea that they would eventually be paired up with another boss, and that encounter needed to be both fun and challenging on its own, yet still fair and manageable when paired up with another boss.

It ended up being a lot more fun to solve that problem than I expected. I just finished tuning up the Boss Rush at the end of the game now, and I think it came together super well.

That's interesting, never seen Boss Rush done that way.
 
Meh. Bad organizing is bad organizing no matter what tools you use. Singletons aren't the problem here, it's insufficient labeling and inadequate structure design.

Ah, so you have not encountered global variable hell. Okie. It's clear to you that singletons are globals, ya?

The problem isn't that you CAN'T write good code with the use of globals. The problem is that just having them allows for a very easy and fast way to get to some pretty bad spaghetti code. If you code alone or in a small team, no big deal. If you code in a larger team, you can't control what others do, so denying them the ability to access state via globals protects the design and structure. If you're working on a small project, then the extra thought required to avoid global state may just not be worth it. Context matters here.
 

shaowebb

Member
So I decided to give a try to the artistic side of gamedev and I gotta say is a PITA. Here's what I'm currently trying to make:

gg3WpM3.png


I tried to make a simple spaceship but I think I fucked up the UV. What should I consider when making UVs? every face should be as square as possible for quicker painting?

I did enjoyed modelling in Blender but the unwrapping and the painting in GIMP have been really tiring... any tips to speed up a Blender -> GIMP -> Unity workflow?

Programming is way easier IMO.

Why leave Blender to unwrap? Its got fantastic unwrapping options.

Here. Watch these and enjoy yourself. It'll show you several ways to unwrap and how to completely customize your UV stuff to get the best checkerboard test so that none of your stuff looks stretched. It'll also help you to layout your UV's on a single map even if its done as multiple objects or polygroups.

pt 1 basics
pt 2 organizing UVs, various unwrap methods, checkerboard testing
pt 3 how to fix your UV's if your checkerboard texture shows signs of stretched textures
pt 4 good ol Ctrl A/Ctrl P averaging and organizing UV maps

Went through those last week and its a breeze now. Better than the old Maya and Zbrush stuff and thats saying something. Just super fast and powerful. Plus remember that after all this you can use RIGIFY in Blender to expedite rigging, weighting, and setting up controls for your models. Its really top notch and you'd be surprised how well the muscle weighting is.
 
I'm trying to build out a population list for the town center in my game, and I'm struggling to find the right balance of NPCs. The more of them I have the more fleshed out and full the town will feel, but also it'll be a lot more work and difficult to distinguish between them. I'm shooting for kind of a Majora's Mask feel here, except since the game runs indefinitely instead of only three days then the characters will have the same routine every day.

Current count is fifty-one NPCs. Some of these play much more important roles than others, including two that are also boss fights, but I'm wondering how many should stand out on their own. At what point does it get too noisy? If I think of a game like Dark Souls, there's not more than a dozen stand out characters. But then a game like Psychonauts has somewhere around fifty different unique and interesting characters. I realize with the latter that's mostly a tribute to Tim Schafer and Erik Wolpaw's writing ability, and I don't want to pretend I'm on their level, but I'm still curious to hear opinions on the matter.

Army of Tentacles has 68 characters, but those are all static encounters. I realize the two are completely different concepts, but you shouldn't limit yourself because you think you are not good enough.
 
Ah, so you have not encountered global variable hell. Okie. It's clear to you that singletons are globals, ya?

Of course they are. They function as globals but they have a different visual interface so that they appear friendlier, because humans are irrational, try as we like to be otherwise.

I'm not dismissing that you can get into trouble with them, but you can get into trouble a lot of things. You can make a while loop that never closes. You can keep indexing more and more memory without freeing memory you've stopped using. That doesn't make while loops or indexing memory bad, that makes them something you have to be careful with.

Singletons are a tool to make certain uses of global variables more intuitive and approachable for human programmers. That makes them a good thing.


Army of Tentacles has 68 characters, but those are all static encounters. I realize the two are completely different concepts, but you shouldn't limit yourself because you think you are not good enough.

See, that seems like a lot to me. But maybe it's not? Were you aiming for more originally, or what was the thought process there?
 
Of course they are. They function as globals but they have a different visual interface so that they appear friendlier, because humans are irrational, try as we like to be otherwise.

I'm not dismissing that you can get into trouble with them, but you can get into trouble a lot of things. You can make a while loop that never closes. You can keep indexing more and more memory without freeing memory you've stopped using. That doesn't make while loops or indexing memory bad, that makes them something you have to be careful with.

Singletons are a tool to make certain uses of global variables more intuitive and approachable for human programmers. That makes them a good thing.

I think you're overly simplifying the issue, and perhaps it's due to not having experience in working on projects with larger teams. I can't control other people that are going to use my code, and add to it, so if I provide them with the ability to access state globally, it's going to get abused with a sufficient number of people modifying the code. This has actually happened to me before. I'm not repeating some dogmatic mantra espoused by Stack Overflow zealots. I've seen it happen. I edited my posted above to give more details.
 

shaowebb

Member
Sorry, my english is confusing sometimes. I meant I did the modelling AND unwrapping in Blender, the painting in GIMP.

Thanks for the videos.

Oh okay. I was wondering there for a bit because I knew GIMP was a photoshop-like program. I was kind of curious how the hell it unwrapped models, but since Photoshop has 3d UV painting stuff these days I didn't rule out that maybe unwrapping itself was moving into the texture editing softwares. Heck, Adobe is now working with Mixamo and they make Fuse and autorigger stuff along with maintaining a market of animations and models so I don't rule out much anymore.

As for what to consider in GIMP I don't know the program, but its not so much making every UV as square as possible. Just making certain textures dont stretch and are seamless (or hid seams well). For that, follow the tutorials I linked. They cover how to clean up UV's to insure your textures come out nicely. They show how to edit the maps in multiple ways to tug them and cut them up and group them so that your textures come out well. Hopefully thats all you need. If you're straight up painting on the map in GIMP though it'll be hard guess work with the shapes UV's tend to come out in to get them precisely painted for specifics. For that I tend to paint on the model in a 3d modeling program ( I usually use Zbrush but I wish to see if Blender has RGB painting options too). Once I paint the general look onto the model which tends to be grainy I export that into my painting program (photoshop), make a new layer and paint my actual textures in detail using the "rough" one I made in the 3d program as a guide.

Its back and forth and painting directly on the model by flipping to that window in Photoshop helps me.
I don't know if Gimp does that last part so it'd be best look up GIMP to Blender texturing on youtube for awhile. The guy in the vid I showed though does great stuff. He may have something for you.

EDIT: For what its worth, I'm new to blender too. Just started this month. But I got a lot of experience in 3d modeling in general from about 4-5 years of Maya, Zbrush, Photoshop stuff. Maybe we can ask each other questions as we go along in case one of us discovers any tips or tricks that the other one might find helpful. :)
 

Blizzard

Banned
I think you're overly simplifying the issue, and perhaps it's due to not having experience in working on projects with larger teams. I can't control other people that are going to use my code, and add to it, so if I provide them with the ability to access state globally, it's going to get abused with a sufficient number of people modifying the code. This has actually happened to me before. I'm not repeating some dogmatic mantra espoused by Stack Overflow zealots. I've seen it happen. I edited my posted above to give more details.
This is a bit of a rude post to jump on the "perhaps you don't have experience" attack when someone disagrees with you. :/

Meh. Bad organizing is bad organizing no matter what tools you use. Singletons aren't the problem here, it's insufficient labeling and inadequate structure design.
To put this another way, if people are going to make bad, global-affecting changes in a group project, and they're allowed to get this through code review, they will presumably do it.

Having code mechanisms that insulate things makes it more difficult for them, but they could still potentially change or implement something in a poor manner.

If the argument is that avoiding singletons makes it easier to spot problematic interactions in code reviews, then sure that may be fair enough.
 
This is a bit of a rude post to jump on the "perhaps you don't have experience" attack when someone disagrees with you. :/


To put this another way, if people are going to make bad, global-affecting changes in a group project, and they're allowed to get this through code review, they will presumably do it.

Having code mechanisms that insulate things makes it more difficult for them, but they could still potentially change or implement something in a poor manner.

If the argument is that avoiding singletons makes it easier to spot problematic interactions in code reviews, then sure that may be fair enough.
To be honest I thought her post was rude, so I responded in kind. I thought it was overly dismissive, but you're right.
 
I think you're overly simplifying the issue, and perhaps it's due to not having experience in working on projects with larger teams. I can't control other people that are going to use my code, and add to it, so if I provide them with the ability to access state globally, it's going to get abused with a sufficient number of people modifying the code. This has actually happened to me before. I'm not repeating some dogmatic mantra espoused by Stack Overflow zealots. I've seen it happen. I edited my posted above to give more details.

And I think you're over complicating the issue. I've worked on team projects before. The nightmares I remember are not from singletons, but from dogmatically doing everything by the book and adding so much cruft to the project that it became impossible to immediately understand what was going on with any code fragment. The only time we worked well together was when we sat down to discuss everything and figure out what was going to be the most efficient and practical for the group as a whole.

Plus Bumpkin was asking for himself for personal reasons, not for a team project.


To be honest I thought her post was rude, so I responded in kind. I thought it was overly dismissive, but you're right.

No. You don't get to do that. You started out by dismissing me. You started out by presuming that I have never worked on team projects before. You came in thinking that your experience is the ultimate truth, never mind that I may have had a decade of experience in programming. Never mind that people work in different ways and each group is different. Never mind that nobody was talking about group projects to begin with. I'm sorry to be so terse but I did not start this.
 
This is a bit of a rude post to jump on the "perhaps you don't have experience" attack when someone disagrees with you. :/


To put this another way, if people are going to make bad, global-affecting changes in a group project, and they're allowed to get this through code review, they will presumably do it.

Having code mechanisms that insulate things makes it more difficult for them, but they could still potentially change or implement something in a poor manner.

If the argument is that avoiding singletons makes it easier to spot problematic interactions in code reviews, then sure that may be fair enough.
To be honest I thought her post was rude, so I responded in kind. I thought it was overly dismissive. I've followed this thread and I know she is working on a small game with a few people. That's the only context I have, and it was presumptuous of me to assume the game is anything more than a side project for her.

Edit: Odd, thought that was an edit, not a double post.

At any rate, this is sidetracking the thread. My apologies.

No. You don't get to do that. You started out by dismissing me. You started out by presuming that I have never worked on team projects before. You came in thinking that your experience is the ultimate truth, never mind that I may have had a decade of experience in programming. Never mind that people work in different ways and each group is different. Never mind that nobody was talking about group projects to begin with. I'm sorry to be so terse but I did not start this.
I agree. Sorry. :\ I've spent the last month dealing with the fallout of global state in a massive refactoring at work. I'm perhaps overly sensitive to the issue right now. Doesn't excuse me being a presumptuous ass though.
 

Blizzard

Banned
I guess my overall point is, my personal feelings are that code reviews are essential in group projects to prevent bad things from being added (e.g. hidden global state modification). If there aren't reviews and you are completely handing your code to someone else, you can do your best to protect it but ultimately it is in their hands. They could simply undo your work.
 
She is getting there...She will be one of two playable characters in our game. Color scheme is temporary. But the high poly sculpt details, material setup, skinning and rigging are done. Last things are the skin and hair materials and I still have to finish her jacket. I also changed the structure of her face a bit so she looks less like the character from Horizons

NNEb.jpg


ONEb.jpg


EDIT: Is her head too big? Now that I am looking at the pics, I think I need to resize her head.....or not?
 

shaowebb

Member
She is getting there...She will be one of two playable characters in our game. Color scheme is temporary. But the high poly sculpt details, material setup, skinning and rigging are done. Last things are the skin and hair materials and I still have to finish her jacket. I also changed the structure of her face a bit so she looks less like the character from Horizons

NNEb.jpg


ONEb.jpg


EDIT: Is her head too big? Now that I am looking at the pics, I think I need to resize her head.....or not?

Slightly big. Not much though. Just don't go too far or you'll start to question your shoulder width.

Looks great btw! Whats your software pipeline for this? Zbrush>Photoshop>3ds Max?
Also great hard surface modeling mixed with softer sculpted stuff. Did you use bump maps to generate the softer areas or did you sculpt them by hand after the initial hard surface modeling was done?
 
Ken, I think her head looks too big for a normal human, but it doesn't look bad.

I agree. Sorry. : I've spent the last month dealing with the fallout of global state in a massive refactoring at work. I'm perhaps overly sensitive to the issue right now. Doesn't excuse me being a presumptuous ass though.

I appreciate it. I'm sorry you're going through that, and I'm sorry if what I said was phrased in a bad way.

Blizzard explained well what I meant. Code review is invaluable. That should be in employ whether you're using singletons or not.
 
Slightly big. Not much though. Just don't go too far or you'll start to question your shoulder width.

Looks great btw! Whats your software pipeline for this? Zbrush>Photoshop>3ds Max?
Also great hard surface modeling mixed with softer sculpted stuff. Did you use bump maps to generate the softer areas or did you sculpt them by hand after the initial hard surface modeling was done?

Thanks! I think it might be the hair "poof", but I'll mess around with it later this week.

I do all the base modeling in Maya. I use Marvelous Designer for various elements of the clothing (cloth simulations on the pants and undershirt). Mudbox for high poly sculpting. Substance Painter for extracting maps form the high polys, then I paint and texture.

So pipeline looks something like this:

Maya (base modeling) -> Marvelous Designer (cloth sim) -> Maya (cloth object editing) -> Mudbox (high poly sculpt) -> Maya -> (update base models from high poly sculpts, UV mapping, skinning, rigging etc...) -> Substance Painter (high poly map extraction, material setup, texturing)

All the soft details where sculpted in Mudbox by hand (with the help of some Photoshop brushes) after base modeling in Maya.
 

shaowebb

Member
Thanks! I think it might be the hair "poof", but I'll mess around with it later this week.

I do all the base modeling in Maya. I use Marvelous Designer for various elements of the clothing (cloth simulations on the pants and undershirt). Mudbox for high poly sculpting. Substance Painter for extracting maps form the high polys, then I paint and texture.

So pipeline looks something like this:

Maya (base modeling) -> Marvelous Designer (cloth sim) -> Maya (cloth object editing) -> Mudbox (high poly sculpt) -> Maya -> (update base models from high poly sculpts, UV mapping, skinning, rigging etc...) -> Substance Painter (high poly map extraction, material setup, texturing)

All the soft details where sculpted in Mudbox by hand (with the help of some Photoshop brushes) after base modeling in Maya.
Niiiiiiiice. I had a similar pipeline but I've been phasing out Autodesk.

I used to go Maya (hard surface modeling and low poly sculpt)> Zbrush (high poly and clothing, some UV),>Maya (other UV, rigging, weighting, skinning animation etc), >zbrush (rough textures to give me notes, and material setup)>photoshop/Substance Designer (textures)

Now I'm phasing out the Maya portions and handling all that in Blender with less back and forth. Not really gonna get to use Substance Designer much since I'm goin cel shaded and I have other stuff that handles that well alongside of Blender's nodes. Just became redundant. I didn't have much experience in Substance anyhow, but I always wanted to work with it more. Its powerful stuff. I also occassionally cheat and use FUSE for a fast low poly base and tweak it into shape in Zbrush and go from there. Its dirty, but its a really fast way to get generalize proportions and features setup before you need to go in and fully sculpt facial details and high poly musculature.
 
So I decided to give a try to the artistic side of gamedev and I gotta say is a PITA. Here's what I'm currently trying to make:

gg3WpM3.png


I tried to make a simple spaceship but I think I fucked up the UV. What should I consider when making UVs? every face should be as square as possible for quicker painting?

I did enjoyed modelling in Blender but the unwrapping and the painting in GIMP have been really tiring... any tips to speed up a Blender -> GIMP -> Unity workflow?

Programming is way easier IMO.

shaowebb posted some really good resource. And I would consider unwrapping your object along where hard edges meet to hide the seems. I would also create shells for the parts that protrude from the base surface. I kind of highlighted some edges to give you an idea of how I start to go about it:

rOEb.jpg

(something like that)
 
Now I'm phasing out the Maya portions and handling all that in Blender with less back and forth.

Yeah I know, and you are a blasphemer for that!

I installed Zbrush for the 45-day full feature trial and I just couldn't get used to it. I am so used to Maya/Mudbox's navigation controls that Zbrush drove me crazy. The sculpting functions are sooo much more powerful than Mudbox, but I didn't like how every mesh was a "bush." Loading objects and additional meshes is so drastically different than Mudbox that I could not adjust. I might give it another shot at a later date, but I like me my Autodesk tools.

Ken, I think her head looks too big for a normal human, but it doesn't look bad.


To big, to small, just right?
FOEb.jpg
 

missile

Member
... The basic idea is that you have a central message dispatch class (think of it as the postal office), and when objects want to hear about certain types of messages, they register themselves with this message dispatcher basically saying hey, I care about these types of messages, so please let me know when they come in. Then you just publish messages to the dispatcher from anywhere in the code and the dispatcher will then notify all objects that have registered for that particular type of message. This results in you having a fairly significant decoupling of code. No direct instantiation in areas of code that really shouldn't need to care about such things, and if you need to change how a message is handled, the objects that care about said message don't really need to know (unless you're just straight up removing it or changing who will care about said event of course). ...
That's the concept my GUI runs on. I'm going to apply the same structure to
some general objects.

Regarding Singletons, I pretty much unterstand your reasoning and fully agree
with you modulo your assumptions about people. ;) But I also use globals at
times esp. when testing out new things and esp. when performance become a
problem because globals need less indexing which is a point when working on
restricted systems. Your talk is similar of not using GOTOs. And indeed, it's
way to easy to mess things up using them. But using them wisely can improve
runtime performance in certain cases, as any assembler programmer may tell
(skipping function headers etc.). But it is a proven fact that code clarity
deteriorates with the increasing use of GOTOs, no question about it. I think
Donlad Knuth wrote an article about it decades ago, iirc.
 

shaowebb

Member
Yeah I know, and you are a blasphemer for that!

I installed Zbrush for the 45-day full feature trial and I just couldn't get used to it. I am so used to Maya/Mudbox's navigation controls that Zbrush drove me crazy. The sculpting functions are sooo much more powerful than Mudbox, but I didn't like how every mesh was a "bush." Loading objects and additional meshes is so drastically different than Mudbox that I could not adjust. I might give it another shot at a later date, but I like me my Autodesk tools.
In the end, so long as the final results turn out well its comfort that matters most. Powerful and easy is great, but if you can't get comfortable in the workflow you'll never get your flow goin as an artist in it.
To big, to small, just right?
FOEb.jpg
Dont grab the head and scale it down like that. Now your neck looks stumpy and shoulder look wide like I said it would try to do. Her face just came out too far before is all I can see really. Try pulling her face back so its not so far from her jaw line and it should shrink her head nicely without throwing off your head width to shoulder width sizing or you neck height. And yeah, the pompador was definitely enhancing the illusion of mass to the head. Just a small pull back and it'd probably fix it.
 
Status
Not open for further replies.
Top Bottom