Search the Community

I just finished uploading the framework so that some friends can help out with the content and scene. I already have the overall theme and game put together, I just have to make them, and in this case get help with converting models, creating materials, and so forth. The framework is going extremely well. I've been working on it more than I should be to be honest but I did spend most of the day on the important matters. Plus it's Sunday for crying out loud. Anyways, I've changed several things about the framework. Here is a brief overview: Configuration is now available in the engine. This provided the gateway to the rest of the features I had plan for the framework, such as key/mouse binds, and generic configuration information for both the "engine" and "game." The key/mouse bind configuration file looks similar to: forward=w backward=s left=a right=d jump=space leap=lshift+space crouch=c | toggle fire=leftmouse aim=rightmouse grenade_toss=middlemouse | release grenade_cook=middlemouse debugphysics=f6 | toggle use=e It's fairly straight forward but the configuration file can contain basic instructions, such as "release" and "toggle." The configuration class itself provides the rest of the support. Examine the following, which is now accessible to Lua: if input:hit("leftmouse") == 1 then -- fire logic end if input:hit(input.get("use")) == 1 then -- use logic end if input:toggle("crouch") == 1 then -- do crouch end The engine configuration is managed with: config.get("resx") The game configuration is managed with: game.get("difficulty") One last feature I've added is a way to change between behaviors. These behaviors are strictly Lua, a hybrid, and strictly C/C++/C#/BlitzMax. If you provide the file "engine.lua" into the root of the project, the framework will only execute that LUA file after creating the graphics context and managers (config, input, game, etc.). The "hybrid" is a mix of the two. The framework calls upon specific Lua files at specific times. They could be looked at like "hooks." The Lua files are located at: "/scripts/dice" Examples are "update.lua" and "flip.lua." The framework also now handles scenes. It allows Leadwerks to process the scenes at the moment but then each entity in the scene to turn into an actor by the framework. This way you can get any actor: local actor = engine:getactor("myEditorAddedActorName") actor:translate(vec3(0,0,0)) actor:setkey("health", 20) Actors have their own Lua files and due to the structure described above we should be able to swap Lua files on the fly. The plan I will be attempting is similar to the following: local actor = engine:getactor("myactor") actor:setscript("newscript.lua") actor:runscript() I assume it will work, but who knows. Since per entity/actor scripts work the flexibility with the framework is fairly polished. I'm starting on default controller mechanics, soon to get into third person characters, and so on. Once my buddies can help me out I'll have more to test mechanics. Everyone should also check out Scarlet Thread Studios work, it looks to me like an RTS/TPS style framework, similar to Diablo series. Slight modifications can turn that into an RTS, FPS/RTS, and so on. Same with Pixel Perfect's engine Neutrino, which utilizes EKI One, and is turning out fantastic. I've bugged him to lease it but he isn't budging. Sorry everyone, lol. Just playing, Pixel. MG, always awesome work. Thanks for joining up to help with the content. Macklebee, hoping you'll come aboard and help me out with Lua. I'm really not in the mood to fully learn Lua at the moment. I plan to stick with hard-coded mechanics, lol. Read the above, it explains how to force the framework to let Lua control the main loop. Figured that would be your expertise. Awesome hangout session. I never planned to make it, thought it was out of my schedule, so it was kind of unexpected, lol. I had to register with Google+ and everything. It was fun, meant to talk about more, and to everyone else instead of just Josh, but I had to go AFK; turned out to be too long. I hope I'm invited to the next hangout but I don't have a camera. Thanks for reading.

There are several here who already know me, but for those who don't, my name is Paul Thomas. I've been programming for a long time now; I started when I was 16 (I'm now 30) with HTML, CSS, Javascript, and CGI/Perl. Hell back then there wasn't a lot of people who even used the internet at home, lol. At least in my area, I'm sure others, especially in California, were a lot further ahead at that time in terms of technology and the interest in the technology. Through the years I've learned multiple languages from strictly web-based to software based. My interest in computers when I was 16 was to make a game, but at the time I thought it would have been much easier to prototype the whole idea in a web-based browser game. I had completed the browser game, which was the original "Eternal Crisis," and worked nicely. My plan was to update the entire web-based system, polish everything, and officially advertise (I had invited friends to play the game). That's when I learned about a "fried hard drive" and eventually learned about "backup" and how to install a hard drive. Those whom already know me, know what Eternal Crisis is, and my Blogger shows some of the history on that project. I had taken that project, along with another, over to Unreal Engine 3 because it best suit the project. Along the years of learning that engine I was using LE for prototyping ideas and so forth. While I'm not working on my own engine (temporarily titled "3D Dice"), FPS/RPG framework for UE3, or R.A.T.S., I work on my framework for Leadwerks Engine 2.5. I've never shared this framework before, in fact it always felt like I had to pull it out of a shallow grave each time I added to the framework design and programming. I'm a notebook junkie, I plan out mechanics, structures, and so forth on paper, before going over to digital. Old habbits that die hard I guess. Now I felt like sharing the progress, which isn't a lot, but it's a great start to me. It's a great start to me because it actually runs, lol. The state of the framework isn't even close to the final planned and written design, but progress is progress. Always move forward until it's finished, even if you can only pick that project up once every two weeks (by then I/you should probably take a look at your workload and fix it instead of attempting such project schedules; however this isn't vital to me and rates low on my importance scale), if it's updated then progress is moving forward. This is also harder to work with if you don't plan your software before actually programming (unless it's routine for you with available libraries for shortcuts in development). As most programmers should know, the programmers "update" isn't as glamorous as an artists "update" as it's not about visual stimulation but overall program/software flow. In the case of my LE framework (obviously untitled) it's all about providing mechanics and how that is achieved is important especially in the case of LUA access and how everything works together; from configuration/data management, to input binding, and all the way down to AI. Until occupied again by my other tasks I will eventually share the entire framework structure and I will always be showing examples of syntax; cause that's what programmers do. Just to clear the obvious questions that may come from the community: Q) Do I plan to give away code, the framework, and be an open source kind of person? A) No, not really. First of all, you would have to wait, to anyone else at the moment the framework is as useful is a partially finished library. How long you would have to wait would depend on how much time I can spend on the framework and in all honestly it's not much at all (read above, and actually read). Q) Do I plan to sell or lease the framework? A) No, don't think so. I even think that's against Leadwerks terms since it could be deemed an "FPS Creator," which is definitely in the terms. Q) Is my framework really that great? A) Nah, I mostly ramble, and I'm actually writing this to share with long time friends here at Leadwerks. Some won't even visit anywhere else to communicate because they are so used to using Leadwerks for that; it is indeed where we all met. Q) Who are my friends? A) I have none, it was a lie. Now, about this framework. This "framework" isn't the same, exactly, as the framework that comes with LE. The framework that comes with LE handles some dirty work for you when it comes to creating the worlds, cameras for those worlds, shader effects, and helper functions. The framework I'm designing is technically similar to a game engine. I personally consider Leadwerks Engine as a rendering API with physics and this framework uses that rendering API and provides mechanics. The mechanics the framework provides is what makes up the detail of the framework. INI SQL Application Graphics Game The above are considered "managers" in that they only handle what they should be managing. The "INI" only works with INI files, such as a configuration manager. The "SQL" only works with SQLite3, providing helper functions for easier SQL management, and so forth. There are more planned managers than the above, but these are what are completed in terms of programming. The only real interesting portion to discuss about the framework is within the "Game" manager itself. The game manager provides two special classes/managers; "Object" and "Actor." Actor inherits everything about an Object. What defines an Object is a game entity that is never interacted with by the player. Objects are useful as it can be used for multiple purposes without consuming a lot of resources for each "component" or "plugin" I'd like to add onto the framework. For example, a Timer would be an Object. You don't interact with a Timer in a game, but there is a timer running in the background. Example: class ETimer : public EObject { public: ETimer(void); virtual ~ETimer(void); void Initialize(void); void SetTimer(float StartTime); void StopTimer(); }; While working with the framework you would do something similar to: // EGame::EObject // EGame::Objects EObject Objects; // .. ETimer Timer; Objects.Add("Timer", Timer); // .. ETimer Timer = Objects.Get("Timer"); Timer.StartTimer(0.0); // .. Timer.StopTimer(); // inherited by EObject Timer.Unload(); An Actor inherits everything that defines an Object. The difference between the two is that an Actor is something that a player could see, hear, interact with, or can move, rotate, and so forth. If you can see how this is all going, everything starts extending the Actor, such as the character, weapon, or items. Here are some examples of working with Actors in the framework: // EGame::Actors Actors.Add("oilbarrel", "oilbarrel.gmf"); // .. Actors.Rotate("oilbarrel", vec3(10.0f, 0.0f, 10.0f)); // .. Actors.Translate("oilbarrel", vec3(10.0f, 0.0f, 0.0f)); // .. EActor barrel = Actors.Get("oilbarrel"); // rotate with interpolation barrel.Rotate(vec3(1.0f), 0.1f); barrel.Translate(vec3(0.0f, 1.0f, 0.0f), 0.1f); // .. EActor Barrel; // new name Barrel.Name = "barrel01"; // new mesh Barrel.LoadMesh("oildrum.gmf"); Actors.Edit("oilbarrel", Barrel); A quick overview of an Actor: //EActor ID Name Tag Parent Location Rotation Mesh Sounds Particles Each Actor can also have children which are also Actors. This provides another version of parent/child relationships but also provides additional benefits which will be discussed in later blogs. The ID and Name variables are provided by Object and the Object provides more variables, but is listed for importance. When creating an Actor it is automatically tagged for unique identification. In the above example "oilbarrel" is actually stored as "oilbarrel_0" and simply incremented for each Actor that is created. This is identified by the Actors "Tag". The "Name" variable is a forced name, therefore searching for an Actor by the name, with more than one Actor having the same name, the first result is returned. Actors will be automatically created properly for each entity in a scene. The framework will be using a custom scene manager and handles initial Actor creation. Programmers/Scripters can then add to the Actors list with C++ or LUA like the above examples. class MyGame : public EGame { public: void Load(void); void Update(float DeltaTime); // .. void MyGame::Load(void) { Actors.Add("custom_actor", "mymesh.gmf", "force_tag_name"); EActor actor = Actors.Get("custom_actor"); EActor actorCopy = Actors.GetTag("force_tag_name"); actor.Translate(vec3(0.0f)); } void MyGame::Update(float DeltaTime) { EActor actor = Actors.Get("custom_actor"); // interp move with speed and threshold option actor.Move(vec3(10.0f), 1.0f, 1.0f, 0.35f); } }; In upcoming blogs, when I do get the time, I'll post up some videos. Those selected for the invite only alpha testing will get their information on how to use the framework. Friends of mine that didn't get an invite and are interested in alpha testing please private message me; I most likely didn't send you the information because I figured you were busy with your own project(s). Well, out of time. Thanks for reading.

Hello guys. This time, here is small utility, nothing spectacular, just smal library what will let you manage available screen size your GPU support, easy. You can also use it in main menu where you will setup all available resolutions and browse trough list, or automatically detect maximum resolution upon start and set screen, etc. So here are commands. So, first we need to initialize library. Global SCREEN_SIZE:TScreenSize SCREEN_SIZE = TScreenSize.Create(bitDepth:Int=32) bitDepth is your screen depth and by default is 32, and it means, supported resolutions will be for 32 bit depth. Now library is initialized. All available resolutions GPU support are accessible trough screen size modes. Screen size modes are nothing but indexes of array, where screen size is stored, for width and height. So, in order to know how many available resolutions we have, we will use this command: Global NUMBER_OF_AVAILABLE_RESOLUTIONS:Int NUMBER_OF_AVAILABLE_RESOLUTIONS = SCREEN_SIZE.get_number_of_modes_available() So, if you want to go trough list of all available resolutions, you will go from 0 to NUMBER_OF_AVAILABLE_RESOLUTIONS. If you want to set up screen size, you can do it like this: SCREEN_SIZE.size(width:Int=True, height:Int=False,mode_:Int=0,higherRes:Int=False) If width is true, returned size will be width. If height is true, height size will be returned. If mode is provided in range 0 to NUMBER_OF_AVAILABLE_RESOLUTIONS, It will be provided size for that mode, for width or height, depending which one is flagged true. If higherRes is true, it will be returned largest screen size for width or height, depending which one is flagged true. So, for example, if you want to setup your screen upon loading on to maximum resolution, since you dont know in advance what kind of GPU/Monitor will be used, and you want to set it higher so user can later change it, you will do simply this(example with framework): Global SCREEN_SIZE:TScreenSize SCREEN_SIZE = TScreenSize.Create(bitDepth:Int=32) Graphics(SCREEN_SIZE.size(,,, True), SCREEN_SIZE.size(False, True,, True), 32) LogStreamEnabled = False'AppLogMode equivalent Global FW:TFramewerk FW = TFramewerk.Create() If Not FW RuntimeError "Failed to initialize engine." ..and rest is history . By combining on many ways, you can have many use of it, from menu systems where screens will be detected, up to automatic initializations, etc.. Also, you dont have to sort out screen sizes. They are already sorted (0 means lovest resolution, SCREEN_SIZE.get_number_of_modes_available(), is the highest), so its easy. Anyway, you can see how to use lib in provided example, so it should be self explanatory. In case it doesnt work, let me know. INSTALLATION: As usual, copy e1.mod to mod folder, and include it as it was done in provided example, and you are good to go..cheerrsss... DOWNLOAD HERE: http://www.leadwerks.com/werkspace/files/file/351-screen-size-utility/

This time, I have decided to introduce character animation control. There are several reasons for that. A lot of people asked me to give some example, and at same time, such library will be essential for following AI tutorials, so having said that, I have decided to introduce AI library, so it will be avoided confusion with corresponding command set in AI tutorials. I would like to also make note that all libraries I have released and Im planning to release, are a lite version of fully fledged feature set in game engine Im planning to sell, after my game is out, so all this is some sort of 'advert' what full version can do, in order to make people more interested about system. Now, lets go back to topic. During game development, one of important roles are game character animations. From programmer standpoint, control of animations must be very simple, much as possible, with same rules applicable to both, gameplay character, as well as NPC's. Even more, it is important to have ability to have character easy 'switchable' between player control or some other system (cut scene manager, AI control, scripted event). So, how is it done in this library?? Very simple. First of all, during design, you will notice that there are always certain animation 'groups'. Animation inside those groups, should fall under same control scheme. Of course, it is entirely possible to have different control scheme for each animation group, but it is NOT advisable. So what are those 'animation groups' ?? Let me explain on provided example. Lets assume that our character has 2 main pose(im not sure is this proper word). In short, lets say that our character can move in normal way (standing up pose) and crouch pose. Each of this poses I call a 'group' . Animations within each group use (should use, but its not necessary), same command set. For example, when character walk while in stand up pose, we use KEY_UP so character animating in WALK animation. When we switch to CROUCH (let say hit button C as usual in games), then SAME command (KEY_UP) will make character animating in WALK animation BUT in crouch pose. Also, while character doesnt move at all, it should be in 'STOP' animation. That animation plays main idle and if player doesnt do anything, system should play some of side idles, if available and after it plays, go back to main idle (like, Lara Croft, bored and play various animations if player doesnt do a thing)..Library giving ability for creation of infinite number of groups and infinite number of animations within groups, so its up to designer/programmer to utilize system properly Library command set is rather simple, and yet powerful, so lets see command set. 'CREATE ANIMATION FOR CHARACTER CHARACTER:Tanimation CHARACTER = TAnimation.Create("MyCharacter.gmf",IdleTriggerTime:Int=20000) MyCharacter.gmf Its animated character we want to control. IdleTriggerTime:Int=20000 This is time representing how long will be played main idle, before plays one of randomly choosen side idles, if any. So it is time what system will wait player, before switch to one of 'boring' animations. Its exposed in milliseconds, so default value is 20000 what is 20 seconds. 'ADD ANIMATION GROUP('S) CHARACTER.extract_sequence("ANIMATION GROUP NAME", "ANIMATION COMMAND NAME", firstFrame:Int, lastFrame:Int,playType:Int=CONTINOUS_LOOP, idleType:Int=MAIN_IDLE, transition:Float=0.0, speed:Float=1.0) This command will extract animation stored in given frame range, under ANIMATION COMMAND NAME and inside ANIMATION GROUP NAME. ANIMATION GROUP NAME Thisis name of specific animation group, what will contain specific animations. ANIMATION COMMAND NAME This is name of specific animation, what will be used to play specific animation, during gameplay. firstFrame First Frame of animation lastFrame Last Frame of animation playType It is flag representing way animation is played. It should be left in default value (CONTINOUS_LOOP), as other modes are used for internal processing as well as for some other libraries im about to introduce later, during AI lessons. Just for info, available flags are: -CONTINOUS_LOOP -ONE_LOOP_THEN_IDLE -ONE_LOOP_THEN_STOP But as i said, you SHOULD let it be default value only, as others are used for other things, we will see, later. idleType This flag tells to system what kind of animation is one to be loaded and therefore, how it will be treated. If animation is MAIN IDLE then flag is MAIN_IDLE. If animation is idle for 'bored' animation, then flag should be SIDE_IDLE. SIDE_IDLE animations are attached to MAIN_IDLE and after idleTriggerTime is elapsed, one of SIDE_IDLE animations will be played and then go back to MAIN_IDLE. If animation is not any kind of IDLE animations, then it should be flagged as NOT_IDLE. This flag will be our, walk, run, jump, die, etc, animations we control. So possible flags for animation types are: -MAIN_IDLE -SIDE_IDLE -NOT_IDLE transition This is value representing transition smoothnes between animations. speed This value representing animation speed. Default value is 1.0. 'INITIALIZE ANIMATION SETUP WE WANT TO START WITH CHARACTER.enable_initial_animation("ANIMATION GROUP NAME", "ANIMATION COMMAND NAME") This command will basically set choosen animation group as default one and play animation from that group with ANIMATION COMMAND NAME when program starts. Usually used to setup main idle play before game starts. In order to play some animation in runtime, we use command CHARACTER.play("ANIMATION COMMAND NAME") This command has to be called just once and system will play it, long as it is not called any other animation. During runtime, we want to switch from one animation group, to another. In order to do that, we use this command: CHARACTER.enable_animation_group("ANIMATION GROUP I WANT TO MAKE ACTIVE") CHARACTER.play("INITIAL ANIMATION NAME I WANT FROM JUST SELECTED ANIMATION GROUP") And thats pretty much all. If you wanna free from memory all stuff, during switching levels and what not, just do this: CHARACTER.Free() CHARACTER=Null ..and you are freeeeeee... I hope you guys will have some nice use of this library. Stay tuned as MUCH more comming.. NOTE: Inside zip file is EXE. you can run it in order to see how it works. EXE contain all shaders, dll's, etc so dont put it together with shader folder of yours. Character seen in EXE example, I cant share, but source code of example is kindly provided, so you just play with your own characters. Also, library consider that all animations are stored along ONE frame line, so keep that in mind. Installation is simple..just copy e1.mod folder in to your Bmax mod folder and you are good to go.. Library available here: http://www.leadwerks...ion-libraryzip/

To prevent non Leadwerks Engine specific/Related entries from my Blog being automatically published here via the Blog Feed, I have removed that functionality, and will simply add a new entry title and link here for all Leadwerks Engine specific/Related entries. Leadwerks Related Blog Entry. Meet The Flockers.

Working on two principles K.I.S.S. (keep it simple stupid!) and more for less. I spent a lot of time researching (read playing) certain games that have what I call an ambient NPC population. This is specifically those NPC's that reside in the background and generally have no real or very limited interaction with the player. Two such areas of research <coff> included Assassins Creed and Fable 2. Although both of these games have a far more complex general NPC population than what I am setting out to create, but the "research" was most enjoyable. First Step: Machine Intelligence "Kinda Almost": Machine Intelligence "Kinda Almost", simply gives an illusion that there is intelligence at work but there is not, sort of like, the lights are on but no ones home. There are several subsets to this group but the obvious one is simple animation. Also this can include proximity reaction behaviour, a posh and complicated way of saying when the player is near, stop what you are doing, and do this instead. But that's as far as interaction goes for those NPC's in this group. This simple ambient NPC type could also use lua scripts, loaded with the level and be left to attend to themselves. For example, just two chaps having a chat: Having a chat is basically all they do, its simple per character animation's controlled by lua scripts. The purple block volume is the walkable area that would be utilised by more "advanced" ambient NPC's, typically those that move about, particularly those that would use Pre-Loaded and Pre Calculated path routes for this particular level. The purple block volumes are simply required by the application I wrote to generate the route node data for the pathfinding tools I created and have demonstrated here. Not that this is a level just something thrown together for testing but I think I should unarchive some of my GMF format models and put together a small town/Village for testing this, rather than another simple "BlocksVille". There are obvious limitations to consider with this approach to the first tier of the Ambient NPC population for a "busy" town/village. The NPC's need animation's, most come with maybe 15 animation's (if you're lucky). My intention is to surmount this by adding animation's to them, primarily Mo-Caps. This will require a little work but will be the bedrock for the construction of this "tier". There are some very good applications on the market for achieving this. For me I prefer Fragmotion, there is also a free alternative that I also use on occasion called Pacemaker. But don't be fooled though, none of these applications will do it all "for you", you will need to skin the mesh to the correct rig for the plethora of free to use Mo-Caps, or indeed ones that can be purchased. It will all depend on budget and or requirement. This is still only a very basic outline for this "packing" stage, it will still require a lot of work but my goal is to get the impact of it at runtime to an almost negligible effect even when including proximity reaction behaviour.

Following on from "On The Right Path, A* Pathfinding In Leadwerks" I thought before I archive the code, I'd have a little "dabble" with a basic function to get an NPC reading the path data and then following it to the "target" I had a couple of ideas on how to do this but as time for playing in leadwerks was running out I opted for a basic idea. 1. Target Position Selected 2. Path from NPC to selection calculated. 3. Path transfered to a temp storage array for that particular NPC 4. An NPC Pilot reads that data. 5. NPC follows the pilot. Think of the "pilot" as the plastic stick thing on the underside of a scaletrix car .. it follows the groove in the track and the car follows right along. This was the quickest and dirtiest method but solved a variety of issues in one. Plus I just wanted to get the NPC moving and the sands of time were running out. So an hour later and I have not only the NPC following the generated path but the path is updated with a repositioning of the target and the pilot takes the NPC off onto the new track. This is all still quick and dirty, when I can remember what the code does and does not need, I will up a small demo.exe to the thread Pathfinding With A* EDIT: I have uploaded a demo.exe here : Hide And Seek Demo

Well, it has been a while since I made a blog entry, let alone done any work in LE. But I do keep an eye on the forum and Leadwerks in between Daily life and working on my project(s). I have also been going through my Blitzmax code archive, where I stored all my Blitmax/LE projects and code snippets (finished and not completed). One idea I had been playing with before, was basic NPC AI. I had some small success with some Bugs using autonomous logic. See Here In my "treasure trove" of unfinished and messy development code I found what was going to be the next step (for me) with AI functionality. The dreaded "pathfinding". I have read that Naughty Alien said he will be doing a two part tutorial on this and I am looking forward to that, having followed his work with Hidden Dawn I expect the tutorial to be top notch. But I wanted to get to grips with the in's and out's myself. So I started with the basics. I spent some time looking for code snippets and A* lib's in any language that had them to see of I could follow along what was being done ... Not a good place to start, in the end I spent some time reading "A* Pathfinding for Beginners", very helpful.I decided it would be best to start with a "2D" approach and maybe use nodes. Most 2D implementations use a grid based on the X and Y co-ordinates of the screen and tiles to represent an "unwalkable" tile. So I thought I would translate this approach to a 128 x 128 flat terrain with some primitive models to define the "unwalkable tiles". As this was a time limited "side-track" in LE from my other projects, it was all going to have to be quick and dirty. I wrote an app to calculate which "tiles" of the 128 x 128 terrain did not have an obstruction and then squirted this data out to a text file to be read into another app as a 2D array. The map data loads in a few milliseconds so this eliminated having to wait for the same data to be generated by the application I wanted to use to try and get the pathfinding working. One problem I did encounter was that I ended up trying to reconcile three different centre of origins for the co-ordinates. The map data had 0,0 at the top left, the terrain of course has 0,0,0 in the centre and my maths managed to get the A* to read 0,0 at the bottom left, after some profanity meditation I used some quick and dirty and hastily constructed math functions to bring them all into focus, thus as per usual the dev. code was a complete mess, atleast on that score I am consistent lol This version of pathfinding is very limited, mainly due to the way I created the node info. But for a first attempt I was quite happy. I have uploaded a demo App to the showcase , the picking can be a little temperamental and sometimes the quickest path is not always found and some "sightseeing" seems to find its way into the route. But on the whole I think it is definitely a platform on which to build.