Games Retro 3D RPG, anime style character, real-time combat

Working Title: Forever Alone
Genre: RPG/real-time combat
Target: Casual, all-ages

STATUS
Active Development

LISTENING TO:

♪Summer in the hills
Those hazy days I do remember♫

VIDEOS:

GIFS:


LAST COMPLETED:
Attack Animation
Zeke proper running animation and RTS/MOBA style cursor
Zeke combat idle animation and added sword placeholder.

NEXT UP:
- Death Animation
- Jumping downward slash (high dmg vs. Single target and hits Flying)
- Spinning AOE attack (barbarian style)
- "Broadside" large baseball bat like swing that throws enemies back. (crowd control)
??????
Profit

Captain's Log:

Spoiler: 4/17/17

I have chosen a game that is very graphic and animation intensive. It's going to have to be built brick-by-brick, not at the speed that a major game studio could do it. If I focus on doing things in phases without ever really thinking about how much work there is to do in total, I know that I can complete it. It's sort of like how some people get claustrophobic, the best way to deal with claustrophobic sensations is . . . focus on anything else. In my head I see something, and I can feel how it feels to play it, but unless I make it you can't also see it. And of course, knowing that there are at least some people viewing this thread, even if they're lurkers, keeps me going.

Spoiler: 4/18/17

Today was my birthday, now I am 32. I realized today that in order to do all of the things needed, I am going to have to mentally switch roles. I can be an artist today, but a coder tomorrow. It gets overwhelming to try to do it all at once, so the key is knowing how to mentally go from one to the other. I find that music, good feels, and the like get me into the artist split personality inside of me. To get into the coder personality is a little different, it doesn't involve music in any way, he's basically just a robot who enjoys puzzles. It's interesting to note that it really is like being different people when I'm doing these very different tasks. I think a lot of my failures in the past have been because I wasn't aware that I was only doing what I felt, art, coding, music, etc. based on when I felt like it, rather than being able to take control of my moods without physically forcing myself to sit on the computer and do what I don't feel like doing.

OTHER STUFF:

Spoiler: Story

The Corporation has used money and an army of lawyers to take over the most powerful nation on Earth. Anyone who opposes them is served a lawsuit and then dragged into court, and made to face The Judge.

Zeke decided to make his own video game, just for fun. It was a clone of the most popular video game 20 years ago, called Space Creepers. He called his game Galactic Bug Invasion. It was a very successful remake and people ended up loving it so much, they donated money to his personal credit account thru the net.

When The Corporation found out about this, they sent a lawyer to Zeke's house to serve him a lawsuit. But Zeke knew that he had a legal loophole--if you can defeat a lawyer in combat, you don't have to accept the lawsuit, thanks to a very old law called the Second Addendum, which ensures that all citizens have the "right to bear swords, bows and all manner of weaponries' in the defence of the queen and her kingdom" as well as an ancient Supreme Court ruling that interprets this addendum to say that all citizens have the right to duel to decide any issue, and the right to do so cannot be infringed.

Zeke is a master of the Breaker--a very large blade, he took classes when he was a kid.

He has to leave his house, his school, because the lawyers keep coming after him. He knows his only choice is to make it to The Capitol and file an appeal before the Supreme Magistrate, because he never sold the game . . . So the lawsuit has no standing.

On his travels, he makes friends with unlikely companions, like a robot named Bot that became sentient after being struck by lightning, and is being chased down for violating copyright laws because that very same thing happened in a movie and The Corporation claims ownership of the robot, on those grounds.

A girl born with magical powers, who is being pursued for using magic, because technically all magical spells are copyrighted and she isn't paying royalties.

And an elven archer girl, who is being chased down because elves belong to the fantasy estate of famed author TRR Colton, and are believed to be derived from his writings and is wanted for questioning.

 

You have my attention.

 

Why did you have to go and ruin to Zanarkand for me

 

It's only beginning.

 

What you already got a positive review? but btut you haven't even started this S***!! way to go frog man dude

"If you are trying to do something intentionally badly, does it not become an art form all of its own?"

yes, some might even say talented, afteral it must take real talent to hold back the inner perfectionist from correcting obvious mistakes any semi professional part time enthusiast would never make. )

 

Semi-professional, part-time enthusiast... Sounds like something I want to pursue in my story.

 

I like the old low-poly stuff, meshes that don't use bones or skinning or weight-painting. The limbs just fit inside of each other like ball-and-socket joints. All of the animating will be done inside Unity, at this point Blender is just a tool I use to create geometry other than cubes and spheres. Actually, if I do it right I'll be able to change the arm and leg and head pieces without even affecting the underlying animation. This guy needs a neck, actually, now that I look at it.



Best goddamn 3D model of all time (pulled from Googles)

 

Looks pretty good. I would pretty much like a copy of animehead.blend.

You see, I am trying to learn of the process that goes behind making assets and I think seeing how you make them might help me.

 

Well, what I am doing is setting myself up for a style of model that will work for what I want to do, and in the style I want it to be in. I have made the large flat areas so I can do anime eyes and mouth, because I am thinking I might want eye expressions at some point.

I had to widen the body parts, and then make him shorter, to achieve the sort of "retro chibi" thing I'm going for, keeping the visual fidelity of the models low, so that overall the presentation keeps a low expectation in the audience. If people can "get past" the bad graphics, and embrace the charms of the style I've chosen, then I can draw them in with a decent story and good game play.

At least, in theory.



Do you know how to use blender?

I can make a little visual guide of the tools I use and how to use them, to work quickly and without getting frustrated.

Here's a zip file, you can see how I am building all of the pieces of the body as separate objects. I still need to set the anchor points to the joints, it takes some time to do, because it is a multi-step process for each object, but when done it will be worth it.

 

dafuq?

 

I have been studying Blender a bit, for about a week now along with Unity, but unfortunately I didn't find a clear place to start like the learn page on Unity so I have been looking randomly around. What I have learned, for example, is about the magic of the mirror modifier, how to use extrude (although I don't think I know all of its tricks) and other basic tools. I decided to read the Blender manual, but I am reading Unity's too, and I am watching tutorials at the same time, so that might take a while. So any practical knowledge I pick along is useful for me.

If that doesn't take too much effort, I would certainly appreciate it. You don't have to though.

 

I'll make a pointer list of the cooler features, take some screenshots of the tools I use and how they work. There is no one place to start learning Blender, it's kinda nexus. And to be fair... none of the Unity Learn stuff will show you how to make a more complicated game than a single-screen arcade style action game, either.

You could make hundreds of tutorials on Blender and Unity and still not really cover everything, so what you will find is 90% beginner tutorials, 8% intermediate and like 2% advanced tutorials (not real statistics but you know). Just really a marketing tool, really, aimed at the broadest cross-section of the target market. And once people learn how to do stuff, usually they are busy doing stuff and don't feel like wasting time helping other people. And I think that says a lot about us as a society.

 

Not sure how retro you want it to look in the end, but I wanted to link you this shader:

https://github.com/keijiro/Retro3D

 

So basically, you can make almost anything with these basic tools and methods. There are more advanced techniques, but I won't be using any of them for my entire game.

Loop Cut



Useful when you want to add some definition where there is none, or cut an object in half, thirds and so on. There are some neat things you can do with loop cut that are of note:

Scale/Slide the Cuts



This is one cool scaling trick that just comes in handy from time to time. Just one more thing you can think of to make the shapes you want.

Delete Vertices



Nothing special, just when you delete vertices, any edges or faces that are defined by those vertices are just obliterated instantly. Rogue edges and vertices aren't fun.

Mirror Modifier

So this one is a no-brainer, perhaps, but when I was starting out I couldn't find this thing easily.



CONTINUED...

 

These settings are the best. "Clipping" lets you merge stuff by moving it into the middle, which saves you a lot of work sometimes.

I use clipping as a lazy man's solution to bad geometry, when two things don't quite line up right with the mirror modifier. Here's an extreme example:



Speaking of lazy man's solutions to things, here's one of my absolute favorite tools:

KNIFE



Knife works through the use of secret magic. It somehow figures out how to chop stuff up so you don't have to expend any unnecessary brain power. It's really great when you need to cut across shapes, so you can add angles to them. Or to make a jack-o-lantern out of the default blender cube.

Another basic one is scaling a bunch of vertices around the 3D cursor in order to get the effect that you want:



CONT.

 

Fixing jacked up stuff.

When I started, I had a lot of problems like this. I would move things around, then I couldn't figure out how to get them back to how I wanted them to be. Then I learned some tricks:

A really powerful one is scaling things by zero. You have to make sure you select "median point"





You can do this with any group of vertices, flatten them along an axis in order to make them line up perfectly.

There's only one last thing I ever use:

Go to FILE -> USER PREFERENCES and type loop into the search bar, then check the box for Mesh: LoopTools



Circle is really helpful for fixing things that have gotten "out of round", it will basically make an even circular shape out of whatever set of vertices you select.



Bridge is pretty cool, too, it can actually "fill in" a gap between two shapes, and it works pretty good when those two shapes are circular and have the same number of edges and vertices and are relatively close to one another.

There are a hell of a lot of other tools in Blender than the ones in these last 3 posts.

I didn't touch on Extrude, or "F" to fill-in faces because of time and I think those are well-covered in every tutorial since the dawn of time. These little tricks are the best (my favorite) ones that I learned over the course of watching hours and hours of Blender tutorials over the last couple of years.

Hopefully they will be of a benefit to someone.

 

Micro update, so I spent some time figuring out how to put the eyes and mouth on the character's head. I tried using the Retro 3D shader, but it resulted in the eyes disappearing half of the time. Also, the Retro 3D shader doesn't work well with alpha transparency. I think I will use the Retro3D shader for everything except for character's faces, the faces will be using unlit transparency on the eyes and mouth.

You can't really tell from this picture, but the eyes and mouth are a separate 3D face, so they are on top of the head geometry. I can create a cycle of eye textures and link them through the editor, and I will be able to make animations like blinking, and talking, and so forth.

This made me think just how important it is that I have a full set of theatrical tools built-in, because I really want to be able to plug characters in and have them talk and deliver lines. I don't know how big this RPG is going to be, but I would at least like to be able to create a beginning, central conflict, climax and resolution.



Now to go play SC2.

 

You could opt for just vertex lighting.

 

Well, this is actually what I am going for. I worked it out so that instead of trying to create eye decals, I just cut the faces out of the eyes and the mouth and turned them into their own objects.

Basically, I want my game to look like it is literally on PS1.

As such there won't be any lighting at all.



Pretty soon I want to get the facial animation system working, so I can make the character blink and have the mouth look like it's talking. There's really an immense and impossible amount of work ahead of me, so I think it's best never to think about it and just work piece by piece, little by little.

 

Then maybe just simple unlit shaders and paint any lighting into the textures?

 

All shadowing will have to be painted onto the textures, yep. And during animations, the shadowing will look off momentarily, but that's how it used to be done and so I'm sure the result will be somewhat nostalgic for anyone who used to play Playstation games.

 

From offline conversations with you I'm sure this decision is based on a lot of thought and reasoning. Care to go into detail as to WHY you've chosen this era and style?
To guess I would say maybe nostalgia but probably most likely to eliminate a LOT of work needed with more modern visuals. Looking back on FFVII we give credit to the creators and overlook the flaws that are really jarring when seeing them today.
Are you planning to eliminate or replicate some of those flaws? For instance near the beginning of the game when Cloud is running to eacape and catch the train and he looks up to see the tower (sorry I cant remember the actual names - I keep thinking Nacatomi plaza ) the camera pauses for a painful amount of time. This happens throughout the game during dialogue and cut scenes etc.
Animations for FF7 at the time were pretty great during battle, but the platforming/adventure animations and cut scene animations were not very good.

Although I can see the benefit of replicating that era in history to reduce the asset development load - I hope your game doesnt play like a ps1 era game.
About 2 years ago I attempted a play through of the original FF7 on original hardware and couldnt make it longer than about 10 hours before acknowledging I was performing some sort of masochistic, mental self torture, though it wasnt enjoyable.

 

Even if I did try to recreate FF7, it would be a completely different game, simply because it's been 20 years and I think collectively we've all changed our ideas of what games are, and our sense of how much time we have available to spend on non-fun stuff is much less now than ever.

When you look at an old game like FF7, what you are seeing is a bygone era where people were only beginning to explore cinematic qualities in video games. Dramatic pauses, cut scenes that cannot be skipped that are not relevant to game play, and you have to think . . . we sure have come a long way, haven't we?

I mean you look at Borderlands, and what do you see, a lot of the dialogue is short and to the point, but it tries to be amusing even as it's delivering that to you. Because games developers of 2017 know what game devs in 1997 hadn't discovered yet, people like content, early, often.

I want my game to look like it was made in 1997, but in terms of the flow of the game and the action/cinematic ratio, you need to take a look at Pokemon, because those games have achieved an excellent balance between storytelling and game play. Often times, the people you battle have two things to say to you. One before you fight them, and one after you defeat them. And for the rest of the game, if someone speaks to you, it is either an NPC delivering some kind of game-related info, a little backstory, something to set the mood of the game, or literally giving you an item or offering you a trade of some kind. And all of the dialogue is injected with the same tongue-in-cheek sense of humor, with the exception of that delivered by a few central characters along the main plot.

Now, it's hard to imagine FF7 as anything other than a long, drawn-out game with lots and lots of leveling up, 45 minute cutscenes (remember after Midgar, that eternity you spend listening to Cloud cry about Sephiroth?) But in today's terms, the game wouldn't work.

A lot of people don't realize this, but Final Fantasy 6 is vastly superior to Final Fantasy 7 in every way, including character development, pacing, character depth and the amount of role-playing it allows within the finite possibility space of the game. But FF7 was the first to have that turn-based 3D battle system that I came to love and the cool 3D characters that look worse than lego people, but they are more expressive than 2D sprites could ever be and far more versatile.

I would even say that FF7 has an inferior battle system to FFX, which actually has a display of whose turn it is that changes depending on the delay of the selected action, so you would expect to see that and a highly streamlined command interface, which is mouse-oriented but also will use keyboard shortcuts. Also, I would intend to have the attacks in the game not just "click and use", but have some attacks that require tapping a button or clicking things with a mouse in order to power-up.

I seem to recall a poll done a long time ago on one of the major forums, around the time that FF8 was in player's hands, where people were asked, "What do you want, more battles or fewer battles with more unique, stronger monsters" and overwhelmingly, people voted for fewer battles, that were harder and involving unique monsters.

And I couldn't agree any more. Forced grinding is bullshit. Making you walk through fields and get in dozens of battles is so old and tired. The formula is a snooze fest, both to play and to watch.

Grinding should be an elective activity, so for example making it so that if you keep the main character in the fights, he will grow to have better stats than the others, making him much stronger so you can defeat any normal encounter you come across, but boss fights will still take a full party and be challenging. Other characters you may come across that you may want to join the party, you may bench them at first, requiring you to bring them up later on, so this would require intentional leveling. But at least at that point, it will be minimal and assisted by the main character on harder monsters, and sharing experience will help them come up fast.

Ultimately my goal is to have fun, and I believe the game should be fun and funny to play, and I think that you should be quickly thrown into conflicts and have battles make an impact on the direction of the story from early on.



Expect within 5 minutes to have the main antagonist established, the main character introduced and within 10 minutes to meet the main love interest and your first unlikely companions.

Thanks for asking! I love talking about this stuff.

 

Sometimes simple isn't all that much more simple. The model is all set up now, the pivot points on each limb have been painstakingly set using the 3D cursor tool, and then "Origin to 3D Cursor" in Blender. I applied all of the scaling in Blender, which inverted a bunch of normals on his right arm and leg, so those had to be flipped. But as of now, the puppet is all set up like it needs to be.



I had a problem where there was blue space on either side of the rendered low resolution area, which I traced back to the render texture, which has a pre-defined width that it wants to use. I didn't think about it before now but this retro 3D uses a render texture and 2 cameras, one camera is an ortho camera that does nothing but look at the render texture, so it's kind of an odd thought that there will always be a render texture someplace and a camera looking at it, and the main game camera will just be sending a render texture to that. Thank God for pro features for free!



So now the rendered texture will always be wider than the screen, that way wide screens will be accomodated. I don't know why this value was set to 320 initially, even though it's a retro 3D thing people aren't going to be cool with 1/3 of their screen being just blacked out dead space in order to make it seem more "retro".



And that's all I have done in the last couple of hours.

It ain't always glamorous but this is what it is, a lot more of the time than I care to think. The fun stuff (playtesting and balancing) will come later on, much later on.

 

UV mapping and texturing makes me feel like...

 

Very nice work. Obviously shows you can make these very low poly characters be expressive... and with just one pose not even animated.

Simplicity is a great thing (when we can get away with it).

 

Week of 4/3/17 - 4/9/17

Hours worked, ~10

Work Done: Mostly graphics, building a single character in the retro 3D style, figuring out how to get the texturing right, figuring out a workflow for exporting UV's->Textures->Unity, what shader settings look best, which tools work best in GIMP and overall, trying to establish a protocol for creating assets so that it can be replicated out a hundred times over to create all of the game's content.

I'm almost where I want to be. I find myself wishing the character's limbs and torso were all rectangular, four-sided shapes, it would greatly simplify the job of placing shadows on the textures themselves, and greatly simplify the process of unwrapping and texturing. I like what I have, quite a bit, but ultimately what I really want will involve even fewer polygons and be less overall work.

On the other hand, all of this unwrapping and switching back and forth between multiple body parts has gotten me to the point that I believe it may be better just to go with a modern skinned mesh using bones and more modern animation tools. I had imagined that it would be much easier to just use separate objects and animate them that way, but I have found that it's actually a pain in the ass and you spend more time trying to make it look decent, where a skinned, rigged mesh would look great right off the bat.

The thing I'm happiest about is the anime look, the bright and clean pixelated texture combined with the excellent Retro 3D shader. I think I am going to end up going with Unity's avatar system for retargetable animations in a reliable manner, since what I'm doing is looking quite sketchy, and there's a lot of room for error since I'm constantly back and forth between Unity and Blender, more chances to F*** something up. For example, I somehow applied the mirror modifier for ALL of the character's body parts AND saved without even knowing it. I'm not even sure how to do that on purpose, but I did it on accident.

I never had an issue like that when I was doing a normal rigged mesh.

Overall, the amount of familiarity I've gained with 3D graphics, Blender and Unity through this process was worth it.

I think a lot of people think Game Development is some well-defined process, where you basically follow a series of pre-defined steps and arrive at an eventual, expected outcome. But the reality is that for an indie developer like myself it's all just a process of discovery, realizing both new things you want to do and things you thought you wanted to do are actually quite S***.

This is effectively the result of all this work: Alpha Version main character, good enough for using to build the game's systems with, but not good enough for showtime. I'll be staring at this guy for quite a while, using him as both enemy and good guy for a while, because when I'm ready to create final characters, I will have a complete process down pat.

Experimenting while creating is fun, it's interesting, but it's no way to get anything done. So as fun as this *was* I am very much looking forward to moving on to building the character controlling code, the cinematic stuff, the dialogue and actor systems and then making cool characters in one consistent style after the fact.

Alpha "Zeke"
On his T-Shirt "Space Creepers" pixel art, a retro arcade game within his fictional world.

 

Looks great. That's interesting you mention it being easier to not use separate limbs and animate that way... because this is exactly how I always plan to animate in 3D. Just use primitives (scaled as needed on x, y and / or z of course) for each part (forearm, upper arm, etc) and then just animate those right in code. Well okay now I will probably do it in the Animator although I think that is overkill.

I guess I'll have to test now using a proper skeleton and animating creating normal animations and the manually animating each part to see which is a faster approach for me.

 

A skinned mesh to a proper skeleton is far superior to this process - and you can still get the segmented limb look you are striving for.
Character rig with skinned mesh will give you IK controls for arms, legs and head, plus can provide other features like animation retargeting within animation package (idk if blender has anything like this) and other features like skin wrapping another mesh to this character - essentially allowing the new character to be animated by the same animations with little effort.
IK is worth the extra time investment alone needed for skinning and rigging and can provide you with the ability to keep lock hands where you want them to be, make feet lock onto points in 3D so the feet dont ice skate in engine and allow the head to look at specific areas with ease. Of course all of this can be accomplished without bones and skin, but with bones IK (afaik from 3D Max) is already built in and doesnt have to be manually set up.
To get skinning to look like you want - just skin each mesh segment 100% to each corrisponding bone. No need to blend skin weights like in a higher detailed contiguous character mesh except for maybe elbow and knees - which are simple skin blend areas.
As long a the character matches the humanoid skeleton (if you dont want to perform avatar masking) retargeting should be very easy for this character style, although with the extra face pieces swapping out the eye blinks and different mouths - managing this outside of the animated rigs state machine and body character controller will probably be less headache in the long run.

 

Well, that was kind of hard.



This is what's on the character:



This is what is controlling him:



Basically the command interface sits around grabbing all of the input, then uses it to interact with the world. I debated whether or not to use OnMouseDown events inside of the individual characters, but this seemed like spaghetti, so now it's all going to be in one central location (where I can keep my eye on it)

You can take a peak at the code for the command interface (I got nothing to hide):

Code (CSharp):

1. // Update is called once per frame
2.     void Update () {
3.  
4.         if (Input.GetMouseButtonDown(0)) { // LMB
5.             RaycastHit hit;
6.             Ray ray = MainCamera.ScreenPointToRay(Input.mousePosition);
7.  
8.             // Selecting a Unit
9.             if (Physics.Raycast(ray, out hit)) {
10.                 //Transform objectHit = hit.transform;
11.                 Unit HitUnit = hit.transform.GetComponent<Unit>();
12.                 if (HitUnit != null) {
13.                     DeselectCurrentUnit();
14.                     SelectedUnit = HitUnit;
15.                     HitUnit.SendMessage("Selected");
16.                 }
17.             }
18.         }
19.  
20.         if (Input.GetMouseButtonDown(1)) { // RMB
21.             RaycastHit hit;
22.             Ray ray = MainCamera.ScreenPointToRay(Input.mousePosition);
23.  
24.             if (Physics.Raycast(ray, out hit)) {
25.                 if (SelectedUnit != null) {
26.                     SelectedUnit.SendMessage("Move", hit.point);
27.                 }
28.             }
29.         }
30.  
31.         if (Input.GetMouseButtonDown(2)) { // MMB
32.  
33.         }
34.  
35.         if (Input.GetKeyDown(KeyCode.Escape)) {
36.             DeselectCurrentUnit();
37.             SelectedUnit = null;
38.         }
39.        
40.     }
41.  
42.     void DeselectCurrentUnit () {
43.         if (SelectedUnit != null) {
44.             SelectedUnit.SendMessage("Deselected");
45.         }
46.     }

So what's going on here is the basics for interacting with different units through mouse and keyboard control. Units are basically anything that can be selected, and anything that can't be selected... isn't a unit. In addition, units have actors which basically do nothing but sit around monitoring their states and playing the correct animations. Literally, the code that moves the character is completely unaware of the code that animates the character, and the code that will ultimately make up the character's stats will have no knowledge of either of these two.

This will prove super useful when I move forward and make new some new character models. I am now free to make the game however I want without worrying about how the whole thing will jive with the animations. That's a completely different issue and it can be dealt with at another time.

So what I'm doing is establishing a framework, a protocol for how objects talk to each other, testing each thing as I make it, mitigating risk by making things less interdependent, while still keeping it light and fluffy. And it's still a headache, so I can't imagine taking a more heavy duty approach.

Here's something interesting:

Code (CSharp):

1. // Generate a list of all animations that are contained within the animator.
2.             Animations = new string[Actor.Animator.runtimeAnimatorController.animationClips.Length];
3.  
4.             var i = 0;
5.             foreach (AnimationClip AnimationClip in Actor.Animator.runtimeAnimatorController.animationClips) {
6.                 Animations[i] = AnimationClip.name;
7.                 i++;
8.             }

So I was able to make it so I don't need to bother with the animator window all that much, since I'm not going to be using multi-layered animations or elaborate transitions, I've basically just wrapped it up with some string-based methods and called it a day.

I can add more properties to all of my components to edit things like animation speed, etc. If I need to without any concern for what will get broken, because all my components have only limited interaction/awareness of each other.

Each thing I build is exhausting, but it brings me closer to the point of automation (@Arowx won't like that) and simplifying the process of ACTUALLY MAKING THE FREAKING GAME. Which is, after all, the only thing I actually want to do...

And of course, more to come.

 

@Master-Frog

I stumbled on your thread by chance and appreciate it a lot (have subscribed). Funny to read + interesting to see how you approach things. Good mix of not taking it too serious but still getting something done. Hope you keep it up!

 

Be careful not to overcomplicate things. Instead of using the message system (which is a really interesting approach actually), you could just make a base "Selectable" monobehavior (and derive ie a Movable from there). In that component, you could just select on OnMouseDown(). You could save the current selected Selectable in a static var and wrap it with a property that also calls deselect on the previous Selectable if != null.

Example: Imagine you have a turret. When its selected and you click somewhere you won't want it to receive a "Move" but to fire a bullet.

 

Automation is fine, we just need a way to ensure that when we automate ourselves out of a job we can retire comfortably on an automated pension plan. ;0)

 

Well, at this point it's hard-wired to activate the "Move" command on the right-click, just for demonstration purposes. What will actually end up happening is that the Command Interface will display a list of Commands, based on Abilities that the Unit has.

And while I certainly could make an entire class just for the purpose of saying that a Unit can be selected, and re-engineer the whole thing tomorrow, the next day, and for the next 2 weeks after that, the job has already been completed and I'm moving on.

This is a case where a situation as you described, a Turret receiving a Move command will be impossible, because when the Command Interface retrieves the Turret's (a Unit w/ an Actor, etc.) Ability list and populates the GUI, there won't *BE* a Move command there. And if I want to be a little squirrely, I can always make a turret that can move, if I truly desire to do so, simply by giving it the "Move" Ability, setting the Unit's movement speed, and then creating an applicable animation, clicking "New Action" in the Actor and attaching it to the Moving Action, same way I'm doing Idle and Moving at this moment, and simply selecting its applicable Walk animation.

What you're describing above says, "Every Movable is Selectable" is an example of hierarchical class structuring, a rigid methodology that has its place, but when I'm trying to make a video game in my limited spare time, its considerable bulk and slow-ness is like trying to navigate a race track in an 18-wheeler.

I have to go fast in order to get done, the faster I go, the more done I get. I am aiming for the magical playable zone, where the game is Alpha as fudge, and I can discover what new features are needed by playing it and getting random lightbulb moments.

I will say this: most devs never get past their Canned Spaghetti phase, terrible code, mostly stolen from online examples, with a refined metallic taste. Those who do are the particularly brainy ones who fall in love with software engineering and then become programmers first, and game developers 2nd, and would actually prefer to refactor the codebase then add a critical feature, because the priority and interest is more on the former than the latter. In my view, a programmer's programmer should write lower-level stuff, such as networking code, shaders, custom importers, advanced camera scripts, etc. Non-visual things that are mostly theoretical. But when it comes to moving little shapes around the battlefield, that is the domain of the Scripting Language (DUN DUN DUN) and the dreaded Visual Scripting Tools (lightning crashes).

What I'm doing is basically setting myself up my own visual scripting tools.

 

Wu Wei, hombre.

There is no try.

 

I suppose for most people, it's hard to understand the concept of "rigidity" in code. For me it is a natural concept because I have no appreciation for hierarchical structures in general, and class inheritance is nothing more than hierarchical structure for code.

Every square is a rectangle, every rectangle is a shape. But what does that mean for a Level 31 Goblin Archer? How many classes does he have to inherit from to give him his unique make-up? Which properties of which class define him? If you want to talk about complexity, to me that is the definition of complex.

I say a Level 31 Goblin Archer is a Unit with his Level property set to 31, a Goblin Actor hooked up, and a ranged attack Ability that generates a Missile (prefab) that looks like an arrow, and when it connects with it's target, a brief information exchange takes place telling the recipient how much damage was received, so that Unit can calculate its net damage after defense and mitigation.

How many classes would you need to write for the above? "Damageable"? How many interfaces? A dozen? 30 files? 400 lines?

My code structure is more fluid in Unity at the moment, I trend toward the "worst case scenario, nothing happens" school of thought as well as the "if I am randomly throwing game-ending bugs, try-catch is just plugging the hole on a sinking ship. Fix the underlying issue."

SendMessage is great because I don't have to write the implementation for it, and the worst thing that happens is a console error "Has no recipient" and it can transmit an object as an argument, which means if you're a clever girl, you can send over ANYTHING.

Also making the Units respond to mouse clicking by hard-coding that functionaility in them is bad, because they are ultimately going to be selected from a turn-list, not from mouse-clicks. Because they currently have no concern for how the Selecting functionality works, I can avoid the issue, even select them in a For-Loop or a Foreach loop if I wanted to.

Be Water!

 

Christ, I just realized that if I did cel shading and rigged low poly meshes it would be way less texture work (so far texturing is the bottleneck of the character creation process), and if I use the pixelization camera trick it will look retro automatically. And players can choose to turn it off if they don't like it.

I have to say goodbye to the retro3D shader though. I think the cleaner anime graphics will appeal to more people, as well, than intentionally bad ones.

so faster + better

and that's what I'm always looking for

I will work on graphics again next week, this week is all turn-based combat stuff

 

I am totally on your side concerning keeping everything as seperated as possible. I'm fighting legacy spaghetti code every day, and I think I do quite well not adding more spaghetti on top of it by now

I was just trying to help simplify a bit. My thought was you can have the selection functionality within one encapsulated monobehaviour. You could then just drag and drop it on a gameobject and it'll work out of the box. Now you implemented two components - the selector sending messages on objects and the additional Unit component , and you will need to place both in the scene to have the system work. Its no big deal at all, but I'd say more spaghetti then use a single component take care of itself. I don't necessarily mean you should not use a UI or something else do selection for you, but the place to put the actual selection code and the currently selected selectabe should be within the selectable class itself, not in the ui or manager.

I also absolutely agree with avoiding too much inheritance. I would sure not want a Level 31 Goblin Archer inherit from 10 steps from a basic Shape class. The Unity way for my understanding, and really I'm just speaking for myself, would be construct this from a set of components - one of those might be a selectable. Another one might be a health component, just like there will be a collider, rigidbody etc.

A litte inheritance however won't hurt. If Moveable is a Selectabe or not - a matter of taste and what you will do with it.

 

I have to admit, now that thought about your application more, having a dedicated selectable component on units might really be overshooting. Since its really just the player interfacing a funtionality that could also be accessed by an AI, like moving, attacking etc, "selection" per se should not sit in the unit itself. Whoops ^_^

 

Smart people syndrome.

 

I like the graphics too much exactly how they are and I don't want to change a thing, so I'll have to figure out an efficient way to deal with it. I love how the skin is so bright and even and the low-rez textures just add so much grit to it. I just have to leave it how it is.

 

I am at the point now where I can let the player start issuing commands to their unit and have the enemy units doing stuff, as well, but I took a moment to consider what exactly it that I need the user interface to do for the player.

I considered at first using a Final Fantasy style dialogue system, where you navigate hierarchically nested menus and arrive at the command you ultimately desire, but it occurred to me that this was a user interface system that was specifically designed for use with a D-Pad. Meaning that, it is not the best design for a mouse and keyboard game.



I also considered doing a circular command style, where moving the mouse in any given direction will trigger that command, ala Doom:



But then it also occurred to me that this isn't a first-person shooter, plus how in the hell will this allow you to select items? What happens if there are only 2 commands available? What if there are 15 commands?

It was kind of confusing me.

So I thought about what kind of an input system works well with a mouse and a keyboard? And it clicked in my brain, because it makes total sense and it's kind of obvious, but then again the right answer usually is.



I'm not exactly sure what this is called, to me it's a grid-based command bar. It's in so many games that it's just part of our lives now. But basically, this is the style of UI that I need to pursue. It works best with mouse because you can easily navigate to what you want to click on, it shows you what keyboard key to press to activate the ability, you can see which ability is where at a glance thanks to colorful, distinct icons that you can easily memorize, and its highly intuitive and most people already know how to use it. Since it is grid-based its super flexible in terms of resizing, adding more cells, and basically doing whatever I need to do with it.

It's as easy as lowering it off screen when it's not the player's turn, and then raising it back up with the corresponding commands when it is the player's turn. And the same system that is used to make the command bar will also be able to do the inventory and other handy things like assigning skills, etc.

 

Sounds great on the controls. The game art looks very good so far. It is simplistic but definitely has some personality to it.

Also dead on about the rigidity of hierarchical class structuring. That's exactly a major problem with it along with bloat. Of course, these things can be avoided with some effort and it has its benefits when not thrown everywhere but the "has a" composition pattern is generally better. And with Unity being built around composition it would seem to make even more sense to use it here.

You seem to be making great progress on your game quite quickly. That's fantastic to see! Always check this thread when I visit the forums.

 

I am trying to avoid the "sorry its been awhile since the last update" b.s. And just keep it rolling.

I need momentum to get it playable, after that it will roll easier, until I get to the near end, when it's just grinding down rough edges.

This is not theoretical stuff, I need a method of making abilities that any Unit can fulfill, and a command system that supports it.

I am not 100% sure how to do this at the moment. I know you can't make a component into a prefab, but I can make a single prefabbed object that holds the definitions of abilities... Once I can assign an ability to a command slot and have the unit execute it without hard wiring anything, the game will be afoot.

 

That awkward moment when you're googlin' for a quick Unity UI drag n' drop tutorial and the person who made is @BoredMormon

Dude basically recorded a video of how to make the UI for my game, epic, love it.

 

I literally just realized it's BoredMORMON, I always thought it was BoredMORON...

Also interesting project, definitely looking forward to seeing where this goes!

 

In case you're still looking, maybe you can utilize ScriptableObjects. Make a base Action ScriptableObject class(I know inheritance, but hey), having an abstract ExecuteFor(Unit targetUnit) and maybe a PrepareUnit(Unit targetUnit). You could then have an Array/List AvailableActions in your Unit where you can now drag and drop Actions into.
Now write Actions as you like. Make copies of your Actions where you vary properties or used prefabs like particle effects. Actions could also have AP, MP cost etc.

 

I realized last night that the Ability itself will not contain/care about the code for how the ability is executed, because in the case of "Move", that code is within the NavMesh agent. The Ability has the job of:

1. Checking for prerequisite conditions
2. Defining the cost of the ability
3. Containing user interface information, such as display name, description.
4. Defining the appropriate visual appearance for its icon in the UI
5. Defining cooldown time for that ability.

I don't want to write each ability as its own class, rather I would have the Unit keep track of which abilities it has attached within itself, and refer to the pre-defined ability in a central data source just for the stats on its own abilities.



The execution of abilities will come down to the unit's code, itself. The ability is just a way of telling the player "you can do this for this many______ points".

---

What I'm really looking for is the simplest solution to managing the data. I imagine in a game like this there will be lots of abilities, effects, items, etc. many similar, but distinct in terms of their effects. I have the following requirements:

1. Graphical user interface (basic CRUD)
2. Accessibility from other scripts

I'm thinking of doing a class inside of a central data controller for each type of data I need to manage, making a custom editor window for it, and treating items and abilities, etc. like database records.

I will probably use a dropdown menu to sort the items, even though a list box is preferable.

...

 

I think I've mentioned before that that one video has been more popular and made more money then any of my games.

Glad I could help.