Calculator Community > Other Calc-Related Projects and Ideas

Project TI-Trek for the CE nears first demo release

<< < (2/4) > >>

ACagliano:
UPDATE

Progress has been made on the User Interface for TI-Trek. Here are some screenshots:
The Main Systems module overview screen


The Tactical Systems module overview screen


The module configuration/info popup, accessible by pressing [Enter] on chosen module


Some changes to the power system setup also. Module efficiency (how well it performs its task) will be a function of module battery charge (current power level * 100 / max power storage) multiplied by power draw setting (set power draw / base power draw). Power draw meaning how much power a module will take from its source (core, auxiliary, or internal reserve) every power cycle. Each module will also have a maximum draw, which is the maximum amount of power a module may be set to draw before the module incurs a damage penalty every power cycle. For instance, if the module's max draw is 8 and you have it set to 10, the module will take 2 points of damage every time it draws power. This means you can set a module to use as much power as you want, to super-boost it, but keep in mind the higher you set this, the faster the module takes damage.

Jonson26:
This looks really nice! I especially like, how you use graphics, to make what's essentially a simplistic interface look fancy. These screenshots remind me of some Amiga games. BTW, do you plan on doing a 68k port?

ACagliano:
UPDATE

Project TI-Trek has now been successfully compiled with full USB support... using srldrvce. Due to wonkiness in CEmu's usb support, it is no longer possible to test networking on the emulator (the lib cannot initialize the driver properly). I will need to move to on-unit testing for the remainder of client-side development of this project. I have gotten written the ntwk_Login(), ntwk_Register(), and ntwk_Disconnect routines, which are the first aspects of gameplay that will be tested. While I have been hard at work on client-side things, commandblockguy has been working on a USB=>IP bridge similar to the one Kerm devised for gCn over DirectUSB. And last but not least, beckadamtheinventor has been hard at work developing the server side of things... from map generation to control codes and saving/loading data. For those interested, the server is written in Python, runs on port TCP 1701 (the registry number of the Enterprise), and uses json for long-term storage. It stores connection descriptors to an array of Client objects, which also contain the IP address, username, and some more information about the connected user.

The game will implement semi-accurate space physics. When the map generates, the server pre-generates some paths for celestial bodies using formulas for things like gravity and inertia. Those objects will follow those paths every tick, scaled to the time-rate of the game. In addition to fluidity in space (meaning planets, starbases, etc will not be in exactly the same spot every time you look for them), other objects will pose a threat... black holes will exist and end your journey very fast. Stars will tick their life cycle and then die in a manner determined by their size. Major celestial events, such as star death or planet destruction will result in a path-adjustment for entities within gravitational range of the changed section.

Also, after discussion with beck, another feature will be added to the game, called a synthesizer. This component will allow you to interact with materials you own on a molecular level to enhance them in certain ways. For example, say you place a piece of tempered steel into the synthesizer. You can then select from reserves of any type of element, and the properties they enhance/detract from will most reflect their actual chemical properties (toughness, deflection, malliability, heat resistance, etc). Say you choose to combine the tempered steel with a type of element that increases toughness but decreases heat resistance. You would wind up with steel (hull plating, for instance) that provides a boost against projectiles and physical impact, but is damaged more by heat sources, phasers, and the like. You could also, for instance, infuse your hull plating with a mineral that enhances magnetism, which in turn enhances your shield deflection. And if you attempt to combine unstable materials, you could, for example, wind up inflicting feedback damage to an attacking enemy, but also winding up with vastly increased damage to your own ship.

For anyone wishing to have a look at the code-base so far (yes, it will need some optimization), here it is. I will say, in my opinion, at least the network handling is remarkably well-organized... for what I usually do.
https://github.com/acagliano/titrek-calc

ACagliano:
A few teasers from the upcoming 0.0.94 release.

1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones.

--- Code: ---lut-entries: true
header-string: "\xff\xff"

--- End code ---
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details.

2) The splash screen has been completely reworked.

The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection.

3) The program now alerts you on the splash screen if your graphics version is incompatible.

The incompatible graphics is triggered in one of two ways:
 a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array.
 b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build.
Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu.

All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.

Xeda112358:
Nice work :O

Navigation

[0] Message Index

[#] Next page

[*] Previous page