next »

[Foolish Mortals]

Devlog 5: Camera Bounds & Movement Pieces

This week I made bounds for my camera movement so it can't move off into the black void of being off-screen. This involved creating two empty objects, placing one in the top left corner, and one in the top right. By comparing the current camera position to these two 'anchor' positions, we can ensure the camera never leaves the bounds I set.

The second (and longer) task was being able to drag pieces around the holding left click whilst moving the mouse. This in itself is pretty simple, but doing it the simple way made the object always center itself on the cursor, making it 'leap' around. This is distracting, so I calculate an offset from the mouse position, and the center of the object we're dragging. This script is posted below, . Feel free to use it as you like.

Code:

using UnityEngine;

// Attach this to an object with a 2D collider
// Allows the dragging (with left click) of the object
public class Draggable : MonoBehaviour
{
    Vector2 offset = Vector3.zero;


    // Called when the user left clicks on this object
	// This is called when the user left clicks on the object, BEFORE a OnMouseDrag occurs
    void OnMouseDown()
    {
        MouseDownOver();
    }
    public void MouseDownOver()
    {
		// Find where the mouse is in WORLD coordinate
        Vector3 mouse_world_position = Camera.main.ScreenToWorldPoint(Input.mousePosition);
		// Find the difference in the mouse posiiton and the center of the object we're dragging
		// This is calculated so the object doesn't immediately center itself on the cursor
        offset = this.transform.position - mouse_world_position;
    }


    // Called when the user is holding down the left mouse button and moving the mouse
	// Note we DO NOT recalculate the offset here: we're OnMouseDrag can be called many times, and recalculating the offset would make the object jitter around the screen
    void OnMouseDrag()
    {
        MouseDragOver();
    }
    public void MouseDragOver()
    {
        // Find where the mouse is in WORLD coordinates
        Vector3 mouse_world_position = Camera.main.ScreenToWorldPoint(Input.mousePosition);
		// We don't want to EVER change the Z position
        mouse_world_position.z = this.transform.position.z;

		// Move to the new mouse position, while keeping the offset from when we first clicked on this object
        this.transform.position = mouse_world_position + (Vector3)offset;
    }
}

[Foolish Mortals]

Devlog 6: Drawing

This week I worked on getting drawing working. The player can now draw directly on a transparent image, which is overlaid on-top of the map. This will be useful for planning potential approaches, and jotting down any random notes.

I'll be making this drawing code free and opensource when I have the time this week.

Interestingly, this data could also be exported later at the end of the match to see if the user actually makes use of the drawing (with user consent, of course). Could be fun to create a collage of end-state drawn images from players, and potentially see how they organized their information. Another idea would be to just take an in-game screenshot, which would also capture the unit pieces. This is just thinking out-loud. Not sure if loud, not sure if I'll end up implementing that.

[pelle]

That looks great, but I would be very careful about exporting user drawings. It is not difficult to guess what users will draw.

[Foolish Mortals]

That looks great, but I would be very careful about exporting user drawings. It is not difficult to guess what users will draw.

Haha, yes I can imagine what they'd draw. That feature would need some more thought...

[Foolish Mortals]

Devlog 7: Visuals Update

I've spent a lot of time working on the visuals in the past week. Of course some might say it's a waste of time working on visuals this early since it's like these visuals won't make it into the final version, but I think it's actually very important. I plan on showing this to the local game design group that I started in a few weeks, and getting their feedback on the controls. If you're going to show your game to strangers, the art needs to look passable or people won't be very interested in your game. It's also much more pleasant to work on the game when it doesn't look awful.</rant>

Anyways, the map now consists of multiple layers. In order from lowest to highest (higher covers the lower parts)
1. Desk background (it's meant to be a map sitting on a physical desk)
2. Blank brownish paper texture
3. Terrain features (towns, forests, roads, rivers, hills, etc.)
4. Grid lines
5. Transparent image for drawing on
6. Draggable unit icons and objective slips of paper

[Foolish Mortals]

Life's gotten pretty busy between classes, teaching and writing papers (I'm a grad student), so no devlog this week. Instead I made that drawing code I previously mentioned available for free at the unity asset store.

Free Draw in Unity

Just to recap what it does: it allows you to draw directly on a .png image while the game is being played. You can use any colour  you like (including transparency) and can also adjust the width of your virtual pen. Nothing fancy, just thought I'd give back like all those other people who share their code and work for free.

[Foolish Mortals]

Devlog 8: Orders

Life has  been very busy as of late, but this summer I anticipate having more free time to work on RG. These past few weeks have been working on four simple orders you can give your troops:

Report Status: Has the unit tell you where they are, and what their condition is. This will have to be expanded upon later as units become more complex, and larger-scale battles happen, it will be important to tell the player only what they need to know. When units become lost, they will report what they can see within a 2km radius. Ex: there's a hill 1km west of us. From this information you'll probably be able to get a fix on your units fairly quickly.

Move to red flag: Instead of having the user constantly type in grid coordinates for telling their units where to go, I decided to go with a red flag that they can drag around the map. Units can then be told to go where the red flag is. It certainly speeds up being able to move units, and so far playtesters have understood it, but we'll have to see if it makes it into the final cut.

Move relative to your position: For this order you tell the units where to go, relative to their position. Ex: move 2km south, and 1km west. This is useful for when your units are lost, and they don't know where they themselves are. If you tell a lost unit to move to the red flag, they won't know where that is relative to themselves. Using the report status order will let you find their approximate location, and then you can use relative movement orders to get your unit orientated by moving them to a road, hill or town.

Hold position: This tells the unit to stop moving.

With these changes, the game is playable! Designing a proper tutorial will be key so players aren't left confused and frustrated. I've got one in the works, but it'll take maaaany playtests to determine if it's good enough.

[Osteel]

Just want to say that I'm enjoying this devlog. It's a pretty cool idea! :O

[Foolish Mortals]

Just want to say that I'm enjoying this devlog. It's a pretty cool idea! :O

Thanks! So long as at least one person enjoys content you means making it is worthwhile. Making devlogs is also just a good idea in general, since it keeps you to a deadline. Without deadlines, nothing would get done.

[MegaTiny]

Thanks! So long as at least one person enjoys content you means making it is worthwhile.

Easy to lurk and forget the owner of the devlog isn't getting any encouragment that anyone is paying attention. Still here and following along, enjoying the videos and learning a few tricks here and there.

Keep it up   

[Foolish Mortals]

Thanks! So long as at least one person enjoys content you means making it is worthwhile.

Easy to lurk and forget the owner of the devlog isn't getting any encouragment that anyone is paying attention. Still here and following along, enjoying the videos and learning a few tricks here and there.

Keep it up   

Thanks! I'm sure most people are lurkers most of the time (like myself), though we'll never know since we don't know how many lurkers there are.

[Foolish Mortals]

Devlog 9: Tutorial Mission

I've been working hard on a tutorial mission. Since the game concept is very different and strange, a good tutorial is critical to teaching players what the game is. If done poorly, players will be left frustrated and confused, and will most likely stop playing. Creating a good tutorial will require stream of new playtesters who've never played the game before. Luckily for me, I started a public game design group in my city (the first and only of its kind), and will hopefully have a continuous supply of test subjects *evil cackle*.

Onto the tutorial mission itself! It starts off with a brief description, and then moves onto a mostly black screen to highlight the radio. As commands are issued, instructional tidbits of paper fly onto the screen, hopefully drawing the eye of the users with its movement. The player has two units to work with. The player must use the radio, and the map to locate these two units. One is in a town, and states that explicitly. The other is lost, and gives a description of its surroundings ('There's a hill 0.7km  west of us, a town 1.8km south of us, etc.). The map is pretty simple (pictured above), so it shouldn't be difficult to locate the second unit since there is only one hill on the map. Once the user has located both of their units, they must move them both to the enemy occupied town. The enemy is in a fortified position that without flanking, will take a long time to defeat (flanking negates some defensive bonuses). If both friendly units are fighting the enemy, the enemy is quickly destroyed.

There's a video of me playing the tutorial mission below. Let me know what you think! Most of you reading this devlog have already been exposed to the concept of my game, so you're already ahead of the poor saps who've never heard of it when they try it. If you spot something that wouldn't make sense to a new user, let me know!

[Foolish Mortals]

Devlog 10: 2.5D Visuals

Been pretty busy during the last few weeks. I was one of the main coordinators of our town's only gamejam, and instead of making my own game during the jam (there just wasn't time after helping other people), I worked on the visuals for Radio General. I call this effect '2.5D'; the combination of 2D and 3D visual elements. The paper map is a 2D sprite, and the desk and figurines are 3D models. You can now pan, zoom, and tilt the camera, letting you closely examine the map and figurines. If you zoom out far enough you can see the 3D desk. I think the 2.5D looks markedly better than it did before.

The 3D model files are from thingverse, a website used for 3D printing. It's great since these little figurines are exactly the sort of thing you'd want to print for a tabletop wargame! Of course the art may be updated later to have more detail/colours added to them. I also applied a little colour contrast to the camera (it makes a surprising difference!).

The above picture is the new look, and the picture below is the old look.

What do you think? Any suggestions on how to improve the looks?

[pelle]

I love that the context menus show up like that flat on the map. UI looks very good already.

[Osteel]

Moving to the new view is definitely a good idea. Eventually, I think scaling of the units will need to looked at as they feel a bit too big. But it's looking good!

Is the intention to eventually build a scene of the war room, with NPCs and such moving about? Could there be other things in the room to interact with outside of just the main war table?

[Foolish Mortals]

I love that the context menus show up like that flat on the map. UI looks very good already.

Thanks! Yeah, the flat menus look much nicer than I expected.

Moving to the new view is definitely a good idea. Eventually, I think scaling of the units will need to looked at as they feel a bit too big. But it's looking good!

Is the intention to eventually build a scene of the war room, with NPCs and such moving about? Could there be other things in the room to interact with outside of just the main war table?

For sure, large figurines could cover too much space and make the map hard to read.

As for the war room, there'll definitely be a tent background. I hadn't considered having more of the war room be interactable, but I've always thought the war room of Ruse looked super cool (https://youtu.be/QAoz-nRK3Ko?t=19s). Art is difficult and expensive for me, so I'll have to put some thought on that idea.

[Foolish Mortals]

Devlog 11: Replays

Whew, this is a long overdue devlog. It's not like I wasn't working on the game; just that what I've been working on isn't ready to show yet. I've been working on generating heightmaps to create topographic contour lines/elevation lines. Unfortunately it isn't that pretty yet, but it's getting there!

Anyways, what I have to show today is replays. During a scenario, a number of things are being recorded in the background. Chiefly, important events. Each event records the time it happened, along with the  information needed to repeat this event in the replay. This data is serialized into a replay file saved onto your computer, which can be deserialized and fed into the game later. Below is an image showing the sort of information being stored in the replay file.

To view a replay, this replay file is fed in, and then these events are executed at the same time these events were executed during the real mission. This more or less recreates the events as they happened in the mission. Unfortunately, due to the increased gamespeed during replays (up to 8x speed) we sometimes get events being 'popped' later than they were in the actual mission. This can lead to 'desyncs' where events happen too late. I will have to record more events such as arriving at a destination, taking damage to reduce the effect of these desyncs. We can see an example of a desync in the end of the youtube devlog I posted, where units appeared to still have some health yet when their 'death' event happened.

To add some visuals to the replays, I added HP and defence bars to each unit, which are updated in real-time. Additionally, I added some gun/bullet particle effects when units engage in combat. These particles have multiple layers: yellow bullets that move quickly, puffs of smoke that appear where the yellow bullets despawn, and glowing tracer trails that follow the yellow bullets. There's definitely room for improvement, such as scaling the amount of bullets based on the damage capability of each unit, and making bullets pop out from the brownish paper background, but it still looks pretty cool for now.

[Foolish Mortals]

Devlog 12: Text-to-speech and Morale

Whew I'm very much behind on this devlog stuff. Life has been very busy between getting academic papers accepted at conferences, teaching classes and working on Radio General. Lots of behind the scenes stuff has been going on, but they aren't quite ready for the limelight. Three major features are ready for viewing though...

1. Text-to-speech: I've implemented the default terrible Windows text-to-speech. Now when units make reports to you, they're said out loud! Unfortunately, this sounds pretty bad, and probably breaks immersion more than help it. Oh well, it was fun tinkering around with it anyways. This is just a temporary stand-in feature until I can record some voice-acting myself (just got a slightly nicer microphone to try out).

2. Morale: This is a major feature that has been on the top of my to-do list for a while. Morale decreases when fighting, and when taking damage. If morale ever hits 0, the unit panics and retreats. As seen in the gif above, the yellow bar represents your morale. When Able's morale hits 0%, it retreats AWAY from the enemy. While panicking, the unit does not listen to any orders. Morale slowly regenerates when the unit is out of combat, and once it has reached a sufficient level the unit responds to orders as usual.

There's a lot of nuances and mechanics to left implement with morale: gaining bonuses when nearby friendly units, lose morale when you see allies retreating, refuse orders when low (but not panicking) on morale, make worse reports when low on morale, etc. Lots of ideas to play with.

3. Intelligent Retreating: The last feature is not so major, but is related to morale. When fighting multiple units, the loser will retreat in the direction that takes them the furthest from any enemies. See the gif above, where the red unit
 retreats downwards in an attempt to get AWAY from the attacking blue units. This took some brushing up on geometry lessons to get working (lots of angles and radian conversions). Hopefully this prevents units from retreating INTO enemy units, which is frustrating in any game.


That's it for this devlog. Will try to make it back to the more regular schedule soon. I have some pretty big news for the next one already lined up...

[Osteel]

Always enjoy watching this devlog, simply because it's so unique. Will you be implementing artillery and such eventually?

[Foolish Mortals]

Always enjoy watching this devlog, simply because it's so unique. Will you be implementing artillery and such eventually?

Thanks! Yes, ordered artillery barrages will definitely be in. It'll be interesting to have to use your own units as spotters.
Able: We see an enemy 2km east of us in E13
*you call in artillery strike*
Able: That got some partial hits, but was a bit off. Adjust 0.5m to the north