gfxgfxFreeBASIC Games Directory Forumgfxgfx
gfx gfx
Welcome, Guest. Please login or register. September 21, 2017, 01:22:44 PM

Login with username, password and session length
14.09.2014 - Check the results of our latest game dev competition here:
gfxgfx gfxgfx
gfxgfx Home Help Search Login Register   gfxgfx
gfx gfx
  Show Posts
Pages: [1] 2 3 ... 14
1  FreeBASIC Game Development / Competitions / Re: FBGD Numbers Competition (June 2014 August 2014), 250 $ 1st prize on: July 29, 2014, 04:33:58 AM
Random drive by screenshot.
2  FreeBASIC Game Development / Competitions / Re: FBGD Numbers Competition (June 2014 August 2014), 250 $ 1st prize on: June 29, 2014, 10:37:57 AM
Ugh, finally finished moving. Anywho, I've got card generation going, and I've been playing around with background styles. Here's what I got so far (front and back). Background is easy, but overlaying the default font to look nice is becoming a pain, and I might just resort to handling it procedurally.
3  FreeBASIC Game Development / Competitions / Re: FBGD Numbers Competition (June 2014 August 2014), 250 $ 1st prize on: June 14, 2014, 12:38:52 PM
Brainstorming here, interested in feedback. Smiley

My current idea is "Dominionoes." It would play as a turn based game combining dominoes with a tile based map like you might see in Settlers of Catan or Carcassonne. The idea is the tile map provides a picture of a country side that you have dominion over, but it's up to you to create industry and supply chains to make the land as productive as possible. Tile maps and the sort order of dominoes would have replayable seeds so players can challenge one another for a high score on any given seed. I think it would be nice for a concept like this to be multiplayer, but I'm going to stick with a single player target for now.

I'm thinking I'll use a double-six domino set to begin, allowing each game to take up to 28 turns. You'd have a small hand of dominoes (four or five) that you can choose from to make your next move. The board would likely be a reasonably sized grid - if it's 10x10, you'd have 100 spaces on the map with 56 total spaces of dominoes (each domino covering two spaces when placed).

To start the game, I think you'll place the "6:6" tile somewhere on the map to represent the city at the heart of your dominion. Each turn, you choose an additional domino and place it in any orientation on the tile map, with the only requirement being that you must place at least one of the numbers on the domino next to a matching number on the board. (I haven't decided yet if both dominoes should be required to touch only matching numbers or not - it seems like that would require much larger boards, as you'd end up with more gaps.)

The strategy lies in how you build your chains of dominoes, as each tile on the map will have some natural resource assigned to it (think lumber from forests, food from plains, gold from mountains). The dominoes represent your supply chain, with resources naturally traveling "upstream" to higher numbers. Perhaps a better way to think of it is imagine a taut sheet held out with dominoes representing weights, the heaviest being the 6 and lightest being 0. Resources will collect at the heaviest points they can reach.

Ideally, you'll get valuable resources to route to your castle, but you may end up with pools of resource at other places. You'd probably see towns or trading posts spring up in those areas, which would still score points, just not as much as if you enriched the trade of your main city. I may have other terrain features influence score, such as rivers facilitating trade, applying a multiplier on the point value of resources carried by river to represent "speed to market" influencing the value of goods.

Ultimately, this is a solitaire strategy game, but with the seeds being replayable, it can also spark challenges. I'm not sure I'd use FreeBASIC to create a multiplayer version of the game, but if it plays well enough single player, I may try my hand at a multiplayer version later on.

Any ideas? Details are a bit vague, as this is an unfiltered first conception.  Grin

That's a horrible idea, because there's no way I can beat that in gameplay. Tongue
4  FreeBASIC Game Development / Competitions / Re: FBGD Numbers Competition (June 2014 August 2014), 250 $ 1st prize on: June 09, 2014, 04:44:25 AM
I don't think anybody's finding a good numbers theme terribly easily. Tongue
5  FreeBASIC Game Development / Competitions / Re: FBGD Numbers Competition (June 2014 August 2014), 250 $ 1st prize on: June 04, 2014, 05:54:28 PM
So my kind of idea for the comp is a competitive "card" game, where the player and a bot are dealt "cards", which are random numbers. You can only see what the opponent's random number is, but each card has an attack and defense that are 2 products of prime factors for the numbers. So the strategy is in choosing good factors. Each player has 6 cards on the table, and each round chooses an opponent's card to attack. If the player's attack surpasses the defending card's defense, the the opponent loses health in proportion to the difference of the two cards' attack. Otherwise the attackers card is lost, but the attacker doesn't lose health. After losing a fixed amount of health, that player loses.

So for example, if you have a "12", that breaks down to factors "2, 2, 3". So for each number, you add it to either attack or defense, such as 5 attack (2 * 3), and 2 defense.

Not terribly complex, but should be doable to finish, even for me.
6  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: February 06, 2014, 04:16:38 AM
Ah, the smell of fresh bugs being squashed. So far, it seems the remote admin daemon for seavax is now much more stable. Fixed a crashing bug when a remote server disconnects, and resolved a separate hanging issue for clients trying to read from a closed server connection.

Had some real fun with seavax, I wrote a simple query system for the table structures. Ended up fixing a bug with game authentication, since the new system allows for properly nesting conditions. eg Don't start a game until host has map of equivalent size *and* map is properly staged as public.
7  General / General Discussion / Re: Damn it's quit around here on: February 02, 2014, 03:14:11 PM
Coding as usual. And the ever-unfruitful job hunt.
8  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: January 27, 2014, 12:50:47 AM
Gosh this place gets quite.

So, the current game is kinda on hiatus; I'm working on a small maze game using the same server. The front-end is java, but the back-end server is still the same ol' Freebasic program. I'm trying to transition to a plugin based system, where game-specific code is loaded as a dll and core logic (eg account management, chat rooms) is the executable itself.  So far you can log in, create and edit mazes, and create empty game rooms. If anybody wants to play with it I can upload the client program, although it's still in heavy development. Currently there's a bug with the client parser where it trips up on empty tables and gets out of sync. I already have a cheap host for the server, and I usually leave it running.

Now, the whole plugin thing. One thing that's kinda baked in to the server program is that there's always a minimal threshold of latency. The client sends a command, the server holds on to the request for a while, runs a set of rather expensive parse operations, then acts on it. Furthermore, most state is pushed to the disk; the server avoids storing most information in RAM if it can help it. That isn't so bad since the server hardware is running on SSDs. But this has lead to an interesting situation: the request-answer latency is high, but the RAM and CPU usage is very low. That, and the amount of stored state is small. Thus - outside of the issue with maintaining consistency of files - the work load is fairly parallel in nature. Given the rapid start up time and using plugins to only load relevant code, it could be possible to build the server to scale. This is all waaaay down the road; I just want to get the games made first.

Most of the server side data is highly tabular. In fact, all files are as text-based tables. As some of the data operations get increasingly more complex, it may make sense to switch over to using a proper SQL database (I'm thinking Postgresql). That would help address the concerns of concurrent processes accessing the shared data. Fun times.
9  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: January 10, 2014, 06:02:46 PM
Cleaned up some more bugs. Here's a sample shell script I use for testing the server using the new interface program:


# Connect new profile to server @ ip address
./seatab -p "chatbot" -i ""

# Log into account 'bot' with password '12345'
./seatab -j "chatbot" -m "/acc/log/login -account bot -password 12345"

# Warn everybody in global chat lobby that the server will be shut down
./seatab -j "chatbot" -m "/chat/msg -m \"Ima shuttin down in a bit!\" -r lobby"

# Wait a couple seconds
sleep 5s

# Shut down server
./seatab -j "chatbot" -m "/prc/stop"

# Properly close profile
./seatab -j "chatbot" -r
10  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: January 07, 2014, 07:50:51 PM
Got the server to be scriptable with a shell. Other big news: Porting to Linux borked everything. ev. er. ee. thing. Cleaned up most of the mess, but the account manager still acts wonky sometimes, and occasionally crashes. Particularly when involving the lobby chat function. On the bright side, testing is now much easier since I can have bash scripts handle the work.
11  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: December 07, 2013, 12:02:19 PM
Welp, ported the server to Linux and I'm using a new build system. Still busy, but still coding.
12  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: November 09, 2013, 09:12:43 PM
More updates.

So, the game is not dead. Still working on the server and fixed a number of bugs and added more features. Busy as can be, but I'm still making progress.
13  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: November 01, 2013, 08:24:33 PM
An update on things.

So, I'm think that the server needed to be coded in a different language, probably C. I'm keep running into issues in dealing with networking and system code, and the lack of FB-specific documentation for the respective libraries is a real drag. Especially when functions get renamed because of conflicts, and the only way to figure this out is to dig through dense headers. Doable, but annoying and inefficient. For the past month or so I've run into some serious issues with the client code; changing the network API has lead to breaking many things, and there still are show-stopper bugs in the packet parser.

And this brings me to the next, and bigger, problem; I just don't have enough time at the moment. I'm taking a heavy course load, but that's fine. Also doing mandatory research, but the final straw is bills; they're much higher (by a factor of two) than I anticipated and previously was paying. Which means my savings dried up way too fast, which means I've been wasting a lot of time looking for jobs to fit my hectic schedule.

Ironically, I moved to save money by living in an apartment with my sister. She was poor while I had was fine with my own job, so most of the family's resources naturally went to her (which makes sense). I quit my job to move, she gets a very nice salary, and now the tables are turned, but no more external funds coming in. We had moved into a relatively nice, but pricy, place, and now I'm living well, well, well over my means trying to just pay for my share. So until I can get settled, I just can't work much on the project. :/
14  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: August 12, 2013, 10:36:32 AM
Update 9:

Starting to transition over to working on the client side again. I changed the networking protocol a little bit in terms of server response. First, the server returns an acknowledge packet if there's no data to send, as opposed to keeping silent. Next, the return packet format is a bit different; now there are three packet-chunk delimiters that always follow the three packet chunks: Header, column, and records. Before, those delimiters followed any list of fields. Headers are a list of fields, columns are a list of fields, and each record is a list of fields. The newer format makes it much easier to determine the end of a table packet, as well as make it much easier to parse partial table data. This will come in handy when I start sending larger loads. Other than a few extra tweaks and some helper commands, not much else was done server side.

I've been pretty productive on the client code. The buttons are now context-specific. So now the connection-state button also acts as a login button when connected to a server, the connect button turns into a disconnect button, and the chat-expand button switches to a chat-contract one. I'm also in the middle of decentralizing the button system. Before, all of the buttons are registered in one big, central list. Well, that can't work because different parts of the screen overlay other parts, but buttons have to be rendered after the background for their subscreens are rendered. Given that a big list would have to be rendered last, that means no other subscreen could overlay them despite needing to. So by assigning buttons to their subscreens, that problem was fixed. It was a bit painful though, cause I kept running into problems with having them respond to UI, but those issues got fixed. It will also make it easier for screen switching, so I don't have to add extra code to disable-enable button states when different screens are pulled up.
Client-side packet parsing got a big overhaul. I haven't tested it out much yet, but it parses iteratively. Unlike the older method, the new parser can handle arbitrarily large tables, as well as incomplete tables while more data is still coming in over the socket.

On the downside, I have met a huge technical problem getting in the way of current development. And that problem is called kerbal space program.
15  FreeBASIC Game Development / Work In Progress / Re: 4xc Seasons on: August 04, 2013, 08:04:14 PM
Update 8:

The past half week I was all over the place working on the code. Basic account information can now be loaded from disk, and clients can now log into accounts. My table structures got tweaked and can act as key:value lists, as that's how I store server properties anyways. Fixed a packet parsing bug and did a lot of refactoring too. But the biggest new feature is that the server now loads the API parameter specs at startup and compares them to incoming command packets *before* calling the executing code. It was becoming a real pain checking for various parameters' existence manually in each API call, and adding way too much unnecessary clutter and complexity. I was able to delete a lot of boilerplate code, and now the functions are much more readable. To see all the gunk I got rid of, see:
And those are the simple commands.

I also did a little bit of work on the client. The gui buttons for logging into an account now work, and when connecting to a server they will try to auto-send. Also added feature to recall last text line entered in chat by pressing the up key, which makes debugging easier.
Pages: [1] 2 3 ... 14
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Cerberus design by Bloc
Valid XHTML 1.0! Valid CSS!
gfxgfx gfxgfx