Thanks, you two.No problem!
I learned some C++, which I liked, and then some C# out of curiousity. Life got a bit hectic and I've been out of it for a while. I think this is actually a good spot to be in since I - reasonably could start working with any of those three languages and head down a path.
Roguelikes are up my alley - both for their simple visuals, and because of my experience with tabletop gaming. I've designed game systems in my freetime that use percentile dice or multiple d6's and - I think - I have a decent grasp of balance.
The problem I'm running into is the gap. Printing text, handling booleans, arithmatic are things I can grasp and implement in clumsy programs. But things - like you mentioned - like tilemaps seem far beyond me. Googling wasn't successful with Python on this, but maybe the C family would be easier. I'm not sure.Just gotta google them and take it all one step at a time. Don't be afraid to ask for help!
// integer coordinates where an image will be drawn at
coordinateX = 0
coordinateY = 0
// integer dimensions of our tiles
tileX = 10
tileY = 10
// objects to hold reference to tile image files
wall = wall.png
dirt = dirt.png
// we store tile objects so we can reference them easily with integers later
// note: images[0] = dirt, images[1] = wall
images = {dirt, wall}
// tilemap array, the integers represent the tiles that will make up the map being drawn on the screen
// expected: 0 = dirt, 1 = wall
tilemap = {
{1,0,1}.
{1,0,1},
{1,0,1}
}
// use the tilemap data to draw the map to the screen
for each row in tilemap { // index variable is i
for each col in row { // index variable is j
draw(images[tilemap[i,j]], coordinateX, coordinateY) // draw() draws an image to the screen; it has 3 arguments: a reference to the image, and the x and y coordinate where the image will be drawn
coordinateX = coordinateX + tileX // we're going left to right by adding the width of a tile to the x coordinate so we can move to the right and print the next image in the row so it's exactly flush with the previous one
}
coordinateY = coordinateY + tileY // we're done with that row, so we add the height of a tile to the y coordinate so the next row of tiles is exactly flush with the row above it
}
So, after chatting with a friend, I'm leaning back on C++.
One - because my buddy is also trying to learn it, and we can bounce code back and forth.
And two - roguebasin has a libtcod roguelike tutorial that I've heard good things about, and might be something I'd like to try later on.
Before all that, I'm going to spend a few weeks brushing up on C++ and then put together a text-adventure, as you recommended. I might even put together a thread to ask questions and to post on my progress as I try to improve on things.
I'll plan out what I want that text adventure to entail - specifically things that will be useful for a larger game (inventories, health points, etc.)
And I'll get to work.
Trekkin, do you have any resources on that? I think I've got a generally good mind for this stuff, but I know it'll be a lot of trial and error on huge, dumb mistakes.
TLDR: Rather than "making a game", focus on "learning to program" first.
Game maker should have just enough to wet your whistle, or be something you want to stick with.
Game maker should have just enough to wet your whistle, or be something you want to stick with.At best, you'll immediately run afoul of the software's inherent restrictions and want to learn how to do something real.
As far as design strategies, I'm more willing to make a massive mistake and learn from it rather than following the schemes and advice of other. I've never been good at following directions without deeply understanding /why/. This is also the wall I ran into early on when doing tutorials and searching for answers - hardly ever a why, just how to do it.
Game maker should have just enough to wet your whistle, or be something you want to stick with.
If by "wet your whistle" you mean it will literally drive him to drink, I'd agree, but at least you didn't plug RPG Maker.
As a general rule, if software is marketed as letting you do something "without coding", kill it with fire. At best, you'll immediately run afoul of the software's inherent restrictions and want to learn how to do something real. At worst, you'll never realize what it doesn't let you do.
Is it paid work? If so PM me, if it's not work I can do I can try and recommend you to someone who can do it.Spoiler (click to show/hide)
Hilariously, on page 47 it says: "Game design cannot be learned from a book. It requires experience.be learnt from a .PDF"
Simple as that. It has programming concepts such as variables, input, random, and print. There was no functions or procedures objects/class in BASIC, so it was spaghetti code.Depends upon the BASIC. PROCs and FNs (value returning subs) existed in BBC BASIC and could do much to cut down on arbitrary spaghettification.
Simple as that. It has programming concepts such as variables, input, random, and print. There was no functions or procedures objects/class in BASIC, so it was spaghetti code.Depends upon the BASIC. PROCs and FNs (value returning subs) existed in BBC BASIC and could do much to cut down on arbitrary spaghettification.
As did GOSUBs, which combined with the arbitrary-point-of-recall RETURN was arguably worse than the GOTO, with both their mutable destinations if you kept line numbers relevant letting you enter and then leave code-segments in an almost untrackable mess. Compare QUADRAT on page 33 with TARTAN on page 35 in the classic manual (http://bbc.nvg.org/doc/BBCUserGuide-1.00.pdf).
Probably the most useful benefit of best practices for the autodidact programmer is salvageability. A project that dies from lack of relevant planning (which is almost inevitable while learning) can be raided for usable parts for the next iteration; buggy spaghetti cannot.
Trekkin, do you have any resources on that? I think I've got a generally good mind for this stuff, but I know it'll be a lot of trial and error on huge, dumb mistakes.
Not to be even more of an ass, but everyone thinks that when they start out. I certainly did. It's kind of why these mistakes are so common.