-->

main-navbar

Saturday, August 24, 2013

Actions

Been really busy the past few weeks, so haven't had much to show for the time. With college classes about to start in two weeks the available time is only going to decrease. However, I did manage to create and partially implement the action system.

What this system does, is handle module actions. This will be integrated into how the AI runs, how the user controls and configures input, and will basically give a framework for handling each modules actions. For example, an engine type module would have actions for controlling the engine. The actions for such a module would be something like: Activate, Deactivate, Set Power, etc. So to get such an engine configured, you could assign say, the spacebar, to Activate the engine when pressed, and Deactivate the engine when released.

The system works by storing a list of the modules actions in the module itself. An action in this system is a custom class that has an activate function, and a constructor. The constructor assigns the target of the action, so when the action is "activated" it calls the targeted function. in addition the constructor assigns a description and a name for the action, so that the user knows exactly what the action does. All the actions are assigned at start of the runtime to their parent module, and made available to all objects that have access to the module. The assembly itself will be the main object activating these actions, and assigning inputs to activate specific actions. These inputs will be stored on the assembly itself so that individual sets of controls can be isolated. (ie: the user controls one assembly, and an ai controls another. Their actions dont activate each other because they are assigned to separate assemblies) Basically the assembly will act as the distribution hub for all of its modules actions. Eventually it will be possible to create custom actions which would set off multiple others, sort of like programming.

With this system, it would be possible to practically let the user program the ship as they would a robot. One of the cool things about this, is a user could create a control system and share it with others who just want to fly the ship, and skip the whole configuring aspect. Or even better, a user could create their own AI. These are some of the major end goals. However, for the moment a simple "this key/button activates this action" sort of thing will be created, until after some sort of release. More complex layers of possible programming will be possible later on.

There are still some fine details to work out, like accessing module variables, but for now I hope just to be able to get a ship that is completely configured by the user.

Saturday, August 3, 2013

Project Update

The demo video I released last week showed some of the features and capabilities of the editor. This past week I have been cleaning up code and adding a few more essential elements to the infrastructure of the program. I also made it possible to select one or more modules and delete the selected modules.

The last part was the most difficult; not so much the selection system as the deletion system. Normally deleting things would be very easy; but it this case it was not because of the assembly system. With the assembly system, each group of modules that are connected to each other form an assembly. The problem is; how do you handle the deletion of a module that is the only piece holding two halves of the assembly together? Somehow I had to get the assembly to update its internal list of which modules were a part of it and in addition I also had to split the assembly into two individual assemblies. This is what was the really tricky part.

Eventually I came up with an algorithm that worked; but it took a while. Basically the algorithm starts with the first module in the list of modules on the assembly. It takes this module and scans through all of the modules directly or indirectly connected to it. Then the assembly removes these modules from a copy of its internal module array, adds them to a list of groups of modules as a group, then repeats until no more modules are left in the copy of the internal list of modules. After this the first newly created group is assigned to the assembly and for every remaining group a new assembly is created and assigned the contents of that particular group.

Anyways that's what I spent most of the week working on. Next will be adding the input/module properties stuff. This will allow the engine to actually fire, and also will allow the user to make control systems so they can build and fly a ship. This will involve a gui on the right side of the screen as well as some serious infrastructure to handle it all.