Apple, Thou Art A Bitter Fruit

 

After upgrading my early 2015 era Macbook Air to Apple's newest OS Big Sur I tried to download Godot to play around with it. Imagine my surprise when I wasn't "allowed" to open Godot because of Apple's over-zealous security measures.

I ended up having to go into the system preferences just to let Godot run.

I find this totally unacceptable. IMHO this is clearly an attempt to funnel all third party software through their app store and/or their developer program to "certify" that this software is okay to run.

Godot is a free and open source alternative to Unity and many people use it do develop indie games over Unity because it is free.

I know there are workaround for this sort of things and people may argue that I should do "X" or "Y" or "Z" but to me that's not the point. If I choose to distribute a game I make on itch.io, for example, and the game refuses to run because it may not be safe then Joe Normie is going to think I, and itch.io, are pushing some sort of Malware.

I'm not. Itch.io are not either. It's silly.

I'm very close to deciding that Apple and it's customers are not my target audience anymore. Which is sad as I used to be a big fan of Apple back in the day when they were the underdog. Back before OS X.

What's even more sad is that Microsoft has been going this way too. Download an open source project off the web and get all kinds of warnings that the software might not be safe. Again, IMHO, another veiled attempt to get you to go through Microsoft approved sites.

Maybe it's time to become a Linux only dev?

Controller Woes

Curse you analogue controller!

Wow, it's been a few weeks since I last posted anything here. I should remedy that.

I think I will.

Let's talk programming.

When we last talked I'd been working on a Zelda-like for Linux and I'd made a bit of progress. One of the things I was testing was the ability to use a controller.

SDL2 makes it fairly simple to hook a controller up to your computer, find it and use it and I did tests that did just that. Using the left analogue stick I made a sprite move around the screen. This worked well for both horizontal and verticle moves. But there was a problem.

Step By Step

Updated "retro style" graphics but not final at all.

Today it didn't seem like I got much done today but I actually got more than I thought I would.

Aside from the new graphic I made for the temporary title screen, I created a timer class so I could control the frame rate of the game. The game now runs as fast as it can but updates the screen ~60 times a second. I'm not sure if I will keep this as some people have displays that refresh at higher frequencies than 60 hertz. Some people are up in the 120 range and beyond.

Accelerated!

Pretty but not much to look at.

I'm not going to lie. I had a hard time getting into the project today as the thought of going over and rewriting stuff I'd done before did not appeal to me. I wasted a bunch of time doing "other stuff" until I forced myself to sit down and actually work on it. I was happy I did. Unfortunately I didn't get as far as I wanted too.

Live and learn, eh?

It's Late. So Late

Not quite state of the art graphics...yet.

So, once again I didn't get as far as I wanted to. The plan was to pull the Windows source code from BitBucket and get that working on Linux.

Well, pulling the code was the easier part. Getting it working under Linux was a lot harder. I spent more time than I should have mucking about with that. Eventually you have to decide if it's better to spend the time trying to get what you've working under the new OS or starting over from scratch.

Success! Kind Of...

Ugh, my day job makes me want to finish this game as soon as possible so I can, maybe, make a living off of game development. I think to myself that maybe I won't enjoy it (you know, seeing how the sausage is made) but I know working for myself is a hell of a lot better than putting up with a gig I do not enjoy.

"Hello World!"

Today I had hoped to be further along on my game than I got. I have a feeling I might be typing that a lot as I progress along this path.

The main problem was that, for whatever reason, my Linux workstation would lock up when ever I tried to do some updates. This happened four or five times and I'm not sure what was going on.

Home Sweet Home

Gaben!

[Billings, MT] Today was a long day and a tiring day but all in all a pleasant day. I got to see some family I hadn't seen in a long time. Unfortunately it threw off my driving schedule. I don't mind because I wasn't under a huge time constraint. I simply didn't want to be driving into Billings in the dark.

Unfortunately this means I'm home, gotten some food, gotten a shower and am almost ready for bed. It's pushing 10 pm right now and I am tired.

I was hoping to get a SDL project up on my Linux box and a "hello world" program going. Doesn't look like it's going to happen right now.

Making A Text Dungeon Crawler On the Commodore 64: Part 5 Catching Up

So, I took a couple days off from my Commodore 64 BASIC dungeon crawl to take breather from the project, a little breather, and to work out how I was going to handle the movement and other factors that are needed to make a dungeon crawl.

In my attempt to "save memory" I decided to use a one dimensional array to store my room data and, even worse, I stored strings instead of integers in my array. Something like:

10 DIM RM$(100)

Making A Text Dungeon Crawler On the Commodore 64: Part 4 A Brief Interlude

Welcome to video four in the series. This is getting to be an enjoyable series for me!

As I get deeper into this project I wanted to take a few moments and fix a variable that I may have problems with in the future. This project is reminding me of the many pitfalls I had on my BASIC game projects when I was in high school. The most noticable to me is the fact that I didn't plan out the projects that well. So, as a result, I'd either work my self into a corner and have to start the project over and better planned or I'd have to implement a feature poorly because I didn't think it out well enough. There were also times I'd get so fed up with a project I'd abandon it. I find that is the case here.

Making A Text Dungeon Crawler On the Commodore 64: Part 3 Character Creation And Bug Hunts

Ah, the third video in a series of videos where I uses the Commodore 64 to create a simple text dungeon crawl. Of course I'm using C64 BASIC.  This video is a bit long and I think it clocks in at over 30 minutes but that was not on purpose.

When I'm doing these videos I'm programming something off the top of my head. This is not the proper way to do things as you would usually do a lot of planning. This was, however, how I used to do projects, well most projects, back when I was in high school. It was any wonder I got any of them completed.

Making A Text Dungeon Crawler On the Commodore 64: Part 2 We Have A Title Screen

Welcome back, this is the second in a series of videos where I program the commodore 64.  I am currently programming a game.  The game is a text based dungeon diving adventure game.

In this video I went ahead and implemented my rudimentary state machine for the game.  The first state is the title screen.  So I've gone ahead and implemented the title screen.  The game is working pretty well right now.

Making A Text Dungeon Crawler On the Commodore 64: Part 1 Initialize the Game

OK so I decided to start programming a Commodore 64 video game. In my last programming video I'd made a Christmas candle it was written in Commodore 64 BASIC.  I enjoyed this process very much and the urge to do another project has started to tempt me.  I had been watching various you two videos of other people's programming projects and several of them had done a simple dungeon crawl.  So I figured that should be my next project.

Game Update 4: A New Mapping Solution?

Mappy Fail?

I have spent many long hours staring at the code I've written for my Ultima Style cRPG. As I mentioned back in my last up date I'd run into a few snags. One was a crashing problem where I was trying to de-allocate memory for an object I created twice. That fix came pretty quickly once I looked at what I was doing.  The next problem has not been so easy to fix.

The problem I'm having (and I'll see if I can explain it) is I have a tile based map (using Mappy) and I have a little animated guy running around the map. Now, every time the little guy moves he moves an arbitrary amount of pixels. This represents his speed and needs to remain constant through out the game. Since the map is bigger than the window that contains it the map needs to scroll. The part of the map that is shown while scrolling is represented by a rectangle and it has a coordinate system that is an offset from the coordinates of the little guy.  The problem is when I'm on the upper and left side of the map the guy moves the correct amount of pixels and the offset moves the correct amount of pixels. But when the little guy hits a certain point going left or going down he begins to double the amount of pixels he moves each time but the offset moves the correct amount of pixels. Eventually the little guy outruns the offset and goes off screen. I have no idea what is going on behind the scenes to make the little guy suddenly double his movement amount but not the offset. Arrgh!

I hope anyone reading understands.

Game Update 3: Tiny Little Dude - UPDATED

Never mind the programmer's art!

So, finally after wracking my head around seemingly simple problems, surviving Halloween and surviving the Elections I'm back with an update. Of course it's a good news, bad news update. But, with projects like these, it seems to be the norm.

The Good News
The good news is that I have my sprite class pretty much working. If you look at the picture above you'll see a little white knight among the tiled background. What the picture doesn't show you is that the little fellow is animated. There are four frames of animation and it seems to work pretty well.  In a way it's starting to feel like an Ultima style game.

Game Update 2: Heaven And Earth

What a world!

Another update on the programming my game. I've achieved my milestone of implementing a map using the Mappy map maker and the associated files. As a result I've had to change my development environment because I was having problems linking the mappy files to my project. Apparently with the gcc compiler on windows I needed to compile it to an "object file" and link it to my project as such. The problem is mapping the %PATH% variables properly so I had access to the Allegro header files. On Windows it's a pain in the ass. Seems like it's much easier to do from Linux.

So, from the image you can see my little program has a map (with my hasty, thus crappy artwork) that can be scrolled using the keyboard arrow keys. I feel good getting to this point however, I've been this far along in other programming projects and lost interest. So, the next hurdle will be to implement a sprite that is controllable by the mouse and that can react to collision tiles on the map (as well as eventual collision sprites that represent mobs.  Eventually.  We'll see if I can cross that line.

Game Update 1: The Blue Screen Of Life!

It's not much but it's a start!

I figure that since I made a huge proclamation of making my own CRPG I should start updating on how it's going.  I mean really, come on, right?

So. Since I made my epic blog post I've worked on the game for a couple days now. Some of that time has been story related stuff and some of that time was getting Code::Blocks, Allegro 5 and Windows all to play nice. I finally got Code::Blocks, Allegro 5 and Windows all to play nice. Wasn't that hard. This is a good thing since when I start making the Linux version I'll most likely use Code::Blocks to develop the game.

Of course, the reward for my hard work is a window filled with blue.  That's okay though because it shows me that everything is working well together.

New Things & Game Programming UPDATED

Since the passing of my grandfather back in June I made it a goal to lose some weight. It took me about six weeks to drop ~20 pounds and I'm still at it. I feel good about this and it really hasn't been that difficult.  So, in honor of achieving a goal of losing weight and since it's been so empowering I've decided to set some other goals and see if I can achieve them. The first of these is a programming goal.

I must confess. I'm an okay C/C++ (yes I know they are two different things) programmer. Not a super good one but an okay one. I can usually figure out how to achieve most task and if I get stumped a little Google-fu has gone a long way in helping me. So, my next goal is going to be programming a Computer Role Playing Game (CRPG) for Windows and Mac since I own the two. I do have a Linux computer but it is in sad need of repair at this moment. As soon as I get it fixed I'll port it to Linux too. I've done some tech demos of 2D maps that I was pretty proud of so I think I can handle the job.

Writing A Commodore 64 BASIC Program On A C64 Emulator: A Christmas Candle [UPDATED]

Going back to a retro computer system is interesting. Especially when you go back to develop software for it. That's exactly what I did. Using WinVice, a Commodore 64 Emulator that most people probably use to play those old C64 games that you can find on the Internet, and using BASIC, that old, somewhat easy to get into, interpreted and insanely slow programming language that was usually bundled with most 8-bit computers, I set about recreating a classic family Christmastime memory.

In the Beginning

Back in the early 1980s I created a flickering candle as a sort of demo/entertainment program to run during the Christmas Holiday. I wrote it in BASIC and I wrote it on my TRS-80 Color Computer. It took a couple days to figure out and write and I had to use a tape player as a storage device. Anybody who remembers those days remembers how time consuming and error prone that tended to be.  I was pretty proud of myself for accomplishing this and rightly so.

Now, I've decided to redo that program on the C64 emulator WinVice. Since I don't have that tape with the program on it anymore nor any sort of printout of the source code I'm having to reconstruct the program from memory and whatever skills I have as a retro computer programmer.

We'll see if I have the programming chops to pull this off.

UPDATE:
Okay, so I finally finished this project and it feels good to do so. It didn't take me as long as I thought it would and I ran into fewer problems than I thought I would. I attribute that to having a plan (somewhat) and structuring my code (as much as possible in BASIC.

That's Not How You Do It or Data Driven BASIC Adventure Games!

I'm way better than Windows!

I was reading an online book that was originally published in the early 80s on writing DnD style text adventure games in BASIC.  As a matter of fact it's a book I used to own but somehow and somewhere between the 80s and now it disappeared.

I have several things that have done that and I often wonder where they've gone. Probably that sacred place where all my socks go during the dry cycle when doing laundry.

As I was reading I came across this page where the author shows how to implement room descriptions for your nasty little dungeon.  Go ahead and take a look. I'll stick around until you get back.

Back? Good! Did you notice what was "wrong"? Not really? Okay, let me point something out.

1020 RETURN
1030 REM ************
1040 REM ROOM 1
1050 PRINT "YOU ARE IN THE HALLWAY"
1060 PRINT "THERE IS A DOOR TO THE
SOUTH"
1070 PRINT "THROUGH WINDOWS TO THE NORTH YOU
CAN SEE A SECRET HERB GARDEN"
1080 RETURN

Here's the problem. He should have used data statements and an array to store the data. Instead he hard coded everything into the program.