UnionVGF Indie Game developers (or thinking about becoming one) corner

Godsmack said:

Want to know why I get headaches? Here is a look at some game code.

Basically, I am tweaking the code to make sure it works for multiple enemies of the same type. See, if the game creates multiple enemies of the same type (such as several archers, several grunts, whatever) you have have to make sure the code treats every one of the differently. Otherwise, you end up with all of them attacking at once, their pathfinding becoming interrupted, them standing there like a dumb ox, or who knows what else.

This screenshot shows what I am going through to make sure they all work fine. It works better now than before, maybe even good enough. I am still tweaking and optimizing. The only thing you can do is add or subtract conditions, change object types if an enemy is made up of multiple parts such as a pathfinding or collision box, disable or move events, or whatever.

I can't imagine having to do this with straight programming. Even with Construct 2's visual event system, it can give you a major headache. Also, note the numbers on the left. The game has over 1,300 events already.

Click to expand...

Honestly, it looks like straight programming would be easier. If not easier, at least ore organized.

Z A C K said:

Honestly, it looks like straight programming would be easier. If not easier, at least ore organized.

Click to expand...

Hmm, it's hard to say. I like how in Construct 2 with the visual editor you can quickly add or move events or modify them just by clicking on them and changing some stuff. I don't know how to explain it very well. It has a lot of features that make it pretty fast.

I've never tried straight programming though. So, have nothing to compare it to.

I also get the feeling that I'm doing something that the program was not really intended for. I post on the Construct 2 forums every now and then and follow other people's games. I'm one of the few people making an isometric, turn-based, action rpg it seems.

starseeker said:

I am not experience with the other engine, but in UE4, I find Blueprint (UE4 version of visual programming) better overall, compared to manual typing. I have some programming experience before moving to visual programming, & its the future. The main advantages of traditional coding is reusability. You can have lines of codes or class etc & plug it into another program, with some modification, to be reused, but thats about the main advantages. There are far more advantages to visual programming, & its still raw. Imagine if its mature.

You will still need to be able to think & construct the logic of game mechanic like in traditional programming, if you are those that do not like manual programming due to being 'bad' in logic thinking , you will be bad in Visual programming as well.

A very good example for visual programming can be explained in a analogy below of copy & pasting file.

Manual programming equivalent will be:

• 
  COPY /V c:\windows\Fruits\apple\pinklady.jpg d:\Door\Supermarket\

Visual programing will be equivalent to:

1) Navigate to folder apple
2) Select Pinklady (ctrl C or right click & select copy)
3) Navigate to folder Supermarket
4) ctrl V or select paste

Unless you know the path at the back of your head, & good at avoid making spelling or syntax error, using copy & paste is the preferred method.

I do agree that certain operations, like operations (if else etc), & mathematical expression are quicker with manual coding, but thats the magic of Blueprint in UE4, you can nest codes & make it into a block with input & output, best of both world.

Click to expand...

I'm sure your argument has merit, but it'll be tough to convince someone who does manual programming everyday that visual can be better organized.

Okay, so I've been hard at work on some new systems for my game.

I have been working on level generation. I got the old system working. It created random levels (all from an array), would spawn enemies and objects, and so on, but it had some limitations. One was performance. I had to be very careful not to push it too hard. I keep having to tone down certain settings such as how fast fog of war can disappear or how fast the z-order sorting worked. On my system, it worked okay, but I keep fearing it may be bad on lesser systems.

The new method of level generation I created, basically is made by hand. I set up a grid and created a system where I could quickly place objects in place on the grid. I can copy and paste for multiple iterations (such as multiple walls, floor tiles, etc.). I can easily place objects and create my own layouts. So, I have complete control over where everything goes. Now, it won't be as random as the previous system, but I can make as many variations as I want, so I don't think it will matter. I mean, with like 50 different possible layouts, I doubt anyone will really notice.

Creating levels like this brings several advantages:

1. I get a decent performance boost. There will be less objects and less going on that needs cpu power.
2. I get full control to make my own levels. I can make the more like real rooms and hallways.
3. I can add doors or other room objects such as pits or contraptions.
4. With functional doors, the rooms will feel more like a castle.
5. I can add in ladders/stairs for going down levels. Again, this means it will feel more like an actual structure.
6. If I choose not to show walls in the foreground, I can make the taller (like the door is taller).

The way the old system worked was you enter the portal and are transported to a different part of the castle. Since it was so random, I didn't know how to make functional doors since the next room would have to reflect the direction you came from. For example, you enter the top left door, you come out at the bottom of the next map near a door.

Now, there will be some limitations on the new system. I am most likely going to make doors jam/break behind you so you cannot go back. This means you cannot freely go from room to room, and you have to keep going forward. However, from a programming standpoint, I will not have to "save" a room layout or objects/enemies in that room. It will make things a lot easier to manage. That, and a map will not be needed with this type of design.

There will be a couple things missing:

1. I will probably not use fog of war. It was tricky to get right anyway, and used resources, so this is not all bad. It just means there's less exploration "in" levels and more "between" levels if that makes any sense.
2. Exploration will be a little less as I just mentioned. However, I think the castle will be more fun to traverse and make more sense from a structural standpoint.

I'm still working out the details, but I am most likely going to continue to use the new system. It just gives more control.

Here is a screenshot of some changes.

Notes for screenshot:

1. You will notice that I have changed the icons under the character portraits. I put an "A" or "M" on the icon to indicate auto attack or manual attack. I think it makes things more clear. The text under the portrait will also reflect this.
2. I have made some very quick doors. Ignore these graphics for now. It's just for me to see how they work.
3. I learned how to create shadow-catchers in Modo. The portal now casts shadows on the ground. So will the characters and whatnot.
4. I was able to make the chests more normal size now that I don't have walls blocking them.
5. I may black out the sides of the walls that stick out on the sides of the map.
6. I may make the floor have volume, so don't take any level graphics as being 'final.'
7. Ignore the spots with missing floor tiles. I did that on purpose to show that I can put them where ever.
8. I have changed the render mode to point sampling to prevent blurry objects when viewed full screen. The game runs in a window at 720p to save some resources and make use of smaller textures. Anyway, point sampling makes things a bit more pixelated, but prevents blurry images. I can put it back to linear sampling at any point.

Thanks, I hope you find the new skeleton bind to be more flexible and user friendly. I wasn't able to make it perfect given my limited time and because I didn't want to modify all the polygons/structure of the hand, but I think it's serviceable and should get you by.

Okay, so I'm trying out some taller wall and floor tiles. I was toying with the idea of making it seamless, but it is so much easier to keep the tiles visible. I think it fits fine with this style of game with levels that are created to be somewhat random with an emphasis on many layouts rather than games that focus on big set pieces in limited areas.



Oh, and I added in that 3d character model just to test how it will look when I get my characters done. That is just a sample model from Modo's showcase demo that comes with Modo.

Quick update.

I've spent several hours refining my grid system. Things should line up much easier now. I thought I had it working, but it was still a bit off last time I posted.

I have refined some of my game assets. I added some detail to the door. The portal was a bit skewed for some reason, so I fixed the camera and re-rendered it. I added a bridge just for some variation in scenery (of course the final game will have multiple types of environments), and I added some back-facing doors.

I'm not sure if I'll keep the back-facing doors like this because I want it to look like they lead somewhere, but I think it'll be okay. The whole level is like a cut-out or something. I don't show walls that would block the view.

I also learned some new tricks in modo such as duplicating the stone texture on the portal and making the second one to modify displacement and add some depth to the stones.

DLC said:

Got help from Godsmack, at first he showed me proportions of hand (drawings), then after had gotten size about right I sent the hand over to him sow he improved a lot on it: he made new skeleton (a much more flexible one), fixed polygons, fixed on little finger /pinky sow looks right compared to rest of fingers.

Click to expand...

Speaking of which, I am doing some practice since I'm about to do my main rig. I used your hand as practice. Some of the rotations of the joints were a bit off (like I said, I didn't have time to make it perfect, plus I'm still learning). Ideally, we want the joint to bend straight, just like real joints. I'll send you the file when I get it done along with some tips on fixing these kinds of things yourself.

I wanted an easier way to render my game assets. Since the game is isometric, I need things to be displayed from different angles such as walking up, walking down, walking left, etc.

I set up a camera system in Modo so when rendering I can simply select a new camera and that's all I need to do.

Here's what it looks like



Now, since the game is 2d, I actually only need one half of those. The others will be "mirrored' in the game engine. For example, walking right will be walking left mirrored. I'll adjust the cameras and get rid of unnecessary things when I start putting my first model in the game. I could add more if I wanted. It just depends on how things look. Of course, more angles means more renders I need to upload to the game engine frame by frame, and it will raise the memory usage.

Also, I was doing some research on how to get rid of those damn spiral loops created by Zremesher, and I found out that 4r7 is out, and it comes with Zremesher 2.0 which fixes this issue! Downloading now!

Cool, when doing things like this, I often study my own hand and see how it naturally moves. For example, the thumb will pull in towards the pinky when you close the hand or make a fist. The more observations you can make, the more you'll improve your ability to animate the hand (or anything for that matter). Keep it up!

You know, I have to admit that I'm tempted to make my game into a RTS. Think more like "Age of Empires" except smaller and more focused. Obviously, I can't compete with engines that have tons of different units and nations and focus on large battles. My game would be more about controlling a small group and you must get them to survive as long as possible. It would mix in some elements of the Civilization games such as researching technologies (such as an axe for chopping trees), and with the rock, paper, scissors combat style of Age of Empires.

Now, it may seem late in the game to change, but a lot of what I set up for this RPG will be used in the RTS. Either game will probably require the same amount of time to finish, given that I've mostly worked on gameplay and setting up templates so far rather than building the final assets. So, I will simply copy over the "base" that I built and rework it.

The RTS will be more forgiving in some ways. It would just be one map to worry about. No goals to worry about, just survival. Combat would not be as picky. With the RPG I have to carefully balance combat and difficulty otherwise it's pointless to play. The RTS characters are more expendable, and death will either be expected or not depending on the situation. Not every situation has to be a winning one.

I'm going to try some experiments and do some tests. Strategy is right up my alley. I can come up with hundreds of ideas a minute, and I've played these types of games to death. I'm sure that I can make my game stand out.

I've had a burning desire to make an RTS game, and I've gotten some really good ideas lately. I chose to make the RPG because I thought it would be easier, but really with this new idea I have for a small-scale RTS, I think that would actually be easier (and possibly more fun in some ways). Note that this does not mean that I would abandon the RPG forever. I would most likely finish it or rework it later on.

The map may be better if you could make it so you can toggle it on and off. Then, you can make it square to show more of the map and larger so it can be seen better. You could simply put it in the middle of the screen and make it very large, or put it to a corner (maybe at the bottom). As it is now, I think it takes up a bit too much screen space.

Unless it shows mission-critical information that can't be easily found, then most people will want to turn it off, or at least only show it when needed. For example, in Skyrim, it used small indicators on screen to indicate waypoints, and the actual map was large and on a separate screen. GTA used a simplified mini-map that was more of an illustration of the layout of the land, but it was used very often to navigate town, so it was always on screen.

Generally, mini-maps are static. The one I made a while back was just a screen shot. So once it was done, it didn't waste any resources. Do you need it to be active? If all it does is show the layout of the land, then it doesn't need to be a live view or fully rendered. I'm not sure what options you have.

But anyway, yeah, I think if you make it so you can turn it on and off, it'll be easier and give you more options. It all just depends on what you will be using it for.

starseeker said:

3) Extract a low poly game level base mesh using a combination of Tools (Mainly the game changing ZRemesher) , then UV it.

Click to expand...

Have you downloaded the new zbrush 4r7? Zremesher has been improved. No more spiral loops in arms and legs of characters!

starseeker said:

Its more of less done. I will sleep over & relook & touch up a bit. To improve efficient, as this is for a game, not a showcase art (to showcase my skill), I set a rule of acceptable quality (by my standard), about 80-85% of what I can theoretically achieve, & move on. This will shave a lot of time, as the final 20-15% can take longer than the first 80-85.

Click to expand...

Yeah, as solo devs, I think it's important to have balance. If we spend all our time on creating assets, then we won't have enough time for gameplay. The game still has to be fun and engaging regardless of how it looks. I also find that creating rough models and then checking them out in game helps because not everything looks the same when you see it live during gameplay. For me, I am working from a top-down view where everything is far away, so I need to think about how much detail I actually need in the game, and what will never be seen. For a first person game like yours, you need more detail than I do since people will be able to get up close.

It's cool. It's hard to judge until I see it in action. Are these spots meant to contain valuable treasure or be areas of great importance? Are people meant to find the areas based on the photo?

Alright, so since I am going to have bows in my game, I wanted to figure out how to rig one.

Here is a very rough practice. I will fine tune it on the final build. I just threw the bow and rig together so I could figure out how to do it.

I color coded everything for visual purposes. I started with the blue one, went straight back to yellow and then purple, then I did the green ones. I applied IK, and set up three goals towards the front to keep that part rigid.

It binded pretty well. I only had to adjust the yellow one slightly so it was not affecting the string area, but that took like two seconds.

The bow operates simply by selecting the purple bone and using the move tool to pull it straight back just like firing a real bow. That's it.

Like I said, ignore how rough it looks. It was just an experiment.