Road Kill Kenny

So I've got it mostly working though I forsee a problem. I was hoping to just have 1 of each type of "lego piece" (if you will), and then just paint them with different materials. However, when you load the same mesh twice it automatically instances the one that is already loaded and if you paint one you paint them all. This means I can't have a differently textured floor in one room than another unless that different room uses different meshes. So basically for each lego piece I can only have 1 texture on for a whole level. Is there any way to separate them (un-instance) the meshes without having to make duplicate gmf files of every single lego piece? If not I could potential just support a maximum of 3-5 differently named pieces that are exactly the same but different file name but I'd rather not if there is a better way.

Let the construction kit begin

Hi All, I'm trying to make a very difficult decision concerning level construction in my game and thought I'd bring it forward to see what other people think. Currently my levels are broken up into a bunch of sections. Each section contains a floor which is one mesh for the entire floor of that section and then a number of walls (varying per section). You may have seen this in one of my past blogs called "A Bucket 'O' Walls". Now this has worked and it is possible for me to go all the way like this. However, there are some downfalls namely Every section has to be modelled uniquely (almost) which means a lot of extra artwork and man hours The positioning of these can't really be "snapped" into nice unit lengths because they are all unique. Some rather big pieces with possibly bigger textures than I may want. Kinda pointless making an editor for it when everything has to be modelled in Blender first. Now I have been pondering another method which acts more like a construction kit/set where I pre model a bunch of level parts that I can re-use to make almost any level I want. I could make this work in an editor nicely and you simply put it together like lego and then add assets once the level frame is made. Some example pieces would be like 1x1m floor, 1x2m floor 10x10m floor, 5x3m wall, 1x1m wall corner etc. etc. Everything would be based on unit dimensions (no decimal points) that way the level could be made to snap together nicely. I could also have a set of standard textures that I could slap on them and would fit nicely to make level creation very quick. However, there are problems with this as well that I can see: Possibly too many entities making performance bad. Well yeh that's about it but that could be a killer. 　 So what do you think, risk the many entities or go with the unique level models and extra work. I'm kind of undecided at the moment. Please keep in mind when r esponding that my game is completely data driven and for certain reasons I cannot, use .sbx or leadwerks editor to make levels. I also doubt that the CSG editor in LE3 would mesh nicely with my code architecture (subject to testing) so for the sake of my question please pretend CSG & LE3 does not exist even though I may port my game over to it.

Yeh that's where I got it from.

I have 2 personal rules when it comes to textures concerning quality. 1. Don't compress normal maps 2. Don't compress anything with alpha. Everything else I compress and there isn't too much of a difference.

If you pre-fix all your LE commands with the LE:: namespace identifier when coding with LE2.X and C++ then it will be much easier to port to LE3 methinks... eg. LE::LoadModel() That way you can easily identify everything that needs to change. Also you can do a search for LE:: and and it will show you everywhere where you need to change the code.

No... you've misunderstood somewhere. Either way, it works pretty much exactly how I want it to work.

Thanks Chris. Yeh I have done no balancing in the game whatsoever. There is no real point in doing it yet because there isn't much of a game to play. But as you said, with my data driven design approach, balance is a matter of changing a few numbers in a well organised spreadsheet instead of wading through code to find the values.

Hehe thanks. I would like to play a demo right now too... unfortunately there just isn't much of a game to play yet. Getting closer though all the time.

Thanks Pixel

AI is something that I haven't really touched, hence the 'new frontier' title. However, overtime time learning how to program games and learning about useful techniques such as finite state machines, it did not worry me very much and I had a good idea of how I wanted it to work. There are three major things that I wanted when conceptually designing my AI system and they were: Diversity of AI Data Driven AI Modular AI Observe the below diagram. Simple enough. It depicts a turret class which is also a finite state machine and has a number of states in it, namely Idle, Attack and Seek. Now this all seems fine and dandy (if I may say simple as well). However, if we want to have a different type of fixed unit such as a cannon turret then we have a problem because we have to re-code all of the states of behavior even if it generally behaves the same. The image below shows how this can get out of hand. Now consider the below image. you can see I have taken away the behaviors from the fixed unit classes and placed them externally so that they not owned by the fixed unit. Now anything can re-use those behaviors. For the most part this is obvious, however, what if we want to have the same types of object utilize and chop and change different behaviors. We get what is shown below. This was ultimately my goal when creating this AI System. It may seem a little crazy and you might thing "WTF is going on there", but keep in mind that out of the 3 goals I had for the AI system, simplicity wasn't one of them. I just wanted to have as many options as possible. This way I can make the most out of every type of enemy or NPC in the game. There is nothing worse than only being able to use something in one single way for an entire game. The below video demonstrates this working in game, shows a bit of the Data Driven side of it and also some code. Enjoy. From a game design perspective, this kind of system is very good as you make the most out of each npc type and mechanic. The player see's a turret and from prior experience in the game that they first came across it they know what it does, it kills them..... However, with little effort the turret can be changed to be smarter and behave differently. The player will have to use what they know about a turret in order to figure out how to tackle the turret behaving differently... and this can be done with any number of npc's not just turrets, effectively diversifying the entire game. For example, you may start the game with the turrets not looking around, then as the player progresses you introduce turrets that look around, then ones that revolve.... Then when they think they have the turrets down pat, you introduce a room full of turrets that behave differently . This effectively keeps everything fresh even though you are using the same thing. (note this is just one example, it is important to have more than just one enemy type otherwise it could get a little bland). Anyway..... It may have been a bit much to follow perhaps because of its complexity / abstract way of doing it.... but more likely because I suck at explaining things. However, I hope you at least got the gist and learned something perhaps. I know I have.

Powered by.... RAINBOW FART!

3 words Chris..... drugs are bad! XD hehe nice work, the rainbow farting deer reminds me of the secret unicorn gun from Red Faction Gaurilla. The player holds baby unicorn up over his shoulder backward, lifts its tail and rainbows shoot out of its ***... classic.

I can vouch for TJ. He is probably the best sculptor/artist I've ever seen on these forums.

In this case not so bad I guess, so long as the performace hit is reasonable.

Yes pretty much. Unless you have voxels very small (which isn't really feasible especially not for mobile) they look ****ty.... I am so over the whole voxel cube thing. There can only be so many minecraft clones....

Oh hell no... please don't

There will be documentation from the start.... or so we've been told.

http://www.leadwerks.com/werkspace/page/videos/_/leadwerks-hangout-2-r157

So... at a hangout on Sunday? hehehe

Must be a matter of weeks at this point.

no

lol

no (lets see how many no's we can get) Here is all you need for the basic setup of framework with C++ Don't mind the LE:: I just like to so I know for sure that is a Leadwerks function. #include "engine.h" int main(){ LE::Initialize(); LE::Graphics(width, height); LE::TFramework fw = CreateFramework(); LE::SetAppTitle("Title"); LE::RegisterAbstractPath("path"); LE::BP lua = LE::GetLuaState(); LE::lua_pushobject(lua, fw); LE::lua_setglobal(lua, "fw"); LE::lua_pop(lua, 1); while([conditional statement]){ LE::UpdateFramework(); LE::RenderFramework(); //Majority of Game Code Goes Here LE::Flip(1); //1 for v-sync 0 for no v-sync } LE::Terminate(); }

I'm pretty sure it was part of Klepto2's custom engine DLL which exposed the paint vegetation to the API.