This is an RTS I've been developing on and off for almost a year now. Inspired by Dune 2 and StarCraft, I aim for there to be some basic storytelling, harvesting and battle mechanics, among other things.

Below you see the main terrain rendering, the camera, and the ability to place down structures which progressively become more complete, mimicking the way the Protoss build.



Graphics are made with Blender and then exported through a custom script. Similarly, the map is also built with Tiled and goes through another exporter.

It's gonna be a long time before this reaches a playable state, but at least I have something to show. I've also put in far too much time to stop.

Cool stuff! I've always thought these kind of games lend themselves better to playability on calcs.

This is really cool!

What features are you working on next? Are you coding this in C?

Thanks.


Yeah, the huge amount of buttons definitely goes in its favor, but the small screen means you'd have to explain the function of each button elsewhere. I intend to put an explanation on some print-friendly web page.


It's all ez80. Probably why it's taking this long, but it's quite fast.

As to features, the main building now builds infantries, and there is pathfinding (forgive the bad infantry sprite):



It's done via a nodegraph where nodes are rectangles. Upon pathfinding, the engine determines the start and end nodes, finds a path between them, then constructs a path of points for the entity to follow. This means entities can go through other entities, but I decided this was acceptable.

It's a bit wonky at the moment because the pathfinding doesn't take into account distance between nodes, and it always chooses the top-left corners of adjacencies between nodes. I intend to fix the latter, and call the former charming instead.

Next up is probably going to be harvesting and resource meters (and the dreadful text drawing that comes with it). Still deciding whether resources should be tiles or entities.

That's really cool and it runs very smoothly. I recall a discussion about RTS pathfinding many years ago and I always considered the node approach the best for calculators, so well done .

What classes of units (inc vehicles) are you intending to have?

That's really cool. Are you thinking AI adversary or multiplayer?

Sorry for the late reply. I had actually done this a while ago, because I was burnt out on gameplay logic. Here's a briefing sequence. Is the text too small? I feel like it only looks too small on a big screen. On the real calc it's just about readable, and I hope to fit a lot in there.

Obviously the dialogue is to be spruced up, and there ought to be the participants faces.

Side-note: it appears this BBCode ignores links to WebP files. I'd suggest to get that checked out. I had to increase the resolution, which as a GIF had made it ten megabytes. With a WebP and its heavy compression I got it to 1.2.

I really haven't thought of anything that far ahead. Apart from the infantry, probably a few more ground units, and an air one, which would ignore pathfinding. I also need to make sprites that actually turn 8 ways, and I fear how adding such core logic would affect the performance.

Only AI at the moment. Because it's story based, but more than that, it's because I don't have a second calculator to test it with. I can't imagine the kind of desync bugs there could be.

Looks good!, I like the image transition/fade, but I think the text may be too small? Would have to see it on calc and with the finished interface (even a mockup). A 3x5 font is going to be pretty small on a small 320x240 screen is all ... then again I'm no stranger to small fonts .

Also CEmu can capture straight to APNG if you use that?

I agree that the text is probably too small. Nothing wrong with scrolling or splitting it into multiple screens if you have to to increase readability.

With that said, the background, stars, and transitions look excellent. Looking forward to more updates!

I had no idea support for APNGs was so widespread today, though it's still pretty ad-hoc compared to WebP.



Well, if not 3x5 then 4x6? I can go up to 8x since it's one byte per row.

As you see it's now a sliding transition. I needed some place to put mission objectives and tips before the actual game, but I may make it fade to black again. Don't know which I like more yet.

There are also now icons & markers. One represents your resources (notice how it drops by 50 once the unit is placed). The second appears when you select some unit, and shows its HP.

I intend for the player to occasionally return to the new unit (the Plant or Power Plant) to gain more resources. Come back too often and you lose some you could've gained later. Too little and the station begins to overflow, losing you resources again.

Another slight tick is that I haven't yet thought how the computer AI would work, and I'm inching ever closer to having to implement it. Its behaviour can't be predefined if you allow the player to meddle with the enemy base.

I like the sliding transition- it's very smooth and well-animated as presented in that screenshot. I also agree that the text is too small, but I like the font. Perhaps you could do 2x2 pixels of screen for every one pixel in the font?

Have you considered pseudorandomly rotating/mirroring the background tiles based on their position to add even more variation to the background (in addition to your existing variants for the base tile)?

This looks really well made so far; I'm excited to see what else you add to this in the coming months

I've done both as you suggested. It does look better.

• Mission briefings are now dialogues
  
• Speaker icons are TBA (they should be animated)
  
• Now it's a bouncing transition and looks like a screen popping up from below
  
• Said screen has some sci-fi eye candy (will have more)
  
• Added pseudorandom vertical mirroring to terrain as suggested by iPhoenix
  
• Because lore-wise this takes place on an enemy planet, you will have planes sending squads instead of them randomly appearing
  
• You're not supposed to control the plane, but I wanted to show the smarter, fixed pathfinding :)
  
• Not shown, but the "plant" unit now grants you resources when you use it
  
• Ignore the bad clipping..
  

Looks great and I agree the font is much more readable now.

Pathfinding is indeed nice and smooth too!

Christ, has it been six months? Sorry about that. I'm very busy with other projects and things, and sometimes I end up ignoring a few of them for whiles.

A few changes:

• Entities can now move more than 1 unit per frame
  
• Sprites are now clipped on the right and bottom sides
  
• "Alert" text in case of info or user errors
  
• You're finally disallowed from moving entities into the blue rocks, or selecting unselectable entities (eg. the plane)

On another note, having even two entities on screen halves the framerate, even though time taken between calls to my swap function is less than 800,000 cycles, according to CEmu. So I looked into it and noticed a peculiarity:

Code:

For what reason is clearing the interrupt flag done first, and not waiting? If the flag works the way I think it does, would this not waste an entire frame's worth of time, if the flag is set before rendering completes? I switched it to the following:

Code:

Now I'm clearly missing something, because this causes tearing, as seen above. OTOH the framerate is now heavily boosted.

Whatever the case may be, I'm ready to call it a feature.

The second method is more correct than the first, the tearing is simply because of the way the graphics are set up by the OS to account for the fact that the screen in the calculator is sideways (its actually a 240x320 display, not a 320x240 display). There are ways around that, the simplest being to change the setup so each line is vertical rather than horizontal.

Glad to see this making a comeback

I'm very excited to see more updates!

I've reached a complexity where every new code path I add features multiple bugs I keep having to iron out, which is a sort of achievement, if you look at it that way.

Unit targeting demo. If the enemy is too far away, the unit goes to the point in the middle and tries again, else shoots. The CPU AI is separate from the player controller, for reasons. The player's attacking procedure is implemented as a generic "Process" that repeatedly creates a pathfinding, which has its quirks but it lets me reuse parts of the engine.

I must also make some pretty large decisions concerning game design now. You may only select one entity at a time currently, by pressing 2nd, unlike most RTS games which let you box select. I am not sure if I should switch, but I must decide before the code becomes too hard to modify. Saying this in advance: there will not be large swarms of units, not even on the levels of the original StarCraft, mostly because there's a hard limit of 255 entities overall, which includes buildings, and decorative entities, like the planes that bring in units. That's also why I have a large "infantry" unit, instead of singular dudes.

As for the selection, one idea that really harmonizes with the keypad is to place a marker beside each entity, telling you which key to press to select it. This will be balls to implement, but it could be worth it.