Tag Archives: Loop Dipole and the Chaoties

Legend of Hondo is Dead! Long Live the Commodore 64!

Life is full of compromises and choices. Given that my time is not infinite, I have chosen to focus my “nerd hobby time” on working with a single computer, the Commodore 64. As a result, here is where my previous projects stand:

RocketTux
Side scroller web based game
Will be finished in 2018-2019. Once finished, I will package it as a native application, using NodeJS, for Linux and Windows. Even though it will not be released as a Chrome App for Google Chromebooks, as it was originally intended to be, I am sticking with the goal of having it play well on a low-end Chromebook (instructions will be provided on how to do so).

Legend of Hondo
Star Wars Galaxies Emulator server mods
Will not see further development. Last fall I was working a huge branch related to Bio-Engineer, which would have been finished were it not so tedious to make BE pet versions of some animals – I bit off a giant chunk of work that I just don’t feel like doing, but the rest of the features for that branch were finished. The plain truth of the matter is that I don’t play the game and it takes way more time/effort to develop it than I want to spend on a game that I don’t play!

Loop Dipole and the Chaoties
Blender Game Engine
Game play wise, it wasn’t fun and that really disappointed me so I took a step back from it for a couple years. BGE also proved to be overwhelming to work with after the project grew beyond a certain level, so I will not be finishing this iteration of the game. However, the initial concept of “go fast and have fun getting there” and the rest will be the basis of a game that I make for the Commodore 64 once I have become skilled with Assembly language.

Rescue Girlies
SDL / Supertux mod
I have not updated this game since 2014, just as I said I would not when I released the custom GPL version of the game. It was a “one off” game that truly I made only for my kids, but I released to the open source community as a way to give back some of my knowledge. Play it if you’d like or study the differences between it and SuperTux 0.3.3 for an idea on how to make such mods.

Solozeroth
World of Warcraft Server Emulator mods
Yeah, I don’t really play this one either, so I haven’t bothered working on it in about a year now! Wrath of the Lich King era was the best, but it’s kind of boring to play solo. That said, the TrinityCore server code base was a pleasure to use!

Tux Time, by Fives
Web based educational game
I really wish I finished this game, but for a while there my girls did use it on the tablet to help them learn how to read a good old analogue clock. All that is missing are the voice overs and the sound setup, so I will post the source on Github, but I will not be developing it further.

SuperCombiner
Torchlight II Mod
I occasionally play Torchlight II and when I do, I use this mod. It still works and I’m content with its features, so it doesn’t need any further development. Along those lines, Torchlight II itself, with the handful of mods I have downloaded, is also fine the way it is so I won’t be creating any other mods for it.

Music Production
Sunvox and Impulse Tracker on PC
I don’t spend a lot of time tracking music anymore, but I will continue to do so when the mood strikes. The sound produced with these systems is completely different than what I will be creating with the Commodore 64.

Electronics Hobby Computer Prototype
Arduino UNO programmed using a Raspberry Pi Zero
I very much would like to build this prototype, but it seems like a frivolous use of our limited discretionary funds and it likely will not be produced. The major expenses are a basic “ten keyless” usb mechanical keyboard ($35 CAD), the 4″ LCD display ($40-$70 CAD), and misc electronic bits (??$$ + shipping…). I estimate the prototype would cost about $200. If I can scrape together the parts, I’ll totally build this a little bit at a time as a proof of concept, “just because”. 🙂

I would like to thank everyone who encouraged me to work on these projects over the years, especially the supportive folks in the SWGEmu server modding community and the world of kind people who contributed to the open source projects upon which my own projects were based.


My game plan for the future consists of the following,

  • Work through the Commodore 64 Programmers Reference Guide, using a real physical book even!
  • Learn everything there is to know about the Commodore 64 hardware and software!
  • Share my Commodore BASIC programs on GitHub in text format.
  • Share my open source games/software in disk image format using Google Drive.
  • Learn how to program EEPROMs and make cartridges.
  • Make a game that is worth selling and distribute it on cartridge – how cool would that be!
  • Try to make an Arduino UNO compatible electrical system that can be programmed using BASIC.

If you’d like to listen to me talk about this sort of thing for 24 awesome “stream of consciousness” minutes, have a gander at the video below! If not, suffice to say that I am making this change of focus so as to get the most return on my “time spent doing things” investment, while also increasing the likelihood that the things I create may actually be of use (perhaps even after I kick off and walk the stars!).

Project Scope – Size Matters

Lately I have been thinking a lot about what I want to do with my “hobby time” and why I want to do it. There are lots of things I enjoy doing in life, but there is only so much time to do it all! It really is imperative that we have some kind of plan to avoid running out of time (or will) and never accomplishing anything. And, that’s where project scope comes in to play.

I’ve determined that there are three basic questions you can answer to determine the correct size for your project, with size being the time, effort, and emotional investment required to finish the project. The questions are,

1. Who is this project for?

2. Why am I doing this project?

3. What is the project about?

To help you understand how this works, I will provide three examples from my own life, Legend of Hondo, Loop Dipole and the Chaoties, and gardening with my family. Each of these projects absolutely have their own scope, their own size, and all three can become completely overwhelming if I lose track of the who, the why, and the what of it all. Writing this post is a way for me to congeal my thoughts, but hopefully reading it will also help you not feel as overwhelmed and paralyzed about your projects as I some times feel about mine.


Legend of Hondo
This is a massive project with hundreds of “moving parts” and by its very nature, taking one game and morphing it into another, it’s something that will take years to complete. And it’s that very “long term goal” aspect which can cause the project to become emotionally crippling – it’s a huge pile of work, with more work heaped on top of it, which can’t really be used until all of the work has been completed. It’s easy to give up on a project like this if you’re not satisfied by reaching incremental goals.

In the beginning, before it even had a name, my Legend of Hondo project was just about making a Star Wars Galaxies Emu server that I could play on alone. Then I got to thinking that I could finally fix some of the stuff about the game that bothered me, which in turn lead to making new content and eventually coming up with an overall theme for a single player RPG. But most importantly, Legend of Hondo was supposed to be for ME, just ME. Unfortunately, my work on the project caused me to get side tracked by fan mail and requests for assistance with other projects, which of course I answered, because I am a nice guy. So all of a sudden my personal pet project exploded into a menagerie of systems and customizations for various SWGEmu based servers, all wrapped up in the need to keep up to date with the ever changing, constantly “refactored” state of the SWGEmu code… As much as I like helping people, doing so made me lose sight of why I was willing to put up with the convoluted science project that is the SWGEmu code base and the game client for which the modding tools are tedious. I’m doing it for ME, so that one day when I am an old man I can sit down and enjoy the game – it doesn’t need to be finished tomorrow or even this year or even at all really and how it works for someone else doesn’t matter in the least.

So to sum that up a little less emotionally…

1. Who is this project for?
Legend of Hondo is something I am creating for myself, because I feel like it.

2. Why am I doing this project?

I am creating Legend of Hondo mainly so that I can enjoy the end product at a later date, but also because I enjoy designing the new systems and creating the new content. I also enjoy most of the programming and some of the artistic challenges involved.

3. What is the project about?

Legend of Hondo is all about making a single player version of Star Wars Galaxies that has everything I always wanted in the original game. It’s the combination of opened ended game play (where you are free to do what you’d like, whenever you’d like) and a sort of choose your adventure type story, where your actions build a meaningful sense of identity for your characters. That day when you finally become The Dread Pirate or The Legendary Pirate or even the Master Pirate will be the day you look back and say to yourself, “Wow, what an adventure the journey to this moment was!”…


Loop Dipole and the Chaoties
Long before it had a name, Loop was a game I personally wanted to play – something that was all about going fast and having fun getting there! Car racing games are alright, but they tend to be about… well, racing cars, which can be more simulation than stimulation. Arcade games like SuperTuxKart and Mario Kart are definitely fun, but they lack certain game play mechanics that are also fun, such as gathering resources and using those resources to customize your character or to solve puzzles, etc. Loop really is a product of those basic desires and that void of content, a reality I have never lost sight of, despite how I have frequently found that building such a game is easier said than done!

I have restarted this project a number of times, each time because the process of building it is a learning experience. I started it by programming in C++ using the Cafu engine. Later I thought it would be better as a mod for SuperTuxKart, which lead me to using Blende. Using Blender lead me to thinking I should just make the whole game in Blender! Then actually using Blender Game Engine to make a full sized game lead me to the understanding that BGE isn’t particularly well suited to making a full sized games. So now I am sitting here in 2017 once again contemplating on where I want to go with it. To 3D or not to 3D, that is the question! Mobile, desktop, web based, who knows?!

1. Who is this project for?
This was a tough question to answer, but the truth is that Loop Dipole and the Chaoties is a game that is for everyone, not just for me.

2. Why am I doing this project?
I am making Loop, because I enjoy the process of making games, but I am also making it to prove to (again) that I can finish making a game. So, it is important to me that the game is finished and that the game is, at the very least, easily available to be played by others.

3. What is the project about?
Loop is about the joy of speeding around blowing stuff up while collecting other useful stuff. Yet it’s also about bringing order to chaos by solving puzzles and by learning about yourself and how you like to play the game. Loop Dipole is an energy being who collects various forms of energy that allow him to take on new shapes that have different attributes and abilities. He also uses this energy to balance out the chaotic energy of his world. You see, at one time Loop was nothing more than a Chaotie himself, only vaguely aware of his own existence. However, one day he passed through a fog of chaos and emerged with a sense of self and with the determination to share his gift with his world.


Gardening With My Girlies!
I know initially said it was gardening with my family, but truth be told, my wife’s idea of gardening is looking at the pretty flowers and eating the fruits and vegetables that magically appear in the yard. The kids on the other hand are much more willing to get their hands dirty on a regular basis!

It’s hard to believe how much time has passed since then, but looking back I have to say that our best years for gardening were definitely 2012 and 2013. Abby and Baylea were still quite young then, so I had to do a lot of the work myself and unfortunately I did spend a little too much time playing the roll of the scare crow, otherwise known as “grumpy daddy who yells at me while I run, carefree, through the garden”. What can ya do, right? Kids will be kids and squashed plants don’t grow. 🙂 In any case, when 2014 rolled around the girls were “all gardened out” and it wasn’t until 2016 that they really took an interest in process again.

This year we’re going back to the traditional style of garden, as our experiment last year with the “living sitting area” (known as Girlie Grove) wasn’t as inspiring or as useful as I had imagined it would be. In retrospect, it probably would have been a big hit back in 2013 when our eldest, Neillia, was still into playing “little kid games”. Man… they grow up so fast, it’s just not fair…

Anyhow, here’s the skinny on my gardening project with my family.

1. Who is this project for?
The gardening project is for everyone in my family.

2. Why am I doing this project?
When I was kid, my dad had a garden that he put a lot of effort into. I wish I could say that we spent countless hours having fun with each other in his garden, with him teaching me all about life and all about himself, but the truth is that I mostly helped him get his tractor unstuck on the days he was plowing. I also happily ate his magical produce and occasionally squashed some tomato worms. Eventually I came around and appreciated his effort and what gardening meant to him, but wouldn’t you know it, I also went away that summer for no good reason and he died the next spring. Such is life.

I want to give my kids the connection to their parents, to each other, and to themselves introspectively, that I lacked when I was growing up. I want to spend time with them showing them how their efforts and their attention will be rewarded.

3. What is the project about?
Gardening is an emotionally relaxing, yet physically vigorous way to connect with my kids. From forging the furrows out of sod to preparing a meal using fresh picked beans, gardening is an experience they can hold in their hands that will live a life time in their hearts.


Well, I hope my examples have given you a some idea of how I used those three simple questions to define the scope and size of my projects. Answering those questions, and keeping the answers in mind as often as possible while working on your project, will help you naturally limit its scope. Understanding who the project is for and why are you are doing the project in the first place will allow you determine the size of the project: If you’re doing a project to prove the point to yourself or to the universe at large that you can accomplish it, then it makes sense to keep the project small and tightly focused so that you can finish it in a timely manner. Break it down into manageable chunks, set clear milestones, and avoid adding more to it beyond refinements to the original design, and you will finish it. And on the other hand, if you’re working on project simply for the joy of doing so and that project will likely take many years to complete, then try your best to keep that in mind so you don’t stress yourself out for not finishing it fast enough. That kind of long term project can be as big as you’d like, because it can’t be finished quickly anyway!

When it comes to hobby projects it is important to not stress out about them, because the whole point of having a hobby is to do something that is fun! If you find yourself stressing out or no longer enjoying your hobby, ask yourself the questions I presented above. Hopefully your answers will help you rediscover your passion for the project or maybe your answers will provide you with the closure you need to move onto new challenges.

Dev Blog: I don’t do “Asking for help” so well…

Truth be told, I rarely ask for help with my projects, because it forces me to thoroughly understand the problems I face and, frankly, other folks have better things to do than answer my questions. I made all of Rescue Girlies without asking anyone anything – instead I spent my time researching the answers to my own problems. Crazy concept, I know!

Anyway, recently I decided to break with my hermit tradition and post a question on the BlenderArtist.org forum. The question was simple enough, “Looking for a smooth, seamless way to keep a car on the road”, but the technical issues of solving it were quite tricky. Perhaps they were so tricky that no one answered or maybe… folks have better things to do than answer my question! 🙂 Either way, as usual I came up with a solution myself (no one else offered any). I guess I’m just that awesome.

Here’s a link to my post and here’s the actual content of the post, with the solution first for those who need a TL;DR…


SOLVED: I decided to go with just a “corner assist mode” that automatically drives the player around 180 and 90 degree bends, rather than gluing them to middle of the road all the time. And instead of having a cooldown, the player can simply choose to toggle it on or off.

I did this by making a set of 4 navigation meshes, left/right for each turn type, and moving them into position when needed and away when finished. The nav meshes have 3 triggers parented to them: Start Pathing, Stop Pathing, and Move Mesh Home. At every corner, I have placed a trigger that moves the correct nav mesh into place (they also have a parented trigger object that prevents them from firing from the wrong direction).

Doing it this way meant I only needed 4 total nav meshes (and their trigger groups) and by moving them rather than creating/destroying them, I didn’t have to concern myself with object name changes. Also, there are only 4 types of generic triggers to move the nav mesh into place, which means they’ll be really simple to add after I have finished laying out the whole road system. Finally, I chose to use collision and property sensors as triggers, because I figured they would trigger consistently and would be processor efficient (I’ll probably need about 200 corner triggers).

It’s not exactly what I wanted, but I think in the long run it’s probably a better solution, because it still leaves a lot of places where the player has to put some thought and effort into driving lol…

If you want to try it out or see how it was programmed, the project is https://github.com/Tatwi/LoopDipole and the two “shapes” that can use driving assist are enabled by pressing NumPad 5 or 6. NumPad 1 – 4 are gliding/flying type “shapes”. I put a little race track in for testing, so there’s something to drive on.

———————–

Howdy fellow Blenderers!

Sorry for posting a question, but I have been working on this issue for months and my research and testing have been unfruitful. I actually don’t like asking for help on projects.

Using the car logic, I have set up an open world driving game, where the player can drive anywhere, on or off the roads. Overall, the game works great, but I am having some trouble creating a “driving assist mode” for when the player is on the roads.

Driving Assist Mode can be toggled on by the user and while it is active, the player is essentially glued to a rail in the center of the road, such that it doesn’t matter how poorly they steer, they will always stay in the center of the road.

What makes this tricky to achieve:

1. The roads aren’t race tracks, where the player can only go in a single direction. Rather, they are more like real life, with junction points and the ability to travel in either direction.

2. It’s an open world, where there is stuff do when off the road, so the driving assist needs to be able to start from anywhere the player happens to enter the roadway.

I’ve already programmed tracking when the player is on or off the road and driving assist is enabled while while holding SPACEBAR. The trouble is, I have yet to program a method of driving assist that actually works! lol….

Here are some things I have tried:

1. Aligning the Y vector of the player to the local Y vector of the ray hit object (road). Works great on a straight line and in a single direction, but is totally useless for going around curves.

2. Dropping a ray down on either side of the vehicle and pushing the player back into the roadway when the left or right ray stops touching the road. This works ok at slow speeds, but it’s jarring and completely fails to work at any speed where it might actually be useful.

3. Added invisible guide rails on corners that push the player back when the “am I on the road ray” touches them. This worked ok, but if the player hit it at the wrong angle it would fling them off the road. Also, it failed at high speeds and was jittery looking.

4. Turning on guard rails to keep the player on the road by basically making them a “bumper-car”. The troubles with this are that the car tends to get jammed when hitting a 90 degree wall or bounce up when hitting a any obtuse angle. It’s also way more work and objects, while also being rather annoying to actually play with and totally not what I had in mind.

Some things I have considered:

1. I thought about making it a “cornering assist” only and putting a “path to object” (Steering Actuator) in both directions of every bend in the road. When the player’s “am I on the road ray” hits a trigger property, the player loses control and is sucked around the corner automatically. I think this would be effective, but it would be a lot of work to build. Update Feb 5th, 2016: I just pushed an update that shows this functionality in action (in one direction, for testing). It works, even moving the same navigation mesh and triggers around, but it looks twitchy (and did so even when I tried 900 faces around the bend lol…) This is probably what I will end up using – not perfect, but a workable solution.

2. Constantly spawning an invisible object in front of the player and having the player path to that object, then destroy the object and repeat. The trick would be programming the spawner to search for and locate the center of the road even on turns.

The nice part is that all of my roads will be built using track pieces, so the 45, 90, and 180 turns are consistently sized and shaped. Thus if I go with only corner assist, I can reuse the method for all corners of the same type (and it will still work once I merge sections of tacks together into larger objects to reduce overlapping verts).

Thanks for your time and consideration!

Growing Pains, Blender Issues, and Stuff Magically Working

I don’t know how game development is for anyone else, but in my experience there is always some inexplicable problem that magically resolves itself or mysteriously arises from the mist. One such issue I had since moving my Loop Dipole project to Blender Game Engine from SupertuxKart is extremely inconsistent collision detection on terrain. I researched the issue and tried many of the suggestions to remedy it, but nothing seemed to prevent the built in vehicle physics system from causing my player character to sail on through angled surfaces rather than going up them or bouncing off of them. It was the damnedest thing, because by rights terrain does work fine in BGE!

As it turns out, one day last week I decided that I really, REALLY did not like the “blocked out” layout I had made for level 1 (the level in which I am building and testing all of the game play systems) so I took another crack at making a terrain. First, I downgraded from Blender 2.73 to 2.69 (used in PcLinuxOS 64Bit), as 2.69 is the last official version that doesn’t break the BGE. Next I started with a plane scaled to 1,000 Blender Units, subdivided a few times. Applied the scale, pulled up a few verticies to make a hill and sure enough, the usual weirdness ensued – driving through the hill, driving off the edge of the hill and continuing on out into open air as if I was still on the hill. Knowing that terrains do work in BGE I sat back thought for a moment. Eventually my mind bumbled upon how video cards render shapes as triangles, so I selected all the faces of the plane and triangulated them (cut them in half on a diagonal, making the squares into triangles). Then it occured to me that there was a physics setting, “… something, something, triangle mesh…” so I popped over to the physics tab and sure enough I could set the “Collision Bounds” to “Triangle Mesh”. Next time I fired up the game, OMG IT ACTUALLY WORKED AS EXPECTED!

Tears of joy, tears of joy…

Turns out that I later unchecked the Collision Bounds box and the collision detection still worked properly, so that does not appear to be required. The really weird thing here is though, in the past I made triangle mesh plains and had collision issues! So… what gives?

From what I can tell, collision detection in BGE is based on frame rate. Testing this theory on my old Dell Inspiron 1501 laptop (dual core 1.8GHz Turion64 with ATi video), the new terrain I made, which works perfectly on my desktop (AMD FX8320 with AMD R9 270 video), still has the same collision detection problems that I was having before. Granted, I was testing using Blender 2.72b in Windows Vista Basic at the time, but still – this game NEEDS a better computer than my old lappy! 🙂 However, that doesn’t explain why I was having collision issues on the desktop up until it magically decided to start working… ah well!

At any rate, collision detection being based on the frame rate is all kinds of crappy, because as a designer/programmer I now have to worry about giving the player the ability to drop his frame rate so low that he literally flies/falls through the level. One way to do just such a thing, even on my desktop system, is to make an ability that instantly throws 500 cubes at 90m/s. Yeah… breaks the world! 🙂 But realistically, it’s not going to be possible for me to guarantee that the game will function correctly on systems with specs lower than the lowest I have to test with (Core2 Quad 8200 / Ati 5670 / 8GB DDR2), because I can’t really tell at what point the physics stops reacting to collisions. I know for certain though that Loop Dipole and the Chaoties will require an AMD or Nvidia video card that can handle GLSL (Intel’s PowerVR based graphics might work, but I’m not going to loose any sleep if it doesn’t).


On a different note, I’ve learned that Logic Bricks are an integral part of the BGE, which can execute commands faster than Python scripts, depending on what one’s doing. One really good example is syncing a “Shoot” sound effect with the physical ability when a mouse button is pressed. Sending mouse button presses to a simple function like this,

def example():
cont = logic.getCurrentController()
obj = cont.owner

# if variable = number, do ability
if obj["abilityLMB"] == 1:
# do something
# call the actuator that plays the sound effect
elif obj["abilityLMB"] == 2:
# do something
# call the actuator that plays the sound effect

will not, in my experience, play the sound effect every time the mouse button is pressed. There appears to be a delay related to how many times Python “ticks” happen per second. However, accomplishing the same thing with logic bricks and Python scripting solves the delay problem.

The Logic Bricks are setup like so,

State 1: Mouse Sensor (LMB) > And Controler > State Actuator to State 2
State 2: Property Sensor 1 (“Listens” for value of activeAbility) > And Controller > Sound Actuator & State Actuator (resets state back to 1)
State 2: Property Sensor 1 (“Listens” for value of activeAbility) > Python Controller (runs script that does the ability)

Functionally, this takes a mouse click, hops into State 2 where (in my case) 8 Property Sensors “listen” for the value of the activeAbility variable (1 to 8, depending on the ability the player is using at the time). If the activeAbility value matches one of the Property Sensors, then the next step is taken where sound plays, the ability is fired, and the state is set back to the beginning.

Quirky thing to have to do, but it works well to make 1 mouse click translate into 1 sound played and 1 ability fired. You can see this in action attached to the Abilities empty in the current version of the game. At the moment I have it setup such that both right and left mouse buttons have their own copy of the abilities, but later this week I plan on moving that into a multi state system so that the abilities won’t need to be duplicated (because WOW do Logic Bricks get complicated looking in a hurry!). That setup, my mind’s eye tells me, will look like so,

State 1:
LMB Click > Move to Stage 2
RMB Click > Move to Stage 3

State 2:
Property Sensors listen for activeAbilityLMB value and move to States 4 through 12, depending on the ability.

State 3:
Property Sensors listen for activeAbilityRMB value and move to States 4 through 12, depending on the ability.

States 4 through 12:
Each state has an Always Sensor that activates the desired sound effect and action of the ability, while also resetting the state back to State 1.

That should work to produce a system that performs the ability only when the correct mouse button is pressed, without having to have two copies of the abilities (one for each button).

Update: I’ve now updated the mouse button ability logic to new method I was describing. Thankfully it worked as planned! Two abilities are complete and I’ve bound one two each mouse button. You can press F5 to spawn some targets and practice destroying them now. Woo!


And finally, since changing to Blender version 2.69 I have noticed that the frame rate and other profiling information doesn’t show up in the standalone player when using the button from the Blender UI. Another quirky issue, as the standalone player in the official 2.69 package displays the info just fine when launched from the command line with the correct switches. Go figure lol… So… I made myself a quick link icon for my Mate Desktop toolbar with the following command:

/home/rob/blender-2.69-linux-glibc211-x86_64/./blenderplayer -f 1600 900 -g show_properties = 1 -g show_framerate = 1 -g show_profile = 1 /home/rob/workspace/LD-BGE/level1.blend

It’s a long one, but it works swimmingly! Hope that little tip proves useful for anyone else out there who is stilling using 2.69.

All that said, I am still keen on making my game with Blender Game Engine 2.69, because it’s a wicked awesome open source tool. With anything there will be ups and downs, so its important to try and work with what you have as much as possible – restarting a project over and over is a sure fire way to not finish it!

Dev: Python + Blender GE is a Great Time!

This is what I wanted from game development! Honestly, as I have said before a few times, I couldn’t give a rat’s ass about where a computer puts its pointers or memory locations, etc. This isn’t the 1960s… computer’s these days can do that sort of… COMPUTING way more efficiently than we human beings, so why waste our time and head-space mucking with those things?

Learning the syntax for Python and the Blender Game Engine API have certainly been time consuming, but that time has also been extremely fruitful and satisfying. In just a few weeks from not knowing anything about either, I have become comfortable with Blender and implemented the following systems into my game:

  • A functional testing map (I had a more detailed one, but I restarted the file)
  • Character movement with the keyboard and mouse.
  • Gliding – jump into the air and fly with full yaw, pitch, roll controls.
  • Turbo – both on the ground and in the air.
  • 4 of Loop’s physical shapes, complete with unique movement stats / purposes.
  • Mech Jump, for the mech shape.
  • The framework for other shape keybindings and stats.
  • And more!

The best part is that at this point, all of those things work properly. All I have to do with the those systems is fix any minor bugs that I find with further testing. At this point I can basically move on from the gliding and driving mechanics to making the turret turning mechanic for the tank and the mech. And that right there is an important note thing to note: I am going to put in a tank with a turret and a two legged “mech” type vehicle, because *I CAN*! I totally would not have done those had I been using STK, as the amount of work to create their movement would have been far too much. Yet with BGE, I look at it as gaining the opportunity to learn how to animate models, because… heck, why not? That kind of stuff is fun!

If you’re looking to kill some time, feel free to download what I’ve completed so far and fly around on the massive empty map. Gliding around sure seems easy when there isn’t anything to slam into… 🙂

Check it out on Github: Loop Dipole and the Chaoties

It runs great with computer, which it really should as it’s an empty map… but still, in case it doesn’t for you, here are my basic specs:

AMD FX-8230 @ 4GHz
AMD R9-270
8GB DDR3 2133MHz RAM
Linux Mint 64Bit
Catalyst Driver 14.501.1003
XFCE Desktop
Blender 2.71

Ps. I would like to extend a giant thank you to the kind folks who created the documentation on blender.org, blenderartists.org, tutorialsforblender3d.com, and the many kind folks who have posted tutorials on Youtube. Seriously could not do any of this stuff without you amazing people to show me, “oh… THAT’S how that thing actually works!”.