November 18, 2024, 06:30:24 AM

1,531,348 Posts in 46,734 Topics by 1,523 Members
› View the most recent posts on the forum.


I started making a game

Started by bluaki, June 01, 2012, 08:48:14 PM

previous topic - next topic

0 Members and 2 Guests are viewing this topic.

Go Down

bluaki

June 01, 2012, 08:48:14 PM Last Edit: June 02, 2012, 02:04:17 AM by bluaki
I initially posted this in the chat thread but I guess it warrants its own thread. Maybe I'll use this thread later to post links to download it or whatever

Also please post some opinions, comments, and questions lubdoods;

During the past week or so, I started making/programming a game. bassir;
It'll be 2D with top-down perspective, with basic mechanics being action-adventure-ish or Zelda-like.

Players can, within the game itself, create and edit maps.
[spoiler=longish description of the map system]Maps are composed of the tile-based floor (with varying dimensions), objects (like trees, furniture, etc.) which can be placed over the floor within the tile grid, entities (NPCs and enemies) which can have customized dialogue and stats, events (maybe RPG Maker-like), and a few other things. Maps can be linked together in various ways or stacked vertically (Z dimension). The maps are also organized into collections/projects called "worlds" which maintain things like save files and have some other custom data like starting position and initial player HP/inventory/skills. Worlds can be, in some way (currently just copying the folder), shared with other people.[/spoiler]

It'll have a character maker for the player character, NPCs, and enemies which will simply combine template spritesheets for (primarily human) body, clothes, hair, etc. Non-humanoid entity forms probably won't have much customization, but will be available.

I haven't yet decided much else about combat, but it'll at least have swords and magic (which will cast forward like Zelda's fire rod or can be charged to place a cursor where it will cast to)

Input mappings are mainly key-based (mouse optional) and can all be changed, also USB gamepads can be connected and used

I think I'll try to make all graphics be vector-based and possibly support "zooming" in and out during gameplay. I also hope to eventually implement network multiplayer and audio creation/sequencing.

My current progress includes most of the menu and input systems as well as like half of the map system. About 2200 lines of code so far n_u

it's programmed entirely in C and I'm currently using SDL's API (which is cross-platform) for graphics and input, although I abstracted it some myself and might eventually support other graphics backend(s). I'll make versions for at least Linux and Windows, but I don't have a Mac so (even though the code should work fine on Mac) I can't make a Mac version, though if there's any interest in it I probably can either figure out some way to run OS X or give the source to a Mac user who knows how to compile code

I have no idea whether it'd be sellable or potentially profitable, so I'm holding off on making any decision about licensing. I'll at least, when it's playable, give download links to the binary here and to some other people I know on the internet.

I'm not too confident that this is something that will be very fun or entertaining to play. It's not too original either; essentially some silly mix of elements/ideas from Zelda, RPG Maker, and Minecraft.

bluaki

Quote from: Thyme on June 01, 2012, 08:44:23 PM
omg

what porgamming language
It's programmed entirely in C and I'm currently using SDL's API (which is cross-platform) for graphics and input

Quote from: silvertone on June 01, 2012, 08:48:27 PM
pls make that game available  4 mac
I've been making it in/using it with Linux, though it probably should compile and run fine on Mac too, but I don't have a Mac so I probably can't make the Mac version myself.
It'll support Windows too.

Minus;

Quote from: bluaki on June 01, 2012, 09:05:07 PM
It's programmed entirely in C and I'm currently using SDL's API (which is cross-platform) for graphics and input
I've been making it in/using it with Linux, though it probably should compile and run fine on Mac too, but I don't have a Mac so I probably can't make the Mac version myself.
It'll support Windows too.


I would hate to do that in C  saddood;
Personally I'd go with Python, Java, or even maybe Lua.
But either way I wish you luck!
happydood;

bluaki

Quote from: Minus; on June 01, 2012, 09:59:34 PM
I would hate to do that in C  saddood;
Personally I'd go with Python, Java, or even maybe Lua.
But either way I wish you luck!
happydood;
I actually like C better than any other language, especially for large projects like this.

For small/simple things, scripting languages like Python or Perl (I don't know about Lua or others) are nice and simple to use and manage, but for larger programs, I prefer the flexibility C has for managing any part of the program I want to in my own way.

For Java, it to me seems to take a very long time and a very large amount of code to make it do anything and everything while also giving very poor performance, forced OOP, poor management of raw binary data (particularly unsigned values and files), and some other issues.

Of the things I'm using, game controller support in particular probably isn't well supported in most non-native languages/environments.

On a side note related to language choice, it probably wouldn't take much effort to make this support homebrew (which uses C/C++ compilers) for something like Wii and it's a little nice to have the option to do so if I feel like it.

Minus;

Quote from: bluaki on June 01, 2012, 11:06:13 PM
I actually like C better than any other language, especially for large projects like this.

For small/simple things, scripting languages like Python or Perl (I don't know about Lua or others) are nice and simple to use and manage, but for larger programs, I prefer the flexibility C has for managing any part of the program I want to in my own way.

For Java, it to me seems to take a very long time and a very large amount of code to make it do anything and everything while also giving very poor performance, forced OOP, poor management of raw binary data (particularly unsigned values and files), and some other issues.

Of the things I'm using, game controller support in particular probably isn't well supported in most non-native languages/environments.

On a side note related to language choice, it probably wouldn't take much effort to make this support homebrew (which uses C/C++ compilers) for something like Wii and it's a little nice to have the option to do so if I feel like it.


Lol this is a matter of opinion I suppose. Some of my friends think C is the best thing ever. I honestly dislike C a lot. It has a primitive type system and isn't a type secure language which bothers me. I'd honestly prefer something like C#. If you're doing a 2d game that will look like zelda then it isn't important if you use C rather than Java. Java programs are generally much shorter than C programs. Personally I wouldn't say there is anything interesting about Java. It's a pretty generic but good general purpose language. It's a lot more type safe than C and the performance hit isn't bad for a 2d game. I'm a little bit of a language hipster though. I'm currently really interested in Haskell. It's a beautiful language IMO. There's definitely a reason that Python is becoming such a popular language. It's an excellent language. Ruby is also pretty good, but I think the community killed it. C has low level manipulation and pointers but those are only useful sometimes. It was really useful when I had to write a crash handler that involved examining the stack. But it probably would not be useful for a high level game. I also like how OOP enforces good coding practices and cod reuse. I would not know how to implement controller support, but i'm sure there is a library/api for that. I really don't think the language is a huge deal. I just wanted to express my opinion. Even if we don't see eye-to-eye.

Hiro

this sounds fancy as fuck.
how far along is it?

bluaki

Quote from: Minus; on June 01, 2012, 11:13:28 PM
It has a primitive type system and isn't a type secure language which bothers me.
If you're doing a 2d game that will look like zelda then it isn't important if you use C rather than Java. Java programs are generally much shorter than C programs.
It's a lot more type safe than C and the performance hit isn't bad for a 2d game.
I'm a little bit of a language hipster though. I'm currently really interested in Haskell. It's a beautiful language IMO.
Though less than some other languages, C has plenty of type safety. I don't think I've ever written an error in it whose cause was type-unsafety. Though I like being able to explicitly do type-unsafe things with void*, it's seldom necessary and for this game in particular I believe I don't even use it for anything except the return value of malloc-related functions which is immediately assigned to the proper type.

Where do you see Java programs that are generally much shorter than C programs that do the same thing? For all code I've seen, it's very much the opposite and Java solutions (especially those that completely follow good language practices like encapsulation) seem to usually be several times longer than their C equivalent in line count while also having much longer lines, except certain cases based on the JDK enormousness.

I intend to someday try to use the Xmonad Window Manager, which is not only written in Haskell but requires using it to do any configuration. Similarly, my only experience with Lua was for configuring AwesomeWM, which by the way I stopped using within a few weeks because I found myself rewriting much of the program when trying to get rid of annoying and broken defaults. I haven't used any functional language yet.

ncba93ivyase

Quote from: bluaki on June 01, 2012, 11:06:13 PM

For Java, it to me seems to take a very long time and a very large amount of code to make it do anything and everything while also giving very poor performance
actually java's performance is getting to be close enough to c's. i still wouldn't recommend it because you have to bend over backwards to accomodate the shittiness of the language. i've had type errors where an entire program breaks down because an object was of type 'int' and something needed type 'integer' akudood;

and there's also the fact that a theoretical error that will never actually occur is detected as an error and aborts compilation. e.g.
Code Select
if (1)
    return 1;
else
    return 0;

error: no return detected akudood;



Also, what you're making is a 2D game, so if you even face any slowdown, you're doing something wrong. My game handles hundreds of particles and their collisions per frame, in javascript, with no slowdown at all. Honestly, writing a game in C will only slow you down. My game totals around 14000 lines and that includes about 170 unique entities in the game, the physics, graphical effects, etc. The reason it's taken so long is because I've only been working about an hour or two per day most days.

and how long have you been working on this

And if it's vector-based, why not just use Flash? It'll save you time on coding in general and it's much easier to distribute it. Lua would also be a good idea because it gives you performance that's extremely close to a compiled language, but it has the simplicity of Python. I'll probably write a game in it someday.

But I'd play it. Here's all I ask: make good levels and don't have any procedurally generated bullshit and make a really good map editor.

Quote from: bluaki on June 02, 2012, 12:34:41 AM
I intend to someday try to use the Xmonad Window Manager, which is not only written in Haskell but requires using it to do any configuration.
why

Quote from: ncba93ivyase on June 18, 2014, 07:58:34 PMthis isa great post i will use it in my sig

bluaki

Quote from: Makaveli on June 01, 2012, 11:56:48 PM
this sounds fancy as fuck.
how far along is it?
I mentioned in the first post:
QuoteMy current progress includes most of the menu and input systems as well as like half of the map system. About 2200 lines of code so far n_u

More specifically, some currently-implemented features include:

reading/writing map files and creating new maps
reading/writing world configuration and creating new worlds

Displaying maps in the game window, with maps linked together horizontally or vertically for smoothly traveling between maps, which can make an area seem like one massive map of near-infinite dimensions. Linked maps are only loaded when they're within a certain distance of the player.

Walking around the world, with camera moving around to follow player (the player is, by the way, currently represented by just a square). Movement is very smooth rather than snapping to tiles or whatever.

Most of the menu system, including various menu types like list (pause menu and main menu), grid (selecting which tile to place in map editing mode), text entry prompt (naming worlds), and error prompt. The main menu has "Load World" and "New World" options which respectively list all saved worlds available to load and open a text prompt asking for the new world's name.

Map editing mode, currently only able to edit floor/wall tiles by switching the currently selected tile in the tile menu and pressing B when facing the tile. Unlike normal mode walking, movement in map editing mode "floats" over obstacles and has a fixed direction (hold L and press joystick in a direction to rotate). Similarly, normal mode can move without turning (strafe) by holding L. Editing mode displays a square outline/cursor around the tile that the player is currently facing.

Input system is pretty much entirely done and mapping can be changed in options menu. The button names I just mentioned earlier are just an example for a typical controller.


It's sorta playable, but there's essentially not much of anything to do yet considering that there's no combat or whatever

Minus;

June 02, 2012, 01:12:49 AM #9 Last Edit: June 02, 2012, 01:34:51 AM by Minus;
Quote from: bluaki on June 02, 2012, 12:34:41 AM
Though less than some other languages, C has plenty of type safety. I don't think I've ever written an error in it whose cause was type-unsafety. Though I like being able to explicitly do type-unsafe things with void*, it's seldom necessary and for this game in particular I believe I don't even use it for anything except the return value of malloc-related functions which is immediately assigned to the proper type.

Where do you see Java programs that are generally much shorter than C programs that do the same thing? For all code I've seen, it's very much the opposite and Java solutions (especially those that completely follow good language practices like encapsulation) seem to usually be several times longer than their C equivalent in line count while also having much longer lines, except certain cases based on the JDK enormousness.

I intend to someday try to use the Xmonad Window Manager, which is not only written in Haskell but requires using it to do any configuration. Similarly, my only experience with Lua was for configuring AwesomeWM, which by the way I stopped using within a few weeks because I found myself rewriting much of the program when trying to get rid of annoying and broken defaults. I haven't used any functional language yet.


I used Xmonad for a while. It's a nice tiling window manager but it's a pain to get a nice toolbar setup. Also nautilus / other file managers break. so when I used it I had to do all file management through zsh.

When I made that statement about Java being shorter I meant in my experience. It also makes a lot more sense for Java to have less lines than C because you have to manage much less on your own and if done correclty OOP is very code efficient.

Here is an article by Jeff Atwood that sort of discusses code expressibility:
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

Functional languages are pretty cool but can be hard to wrap your head around. I haven't been working on learning Haskell very long or very hard. I am awful at it though. I can do small things but nothing cool. The example where they read in a file and print it would be written as such in Haskell:
Code Select

import System.Environment
main = do
   [f] <- getArgs
   s <- readFile f
   putStrLn $ s

In the examples on that blog post they exclude the import. Without the import it would be 4 lines.

Edit: Also didn't realize they just hardcoded a file name. That haskell code does command line input. So hardcoding a name would make it a line shorter. So without the import 3 lines.

bluaki

June 02, 2012, 01:22:27 AM #10 Last Edit: June 02, 2012, 01:38:41 AM by bluaki
Quote from: Pancake Persona on June 02, 2012, 01:04:51 AM
Also, what you're making is a 2D game, so if you even face any slowdown, you're doing something wrong. My game handles hundreds of particles and their collisions per frame, in javascript, with no slowdown at all. Honestly, writing a game in C will only slow you down. My game totals around 14000 lines and that includes about 170 unique entities in the game, the physics, graphical effects, etc. The reason it's taken so long is because I've only been working about an hour or two per day most days.

and how long have you been working on this

And if it's vector-based, why not just use Flash? It'll save you time on coding in general and it's much easier to distribute it. Lua would also be a good idea because it gives you performance that's extremely close to a compiled language, but it has the simplicity of Python. I'll probably write a game in it someday.

But I'd play it. Here's all I ask: make good levels and don't have any procedurally generated bullshit and make a really good map editor.
why
I actually currently don't (yet) limit the speed it runs and I have like ~350 "FPS", mostly limited by X11 because of my program sending all that excess video information. I don't expect speed to be an issue in this regardless of language choice, but I at least like to keep memory usage as low as I can for the features.

I simply like C and I don't think using it is slowing me down at all.

I just started it about a week ago and I've spent maybe a couple hours each day on it since then.

I think vectors would just be relatively easy to create images with and I think I might choose to just export images at certain fixed scales (like 16, 24, 32, and 48px tiles) for any zooming. Zooming isn't really a very high-priority feature but rather one that I think would be nice to have eventually.

I don't want to make procedural generation the main method for creating new maps or simply playing the game, but I was thinking that I'd like to add it as an option eventually. It seems like a rather difficult thing to do well so I consider it as rather low priority. Maps are not and will not by default be automatically expanding to near-infinity in all directions, but in the editor the map can be easily "expanded" by what is internally a horizontal or vertical link to another map and the limit to these expansions is near-infinite (about 2^31 whole tiles I believe).

By the way, in contexts of my game where coordinates need sub-tile precision (camera and player/entity positions), I store them as 64-bit integers with 8 fractional bits, such that 1 increment is 1/256th of a tile and Y=0x100 is one tile above Y=0x200.

I do intend to include some of my own maps with it by default, though I'm not sure how good I will be at making them.

I have quite a few detailed plans for the map editor. In particular, I hope to make the events system versatile while at the same way giving the editor ways to use its important effects without touching the custom scripting language or whatever it'll use.

Minus;

Quote from: bluaki on June 02, 2012, 01:22:27 AM
I actually currently don't (yet) limit the speed it runs and I have like ~350 "FPS", mostly limited by X11 because of my program sending all that excess video information. I don't expect speed to be an issue in this regardless of language choice, but I at least like to keep memory usage as low as I can for the features.

I simply like C and I don't think using it is slowing me down at all.

I just started it about a week ago and I've spent maybe a couple hours each day on it since then.

I think vectors would just be relatively easy to create images with and I think I might choose to just export images at certain fixed scales (like 16, 24, 32, and 48px tiles) for any zooming. Zooming isn't really a very high-priority feature but rather one that I think would be nice to have eventually.

I don't want to make procedural generation the main method for creating new maps or simply playing the game, but I was thinking that I'd like to add it as an option eventually. It seems like a rather difficult thing to do well so I consider it as rather low priority.

I do intend to include some of my own maps with it by default, though I'm not sure how good I will be at making them.

I have quite a few detailed plans for the map editor. In particular, I hope to make the events system versatile while at the same way giving the editor ways to use its important effects without touching the custom scripting language or whatever it'll use.


I think i've just done too much fucked up stuff in C to legitimately enjoy it as a language. My schools curriculum is largely C based so I still have to do stuff in C. But it pisses me off at how they don't teach everyone good coding practices. Like everyone still uses deprecated functions and don't detect memory leaks around here (well at least students in my classes). I was a sophomore so it's about time people start dropping out. We had a class that killed a good portion of the CS students here. It's easy for people to go high level but once we go low level everyone has trouble. One of our assignments was writing malloc, and making it more efficient than libcmalloc. That absolutely killed everyone. I thought that was one of the best classes because it really helped me understand a lot of stuff that higher level abstracted languages take care of for me. Also we did a lot of abusing C and it's pointers and memory. A lot of abusing everything really. Even after we had several assignments that were like smashthestack people still use unbounded array functions. That really pisses me off about some people. My friend's response when I got angry at him was: "I don't care much for security. I'm just writing it to serve it's purpose and that isn't being secure". I'm glad he's more interested in theory because i'd hate to see what he writes in industry.

bluaki

June 14, 2012, 06:31:14 AM #12 Last Edit: June 14, 2012, 06:35:32 AM by bluaki
I recently started on the music editor for it
here's a mock of what the current design I have for it is:
[spoiler][/spoiler]
the game would render it almost exactly the same as that picture, except with a non-antialiased font

It's essentially a grid in which the vertical position is pitch (note letter followed by octave number, such that C4 is middle C) and the horizontal position is time. For time, each square represents an eighth note (half-second) and all positions are whole increments of sixteenth notes.

Notes are shown as rectangles in that grid which have a pitch, start time, duration, and instrument, but nothing else. Colors represent instrument and I'll limit the available "instruments" to easily-synthesized stuff like square and sawtooth. These notes aren't placed in tracks.

Both axes scroll and the song's duration increases easily when scrolling right and placing new notes. When a song plays to the end, it returns back to a specific loop position (set in the menu) rather than to time 0.

Controls would be something like (using 360 controller's button labels, although keyboard has similar mapping):
A: Place note (tap) or change note duration (hold)
B: Change instrument (tap) or move/shift selected note (hold)
X: Play selected pitch/instrument
Y: Play visible time range (including both visible and nonvisible pitches)
L: Decrease cursor size
R: Increase cursor size
Start: Menu (save, load, rename, set loop position, quit)
Select: Start/pause/resume playback of whole song (tap) or stop (hold)

and mouse support, which I'll add at a later time:
Left click (in grid): Place note or change duration
Right click (in grid): Move/shift selected note
Middle click: Menu
Click pitch label: Preview note (like X button)
Click instrument name: Switch instrument

The labels visible in that picture are:
top: song title, duration (mm:ss), duration (seconds)
bottom: selected pitch, selected time (seconds), cursor size, current instrument

Do any of you have any suggestions or opinions about this? In particular, I'm unsure whether to leave the X/Y axes as is or to swap them. Like all other editable things in this game, I intend to include default songs I made. I think (or hope) that, despite the limitations, some good assortment of things can be made with it and they'll seem more like the style than annoying limitations.

I'm actually not familiar with any audio sequencing software so it's entirely possible that this design or interface is completely bad&wrong. n_u


I probably could have better priorities than making this music editor before features like doors, enemies, NPCs, and events, but it's what I felt like doing now giggle;

ME##

lol should this not go in the tec board?  confuseddood;

Thyme

Quote from: Dovydas on June 14, 2012, 11:12:41 AM
lol should this not go in the tec board?  confuseddood;


well at least you ask
tec or aubrey would have moved it immediately if they had thought about it ifeelbetter;

Go Up