Rick

I personally think it sucks that we have to handle this on our own and this is why having a GUI built into LE would help a lot because it's job should be to handle stuff like this. You have a couple options: 1) You can use code that is dynamic to the resolution/aspect ratio 2) You can do setup/config that is specific for each resolution Web programming (CSS) is the path for step 2. It's a little more tedious but if gives you fine control over everything. However, you have to code this system in LE because LE doesn't have any CSS type of concept. I'm planning on this system so you do get fine control. In this process you have some configuration data where you have have every control name and it's position/size listed per each resolution (or it can fall into more than 1 resolution if the resolutions are close enough and you want to use the same pos/size data). So let's say you have your flashlight bar. Ideally that's an element with a name and in this config file you'd have something that branches off based on each resolution and you give that element's pos/size for that resolution. Another way splits position and size into 2 different categories. Positioning becomes relative to anchors points on the screen. Anchor points would be top_left, top_center, top_right, right, left, center, etc. 9 anchor points in total. All of these anchor points should be calculated using functions like window:GetWidth(), window:GetHeight(). Sizing can also be calculated based on the resolution. This method can have artifacts because it's all calculated and it may end up with some strange rounding errors. So basically it's a pain in the ***. With either systems you have to code the system to do these things and 1 method makes it tedious in setup but exact control over everything, and the other is less tedious but with a lack of control. A hybrid could probably be created I guess as well. I'm going to create a system for our game that uses the CSS type approach and hope that it'll be generic enough and not that invasive so that it's easy to re-use for people.

Yeah, it would be cool to create a module to plug and play some of these basic UI elements. Does your html scale correctly according to the resolution/aspect ratio? That's always been another issue for me.

Yeah, I'd love to see the html/css/javascript for the inventory. That was a part that sort of stumped me. Also, did you get keyboard injection working with Awesomium?

Unabomber style.

I love Awesomium. Did you actually get the inventory working yet (dragging icons around and such?).

1st I'd say your bool1 and bool2 are global variables and you don't want to do that. Add self. to them. Next I'd say where are you doing that if check? It's outside of any function. Ideally you'd make a function in that script and check call it inside both Input1() and Input2().

Don't live in WI, it's ****ty there. I would suggest either MN or IL where you are about 15 mins or so from either cities (Chicago/Minneapolis). MN is a better nature atmosphere than IL. MN is one of the biggest bike (pedal bike) community so if you're into that there are paths everywhere and you could bike to most places. Minneapolis also has a lot of arts stuff. The people are nice, but watch that Minnesota nice thing. You can get to know a lot of people but it might be harder to break into groups of friends and become really good friends with people as most people are born and raised here and have established friend groups. Activision has a branch here as far as gaming goes but that's pretty much it. There are a few small game companies here. Overall, I'd never live anywhere else personally,

It moved to the model editor. Double click the mdl file in the assets window and in this model editor there is a physics menu option. Things have changed since a lot of these video tutorials.

As hank said use a pick, but you can also pick from the camera itself (where the mouse position is the center of the screen). No need for that specific example to use the world and Transform:Point(). Same idea, just an alternative way to do it. http://www.leadwerks.com/werkspace/page/api-reference/_/camera/camerapick-r199

I'd used it and it works. It's complicated to setup though because behavior trees really need a GUI to be easy. I might do a video tutorial on it. I think the flowgraph in LE is just really meant for level designers making level events and honestly it's great at that. My concern is that Josh thinks he can make our games for us all by himself by providing all the models and scripts instead of focusing his time on systems for the engine that all us to do all that stuff for ourselves easier.

His PC isn't powerful enough is what I'm getting from that. I think it needs to be HD Graphics 4000.

From watching that video, it's almost like there are 2 pivots. One at the start of where you want to rotate and one at the end and the amount of rotation that happens depends on the distance you are to that pivot. So maybe a way to do this would be to put a csg with invisible mat on it and set to trigger with a script attach around this entire area. Then put 2 pivots on the start and end of this area. When the player is inside the trigger and moving in the "right" direction check the distance from the end pivot and rotate a value based on that. If the player is moving "left" check the distance from the start pivot and rotate a value based on that. How to figure out how much to rotate by distance, I'm not 100% sure. I guess you'd figure out how much total rotation you want first. Then you'd figure out the total distance from the 2 pivots. That should tell you perhaps how much to rotate every 1 cm based on the distance each frame. Then use the Math:Curve function to make it smooth.

Go into the users appdata folder and check out the log file to see if it leads to any clues. I think that folder is hidden by default so you'll need to turn that on or perhaps just navigate directly to it in the address bar. C:\Users\Rick\AppData\Local\RTS Where 'Rick' is that person's username and 'RTS' is the name of your game.

No GUI (graphical user interface) in Leadwerks. What you are doing is what we each need to do at this time. Feel free to make a system for others to use

Put in a bunch of System:Print() statements and give them numbers at various major points in your code so you can see the last one it hit and you can narrow it down to where it's failing. Generally these are when things point to entities that don't exist.

You are correct, however, the complexity with AI isn't in the tasks that check for conditions or even do specific actions like shoot a gun (and these are the things we should create in script), it's in structuring all that logic. That's where the AI complexity comes in and that's why having a more structured "if" statement system is important. Imagine if you/we are able to just focus on writing small scripts that do specific checks and tasks and people can pick from a huge library of those and combine them in ways they want visually to make different behaviors. You can devalue these systems all you want, but the entire game industry has moved to behavior trees. If you don't do them today in LE, you'll be doing it in 2 years. If you haven't looked into behavior trees, it's well worth it. I'll stop beating a dead horse now

I'd still question why you want to store position for a cell. Your cells should be a constant size and because of that you calculate the cells position based on the row/col with (note this is the opposite of my other formula that caled row/col from position): Here are the functions and constants we use in our game. We created a 256 size terrain and this lays a grid over that. TERRAIN_HEIGHT = 13.44 TILE_SIZE = 1.28 TERRAIN_SIZE = 256 TERRAIN_GRID=200 -- utilities function TileToWorld(row, col) local x = ((col - 1) * TILE_SIZE) - (TERRAIN_SIZE / 2) + (TILE_SIZE / 2) local z = ((row -1) * -TILE_SIZE) + (TERRAIN_SIZE / 2) - (TILE_SIZE / 2) return Vec3(x, TERRAIN_HEIGHT, z) end function WorldToTile(pos) local col = math.floor((((TERRAIN_SIZE / 2) + pos.x) / TILE_SIZE)) + 1 local row = math.floor((((TERRAIN_SIZE / 2) - pos.z) / TILE_SIZE)) + 1 return row, col end There is little need to store the position of the grid when you can calc it like this. Save yourself some memory and these calcs are fast and you don't do them all the time anyway. Only when certain things happen and you need to know the information which isn't every cycle usually. About your PPS. I still think look into the LE entity callback functions. What I would suggest personally is that you mimic the Lua entity script structure in C++. Below would be the general idea on how you'd do that, but the jist is that there is a Draw() callback that I believe only gets called when the entity is visible. Put your animation update code in there so animations only happen when it's visible. Look at the hooks at the bottom of the page. http://www.leadwerks.com/werkspace/page/api-reference/_/entity. These are all hooks that get called per entity when you attach the hook to an entity. If you are using C++ and OOP my suggestion would be to attach these hooks to the entities that need them (actors and other interactable/movable things). Now the bad part about this is that these are global C function hooks and that generally doesn't mesh very well with OOP. So what I do is the following (and this mimics the Lua entity script system but in C++): 1) create a base class with virtual functions for each of these hooks. ie. class GameObject { private: Entity* e public: GameObject(Entity* enitty) { e = entity; } virtual void OnDraw() {} virtual void OnCollision(params here) {} virtual void OnPostRender(Context* c) {} virtual void UpdateWorld() {} virtual void UpdatePhysics() {} virtual void UpdateMatrix() {} }; 2) Create derived classes from this GameObject class for certain entity types like Actor, Mine, Tree, TreasureChest, etc and define their virtual usages of those functions. 3) Now after you've loaded your map loop through all the entities and have some way to identify what kind of type it is and make a new instance of that class. If it's a Mine, then create a pointer to a Mine class. Also be sure to hook that entity to all those hooks. 4) Now you pass that pointer as user data to the entity itself. That pointer will now stay with that entity wherever it goes. http://www.leadwerks.com/werkspace/page/documentation/_/object/objectsetuserdata-r22 5) Now when those global C hooks are called (LE will call them automatically), it'll pass in the entity that it's running that function for. From that entity you get it's user data (your class instance) and cast it to GameObject pointer and call the corresponding virtual function. It's been some time since I've been in C but I believe it's: void Draw(Entity* e) { GameObject* obj = (GameObject*)e->GetUserData() if(obj) obj->OnDraw(); } So now your derived GameObject classes become your entire game for the most part. This really gives you a nice OOP style with LE in C++.

Our grid map is a 200x200 2D array (and we can go MUCH higher with no impact) making about double the cells you are thinking about. I feel like you are over optimizing/thinking before you even begin. If you do this your life will be A LOT more simplified in pathfinding and entity placement. I personally think it's easier to get the entities location and do a simple calc to figure out which cell it's on. row = math.floor(entity.position.z / TILE_SIZE) col = math.floor(entity.position.x / TILE_SIZE) This is a lot easier than having to worry about storing and updating and all the management that comes with swapping pointers between cells as things move. I just see more trouble than it's worth when you can figure all that stuff out. No need to be looping through all the objects. You won't be dealing with all the objects. Most of the time to get entities you are picking with the mouse, or doing a bounding box check to see what entities are in a radius around another entity and LE uses ForEachEntityInAABBDo() for that. Once you have the entities this way you do that simple calc to see what cell they are in and bobs your uncle I just think you're making your life harder right out of the gate for no real advantage. If you want Lua type behavior where your entities can have code that runs every cycle (like UpdateWorld) then you can attach LE callbacks to your entities and handle it that way so you don't have to loop over any sort of list of things on your own.

OK, we are using a grid system with A* pathfinding so I understand your decisions now. If I was to look at your grid cell I'd say you don't need to store position in it. By using a 2D array you can calculate (easily and without any performance hit really) the cell position whenever you need to. It's very easy to convert from 3D position to cell position and cell position to 3D position (center point of the cell anyway). You also don't need to store the entity in a cell in LE. Curious as to why you think you'd need to store an entity per cell? In our game the 2D map is a pathfinding map combined with SOME information. What does that mean? It means each cell just stores an int. 0 means it can be walked on and a non 0 means it can't be walked on. This tells the A* pathfinding library where things can walk. The non 0 part is the "some information" I talked about. We use these numbers to identify things about non walkable areas. For example 1 could mean nothing special but just can't walk here. 2 might mean water, 3 might mean something else, etc. So now you have a 2D array that solves a lot of your problems.

My opinion is that you can deny an AI system isn't needed until the cows come home, but until you implement one of the common systems out there in the gaming industry you're never going to get your more complex and interesting games that you seek from us. You said yourself that you have plans for implementing a multiplayer system and a GUI system. Why? Given your stance above there would be no need to do such a thing. People can just implement it themselves like you want them to do with AI. Why would you view networking and GUI any different and make plans to implement those systems in LE? An AI system is no different than a networking and GUI system. So for me, your opinion seems inconsistent. All I can think is that you devalue AI because you feel it can be thrown together willy nilly, which hey, let's face it, any of those systems can be thrown together willy nillily. The point of an engine is to provide nice, consistent systems for it's users that make making those things easier. Today your solution to that is to write your own and give it to your users. Do you really think that's the correct solution to this problem? Let's put it this way. Think back before you implemented pathfinding. Do you remember those days? Probably about 1% of the users had things moving around in their game and those users went to great lengths to do so. Your stance was that you didn't need to make a system for them, they should be able to do it themselves. Flash forward to today. Basically every game created uses the pathfinding system in some way and everyone has things moving around their game. When you implemented pathfinding you created a 'movement in game' boom. Every kid on the street could now easily move their character controllers around the scene. Yes, it has issues and limitations and caused you a headache, but would you take it back? Would you remove it from your engine? No way! The exact same thing will happen if you create some kind of AI implementation, which you don't have to fully make yourself but just implement a library that exists like you did for pathfinding. There is no way you can deny the implementation of pathfinding in LE helped people make more interesting games and doing an AI system will do the same. You shouldn't be spending your time implementing custom spaghetti AI code for all these different types of enemies in my opinion. It's a waste of your skill.

If it's a game like Kings Bounty and the map is static once it's built why are you wanting to use a grid system at all? Why are you thinking this needs to be a grid based game? Build it in the editor and use LE's built in navigation system for movement.

I would take Sakru's advice with a grain of salt personally. I wouldn't agree with that at all. That's like saying if you really want to drive a car you should make it yourself. You don't need to do that and in fact very few people are doing that in this day and age. You are just starting out, the idea is to start way smaller with your idea first and build the experience it takes to making a game. Seriously, your face game should only take a month and should be very very basic. Probably to the point where it's pretty boring but has basic game parts to it. GUI, player interaction with something, leaderboard maybe, very basic enemy AI.

Just because they don't work often is no reason to give it up. Failure is only a learning experience.

I agree with martyj. I guess my recommendation for trello at this point for him was to bullet out rough draft of what he wants his game to be (what high level features) and assemble the design doc from there as his thoughts are most likely scattered and all over the place and I find Trello to be a nice way to easily organize my thoughts given lists and tasks that you can dragged around and move easy enough, but yes ideally I agree with martyj, you need that design doc at some level once your ideas are organized enough to make it. Then Trello can double as a task list of things to actually do. I view Trello as a jack of all trades vs just a scrum area for development I guess.

A fb page isn't going to do you much. You'd be better off starting a public Trello page for people to see and get your ideas down in there and then organize. That's a better start than a fb page. Also, the game you are looking to do is too much. It sounds like you've never completed even a small demo so no way you should be looking at the game you are. That has to be your 5 year goal game, not your 1 month goal game. Get a game idea going that you can finish in 1 month's time and start from there.