I'm starting a weekly video development blog for my project to help me stay engaged. I'll update this post with links when they are released. Let me know what you think of the project
Devlog 001Devlog 002
So far, IMO: awesome. Greatly appreciate the Ultima-style method -- brings me back to
days of yore... :-) Keep at it!
Thank you everyone for the subscriptions! It's really encouraging
I'm very sick this weekend (that's why I sound kinda spacey an unenthusiastic on the video) so I may not get a lot done this week, but I'll also show parts of my dev stack in future videos as well.
Subscribed!
If this is an Ultima clone I hope you'll ditch the food requirement. Realism in RPGs can bite my Dingoo.
slobu wrote:
If this is an Ultima clone I hope you'll ditch the food requirement. Realism in RPGs can bite my Dingoo.
Agreed
As I work on the design more and play around with the prototype I'm thinking about taking this in a different direction. More of a Binding of Issac type of game than Ultima. For some reason the Ultima-like concept just seems boring to me somehow.
I think what it comes down to is that I wouldn't enjoy playing an Ultima-like game that I created.
Also there's been a title change now that I have themed the design. I'll update everything with the next devblog, which may come more than weekly.
Again, thank you all for the subscriptions! It's very encouraging. Also, in case anyone is wondering I never finished that FFVII speedrun I was working on. Diablo 3 came out and it was all over with
Yeah. The only thing that would excite me (as the developer) would be a Dwarven Fortress type adventure mode where everything is procedurally/randomly generated. Ultima as a sandbox game.
The Ultimas were very much sandbox games, but static sandboxes like the GTA series. I'm thinking of doing something that isn't exactly a sandbox, but with randomly generated content.
slobu wrote:
If this is an Ultima clone I hope you'll ditch the food requirement. Realism in RPGs can bite my Dingoo.
I've been toying with making food optional but helpful. One would require food only for running; walking can be done on an empty stomach.
One idea that's been used in some recent Roguelikes is to use food items for slow health regeneration. Like you slowly regen your health over time, but not if you're hungry. I kinda like the idea.
Some of the later Ultima ports (U5 for NES comes to mind, terrible game that it is) only consumes food when you camp or sleep. If a character has food in their inventory the regen health as normal. Otherwise they do not.
See, what you and tepples suggest is exactly the way to balance realism with fun. Minimize negative rewards. Maximize rewards for using game systems. Basically, get them to squeeze as much gameplay out of your work and reward them for it. Why can't big brand name companies get this?
How should "Skare" be pronounced?
Well the name's been changed so it's not much of a difference. I pronounce it like Ska-Rey. It's my DND campaign setting from Highschool. It's what I name any fantasy-themed project before I have a name for it
Quick tip (maybe you can use this in some amusing way): the word "skare" in Swedish is pronounced the same way (skah-rey) and refers to the situation where there's hard layer(s) of snow on top of layer(s) of soft snow. I can assure you our Scandinavian buddies will find this game title quite amusing ;-)
Quote:
the word "skare" in Swedish is pronounced the same way (skah-rey)
The description was correct, but it's actually pronounced more like skah-reh (or skaoh-reh if you're Scanian
)
Interesting. I stole the name from the Ultima games, a shortening of Skara Brae, which in turn took the name from the
neolithic settlement in Scotland.
mic_ wrote:
Quote:
the word "skare" in Swedish is pronounced the same way (skah-rey)
The description was correct, but it's actually pronounced more like skah-reh (or skaoh-reh if you're Scanian :P )
Thanks for the correction -- I'm better at pronouncing Swedish than I am with phonetic transcription (i.e. I fuck this up even with English words). And I never could read
IPA very well (brain's already full!).
mic_ wrote:
(or skaoh-reh if you're Scanian
)
Scanian = Skåning?
I really like the idea of a video devblog and am eagerly awaiting the next part!
I will post the next part tonight, but it's not going to be very impressive
I've done a lot of design work but not much coding. Work has been killing me this week.
This is interesting qbradq! Hope to see week 2 soon.
Part 2 may have to wait until tomorrow. I'm still stuck at work
Just posted the second installment. See first post for link.
Qasm is really impressive to me! I don't know about any of the things you mentioned
so... it sounds enormus!
You are the first person that I've noticed using Programmer's Notepad 2 too. Asm6 is still for me... it's much simpler than Qasm I guess.
Yea it's just one of those tools I wrote for myself. As someone has mentioned in the comments, many of the complaints I had about CA65 were either fixed since then or were due to my poor understanding of the product.
I love PN2! I find it especially nice that I can define a "Build and Run" button and even have error logs with click-to-line functionality.
Despite your comments about CA65 being either "wrong" or "having since been addressed/fixed", I'm in agreement with you about the annoyance factor (based on your description). I had no idea about the forward reference annoyance -- that would piss me off to no end. I've tried using ca65 so many times over only to find that I often spent more time fighting with the tools than actually getting shit done. In fact, I find most tools today are like that -- you'll spend hours inside of a GUI "messing about" rather than writing the damn code, or "trying to get the tools to do what you want".
So that said, kudos to you to writing an assembler that does what you want and how you want.
I do not want to turn this topic/thread into an assembler debate (here we go again -- tepples, if you want to split this off into another thread, be my guest), but... Still to this day I do not understand why on bare-metal platforms where assembly is used (i.e. most retro consoles, Apple II, etc.) people bother with all this unnecessary crap (ex. "segments" when there is absolutely no ld.so or equivalent, "procedure defines", concept of scope, and other such things). It's not like any of these things inhibit foot-shooting -- if there's a bug in your underlying 6502 that stomps all over ZP, the assembler isn't going to know that thus keep you from hurting yourself. As someone who has done 65xxx since 1987 or so, I've never, ever understood what these offer purely from a native processor/6502 functionality standpoint. You're writing assembly on bare metal, not C; there is no RTL, libc, or ld.so (since we're talking about segments here ;-) ).
Honestly, I think it gives the *impression* of "clean code" when in reality there's functionally no difference (and I would argue no advantage). Splitting things up into separate include files + writing proper comments is honestly all I've ever seen needed, and that's even on gigantic/huge projects (such as major tools on the Apple IIGS written purely in assembly).
I have a completely different stance when it comes to non-bare-metal environments (i.e. present-day OSes) where C is often involved or where there is an abstraction layer (that should be used to ensure stability given the complex nature of the environment) between you and the underlying CPU. Same goes for scripting languages, including things like perl. So I understand the advantage, just not on bare-metal platforms.
CA65 is not a standalone assembler, it is part of the C toolchain. It is not targeted to any particular platform either, just 6502 CPU. The segments allow to make up any memory model you need to get output you need. It case with the NES this probably could be useful since the hardware could vary from game to game - banks, their sizes and placements, extra RAM, etc.
I personally tried all three assemblers popular in NES development - NEASM, CA65, Asm6, and had no major problems with any of these. I also used DASM for some C64 development, and recall it be less convenient that any of these.
I'd say this is on topic. I created the topic to discuss the devblog, and we're discussing it's content
I like lexical scoping because it allows me to type less. Rather than doing something like kernel_nmihandler_hadnmi, I can just say hadnmi. And when referring to it from another module, I can say kernel.nmihandler.hadnmi. But you are correct that it adds no value to the assembled binary, and actually introduces some complexity for the programmer.
"proceedures" are just cosmetic. The .proc directive is aliased to .scope, and every scope defines a label (if it's inside of a segment). Originally I had intended to do some sort of static call chain analysis, but later realized that was kinda dumb for an assembler
I use segmentation for RAM as a way to allow easily relocatable libraries. I got the idea when looking at FamiTone, which wanted RAM in the $0300 page. I thought it'd be nicer to be able to write a library that just expected a RAM segment called "ft_ram" or something, then let the developer define where it was. I use segmentation for ROM as a way to manage physical banks.
Anyhow I'm no longer trying to get people to adopt the assembler for use. I suppose too many assemblers muddies up the waters. Also it's not being developed with everyone in mind, really just my own needs. But if someone thinks their needs are similar to mine and would like to use it, it's open source and very well documented.
Hopefully this week I'll be able to show you all more than just a title screen, but it's not looking too good. This week is going to be crazy busy with work as my team is piloting our product and there's a lot of operational cost at steak for the business. I'll basically be working non-stop for the next 48 to 72 hours, breaking only for sleep, food and occasional forum posting
qbradq wrote:
... and there's a lot of operational cost at steak for the business. ...
I hope it's medium rare! *tries to get a laugh out of people* ;D
Shiru wrote:
(ca65) It is not targeted to any particular platform either, just 6502 CPU.
It supports 65816 too, unless you count that in as 6502.
(The C compiler only supports 6502, though.)
Work... so...
*passes out*
No devlog this week. I've barely got time to play with my kid and see my wife this week. Next week is more of the same