Blogs - neutronio

Hey there!
I just released a collection of music free for you gamedevs to use, also for commercial purposes, as long as you don't sell the music itself. You are free to include it in commercial projects, as long as you give me credit. (It also documents and preserves my work as a composer so win-win situation here)
The genre is Electronic Music, reaching into many other genres such as ambient, classical, dance, dubstep; Most songs have a usually non-linear structure and a dramatic mood.
If you wish to listen to some samples prior downloading, check here:
Soundcloud.com

The collection can be downloaded from here:
Mediafire.com

Enjoy.

SO yesterday I was spending all day making new textures, revamping existing textures and applying a new material library for StarFire (you can follow it here Indiedb.com ) which without doubt was a shitton of work. This is also the 5th time or so I've completely rewritten material handling (I do hope I will stick to this one for a bit longer). I'm sure I did path the way for quite large arsenal of materials to chose from since I only need to import a diffuse and bump map texture for each material type (instead of creating a material definition file for each block material using the old material library, as it will generate these automatically now).

Using the new Material Library I can create proper markers for selection mode and numerous other features that weren't possible before. However, by implementing the new Material Library I broke a few things as well, such as image flipping and transparency of cockpit elements.

I also created a BlockFilter for elements. Each Material and MaterialVariation has one filter property. RawMaterial for example can have the filters "ship", "building" and "all" , while MaterialVariation is structured in "decorational" and "functional". BlockFilter will also include the shape of elements available (i.e. rectangular, triangular, spherical). This way I can categorize and filter out certain blocks in the user interface, providing the necessary clarity and structure the user needs to use the interface effectively.
All these changes are part of the aim to give elements a function. It will go so far that every Item in the game will have corresponding 3D object in form of an Element which you can interact with according to the effect it holds.
My ToDo List includes:

• Finish missing textures for block type 4x4x1
• Introduce block type 1x5x1 and a 2x2x3 seat (+ textures)
• Fix ShipLight class
• Fix existing Bugs with Repaint, History and Block Removal
• Merge _fd and _cont material variations to _itcont
• Merge _fuel and _oxy material variations to _tank
• implement advanced MaterialPicker
• BugFixing (focussing on MaterialPicker)
• implement functional Elements, make Element a parameter of Item, change accessibility using the Item class.
• Adapt ShipEditor and ShipModel to these changes.

After this I can finally head to the actual simulation part of the game. I will probably won't finish all of these points in my list but it's always good to have for motivation purposes.

Updates! Still primarily working on the editor alot. The most recent version includes tons of internal changes that enable me to extend and work with this editor more easily. It's running rather stable which is mostly due to the fact I've been spending most of the time with fixing the current bugs instead of adding new features.

This above image is the result of a 2h hardcore test where I wanted to figure out if the editor was running stable enough to endure normal using conditions (and I must say I really lost myself making that ship :D )

I will post the newest demo of the current version (0.0.035a) later on. You can find the changelog at the end of this blog.

Future! I am currently preparing for profound changes in the editor interface, which will include a better overview of the tools you have and what they do. You will be able to:

• change tool settings
• chose between mouse/keyboard or keyboard only input (which both have their advantages and disadvantages in my opinion, so I decided to let the user make use of both if he (she?) desires to)
• select multiple blocks, repainting and removing of multiple blocks
• copy and paste blocks
• set camera viewpoints
• [low priority] it should be technically possible for me to make a mirroring function as well.

Besides the changes on the ShipEditor I've slowly begun to work on other fields such as the space simulation itself, storing of game settings and also made some approaches towards implementation of music and sound. I expect to be ready with a basic space simulation at the end of next month.

Changelog:

v.0.0.35a
- implemented removeBlock and paintBlock modes.
- implemented ShipModelHandler (+threaded loading&saving) and ShipModel.
- adapted editor to the implementation of ShipModel. All ship relevant data is now saved in a single
shipModel variable instead of multiple static variables inside of the editor intself.
- added new blocks: 3x4x1 element, 2x4x2 cockpit element (+4 different glass tones), 1x2x1 lamp element
- added customizable lighting (very buggy)
- improved internal material handling (easier to extend now)
- fixed a bug where the last placed block could not be repainted/removed.
- fixed a bug that didn't let the user repaint and remove blocks after a model has been loaded.
- fixed a bug where some ship elements weren't loaded into the editor.
- fixed an internal duplication bug caused by missing removal of the old model after loading a new model.
- fixed ShipInfo Box not updating.
- fixed material display on material info box on Paint Mode
- fixed material display on material info box while displaying special materials (material handling changed)

So I haven't posted anything in a while. That's mostly due to the fact I've been working on ship editor features like some mad scientist.
I've been making quite some progress since the last blog post. These changes are mostly internal changes and usually affect the ship editor.
You can now save and load your ship models, material display has been fixed, information about blocks, the program's status is logged for debugging (you cannot deactivate that yet), and your ship info is now displayed on screen, just to name a few. All changes ever since the last commentary video about version 0.0.02 are listed below.

Future versions. This editor is designed to be easy to use and learn. As such, it goes through a lot of trial and testing before I decide to implement a feature as is. I have big plans for it - Just now I finished a remove block function, and many more are to follow. I think I'll stick to keyboard input as a way to control the editor, and I already have something in mind for the coming advanced interface. It's going to be a bit tricky to make a comfortable interface merely basing on keyboard input but it should be doable. I will soon release an official demo of this editor once I finished creating a few more edit modes and fixed the the saving/loading bug.

[STAR FIRE SHIP EDITOR - CHANGELOG]

v.0.0.34b

• Implemented a primitive file saver/loader. It's now possible to save your ships. Be aware this is an extremely buggy feature as of now, so check the created files twice if you decide to load or save anything.

• introduced basic audio effects.

[Notable Bugs]

• Ship Info is not updated if loading a ship from a file
• There seem to be problems with loading/saving files that have a similar name and a number (i.e. "file2" and "file1") in which case it will load/save to the wrong file. Make sure you use names that are completely different from eachother.

v. 0.0.34

• introduced ToolBox with working Buttons/Icons.

• introduced Tool Modes, updated command handling. Only mode that's working properly is PlaceMode.

• now using a CrashLogger.

v. 0.0.33

• Introduced an Icon class as part of the graphical user interface. Doesn't do much at the moment other than sitting on the screen staring at you, occasionally switching its state.

• DisplayBox introduced. Block data attached and displayed in DisplayBox.

• Fixed most Bugs that occured in versions 0.0.30 - 0.0.33.

v. 0.0.32

• Changes in Material Management have been made. Now they are stored in SubMaterials so I can assign different textures to an element, while keeping its basic material data. That way different blocks for decoration can be added.

• Enum Elements now contains an array of available Materials for its dimension. This enables me to have different textures exclusive to one blocksize, as required if I want to create consoles and lamps.

• Attached data to the blocks. This data is displayed on screen.

• Updated command handling.

v. 0.0.30

• All available blocks are now automatically initialized.

• All available Materials are now automatically created.

• Material choice fixed. Now only appropriate materials will display on the element.

Good news. After I've kind of got stuck at creating a basic spaceship simulation last week, I made some significant progress in the last two days. I now can move objects in space according to their speed and rotation (seeing how I completely suck at maths and all that's related to it that's quite an accomplishment). It's far from done, but it's something I can work with.

I also set up basic programming for a feature that's involving spacecraft and spacecraft equipment. Perhaps you can tell what it's going to be?

On a side note, last week's progress also includes the completion of the XML handler and a working Item Editor:

As of now, the project and all its relevant classes (meaning classes in development not included) have a total length of 2750 lines of code.

Perhaps you noticed that I'm switching the initially planned order of the classes to be developed. I came to realize that I cannot program more profound game logic without game editors - so I decided to make them first instead. All in all, I'm quite happy with the progress.

What needs to be done:

High Priority:

• Optimizing game data managment: Change data feeding to the XMLHandler for easier extendability in case the content changes. [optional] Instead of using XML I could simply create my own file handler that makes use of its own variables. Either way, I could store and organize data using the .getFields() method. I'll look into that further.

• Create Editors for Planets and Stars.

• Improve visualization of Planets (rotation, rotation angle)

• Performance tests: how many planets can be displayed at the same time without fps drop?

Low Priority:

• Prepare for GUI development: find ways how to possibly program a GUI in jMonkey (also includes HUDs)

• Prepare for Generic Universe Generation (GUG). Arrange Planets in Star Systems.

• Introduce Star Visualization

• Fixing the ItemEditor. I may revise it in the future.

StarFire will be an open-source, java-based space simulation shooter that is currently in development and running on jMonkey engine with self-created game resources. There will be many simulation elements that will make an significant impact on gameplay and if the world/universe is going to be completely generic or pre-defined, will be completely up to you. The GUI as much as the gameplay should be self-explanatory and user friendly, and if something is not so clear it will either have a detailed manual or an ingame tutorial - I don't want to spoil much of it here as I just recently got out the conceptualizing stage of this game.

However, I really need to plan this out thoroughly if I want to succeed, especially seeing how my programming skills aren't the best and that I plan to do it all by myself (unless I find people who are willed to help me out, of course).

What I already have, after two weeks of conceptualizing and one week of programming:

• a carefully-planned, hand-written, 40-pages concept as to what I'm going to do and how I could possibly achieve it
• basic classes for star systems, planets, spacecrafts, items and their affiliated characteristics
• an (relatively easily-) extendable xml handler that manages and saves game data for the above mentioned classes to a file. I might need to look into that further as I fear xml might not be the best choice when saving a huge amount of data (unless I manage to logically split up bigger data chunks somehow)
• Some basic classes in which I played around with potential visualization of planets
• Some basic graphic resources

So here are my plans for the next two months (or weeks, depending on how fast I work) :

• First thing I need to do is to get basic game data done. To make this job easier, I need to create a couple of GUI editors that convert raw data (which is a pain to work with) into an easy-to-understand interface.
• Based upon this basic game data, I can create basic game logic, such as collision detection, GUI development, inventory management, spacecraft behavior and so on.
• Just then I can proceed with client/server programming to establish multiplayer games.
• After all this is done, I will proceed with an advanced 3D editor for customizable content. This mostly will affect planets and spacecraft.

I will most likely learn as I go by, and I do hope this project will be a success in a long-term.

Blah blah, that sounds great and all but when can I play it?

You probably won't be getting anything playable in the next 3 weeks, so please be patient. :P