In my other blog (https://www.leadwerks.com/community/blogs/entry/1908-top-10-celebrities-who-use-component-architecture/) I talked about the component architecture I was using. I've since teamed up with Roland on this idea and together we have fleshed it out more. It's not 100% ready to be released yet but I realized that we've come a long way and that where we are today might seem confusing to someone if they weren't along for the ride. So I thought I'd use this blog to start down the journey
The last blog I posted was Nov 2013. The blog section seemed stale for for a week or so so thought I'd share a change in design I recently did for our Dead Anyway game to spark conversation and ideas.
Our player script was just getting too massive and was doing too many different things directly inside of it. Adding features or modifying existing features was scary as hell. All the "helper" variables were adding up and the amount of hunting for what I needed in the script was pissing me off.
I like the idea of being able to add dynamic properties at run-time. The following code shows how you can set this up. Instead of declaring a hardcoded amount of variables in a class you could just give it 1 Properties class and it can be dynamic!
#include <string>
#include <map>
using namespace std;
class Prop
{
public:
virtual ~Prop()
{
}
};
template<typename T>
class Property : public Prop
{
private:
T data;
public:
virtual ~Property()
{
}
Property(T d)
{
data = d
[EDIT]
Now with sound!
I'm making a game that revolves 100% around old school final fantasy battle style fighting. I thought about what often slows me down and kills my motivation in games I've tried to make in the past. My conclusion was that dealing with graphics (models, UI, animations, etc) often slows me down in various ways. So as an experiment for this game I'm going to first code the entire core gameplay in a console application with a basic text based interface first.
I'm ho
Thought I'd share my experience like Aggror did.
First I'd like to say that it's a bummer that only 11 people voted so far. It's not a very big sample size and I hope many more will vote in the next day. I'm open to leaving the poll open for longer to let more people try the games available. Maybe over the weekend or so as people might have more time then.
I'm also bummed out that only Aggror and myself have exe's to try. Was hoping for a better turnout and if he and I win it's a littl
There is no question that LCP (Leadwerks Community Project) 1 had some issues. I think we learned a lot from working on it and I'd like to apply those lessons and give LCP another try with LE 3. I'm thinking with CSG, "automatic" pathfinding, and a better scripting system that LE 3 has to offer will greatly increase the speed and quality of another LCP project.
This blog entry is to get a feel for people interested and to give a basic overview of the game and requirements. Unlike the last LC
I like reading blogs and Josh has been the only one spamming them recently (j/k I know we all love hearing about LE3) so I figure other people like reading blogs too. So I thought why not make one about what I'm working on.
Over the last month or so I had pathfinding working using basically a 2D grid over a terrain using A*. Being able to move actors around like that just feels so inspiring and feels like the sky is the limit which what you can do with that. I had so much fun with just that
<?xml version="1.0" ?>
<root>
<behavior name="create_cube" >
<result type="Entity" value="cube1" />
</behavior>
</root>
These 6 lines are the start of a flowgraph system I'm working on. I've been playing with UDK's Kismet and enjoying what it can do. Now UDK's Kismet is pretty specific to UDK functionality for the most part. They have things like SpawnPlayer, which LE obviously doesn't have. LE gives you much lower level control than SpawnPlayer type s
So I was able to get prefabs working with the component design. It's really easy too! A prefab is just an xml file that describes the different components and their attributes that make a game object.
For example, in the editor I added an empty game object to my scene, then attached a spotlight component to it. This provides spotlight functionality. It creates an LE spotlight and exposes some attributes to control the spotlight. I then right click the game object and choose Save As Prefab.
The Goal: To be able to open a world of game functionality to non programmers, and to allow programmers to create this functionality. To give drop and drag with configurable functionality without restricting possibilities in any way.
The Design: This approach uses the component design along with an attribute design. The attributes represent the data a component wants to expose. A component is a smaller behavior piece that is attached to a game object. Components expose events. Events drive e
I implemented rising numbers of the amount of damage or healing that is happening to a unit. I spent a decent amount of time to have it like a billboard so it had depth but I think I'm better off just using DrawText() instead. It looks better. I made the the Shield Slam cause 5 damage and it worked very well. Just 1 minor bug with the way the health bar is drawn on the right hand side. Instead of the just the width to worry about like the left hand side I need to change the x value and the width
This will be my dev blog for Warlords. It's coming along very nicely and I'm very proud of what I have so far. This is a game that has been in my head for a long time. I've made past attempts to make this game but they all failed because when I would find a "bug" in Leadwerks that would set me back I would just stop. This time I'm determined to complete this game. Players don't care about if you had to hack something together and now either will I. If Leadwerks has a bug or doesn't do something
I got all 3 of these functions working. I'm working on an script to show how these 3 will work.
DoSound(cr, 'abstract::hello.wav')
DoMoveTo(cr, fw.main.camera, GetEntityByName("pivot01"), .05, 1) -- moving the camera to the pivot named pivot01 at a rate of 0.5 and it'll stop when it's at a distance of 1. This move function doesn't use physics. Another function will use physics for movement.
So I was able to get DoWait() working. It's not 100% ideal because you have to piggy back off another entities Update() method because of the limitation of not being able to have any global values. If you would like to try it out I'll give the steps here.
1. Make a file under the /Scripts directory named cr.lua and paste this code in it:
tblWait = {}
waitID = 1
clsWait = {}
clsWait.__index = clsWait
function clsWait.create(tm, func)
local wait = {}
setmetatable(wait, clsWwait)
wait.i
I'm currently working on coroutines in lua. This will help people setup scripting sequences for their game. The cool part of this will be that you will use it in the editor like any other entity. Drag it into your scene and now in your other scripts you'll have access to these functions. Here is an example usage of what you would do in lua.
--- This defines the function that stores your script sequence
function MyScript01(cr) -- cr is the coroutine to this function. The functions th
I've made and continue to work on 3 objects that you can drag into the editor and get player movement features in about 2 mins. I'll discuss them and their plans here. I prefix them with Pi because that's my sort of namespace so when you place these in your editor's path they won't have the same name as other objects you create/download. Pi is the start of my last name and I'm using it as a brand or sorts also.
Character
http://leadwerks.com/werkspace/index.php?app=downloads&showfile=46
