Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[delphonso]

I - like probably all of us - have had a million and one ideas for games that I'd like to play.

Now, I'm in a generally stable position, with adequate free time. I want to put this time to good use and learn to make some games from scratch. I've had the slightest of brushes with programming languages and am fond of the C family.

So, where do I start - really?

[Parsely]

1. outline game idea
2. research
3. implement
4. test: it's bugged so return to 2, else continue
5. you made a game, celebrate!
6. post-completion: final release and/or patching, or abandonment

Detailed:
Google tutorials for the most basic game you could make (tetris, a shmup, pac man, pong, etc.) in your language of choice and follow along! This will help give you the confidence that you can construct a simple game and these fundamentals will make you just good enough to try implementing your own game, and only implementing will let you understand how tough your idea is to realize.

Then you should start organizing your ideas and try to think of an easy idea you'd like to implement, this is really important because most game ideas people have are very complex for a single person to implement. Once you have it in plain english write some relevant pseudocode, this is where you'll realize how much stuff you don't know (like how to make a tilemap) and you can start googling topics to research and putting those in your notes.

If you've never made a game before I say for now don't worry about all the complicated stuff like release, marketing, financing, patching, or support. Just focus on being creative and having fun!

You could even make a thread in creative projects and blog about it and just throw every small question you have at the wall, could be fun!

[nenjin]

There are many moving parts to any game.

And new game creators often want to do too much with too small of a skill set.

Start small, and start with your programming, because you don't have a game without that and it's objectively the hardest part to work through.

I'd start with Python and try writing a text adventure game with some actual game logic, like Hit Points and attack rolls. If you can pull that off, you can graduate to something more elaborate. There are many tutorials online with good templates you can implement, understand, modify and then fill in the blanks.

We've got a few budding game developers around here too. Like the dude who is making the Innkeeper game in Other Games, he's built that project from scratch over the last couple years. Maybe ask them where they started and what they started with.

[delphonso]

Thanks, you two. To give some additional information and background - I took a crack at this before (ignoring the many times I've fooled around with game making resources like RPG maker) trying to go down the Python route. I learned an adequate amount of Python skills and put together a simple text adventure. I then opened PyGame, for which I could only find tutorials of previous versions of Python, meaning the syntax and examples weren't able to be used. I lost motivation and bailed.

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.

[nenjin]

Yeah, graphics are one of the big hurdles to overcome.

If you don't know how, your only option is to research, practice and prototype. I wouldn't even try to think of it as a game right now, think of it as "I need to print stuff to the screen, even if it's just the @ symbol."

But I'd be surprised if there aren't C# tutorials online that are geared towards displaying graphics for games. But this is why I suggest maybe starting in a lower level language than C. You may find more resources directly related to what you're trying to do.

[Parsely]

Thanks, you two.

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.

No problem!

Don't get too hung up on language, people have made games in any language you can think of. All the popular languages will have loads of tutorials if you know what terms to search (that's the hard part). Pick something and go for it!

Balance can only be achieved through testing.

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!

Explaining tilemaps sounded fun so I decided to give it a shot. Tilemaps are fairly easy but I needed to be walked through the idea the first time. There are loads of tutorials about these online, if you're looking for one in a specific language I can help you find one.

My brief explanation of tilemaps
What's a tile? Video game graphics jargon. It's a square or rectangular image, usually a part of the background, in a video game.

What's a tilemap? A tilemap is some data structure (like an array) that stores data that represents tile positions and types. This is useful for building maps in tile-based games. Like all problems in programming, there are zillions of ways to implement a solution.

Important about drawing to the screen: We have a screen whose origin is (0,0), where (0,0) is the top left corner of the screen. Any images we draw are also drawn from the origin, so whatever point you choose to draw an image from, that's where the top left corner of your image will be. This is important because if an image isn't part of the background it probably uses transparency and then it's not always obvious where the center of the image (important for objects like projectiles, enemies, the player) is going to end up.

Code: (pseudocode for a basic tilemap) [Select]

// 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
}

Other issues you might have to solve now that your basic tilemap is working:
- I have more than one map, I need to store all these tilemaps so I can reference them as the game progresses
- I have this huge cool map but I only want to draw part of it to the screen
- I want the screen to scroll as the player moves, I need to update the map in real time somehow
- I need to draw multiple layers of tilemaps to the screen
- I want the map to change and react to the player's actions and vice versa

[delphonso]

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.

[Parsely]

Absolutely sick nasty

Make sure you let us know if you're gonna blog it up

[Trekkin]

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.

It'd be worth your time to learn about best practices in software development more generally, too; there's a layer of skills between the code and the concept that runs from encapsulation to testing to version control to a whole panoply of engineering esoterica designed to keep you from doing things that only look foolish in hindsight. It's boring as all get out, but it's also how you avoid coding yourself into a corner or piling kluges on top of each other until the project grinds to a halt under the increasing weight of its own debugging load and you're left with an unrecoverable pile of spaghetti, that being the usual fate of amateur coding projects above a certain size.

[delphonso]

Things are going to slow for sure, as the fan on my laptop has given up the ghost, and I'm likely not finding a replacement until the end of February.

In the meantime, I can do plenty of reading and light work (interrupted by overheating) in coding.

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.

[Trekkin]

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. And yes, I do have a set of resources I use for this, but they're full of code I can't legally show to you so they're of no help here and they're overkill for a game.

Unless you want to actually get a degree in software engineering you'd probably be best served just Googling everything I mentioned; there are plenty of explainers out there for this, but you're the only one who knows which one will make sense to you. There's a lot of routes down this particular rabbit hole and they meet up at the bottom, so don't worry too much about finding everything. If you want relatively modular things to start with, search "how do write unit tests", "why do we encapsulate things" and "how to version control" and then look up everything that doesn't make sense to you about what you find.

[Starver]

Because I'm not currently in the middle of any coding project other than my own things, I can perhaps more freely wander through this territory without having to self-censor for privileged information. Although it also means I'm low on example materials (through sparcity, rather than confidentiality). So if you can handle some rather generalised and imperfect advice, I'm giving it.  And every new coordinated project I'm attached to always seems to have a different ideology behind it (written or unwritten) so that I'm not tied to a particular fetish or paradigm-of-the-month. There's all kinds of things to look out for. Some of which may be useful to you (OP), some of which may be effectively snakeoil as far as what you really need.

A good start (before even looking at collaboration) might be understanding the Waterfall Model of project development, but in my experience it'll usually end up with eddies sending you back up a level or three when you discover you were hasty/shoddy over a phase. With the most structured ways of dealing with this maybe being the V or Spiral models, but they can easily be (mis-)applied to projects with no end specified (intentionally or not), so beware.


And keep a look out (sometimes in the manner that you need to look out for 18-wheelers with dodgy brakes!) for "Agile", "Rapid" and/or "Extreme" methodologies in group working, in amongst the rest of them. Links to these (probably) exist somewhere in the above pages, and I imagine you probably won't get beyond what passes for their summaries, at least on first reading. But they work for some, and/or some of the time, when it counts.

But, naturally, if you're teaming up with a buddy in a mutual development (and can get some physical or telephonic shared time to see the same thong at the same time) it would be remiss of me not to mention Pair Programming. Maybe you'd rather make it more like Postal Chess, though. (And make sure you comment the code thoroughly?)


Some of these things mentioned are how to plan things, some of them are how to do the things you may or may not have planned, some of them handle both. There's also bits in some of them that try to get you (at the coding-coalface) properly reporting up to the Manager for the project (internally or externally supervisory) and obviously that would be reduced to just common contentedness with how your collaboration is going, rather than a time-sensitive deliverable to a finely defined and legally-binding delivery spec. But do think about at least aspirational waypoints, at one or two steps towards the vague "learn something" end-goal.


How you stand by these methods and practices is another matter. When you're working to deadlines and budhets and have to fill in timesheets, there's often also plenty of auxiliary (not directly productive) paperwork, or e-paperwork, needing your signature, or e-signature, and it sounds like Trekkin knows all about that. I'm not sure I would recommend you go that far and be your own slave-driving 'bosses', at this stage. But think about some of the written(/typed) planning.

What's the current aim and how will you know you've achieved it, for example?

[Trekkin]

I'd thought about mentioning the models, but in my experience, self-directed newbies starting from whole cloth instinctively gravitate toward a version of spiral anyway just by dint of not having the confidence to plan in large steps -- and telling them about process models generally leads to a lot of abstract yak shaving. When someone doesn't know what they're doing, planning is a lot more appealing than implementation, and they can end up writing elaborate, highly detailed, and entirely useless specifications for software that they don't know how to write and that often cannot exist. You can even watch how they shift the bits they don't understand away from whatever they're currently pseudocoding.

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.

[nenjin]

TLDR: Rather than "making a game", focus on "learning to program" first.

[Trekkin]

TLDR: Rather than "making a game", focus on "learning to program" first.

Sure, but absent any idea of how to learn to program, telling someone to go do it is useless.