My week in game dev (13 June)
Hello, and first of all, some QA -
What is your approach to writing assembly language on the Spectrum, compared with PC dev?
Assembly is so, so hard, that you don't want to be experimenting with it. This would be an epic time sink. So I am writing everything in Lua+Love2D first. This is an easy place to experiment and get things working with cheap and nasty code. In other words I write two versions almost in parallel. On the Lua version I have the screen and coordinates exactly as they are on the Spectrum, meaning that in many cases the code is then just a port. This is working well. It's also interesting how a chunk of Lua code that would be considered final on PC, can actually be simplified and optimised multiple times over before it ends up as final Z80 code.
When will the Next game come out?
Good question. I really hope this game is pretty much working in a couple of months time. Then it will just need polishing and so on. I think Fusion Retro might then do a Kickstarter. That's as close as there is to an actual plan :)
Ask me questions. I like questions!
The Next project -
You might recall how pleased I was with my Spectrum Next scrolling last time. And indeed it felt like quite an achievement. With that seemingly working the next logical thing to work on was a player character - or object, as coders might call it/him/her. I already had a basic object running on the PC prototype version on the game and so I made a start on porting this over to the Next.
Instantly I hit the wall of new and difficult things in the form of hardware sprites on the Next. These are the game changer on the Next as it's basically free sprites - and lots of them. Again, of course, there is no space to store the graphics, but the process involves switching the sprite data into real memory, shunting it all down a pipe into some special sprite memory (and freeing up the main memory again), and then telling the Next what frames (and where) you want displaying each game cycle. It's actually very well thought through, and works a treat. But there's a learning curve.
Now, the thing about the player object is that it can start anywhere on the level. This means the map will begin scrolled so that the player is (obviously) visible. I hadn't really thought through the implications of this when I'd first got the scrolling demo working (and was dancing around for the sheer joy of being alive). And that's because I have two bits of code - one draws the initial screen full of map and the other draws the edges as it scrolls. If the player starts at the right hand side of the level then it will be as if the screen had been scrolled all the way over. But my initialisation code didn't take this into account as it used the same scroll index for the map and for the hardware scroll. I had two choices - change the initial draw so it calculated a bunch of pre-hardware scrolling first, or decouple the hardware scroll values from the game's own how-far-have-we-scrolled flags.
Here's a good rule for coding (and maybe life in general) - if something looks like two different things, then it probably is. Or, don't cut corners by shoehorning things together. So I took he decoupling route - but there was some stress as I had to break already working code as part of the process. Coders hate doing that, but an unwillingness to backtrack costs lives. (and screws up a lot of software development)
Anyway, the scrolling works again. But this stuff cost me a couple of days!
So, I get my one frame static player running around which led to three new tasks.
1. Push the scrolling as the player approaches the edges of the screen - easy enough.
2. Port the the Lua prototype code that slides the player around any wall edges he hits - super not easy! This is lots of IFs and compares which soon get out of hand in assembly.
3. Animate the player - nice and easy after #2
Anyway, all this now works and I'm comfortable with Z80 again. The levels of concentration required for this kind of coding is off the scale, but the joy of seeing it work is equal reward. All is well in the world.
With these things all working the next stages will be more content orientated, all being well - baddies, shooting, killing, doors, puzzles, etc. Fun times ahead!
Wormhole Dungeon
Status | In development |
Author | Tony Warriner / UFO Spares |
Genre | Adventure, Action |
Tags | 2D, Indie, Pixel Art |
More posts
- My week in game dev #1360 days ago
- My week in game dev (2nd June)97 days ago
- My week in game dev (17th May)May 17, 2024
- My week in game dev (3rd May)May 03, 2024
- My week in game dev #8Apr 23, 2024
- My week in game dev #7Apr 15, 2024
- Devlog #6Apr 06, 2024
- Devlog #5Mar 30, 2024
- Devlog #4Mar 23, 2024
Leave a comment
Log in with itch.io to leave a comment.