It’s been a while since I’ve posted on here. Much to some people’s disappointment.
This project is on the backlog indefinitely while I work on Foxhole: Scrapshoot
When I’m finished (or bored) of that, I’d like to restart development on Clarion.
For a short time I was trying to redo the project in C++, but then Game Maker: Studio was released and invalidated the point of working in C++, which was simply to get better performance. With GM:S’s better optimization and portability along with upcoming native C++ compiling support and general ease of use since I’m very experienced with it, I’d like to someday make Clarion in GM:S, better and faster than I ever could have made it before. I won’t have to reinvent much since I have all the old code.
To familiarize myself with the changes in GM:S, I started experimenting with a simple platformer. One thing led to another and I decided to create a game based on my webcomic Foxhole, to spiritually follow the old GM8 project Foxhole (which funnily enough, the comic itself is based on).
Foxhole: Scrapshoot should be an indication of the improved performance I’m talking about. Compared to the original GM8 version of Clarion, it runs at twice the framerate (60), up to 1080p as opposed to 800×600, and with twenty times as many tile-based graphics onscreen.
I’m aware of some people that were following Clarion and are uninterested in Foxhole or find it to be offensive to their taste. I’ve heard it called “a waste of your talent” among other harsher things. I knew to expect that kind of reaction and I understand that the two games have wildly different potential audiences. I just ask that you have patience while I pursue other projects.
Thanks for taking the time to read this.
This summer is when we’ll really get down to business. So far I’ve just been picking at unimportant pieces of code, and the team has been going over design decisions and some more meta stuff unrelated to the core game itself, but rather to our company.
Work will start sometime late next week. There’s college work to get out of the way before then.
While at the studio I did tons of work organizing some internal… stuff. Nothing I can really show. So, at the end of the day, I decided to put the lighting system through its paces. I put a shadowed light source on each of 40 blue guys, who move around constantly. This was the result. And it ran fine!
It made me think there could be a dungeon or cave full of phosphorescent plants that light up like this. There’s lots of cool things we can do with the lighting.
This feature is an example of one of the advantages to rewriting a game.
In the Game Maker version, I hardly knew what I was doing when I started writing the turn controller. By the time I had realized what I SHOULD have done, it was too late to actually DO it.
But now it’s so much easier to work with.
I will list the ways.
-The player actor is now no longer treated as a special interrupt case by the turn controller. Which cleans up the code quite nicely.
-Any actor is now capable of pausing the simulation for its turn if it needs to. Turns must be explicitly ended by the actor itself, not the turn controller.
-There is now the feasibility of controlling multiple characters (or multiplayer?!) by simply adding another player actor on the scene. There’s no need for any other setup conditions.
-A pointer to the actor who’s turn it is is now available.
-The “simulations-per-frame” (game speed) variable is more optimized. Dealing ONLY in game turns, and not any other frame-by-frame logic events, like lighting updates and key presses.
-And to top it all off, turn delays/cooldowns for various actions and default game simulation speed are both increased in order to make the timing more precise.
In order to make way for the ability to add more than one kind of character in the game, I had to refactor and add a lot of things to the base actor implementation, so it took a while. Now that it’s squared away it’ll be easier to do the same thing for other kinds of objects in the game, since now I have a sort of template I can go back to and see “oh right, that’s how I set that up…”
Anyway, I tested this by adding about fifty of these A.I. controlled blue guys who just zip around the screen really really fast. Surprisingly, the framerate was also really really fast, despite all those pathfinding calls. It’s good to know that a bunch of actors on screen doesn’t slow anything down. Especially good seeing as how the actors were having their A.I. logic run about 50-100x more often than would be in an actual gameplay scenario, which is turn-based and slowed down.
I figured out a much more elegant way to save game data than what was in the previous GM version.
Each object defines its own behavior for how it saves itself to a file. This allows me to make a file that JUST stores data for a single actor, or a single tile. I can also store data for more abstract objects, like the game world itself, or the player’s current session. As well as calling functions to write its own data to a file, it will call the save functions of the objects it “owns”. It creates a convenient, modular chain that’s easy to change as I go.
I finished up a quick and dirty implementation of this today, and it works! Hopefully, it stays that way.
The next task is to take care of the message log. In the GM version, whole lines could be colored. In this version I will attempt to allow per-character coloring using formatted strings of text.
The text shaping options in Allegro 5 are quite limited, so this is going to be frustrating getting it to fit the dynamically-sized UI. To alleviate some of the pain, I’ll be using a monospaced font for the message log.