Latest Posts

A Sony conference changed my perspective

In my last post I was investigating an idea for an isometric 2.5D game inspired by final fantasy tactics. However, since then, I went to a private Sony conference and was honestly bothered seeing a bunch of people who probably never played a game in their life talking about publishing, developing, and the business of video games; and honestly it struck a nerve with me.

The Sony conference

Of course these big companies have a lawful requirement to do whatever they can for shareholders, but they also have to make money to keep alive. It's not such a crazy idea, I know many indie developers are making games to either make a "hit" game to make a lot of money, or are making indie games so that they can make it their day job and stop working for someone else. So, indie or AAA, it seems to be a lot about the money, and very little about the games themselves.

Indies? Hustler culture?

So many indie developers are spending so much time creating games in hopes that it'll "pop off". I can't even begin to count how many instances of indie developers I've ran into who have a "great idea" (meaning money) rather than a "fun idea". It feels like the same hustle culture that I felt at the Sony conference. And... The worst part of the whole thing is that I fell into the same trap as everyone else.

Going back to "the good old days"

I have always just done what I want to do, and that's why I have so many dead projects. I find one thing I'm interested in and then try to make some big ol' game idea based off that. Then I do the stuff I want to do and abandon the project. What I need to do is what I used to always do, which was find a very small scoped game I want to make, then make it for the fun of it and not even care if I sell it or make any "return". There is no return that I want other than to do the work to make the game. I thoroughly adore "the process" and not the goal, so when my view shifts to "the goal", I completely lose interest.

More than just mere words

The game I've been working on for the last 2 weeks is a multiplayer Sudoku game. The game will use PBR rendering, and network code I developed just for the game. I've also developed a master server registry so that players can find each other and utilize UDP NAT hole punching. The primary gameplay loop is playing sudoku, getting a token for playing easy/medium/hard/multiplayer, and unlocking name tags and special player cursors (which show in multiplayer).

I can have a more formal development log for the Sudoku game specifically in another post, but that's basically just me "putting my money where my mouth is" as it relates to these things I've been feeling since that Sony conference.

Where do we go from here?

Designing an isometric 2.5D game like Final Fantasy Tactics Advance

One of my favorite game consoles was the Game Boy Advance, particularly the SP version because it had a light-up screen and you could fold it to fit in your pocket. However, I find that I'm enjoying the old form GBA now days, mainly due to being able to mod it to have a back-lit screen, and it's more comfortable to play with.

modded back-lit screen game boy advance, with final fantasy tactics advance

One of my favorite games on the GBA was Final Fantasy Tactics Advance, when I was a kid I picked it up because I liked the artwork on the box. Recently, I've been playing the game anytime I have some down-time and, other than being fun, it has got me thinking about developing a game. Playing through it I started to think about how cool it would be to create a game with that isometric style including using pixel art characters and animations.

Isometric, without tactics

final fantasy tactics advance tile layout

It would also be interesting to see if I could get the world to dynamically load in as you move around, this way there would be no loading screens in the overworld. If I dynamically load the interior of buildings as they are loaded into view, it might also be possible to teleport the player to the building interior instantly upon entering the building door.

The last part of this is that I want to make the world 3D, but the characters and props are going to be 2D sprites. This will make the physical movement around a bit easier, and it will make it easier to place objects within the world. This might give it a bit of a Ragnarok Online feel, though I don't really have an intent to orbit the camera around, it'll likely be fixed but can zoom in/out. Ragnarok didn't have this tactics style isometric floor, but it did have the 2.5D artwork (see below example).

ragnark online gameplay

Gameplay

Game Engine

Getting started with tiles

cpp
Mesh* m = isoland_create_cube(host, IsolandConstructCube{
	.height = i+1,     // Copied from a loop, thus the 'i'
	.tilesetWidth = 4, // Tiles in the tileset image
	.tilesetHeight = 4,
	.sideTileX = 0,    // Side tile image in tileset
	.sideTileY = 0,
	.topTileX = 0,     // Top tile image in tileset
	.topTileY = 0,
});

first test of floor tile code

Resolution and camera

Example of 320x240:
example of rendering at 320x240

Example of 720x480:
example of rendering at 720x480

Example of full resolution:
example of rendering at full resolution

For the camera, I'm likely going to be rendering in perspective, but with a lower FOV (field of view) to get a somewhat orthographic look without actually using an orthographic camera. I'm not entirely fond of a fully orthographic camera for rendering just because I think some perspective gives it a little more life/character than no perspective at all. As stated previously though, I'm not likely going to allow for the camera to orbit, but I will likely let it zoom in/out a bit for cinematic effect.

What to work on next

Placing buildings and props should be as easy as specifying their location in the world, the height should be automatically picked up from the heightmap data. This will require a standardization of assets, all of the pivot points of each asset must be at it's base so that it will snap to the floor correctly. However, I will need to also provide the ability to offset from the floor, in case the prop is on top of something or floating in the air for effect.

Timeline and goals

As for my goals, it really is just to make a game in my game engine. Retro Sketch's goal was to create some software I can actually use to create games, but also to fully test out my bespoke UI system idea in the engine. Since that was pretty successful, I'd like to use this game as a way of proving out the ability to create games without much friction from the engine. I'm not typically focused much on money/return on the things I create, though nice, it's not exactly my primary goal for creating things.

Addressing the hiatus

Hello everyone! It’s been a little while since we’ve had any updates on the blog, Retro Sketch, or the game engine I’ve been wrestling with. But fear not! I’m getting back into the swing of things, and thought it would be a great opportunity to share what’s been happening.

Life, as it often does, threw a few curveballs recently, which pulled me away from engine development. You know how it is – other exciting projects pop up, demanding your attention! Thankfully, I’ve tackled those life events and distractions, and I’m now laser-focused on games and the engine.

My next step is to start working on another game in the game engine. That means I probably won’t be pushing out updates to Retro Sketch unless a bug pops up, or I need it for a feature while I’ve been developing my game. Don’t worry though – I use Retro Sketch myself for my pixel art, so there will almost certainly be updates related to that!

Of course, diving back into code after a few months can be…interesting. Turns out nothing was compiling or running! I spent the last couple of days wrestling with the engine just to get it building and running again. The good news? The address sanitizer is now fixed and working! That was pretty annoying to be without for a while. Another cool feature I’ve been experimenting with is time travel debugging – a fantastic tool built into Windows when you install WinDbg. With all my cool tools back online, it’s finally time to start developing that new game!

I’ve been making games for over 15 years, and have published quite a few… though not under the “Marshmallow Bear” moniker. Previously, I ran a studio called Bearded Man Studios. But that chapter has passed, and most of the amazing people who worked with me have moved on. Those games have faded into obscurity, and they’re sadly built on older versions of Unity, making a resurrection quite the challenge. If I find the time and the desire, I might resurrect them in the new engine someday. But my focus right now is on creating something brand new.

Once I have something genuinely fun and interesting to share, I’ll be posting it here on the blog. For now, I’m overflowing with ideas – but, ideas are cheap. I’m starting to test out some of these concepts, probably sticking with pixel art for the near future. The game engine itself is a 3D engine, and it plays very well with Vulkan. However, creating 3D art and all the assets that go with it takes a lot of time and energy, especially when you’re a bit of a perfectionist (like me!). I want to make simple, fun games, and the easiest way to do that is to embrace some constraints.

Although I am completely comfortable working in 3D and working with 3D game engines, animation rigging, texturing high-poly models, re-topologizing, sculpting and the rest of things that come with 3D. Right now, it just isn’t something I can realistically focus on. Feel free to stay tuned for what I’m working on next.

Art topic rules

You are free to share your own art. You are also free to share the artwork of others, just make sure you give proper attribution, including source links and preferrably links to the artist's online profile(s). There are a few rules for your artwork though, see below.

1. Explicitly sexual content is not allowed
2. Content that can be considerered a fetish is not allowed
3. Don't spam your artwork, re-use threads for iterations on the art
4. Be nice to other's artwork, critique's are fine

General Forum Rules

Updated forums formatting, categories, embeddings, and more

We've added a lot of new updates to the forums so that posts can be formatted in more interesting ways. Tables were added so that guide threads are easier to both explain things and read things. We've added embedding of Imgur, Odysee, and YouTube links for more media interactivity as well. You can also select a category for your thread so readers know what they're getting into before clicking. You also can now click on an account image/name to view that person's profile and their latest posts.

List of additions

Game development topic rules

You are free to chat about anything related to game development. Show progress, talk about your own projects, ask for help, or help others. This can be related to using any game development tools, frameworks, engines, APIs, or just raw code. Before you post or reply, there are some rules that must be followed:

1. Don't post anything related to adult content
2. Don't create multiple threads about your game, a single thread will do
3. Don't spam about your game, use your game's thread to talk about it
4. Stay on topic with the thread, don't veer off on unrelated subjects
5. Test code you are about to suggest or clearly explain that it is pseudo-code

General Forum Rules

Retro Sketch

Retro Sketch makes it easy and fun to create awesome pixel art drawings and animations. Use layers to organize your frames, and use tracks to sequence your animation in the timeline editor. Draw from life by importing reference images to trace or use for animation rotoscoping. Master the many available pixel art tools within Retro Sketch to create beautiful images and animations. With all these tools and more, you have the power to bring your imagination to life!

- Stylus support for s-pens, surface pens, and other Bluetooth pens
- Pixel art brush and eraser tools
- Color sampler
- Color swap
- Flood fill
- Pixel grid
- PNG Image importing
- Project management
- Shape tools
- Robust undo/redo system
- Selection tools
- Layer management
- Frame management
- Grid positioning and other helpful drawing tools
- Image reference for tracing and rotoscoping
- Timeline animation editor
- Animation previewing
- Project file export/import
- Seamless integration with desktop project files
- No pen, no problem, with full touch drawing support
- More features to come in future updates

Retro Sketch has a lot of features. Take full advantage of our app by taking the time to review the documentation and tutorial videos! Don't forget to contact the developers for any feature requests or bug reports.

General Forum Rules

Multi-threading, network, and new Profiler

We’ve been hard at work on the game engine as we are continuously developing games on it. The benefit of using our game engine for things like retro sketch is that it automatically gets the benefits that we add to the engine.

Threading

Networking

Profiler and profiling

game engine custom profiler

Keeping Itch.io Up-to-Date

One of the major problems when it comes to any development is that you get hyper focused on a particular platform and sometimes forget about other platforms. We have fallen prey to this exact problem and spent a lot of time focused on either Android or Steam. Well, now that Android is out of the picture for now, it seems like we’re focusing all our time on Steam. However, the problem here is that we also have Retro Sketch on itch.io and it is not getting much love.

Automatic updates to itch.io

The way that the tool works is very simple. You unzip the files to your automation machine, and then simply log in at least once. Once you have logged in, you’re free to call the push command to upload any new updates to a specific channel. Channels are just a fancy word for platform, from what I can tell. You then can read the error code supplied back from running the executable inside of your shell script, to know if the operation was successful.

Still working on things

One of the main issues with any development is that many platforms assume that you’re making a very long 2 to 3 year project. The thing is, for us that we make a small project that only lasts a few months, possibly. So it is just tedious to have all of our separate development logs per project done on multiple platforms such as X, Steam and itch.io. And it’s much easier to do brief nonsense on X and then do development blogs and such on our website. That just leaves the list of features and fixes going out to steam an itch.

Planning and Continuous Development and Delivery

When we decided to rewrite everything from scratch in C including the Lua code for Retro Sketch, we also decided that we would build out the rest of our infrastructure. One of the things that indie developers wind up doing is spending too much time on needless things, such as setting up Jira and automation systems. We believe that writing code is what we do, it’s in our blood, and using other people’s tools is not exactly the most efficient use of our time. Oftentimes it takes just as much time to learn somebody elses tools as it does just to write your own.

Project management

For me, I don’t care so much about the history of work that I’ve done. The work is done, after all. What I’m more interested in doing is keeping track of things I think about that I need to do later, that I can’t be bothered with doing right now. If I can’t be bothered by doing it right now, it means I don’t want to spend much time thinking about it. Therefore, opening up some 3rd party tool and doing all of this rigomaroo with it is just an annoying distraction.

So, the way we track things that we need to get done is inside of markdown files that is committed directly to the repository. When we’re done and need something else to do, we can look at the markdown file to find out what is left to be done. We then pick something, and then when we complete it, we delete that line from the markdown file as part of the commit.

Build and Automation

cmake logo

Though in the past we used either Visual Studio projects or makefiles, recently we started using CMake. I have to admit, at first, the language for CMake was confusing and poorly documented. Which is ironic because they have such a crazy amount of documentation. This is partly why I didn’t want to use it in the beginning, there is too much and I just wanted to get things done, so a simple makefile would do. However, after playing around with CLion, it was able to generate a bunch of the seamake code that I wouldn’t have known how to do otherwise. Now CMake is much easier to understand and I don’t have any issues with it. In fact, it has become an integral part for our continuous development pipeline. My advice to anybody who is a little hesitant about CMake is to use an tool like CLion to generate your sea make files, it makes it a lot easier to understand.