That's right—ClrHome is moving to a new host, yet again. Expect some downtime as we get stuff up and running on the new server!
On less exciting news, I accidentally left my working graphing calculator (TI-84 Pocket.fr) in a different city and will not have access to it again until the end of December, which is exactly why there haven't been any updates to Maximum Security recently. Expect some fresh downloads near the end of the month!
EDIT (2014-12-14 10:03 PST): If you can read this, welcome to the new server! We're bound to have some bugs still lying around (turns out not all servers are identical), so if you see any, please don't hesitate to contact us or comment below.
Progress on Star Trek has been coming nicely and seems to be nearing the 50% mark. Help from the programming community has been very valuable.
This game started as a passing idea for something that the CALCnet protocol could accomplish and evolved into a large-scale real-time strategy game that is nearing completion. Aspects of gameplay continue to evolve by whim as progress continues, as do ideas for seamlessly integrating server and client task management to create a pleasant gaming experience and a networking masterpiece, something previously considered impossible on a Texas Instruments graphing calculator.
Already done are most of the Main Menu and Connect Menu windows, and their related subroutines...relaying login, registration, and change info packets to the game "hub", the server-based interface that enables calc-to-calc and calc-to-server interaction. Additionally, you may file a bug report directly from your calculator. Game saves are stored server-side, not on your calculator.
Remaining to be done is the remainder of the networking, 3D motion, and the combat system, as well as the programming of the server. At the current rate of progress, I have no doubts that the game will be ready for beta testing within a few months. Stay tuned to ClrHome for the latest news on this project.
After some personal issues and a filled summer, I have found some time to get back to programming. Since this was my most interesting/promising project, I have decided to return to it. This article will refresh anyone reading it on the planned features of the game, and allow a forum to suggest more features, volunteer to assist in the making of the game, and so on.
Star Trek Multiplayer will be a fully-functional first person space shooter for the Texas Instruments graphing calculator, in the style of Star Trek combat. The view screen allows you to see directly in front of you, but hotkeys on the calculator allow you to access such things as sensors, weapons and shields controls, power configuration, communications, and much more.
To add more flair to the game, the core of gameplay is built around the DCS7 CALCnet/global CALCnet protocols, enabling unit-to-Internet communication. Every calculator running this program and DoorsCS7 may join the game and play against other players on the server. Each player creates a ship, outfits it with basic weapons and enters the server's game world.
Through gameplay, players earn three types of points. For defeating players in combat, you earn combat points which may be used to upgrade weapons systems. For rescuing other players or allying with other players, you earn diplomacy points which can be used to upgrade ship armor and shielding systems. For defeating opponents with minimal combat, you earn stealth points which can be used to buy stealth equipment, such as stronger sensors, cloaking devices, EMP guns, and the like.
An additional feature to the game...shields and weapons may be calibrated with a number, called a modulation factor. Let us assume a player's shielding systems were calibrated to 123. This means that, should a player have weapons calibrated to 123 as well, their weapons will completely breach the shields, raised or not.
Terrain on the server includes bases (neutral zones where players may go to buy upgrades and repair their ship), stars, nebulae, black holes, and other space terrain. Relevant terrain will have gravity, cause collision damage, or even heat damage.
Players may attack with more than simple weapons. Viruses may be loaded into other player's "computers" that will shut down systems, redirect power, etc. You may beam crew members into opposing ships. There are remote override commands.
The power system utilized in the game will be Star Trek realistic. The warp core will produce main power as a certain rate. That rate is proportional to the current health of the warp core system. That power is stored in the power reserve, and is depleted by systems. The backup generator also provides power, but at a much slower rate. Should the warp core be destroyed, you will need to switch to backup power. Each system works at an efficiency equal to the percentage of power available. So when the power reserve is full, all systems operate at 100%. When the power reserve is at 70%, all systems work at 70%. When the power reserve is empty, all systems fail. To conserve power, or boost your attack or defense strength, individual systems may be configured to use more or less power. For example, a phaser that is set to 150% power deals 50% more damage than normal, but also consumes 50% more power.
Sensor systems are required to lock onto ships for firing, obtain data about a ship, and track a ship at warp (up to a certain range), whether it be fleeing or coming to attack. The more upgraded your sensors, or the more power to them, the better they work. Should your sensors be knocked offline, you will need to manually find your target by steering around to bring them into focus, instead of them being automatically hit.
Firing a weapon at an enemy does not occur on a point-to-point basis. In many PTP systems, if the weapon is fired the transmission is sent directly to the opponent. However, in this game, a fired weapon becomes an entity and its speed and position are handled by the server. Should the target change speed or direction, your shot may miss and hit something else.
Here I'll give a basic synopsis of how a gameplay session would work, so people interested in playing it will know what to expect, and developers will have an idea on the vision for this game.
You start the game. After moving through the title screen, you get presented with the Login or Register interface. To log in, type in your password. To register, type in a username, a password, and an email address (to send updates/file bug reports). After successfully completing one of these two actions, two small (under 100 byte) AppVars are created, one with information about your player account, the other with ship configuration data. You will then get the Connect, Settings, About, Credits, or Quit menu. Changing credentials lets you reset your username or change passwords. Settings lets you change your frame rate (how long your client waits before refreshing the map). Connecting enters the game.
When you join the game, your player account gets a one-byte ID associated with it. This ID becomes associated with your calculator's 5-byte client ID on the server (which also caps total number of players at 256). Each client saves the list of connected players into a third AppVar, with the one-byte ID for that player first and the username second (coordinates of players near you stored separately). This comes to a maximum of 2304 bytes for a full server, which is not bad at all.
In sync with your client's frame rate, the calculator will pull map data from the server and redraw the view screen (stuff directly in front of you) as well as show other things on sensors that are near you. This list of objects near you includes only objects within sensor range and nothing else, and is stored in RAM (saferam2).
There are hotkeys associated with certain actions like firing, switching equipped weapons, raising and lowering shields, changing speed, and much more. It is planned for a later release to allow you to change the default key binds within your settings (by cross-associating the default key bind to the new key bind).
When you are done playing, you press the key to disconnect from the server. At this point, the contents of the player save AppVar and the ship configuration AppVar are sent to the server for saving. Once the server indicates that you are successfully disconnected, the client destroys the local copies of those AppVars. From there, you can Connect again or exit the program.
This and more is planned for this game. Anyone willing to help or test please comment below. Needed: Z80 Assembly programmers or python programmers.
So I was too optimistic in my timeline for Maximum Security. Ah well, it's still pretty close to the end.
You can download the current version of the program
as well as a level pack
I've been working on, with two levels. (Also, here's a screenshot of a really dumb level that just demonstrates the physics engine.)
In particular, the level editor and main menu are now integrated into the program, and loading level packs and saving progress all work splendidly. It's all essentially complete, with the exception of a simple way to go from the level editor to a testing environment for the level being worked on. (Of course, you can always just load the level pack normally and test it from there.)
But now that the core program is finished, what remains (besides documentation) is to make some levels, and this is where I make other people do my work for me. If anyone is interested in making levels for Maximum Security, you can do it now!
As we've said before, Maximum Security will depend on level packs. Anyone can create a level pack using the main program as follows:
- Select Maker from the main menu
- Choose the option "Create new level"
- Enter the name of the level pack and then its password for editing
- Use the following controls to manipulate levels:
- + creates a level
- – deletes a level
- × moves a level down in sequence
- ÷ moves a level up in sequence
- 2nd enters the actual level editor, for which the controls are as follows:
- MODE to enter the tile selection menu
- TRACE/GRAPH to quickly switch to the previous and next tiles in sequence
- 2nd to set down a tile
- DEL to delete a tile (same as pressing 2nd when the blank tile is selected)
- ENTER to save
- CLEAR to quit
This is all much more complicated than it really is; you can see an actual screenshot of the level editor in a previous post
. If you create a level pack you're particularly proud of, email it to me to showcase it in an upcoming gallery!
Maximum Security is. (There's already a demo here
for those interested, but in any case I don't expect the final game to take more than a few days!)
It's been a while since I've posted an update on an actual calculator game
(and to be honest, it's been a while since I've worked on one). Well, thanks to a combination of (unfortunate?) events, I'm back to calculator game design for the summer!
First item of business: Maximum Security, the new, haphazardly awesome puzzle platformer
I started working on after Fruit Ninja was finally released
. I've posted screenshots of it before
, and though there hasn't been any updates on the actual game engine (which is basically complete anyway), here's are some new updates on the progress of the rest of the program.
As you can see above, the menu as described in the mockup in the previous post is completely implemented. Apparently I've never gotten around to posting screenshots of the level editor, so here they are, from a year ago.
Expect the game to be released soon—all that's left is to clean up the level editor, create some default levels, and publish! I'm really glad I picked up this project again; it feels great to finish things.
I have decided to at least make an attempt at a Legend of Zelda reboot, since my Star Trek project was a bit too involved, but I don't entirely want to shave off the concept of a playable game. I feel like my assembly abilities have increased, so I should be able to get a decent amount of this game done. That being said, if anyone with some spare time and some assembly experience is able to code graphics, movement, and AI, please feel free to comment this post and ask me for access to the repository on Bitbucket. Anyone who contributes will be listed as a co-author.
One of the features I've considered for this game for about halfway through the game, to resemble a spread of evil, the graphics to slowly darken until the screen is entirely black, requiring the use of magic to light the area around you.
Many of you Linux/Mac gurus out there may be familiar with what file integrity
software is. For those of you who aren't, file integrity software works by saving data on various attributes of files, and then periodically rechecking it. Any changes to those attributes could be a sign that they have been tampered with by someone.
As the TI calculator becomes more advanced (including recent improvements in the CALCnet 2.2 application, by Kerm Martian
), the likelihood may increase that tech-savvy users may find a way to get malware onto your calculator.
Calculator malware ranges in severity from a simple prank to display rude text on your screen to a program that can destroy the screen, corrupt the operating software, and brick the calculator (term meaning "render permanently unusable, software-wise").
TI-IDS is a new software project that aims to bring file integrity checks to your calculator. The software will, the first time it is run, create a database of hashes for every potential executable on your device (applications, application variables, programs, and the OS and certificate [for advanced users]). You can update this database at any time. You can also scan the files on your calculator. New files not in the database, as well as files whose hashes have changed will be returned as "problematic" when the check completes.
Many "anti-virus" programs exist on the forums at ticalc.org, but most of them are either "for fun" programs that do nothing, or simply scan by name, but not by content. This aims to be the first TI calculator program that actually has a content scan.
This program is DoorsCS
compatible. Version 7.0 or later required.
Version 1.0 goals: manual database updating, manual calc scanning for file integrity issues.
Version 1.1 goals: automated database updating, via RunProg integration (see DCS7 manual), OFFSCRPT. Detecting programs with mal-opcodes.
Some of you noticed that there had been significant downtime last month. Our apologies—the free host used by ClrHome had implemented a new daily usage cap, and it turns out that some of our heavier webapps (IES
in particular) tend to be a bit CPU-intensive when they're compiling. (This only affects the server, not your computer.)
In any case, we've moved ClrHome to a paid hosting plan (finally!). It's been getting close to 100% uptime in the month since we've been here, which is great. For the curious, http://mon.clrhome.org
has full uptime stats and downtime logs for all the servers we use (current server at the top). If you'd like to help with the cost of hosting or to support the projects we create, we also have a PayPal account now:
And it's been another big one!
In projects, there were some small utilities released this year, which you can check out here
; in addition, we're actively working on some new games that might be interesting. There's Star Trek
, back in development courtesy of ACagliano and Sorunome, as well as Maximum Security
, a new—well, you'll see.
On the site, we introduced a brand-new webapp called IES
that lets you write code, draw images, and manage lists and matrices for your calculator projects online. We also made improvements to several existing ones, like adding autocomplete to the ORG assembly IDE
and sprite image generation to Pixelscape
. Many new features and a new online resource or two are planned for next year—keep an eye on the Resources
page or subscribe to our RSS feed for updates!
On the official side of things, this has been the year that several new calculators
have been released. Interesting ones.
Happy New Year to all of you us at ClrHome!
project has received a few new updates in time for the new year! In particular, more support for exporting sprites as images and text has been added after a request was made for the feature. (As always, if you have an idea for any of our projects, feel free to shoot us an email or tell us via our contact form.)
While editing sprites on Pixelscape, there's now a new button next to Export on the bottom row labeled "Sprite." Clicking will bring up a dialog that lets you export the sprite you're currently editing in one of two ways:
- Direct sprite images. You can instantly generate a URL to the current sprite as an image, so you can embed it in posts, pages—anywhere you want! Scaling and image format can both be customized. (The images above (on the left) were generated at 1, 2, 4, 8, and 16 scale.)
- Unicode sprites. The idea here is that some places (such as text forums) may not allow you to include images in posts. Instead, you can use this new feature to copy-and-paste the sprite as a sequence of Unicode block characters that look like the sprite! On the right above is such a Unicode sprite (in reverse) of the images on the left.
Both features work for monochrome sprites as well as sprites with three and four levels of gray. If you have any comments or suggestions, please leave your feedback below!
Here we are again with some more updates on progress for Star Trek Multiplayer.
First things first: the project page at http://clrhome.org/startrek
has been given a makeover. This makeover consists of an improved design, more concise information, and an overhauled downloads page.
The actual game has been coming along smoothly. While we still cannot project a completion date, many major features have been completed. All that remains to do is graphics, movement, and the battle engine. In addition, I have decided that the automatic update feature will be abandoned, and replaced by a simple window saying: An update is available. Check out http://clrhome.org/startrek to download.
Additionally, I will, when done, release the source code to a programmer who develops for the TI-84+ Color Screen edition, so that this game may be released in color for that platform.
Stay tuned for more updates.
There has been a slight revision to the intended release schedule for Star Trek Multiplayer. After discussing the practicality of it, Sorunome and I have agreed that it is viable to release a first alpha version of this program in the near future.
This alpha version will contain only a functional automatic-updating system--a system by which the program will automatically download and install later versions of the game onto your calculator with no additional action from you.
It is my hope that this system will encourage people to use my game, and make it easy for them to install future pre-releases, betas, and official versions of the program onto their calculator. Understandably, it is tedious for a developer to offer perhaps ten or twenty pre-releases and keep asking users to update, considering the process associated with that. With my automatic update feature, you no longer need to go through that. Just click on "Update" when prompted and you need do nothing else.
Stay tuned for the first alpha release to be uploaded.
Progress on Star Trek comes slowly, but surely. Coding is already done on a good portion of the client side program, and a list of message types and configurations for packets the server sends and receives has been prepared and uploaded to me and Sorunome's shared project directory.
Some screenshots for the program are below.
Additionally, I will be implementing an automatic update function in the game. Every time your calculator connects to our server, it will silently check for what the latest version we have posted is of the calculator-side program. If our version is newer than yours, you will be given the option to update the program, right from your calculator, right there. No downloading the game, transferring it yourself. All automatic. Of course, all updates will be made available for manual download on the project page as well, for those who don't already have the game on their devices.
The screenshot of the splash screen for Star Trek MP.
The screenshot of the program icon for Star Trek MP.
Star Trek Project Pagehttp://clrhome.org/startrek
Many of you probably thought this project was dead. Well, psyke. It is alive and well.
Star Trek's entire conceptual design has been given a complete overhaul. Sure, the game will still run as you would expect. But, under the hood, something a whole lot different will be going on.
Instead of having each individual unit do all of its updating and incrementing, then sending transmissions to every single calculator on the network, which would require finding enormous amounts of memory to store usernames and calculator ID's (similar to an IP address, but utilized by CALCnet to identify a calculator), I have decided to put most of this processing on the server. Every calculator communicates only with the server, not with another unit. The server handles figuring out what data it should respond with, or what to do with the transmission.
To exemplify this, assume that I have sent off a message to the server, asking for the other objects around me on the server. The server, in turn, responds with only the objects in my sector (immediate area). This includes terrain. This prevents the calculator from becoming overloaded with all that data for objects so far away I really don't need info on them.
On the visible side, there are some notable new features planned. First and foremost is existence of user accounts. Each player must have an account in order to join the server, for the purpose of storing save files. Players can log in, register, and change their username and password from right on their calculator. Additionally, instead of holding game saves in an appvar on your calculator, save files are kept on the server, associated with your account. When you join the server, your save file gets downloaded to your calculator. When you disconnect, your calculator uploads the most recent save data back onto the server. This is another attempt of mine to minimize the memory used by this game.
Last but not least, welcome to the dev team Sorunome, and thanks a million for your assistance with this project. :)
The image here is a mockup of the title screen to the upcoming game
Maximum Security. As with a lot of other things in the game, the highlight around START will be another unnecessary animation in the actual program, which I'm working on now. This idea got big fast—it was originally meant to be a quick little project to prove I'm still alive, and here we are a year later!
As promised, here's a screenshot of MaxSec. (Don't you just love CamelCase
?) It's not entirely new (having been taken two weeks ago), but it's certainly an update on the last one.
Since there's a lot going on in this screenshot, here's a quick run-through of the things that the player encounters in traversing the demo level:
- Water starts pouring into the upper part of the level.
- Turret (aimed at the player) launches a bullet.
- Bullet strikes a boulder and bounces off.
- Bullet strikes a dynamite crate, which triggers a chain reaction, clearing the level.
- Water from upper part of level can now flow down the new corridor.
- Player pushes boulder onto turret so it's safe to walk by.
- Player collects coins, opening the exit door (which changes visibly).
- As player is underwater, his breath count (white "health" bar on the right) drops bit by bit. (Kinda proud of that bubble animation myself.)
- As water covers the entire map, it leaves some air pockets which player uses to replenish his breath count.
The water behaves a bit oddly in this level, but anything I try to fix the water algorithm seems to leave me with a fantastic RAM clear
. I'll probably just design levels in a way that it doesn't look quite as odd, or call it something other than water. Why not acid?
So here it is—our latest major project. More screenshots are yet to come as the remaining parts of the project get finished!