Print

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

[eerr]

What I was thinking:
Test the water with Game Maker. Figure out if you want to step it up a notch.
If that doesn't satisfy you, find something with more power, like Unity.

I'm making something myself
I slowly work on a discord bot. I use this discord bot to play mastermind through discord.
Right now my work is stalled because I'm not sure where I want to go with it.
My stuff

Also, the easiest type of game to make is a 2d shoot'em up game.

It's just collisions and enemies that fly in one direction. AKA Game Maker or Unity can get you there.
Undertale, though well recieved, was Toby Fox's big "proof of concept".
It's basic concept, dodge and deliver narrative, is simple enough.
If he can do it, so can you.

[Jimmy]

Alternatively, just use the tried-and-true method of making games!

Step 1: Start with a large fortune
Step 2: Hire people to make the game for you
Step 3: Sell game to public
Step 4: Watch your large fortune turn into a small fortune!

In all seriousness though, perhaps teaming up with an existing group of like-minded individuals to gain experience will assist you in reaching your goals. Especially if your group has a good team leader that can allocate the workload out to the best people for the job.

[Sanctume]

Geez, back in my days, there was Compute Gazette magazine that has printed code in basic. 

Simple What is your name? 
> Sanctume

:100
Hello Sanctume.  Would you like to play a game (Y/N)?
> Y

Pick a number between 1 - 6.
> 4

You lose.  My number is 5.

(go to 100) 

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. 

--
My first text game was based on those Choose Your Own Adventure book.  But it was too wordy and a lame book, so I substitute my own D&D flavored encounter, treasures, etc.  Soon enough, I understood outlining and pretty much the summary of my game. 

When I got into C, it was totally hard, because I was unfamiliar with the syntax.  However, the knowledge of programming concepts such as for loops, while loops, boolean logic, remain.  The new thing that threw me off were index of multi-dimention arrays, and memory pointer. 

--
I've gone back and forth in designing my games, to rather just find something and play now. 

I did try Unity engine, but I was just not up learning a new engine to draw for me.  Text based adventure is where I got comfortable, and did not care much how to make it into graphics. 

I even got into some AI DM kinda code, and some version of TRADE WAYS 2010.  Fun times, regardless of the final result.  I just learned that I enjoy coding as well as learning something along the way.

[Starver]

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.

I rewrote many a magazine/book programme listing into a micro, including a very complex adventure game where all the *spoiler* game info was stored in the DATA sections in encoded form, so that one could not learn the in-depth secrets of the game during its transferal. The debugging was a pain, due to both thebsheer quantity of the material and the obfuscated nature of it all to hide obvious typos. (While the one entered that was a simplified Eliza revealed all its secrets. It was still entertaining for a while, though it did take some of the marvel out of all other implementations - much better to watch others, e.g. on ElizaBots on IRC, back in the day, and unsuspecting users rused to arrive on their channels.)

[Iduno]

The computer programmers I've known always said they started a new language by making a version of Scorched Earth. It's a simple enough game, but I guess it makes you use a lot of different programming techniques.

[Jimmy]

You can usually purchase prepaid visa cards that are used for gifts if you need something with a credit card number. Comes with the added bonus of never worrying about compound interest!

[Dreadusa]

post deleted

[Reelya]

I'm wondering if anyone had any progress with their game-making? Should we have a game-making challenge thread?

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.

Wow, the BBC Micro home computer. Fun Fact: it was made by Acorn Computers, and Acorn was selected as the name because it would appear alphabetically in phone books before Apple. So people think the BBC Micro just disappeared I guess, a failure that was just to be forgotten? ... The "A" in ARM processors actually stood for "Acorn". Effectively everyone has a descendant of the BBC Micro in their pockets now! They beat Intel and Microsoft!

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.

A good approach here is testability. You can write a framework that does unit tests, which are code that runs other code through some tests and outputs the results, giving warnings if the results are wrong. You can then design classes inside that framework and you put test data in and get it to spit out the results and compare to some "expected" results. Tests can be hierarchical too: you have code that tests your basic functions, those tested functions are then used in some higher-level code, which also gets its own tests.

Once the object works, then you import it into the main program. This also applies while learning to code as you go. Generally you'd make a main function and have it call all your other code and spit out results. Don't throw that framework code out, keep it as the start of your testing framework.

If you change a class later, you can then run the tests now and then to make sure nothing got broken by the changes. By having multiple projects inside Visual Studio for example, you can automate building a testing exe alongside the normal exe.

One thing that encourages is modularity, since it encourages you to make code that can be pulled out and run anywhere. Designing a class/object in-place means that it's often easier to let the object rely on a house of cards of other code, so if you pull it out and want to use it elsewhere then it won't work unless you jury-rig up the framework it expects to be there. This can be messy and makes it easier just to rewrite the code. Designing the object standalone in a testing framework prevents this approach.

[delphonso]

Shit guys. I lost all will to continue.

I got caught in a hole figuring out random numbers then spent like a month learning the mathematics which I found interesting. Dunno, guys. I think I should take a course or something just for the structure/time constraints.

[coalboat]

Apply the random number and maths knowledge to online poker and make enough money to hire programmers making your game. 

[Reelya]

That's why they suggest things like 1 week game challenges. Make something in a week, and it needs to be playable and demonstrable by that point. Then rather than getting bogged down adding to the first thing, you make follow-up 1 week games, but you're allowed to strip parts out of the first one. The advantage of this approach is that rather than one big unfinished game you end up with a lot of small actually-working games. The goal is to be constantly at the "look at this thing I made" point rather than being at the "look at this code for the thing I'm planning to make" stage, which is 100% guaranteed to be where you get stuck.

In terms of, for example art, the "make big ultimate game" idea-fest thing is like getting into drawing by sketching out this huge epic mural you're going to draw, when in actuality you can barely get a stick figure onto paper. Common sense says you get good at drawing a lot of simpler pictures first, the same as common sense says you get good at making games by having made (and uploaded) a lot of simpler games first. And I say uploaded because to get a good feel for game creation you really do need other people to have played your game and told you everything that's wrong with it. Which will be most things. For a start, it might work fine on your system but probably won't work well on anyone else's. Which is the kind of thing you want to know before spending a lot of time making something.

The "learn epic coding" approach is like if you want to draw the big mural but you never actually make any other pictures first, you spend all your time reading books about perspective and learning how to do shading really well, and expect to come up with a good picture at the end despite never having drawn anything else in your life, but you just know that once you perfect all the perfect pencil-handling skills and color theory, your mural's just going to be awesome. That's why I suggest making Tic Tac Toe, Tetris, Space Invaders, Pac Man etc. If you can't make the very basic stuff you're not going to make anything better, and believe me you'll learn plenty trying to implement all of those. Anyone competent should be able to whack out working versions of those within a few days so I'm not going to be buying it if anyone says trying to make those is a waste of time that they could be spending on their epic roguelike that's going to redefine the genre. So, either way: competent people should be able to cobble together a ton of simple games quickly, and if that takes too long then the person clearly isn't competent and needs the experience.

[Sime]

Personally, I recommend a 'top down' approach , by searching for preexisting Github projects  that are relevant to the idea I have in mind,  and then  meticulously studying their design, architecture and use of the language.    In this day and age there  are  many great open-source projects  to learn from directly, that it is unnecessarily slow and even counter-productive to code  'bottom-up'  from scratch through trial and error.

[Сontrast-spam]

I think this is interesting

[delphonso]

I have actually been meaning to post on here again.

I picked up Godot and started Harvard's free CS50 course. These two in combination have made all the difference. I feel like I'm making real progress in regards to coding, and Godot clicks pretty well with me wrt making little games for my friends.

[nenjin]

You know when I started trying to write a text RPG in Python, I got to the point where I wanted a hitpoint and damage system, and also dove down the rabbit hole of random number generation, and that's also what killed my drive to keep going.