Recent Forum Posts
From categories:
page 1123...next »

Consider me signed-up.

My plan is to start a new 2d-platformer shooter with stealth aspects.
Also to be included should be of course, multiple weapons for the player to choose from.
AI would be nice, but I'm not sure I'll be able to achieve that.
Character customization would also be a "plus". But I lack any kind of artistic skills, so it could be rough.
And who knows? For interesting gameplay I may even throw in the use of FarseerPhysics and some random crates and things scattered about the levels.

My primary goals however is not even to finish the game. But rather to dedicate 1+ hours a day except on weekends.
Weekends will be for other projects :).

Re: Signup List by Icecream-BurglarIcecream-Burglar, 22 May 2017 16:20

If you are looking for people to join your team, or want to join an existing team, here's the place to post that. We'll do what we can to try to get people into teams that they like on a game that they're interested in working on. (If you're on a team and decide you don't like it, you can tell the team and leave. It doesn't have to be a permanent commitment.)

Team Forming Thread by rbwhitakerrbwhitaker, 21 May 2017 21:29

I'm signing up as well.

My plan is to finish the half completed port of Tunnel Lords to Windows Universal Platform for Laptop/Desktop and Tablet. This includes support for multiple resolutions, fullscreen or windowed mode, mouse support, and touch screen support. (gamepad and keyboard support is already fully complete). There must also be a way to compile the game for older versions of Windows.

I'll be light working on the week 12-16 June because my wife and I are volunteering to help with VBS at our church.

Considering the difficulties I've had with touchscreen and integrating the new .net ecosystem into the project, I'm certain it will take more than 30 days, especially if I take 6 days off. I guess that means I'm in for the 100 day challenge. Hopefully it doesn't take a full 100 days though.

Re: Signup List by Brett208Brett208, 17 May 2017 01:55

I'll be participating! I'm not sure what I'll be working on since I've been really busy for the past 3+ months and am just now able to start slowing down, but I'll definitely work on something.

Re: Signup List by Marcus42Marcus42, 16 May 2017 23:06

I'll be in for this one as well. I was planning on doing a 30 day continuation of my Space Invaders rip off, which I probably still will…. but the 100 day challenge seems pretty interesting too. I may spend the first 30 days on that, switch to an older project that seems to have gotten sucked into cyber oblivion (Umbra), and then switch back to the space invaders deal after 30 days on Umbra.

Just thoughts for the moment.


"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

Re: Signup List by PiscesMikePiscesMike, 14 May 2017 08:29
Re: Signup List by Ninjaboi8175Ninjaboi8175, 14 May 2017 00:09

I will be joining Competition #11. I'm working on a game with some guys at work that should be a small, simple mobile game. (We've actually got two that we're deciding between. We may work on both of them.)

I've also got some ideas for some other individual games that I might work on when things are slow with the group project. I'll probably create separate threads for any of the different games that we work on.

I said at the beginning of the year that this is the year I plan on publishing my first game. With the efforts that went into the 3rd Edition of my book early in the year, this is my first real opportunity to try to make good on that commitment!

I don't know how many other people are doing the 100-day competition that spans this and the Summer competition, but I'll be doing that for sure.

More details on the games I'm working on to come as we get closer to the official start of the competition!

Re: Signup List by rbwhitakerrbwhitaker, 13 May 2017 22:58

In these competitions, we like to include some little side quests or bonuses, styled after the Achievement Unlocked! meme of video games. Below are your very own Achievements to unlock while you work your way through the competition!

These achievements are self-claimed. When you feel like you've met the criteria for the achievement, then claim it as your own accomplishment! (Most people list their achievements in their game's development thread, but it's not required.)

This list is not exhaustive. If you feel like you've done something that deserves recognition (or a self-deprecating dubious award about new creative ways you wasted time) add a new post with the achievement so everybody else can claim it too!


Accomplishments

Leveled Up: You learned something that you didn't know that you can reuse in other games or other programs.

Prototype: You have something that could loosely be called a working game.

Victory: Beat your game for the first time!

The Great Unveiling: Provide a download for your game.

Additions: Add at least one game feature that you weren't planning on or didn't think you had time for.

Seeing the Matrix: Share your source code with the people in the competition via GitHub, BitBucket, or a simple download.

Goals

Taking Aim: Set a goal for yourself for one week (or the full length of the competition).

Claim Adjuster: Change a goal during the competition after seeing it not go so well.

Stay On Target: Take the time to re-evaluate your goals during the competition, and determine that they're working.

Failures

Law of Live Demos: You show your WIP to somebody. Something goes horribly wrong.

Happy Accident: You accidentally create a bug that leads to humorous results. Post the video or screenshot in the Happy Accident thread.

Time Machine: Worked for over an hour on code that you rip out.

"Research": You spend a few hours playing a game when you should have been making one.

Monday: The entire weekend went by and you didn't get any programming done.

Wait, We Were Supposed to Make a Game?: Go for a full week without spending any time on the game.

Insufficient Vespene Gas: Eliminate at least one game feature due to time pressure or lack of programming knowledge.

Game Features

Game Over: You add the ability for players to lose the game. (Also, you just lost the game.)

Gratuitous Blood: Your explosions and deaths result in far more destruction than is necessary or even believable.

A Box Without Hinges: Create an Easter Egg and hide it somewhere in your game.

Konamified: Make the Konami Code do something interesting in your game.

Special Thanks: Create a credits screen which list all those who have contributed to your project.

Plot Whole: Create a story (however simple) and implement it into your game.

I'm Sorry, Dave. I'm Afraid I Can't Do That. Add an AI enemy, opponent, or component to your game. It doesn't have to be any good.

Two Can Play This Game! You make your game multiplayer (same computer/device, LAN, or Internet all count).

Heads Up: Add a Head-up Display or other UI overlay to your game.

Widget Factory: Add a UI of some sort to your game, with buttons, sliders, check boxes, etc.

Programming

Head Banger: Use recursion in some form in one of your games.

Jurassic Programming - While making your game run into a situation where you must add a ton of code lines to get something to work. (IE: adding points into a collision detection array) - "I wrote a million lines of code to run this park!"

Less is More: Lines of code ain't everything. Sometimes, the best solution is to refactor to eliminate redundant lines of code, leaving you with less but better designed code. Do this and unlock this achievement.

Art and Sound

It's Just Temporary: You put in artwork in your game that you claim is temporary, until you or your friend can provide you with better art.

8 is Enough: Use old school 8 bit graphics or sound/music in your work. Could also be a midi file on the music side.

Hang it on the Fridge: You create at least one piece of art (sound, texture, model, sprite, etc.) for your project.

*Artistic:* You create four pieces of art for your game.

Vincent van Gogh:You create 10 pieces of art for your game.

I'm a Lover, Not an Artist!: You get all, or most of your work, from online sources and do very little of your own artwork.

Silence is Not Golden: Add sound effects or background music to your game. 8 is Enough optional.

Progress

1 Hour: You spend at least 1 hour working on your game during the competition.

10 Hours: You spend at least 10 hours working on your game during the competition.

25 Hours: You spend at least 25 hours working on your game during the competition.

50 Hours: You spend at least 50 hours working on your game during the competition.

100 Hours: You spend at least 100 hours working on your game during the competition.

Ā½KLOC: Your game reaches 500 lines of code. You're off to a great start!

1KLOC: Your game reaches 1000 lines of source code. Making progress! Excellent!

2KLOC: Your game reaches 2000 lines of source code. Keep it up!

3KLOC: Your game reaches 3000 lines of source code. Your game definitely has some weight behind it!

5KLOC: Your game reaches 5000 lines of source code. Well done!

10KLOC: Your game reaches 10000 lines of code. That is a lot of zeroes! And it's 16 in binary! (That makes it sound… rather unimpressive!)

15KLOC: Your game reaches 15000 lines of source code. Are you programming in your sleep or something?

20KLOC: Your game reaches 20000 lines of source code. Are you just copying and pasting lines of code to unlock achievements?

25KLOC: Your game reaches 25000 lines of source code. OK, you must be cheating. How are you writing this much code?

Miscellaneous

Applying Research: Spend at least an hour programming when you should be doing something else.

Moral Support: Leave a comment on somebody else's game thread with (constructive) feedback.

3 AM Code Fest: You spend several hours programming your game between the hours of midnight and 6 AM. Beer and pizza optional.

Back of the Line: Don't get started until the competition is well underway.

The Thinker: Spend a hour thinking through a complicated piece of code and get it right first try.

The Tinker: Fiddle with a complicated piece of code and get it to work only after a lot of failed tweaks.

Way to Brag: Claim at least 15 achievements.

The Buddy System: Spend all or part of the challenge building a game in a team.

Lonely: Program on a Friday or Saturday evening.

Change Of Plans: You stop making the game you originally entered and instead enter a new one. Whether you got bored, stuck, or whatever, the whole point is to have fun and make something you like!

Thinking Ahead: Spend time before the start of the competition planning your game.

Open Invitation

This list is not intended to be comprehensive (despite being "official"). If you come up with something else that you think is deserving of recognition or note, please help us add to this list by posting below.

Achievements by rbwhitakerrbwhitaker, 13 May 2017 22:55

What is a Sprint?

In the software development world, especially in the agile software development world, a "sprint" is a fixed, regular timebox that governs your work and how frequently you do updates, demos, or previews.

Usually, a team will decide that they are doing 1-week sprints, or 2-week sprints (or pick your favorite number, but rarely more than about 4 weeks). At the end of a sprint, they will do a demo of what they've accomplished, and if the product owner (a.k.a., the guy in charge of what to build) decides it is good enough for release, it will be released as well. Often, these releases go only to a group of beta testers, rather than all customers, with full releases coming less frequently (3 months or 6 months, or whenever a certain threshold in terms of features completed is met) so that your typical users don't have to deal with updates and changing UI all the time.

In most cases, at the end of a sprint, there will be some sort of demo or review of what was accomplished by the team. These demos are usually fairly simple and informal. They're a chance for people who are following the game or product to get a glimpse into how things are progressing, and offer feedback. They're also a nice way of generating buzz and excitement about what's happening.

It's also pretty typical for developers to take a look at what's coming up next, and set goals or plans for the next sprint.

Here's a good example of a game (Space Engineers) that does weekly video updates and weekly software downloads: http://www.spaceengineersgame.com/news.html

Competition #11 Sprint Cycle Guidelines

As a group, we've collectively settled into a pattern of doing 1-week sprints. Sprints are not required, so don't feel obligated to join them, but I can almost guarantee you will find benefits in doing sprints. Feel free to follow some or all of the guidelines below.

1. We will be doing 1-week sprints. (If you want to run 2-week sprints, all of your sprint boundaries will still line up with everybody else's. That works out pretty nicely.)
2. Sprints will start and stop on Mondays. That means Monday is your day for doing a review or demo of what you've accomplished, and for posting new downloads. If Monday doesn't work for you, feel free to pick another specific day. (But choosing a specific day is a good thing.)
3. The competition starts on Saturday, so the first Saturday and Sunday don't count as an official sprint. We'll call this Sprint 0. Feel free to post an update for Sprint 0 or just roll that into Sprint 1.
4. Your demo/review should be something that is visible to the other people here in the competition. In past competitions, people have made a forum thread specifically for their game, and I would encourage people to keep doing that. The demo or review can come in the form of a text post, a series of screenshots, a shared video on YouTube, a Twitch stream demoing the status, a combination of any of the above, or anything else along those lines that you can dream up.
5. Pay attention to other people's sprint demos, and give them feedback as well. That's what these demos are for.
6. Sharing a compiled build for people to actually play is strongly encouraged, though definitely not required.
7. Sprint planning or settings goals for the upcoming sprint is also encouraged. Telling other people about your goals for the upcoming sprint is a good way to hold yourself accountable. (Remember: process goals are preferred to target goals.)
8. Sprints can continue between competitions and can continue with the same numbering into the Summer Competition if you are doing the 100-day challenge that spans the two competitions.

Other Benefits

Because there's a weekly reset switch, if you got distracted during one week, you can always recommit for the next week.

It also means if you know you're going to be busy one week, you can back off your plans for a sprint, or take the sprint off entirely, and come back fully engaged the sprint after.

There is also the scenario in which you get sick of the game you're working on. Sprint boundaries are great for deciding, "Eh. I'm done with that game, at least for a while. I'm going to work on another game this next sprint." In those cases, it's often better to switch to a game that you'll actually work on than it is to let the one just languish.

Competition Sprint Cycle by rbwhitakerrbwhitaker, 13 May 2017 22:54

This thread is the place to sign up for Competition #11!

Signing up isn't mandatory (you can do the full competition without ever signing up) but signing up is a great way to make a public commitment to the world that you're going to work on a game for 31 days and try to produce something interesting.

Please feel free to sign up below here to get the ball rolling!

Signup List by rbwhitakerrbwhitaker, 13 May 2017 22:52

Well for the first time ever, we don't have to have a two-week long discussion about when do do the competition, thanks to our planning for the year and future.

Competition #11, a.k.a. the 2017 Spring Competition, will be starting on Friday, 26 May 2017 (the start of Memorial Day weekend in the USA) and ending on Sunday, 25 June 2017.

Note that while this is a 1-month competition, running through the Spring and upcoming Summer Competitions, as well as the time between them, will compose a single 100-day period of time for making a game. In other words, the start of this competition is also coincidentally the start of a 100-day game dev challenge for those who want it.

While these are the official dates of the competition and what most people will be using, you should feel free to bend the dates a bit to better suit your own personal situation. If your weekend is Wednesday and Thursday, feel free to shift the dates by a few days. If you've got a bunch of tests at the end of the school year that you need to concentrate on, feel free to delay the start of your competition work by a bit (or just do a 21 day competition instead of a 31 day one).

Remember: the real goal of the competitions is to get each of us into a pattern where we can weave game dev into our busy lives. You shouldn't have to put your life on hold to make a game, nor should a busy life completely prevent you from doing something you love like game dev. Find the balance that works for you. That's the true purpose of these competitions.

Time Frame by rbwhitakerrbwhitaker, 13 May 2017 22:51

The goal of this Game Development Competition is more about providing the right kind of motivation to get you to actually sit down and build a game than it is to prove you're a better coder than everyone else. As such, these rules are pretty light, and pretty casual. If one or more rule doesn't suit your needs, feel free to be a Competition Rebel, break the rule, and enjoy the competition anyway.

These rules are tentative. If you want to suggest a change to the rules, post a comment below and we can talk about it as a community.

Picking Goals

Because the focus of the competitions are to get things done on a game, the competition doesn't prescribe how much or what parts of a game you should make. Instead, you must choose a specific goal for yourself.

There is a preference for process goals over target goals. The following are target goals:

  • I'm going to complete a game in the 31 days of the competition.
  • I'm going to add networking to this game I've been working on.
  • I'm going to build enough of a game that I can start play testing it with others.

These are good goals, and the competition doesn't discourage using these types of goals, but…

These are process goals:

  • My problem is that I keep doing other things instead of working on my game. My goal is to dedicate at least 6 hours every week to working on my game so that it can actually progress.
  • My problem is that when I sit down to work on my game, I get distracted by other things. My goal is to eliminate my distractions when I program by turning on my Strict Workflow Chrome extension to block Facebook, YouTube, etc., close Discord, and put my phone in the other room while I'm working on my game.
  • My problem is that I put my life on hold when I start working on a game and burn myself out by doing nothing but game dev. So my goal is to get at least 8 hours of sleep and spend 30 minutes taking care of other life responsibilities before moving to game dev.

Target goals are not bad. We eventually want to get that first game out there. But software development is extremely difficult to predict. Something comes up and suddenly, your target goal is out the window and you lose motivation for continuing because you can't hit your target anymore.

This is what makes process goals better. Process goals are way less prone to surprises happening. The outcome of a process goal is nearly always the result of your own efforts and decisions, not some external surprise.

A key part of the competition is picking one or more goals to aim for during the competition. Process goals are preferred, but target goals are also acceptable.

Another key part is continually re-evaluating your goals. You are not only allowed to change your goals during the competition, you're strongly encouraged to re-evaluate them and decide if they need to be adjusted. (This is commonly done as a part of our weekly sprint cycle.)

Rules

1. You must choose goals for yourself. Since the competition doesn't prescribe exactly what you must complete on a particular game, the burden is on you, the participant, to decide what you need to accomplish during the competition. Pick one or more goal for the competition and list it in your forum thread or elsewhere that people can track your progress. Process goals are preferred to target goals, but both or either are allowed.

2. Show your work. To count as a "win", you must show your progress to the other participants. The most common way to do this is by creating a forum thread for your game in the competition's section of the forum. In your thread, you can post status updates, screenshots, and even downloads for the game. (Even source code, if you want to make the game open source.) Some people post daily updates or weekly updates, but at a minimum, final results are required to meet this requirement.

At least weekly updates are strongly encouraged, as the community tends to have a weekly sprint/cycle/cadence. A week is usually enough time to show some amount of progress, and keeps you moving forward one week at a time. For most people, this ends up being Sunday evening or Monday sometime.

3. Making sellable games is strongly encouraged. Not that you have to actually attempt to sell it, and not that if you tried to, somebody would pay money for it, but you should be carefully watching licensing agreements an avoid copyrighted material (or get permission from the copyright holder). For anything that requires attribution, the copyright holder should be listed in the credits.

Beginners can have an exception to this rule. If you've never made a very large project before, it is probably better to start by cloning a really simple game first (Tic Tac Toe, Pong, Breakout, etc.) to start to figure out how to build functioning games before tackling the magnum opus floating around in your head.

4. No restrictions on team size. While most people tend to work alone, working in a team is allowed and encouraged. If you don't have a team, post a message in the competition's section in the forum and ask for people to join you or express your interest in being a part of a team.

5. No restrictions on tools, engines, frameworks, languages, etc. The competition doesn't prescribe any particular language or engine. Use whatever you think is best for you and your game.

These rules are quite different from earlier competitions, so if you have questions, comments, or suggestions to improve them, comment below.

Official Rules by rbwhitakerrbwhitaker, 13 May 2017 22:44
SomeoneWithAQuestion (guest) 12 May 2017 17:35
in discussion Hidden / Per page discussions » MonoGame Texture Atlases

Let's say that I am trying to load the animated sprite. My code looks like this:
Game class:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;

namespace Game5
{
    /// <summary>
    /// This is the main type for your game.
    /// </summary>
    public class Game1 : Game
    {
        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        //instance variables

        public Game1()
        {
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";
        }

        /// <summary>
        /// Allows the game to perform any initialization it needs to before starting to run.
        /// This is where it can query for any required services and load any non-graphic
        /// related content.  Calling base.Initialize will enumerate through any components
        /// and initialize them as well.
        /// </summary>
        protected override void Initialize()
        {
            // TODO: Add your initialization logic here

            base.Initialize();
        }

        /// <summary>
        /// LoadContent will be called once per game and is the place to load
        /// all of your content.
        /// </summary>
        protected override void LoadContent()
        {
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);

            Texture2D texture = Content.Load<Texture2D>("ocinWalkRight");

            texture = new AnimatedSprite(texture, 2, 5);

            // TODO: use this.Content to load your game content here
        }

        /// <summary>
        /// UnloadContent will be called once per game and is the place to unload
        /// game-specific content.
        /// </summary>
        protected override void UnloadContent()
        {
            // TODO: Unload any non ContentManager content here
        }

        /// <summary>
        /// Allows the game to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing audio.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Update(GameTime gameTime)
        {
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed || Keyboard.GetState().IsKeyDown(Keys.Escape))
                Exit();

            // TODO: Add your update logic here

            base.Update(gameTime);
        }

        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.SpringGreen);

            //spriteAnimation.Draw(spriteBatch, new Vector2(ocinPostition.X, ocinPostition.Y));
            // TODO: Add your drawing code here

            base.Draw(gameTime);
        }
    }
}

Texture Atlas class:

using System;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Input;

namespace animatingSprites
{

    class AnimatedSprite
    {
        public Texture2D Texture { get; set; }
        public int Rows { get; set; }
        public int Columns { get; set; }
        private int currentFrame;
        private int totalFrames;

        double timePerFrame = 0.2; // five times a second

       public AnimatedSprite(Texture2D texture, int rows, int columns)
        {
            this.Texture = texture;
            this.Rows = rows;
            this.Columns = columns;
            this.currentFrame = 0;
            this.totalFrames = Rows * Columns;
        }

        public void Update()
        {
            //  currentFrame++;
            // if (currentFrame == totalFrames)
            // currentFrame = 0;
            currentFrame = (int)(GameTime.TotalGameTime.TotalSeconds / timePerFrame);
            currentFrame = currentFrame % totalFrames;
        }

        public void Draw(SpriteBatch spriteBatch, Vector2 location)
        {
            int width = Texture.Width / Columns;
            int height = Texture.Height / Rows;
            int row = (int)((float)currentFrame / (float)Columns);
            int column = currentFrame % Columns;

            Rectangle sourceRectangle = new Rectangle(width * column, height * row, width, height);
            Rectangle destinationRectangle = new Rectangle((int)location.X, (int)location.Y, width, height);

            spriteBatch.Begin();
            spriteBatch.Draw(Texture, destinationRectangle, sourceRectangle, Color.White);
            spriteBatch.End();
        }

        public static implicit operator Texture2D(AnimatedSprite v)
        {
            throw new NotImplementedException();
        }
    }
}

The Texture Atlas class is located in the same folder as the game class and its properties are:
Build action: Content.
Copy to output directory: Do not copy.

It gives me this error when trying to call the constructor:
CS0246 The type or namespace name 'AnimatedSprite' could not be found (are you missing a using directive or assembly reference?).

I would really appreciate you replying to this since I have been stuck like this for approximately 4 months now; done a lot of research and found absolutely nothing.

I will be patiently waiting for your response.

by SomeoneWithAQuestion (guest), 12 May 2017 17:35

We finished up the Game Jam for the ASCII text game. Overall, I thought we covered a lot of ground. A lot of functionaility was added like being able to interact with doors, pick up items, and use the items. We didn't make headway on the Random Map Generator, which was one of the bigger goals.

AsciiTestGame.gif

Results:

  • Ability to generate maps with rooms and hallways.
  • Doors that may be (O)pened and (C)losed. They impede movement when closed.
  • Ability to move around the map with proper collision detection.
  • Placement of up and down stairs. (Do not change level though)
  • Placement of items (Apples and Smoked Fish currently)
  • An inventory screen showing the weight of each item picked up.
  • A Char Stats screen that shows health, experience, current location, etc.
  • Critical stats change color to yellow and then red as they are depleted.
  • Slow recovery of health as you walk around.
  • Quick recovery of health by using the (R)est command.
  • A command pane for selecting your (I)nventory.
  • Ability to select indiviual items from your inventory (A-Z).
  • Ability to (L)ook at items in inventory and get a description.
  • Ability to (E)at food in your inventory.
  • Ability to (G)et items that are on the floor of the level.
  • A light source on the player that lights up the surrounding level.
  • Stacks of Copper, Silver, and Gold that translate to money when picked up.
  • Ability to auto-pick up coins when walked over.
  • A spike trap that damages the player when walked on, Symbol is (^).
  • Traps are hidden until first stumbled on by player.
  • A different font for the user interface than the square font used to generate the map.

Some of the bigger things we didn't have time to implement:

  • Actual random map generator.
  • Fog of War / Terrain discovery as walking.
  • Ability to go up and down staircases.
  • Keeping the player's light from lighting up parts of the level that the player cannot see (Like around bends/corners).
  • Ability to (W)ear / (W)eld an item.

Participants:

  • TowTow10
  • PiscesMike
  • RB Whitaker
  • Brett208

Upcoming Events
Next up will be a 30 day competition starting on 26 May. Expect to see more about it soon. The next Game Jam (Collaboration) will be mid to late October.

ASCII Text Game Results by Brett208Brett208, 07 May 2017 18:44

PiscesMike,

Just looked over the code you wrote. I think it is a good start. Here are some changes I would consider.

There is probably no need for a visibility enum. A simple bool Hidden would probably work. We will probably run an alghorithm based on the lighting and line of sight each time the player moves to determine what map cells are current visible to the player. Other cells that are not hidden and not visible would by default be inactive.

I would probably rename what you are calling WorldItem to MapCell and change it from a struct to a class. Making it a class makes it possible to change the contents without re-initializing it. Only one will exist per space on the map, so MapCell seems to describe it better to me anyways.

I see the game having 3 layers per space on the map. Layer one would be the terrain (door, wall, floor). Layer 2 would be a list of any items on the space. Layer 3 would be the person/monster/character on the space. You would then draw in that order, so if a person/player is on the space they would be drawn. If an item is on the space, it is hidden while a person/player is on top of it. We could limit to one item per space to simplify. If multiple items are on a space, perhaps they are represented by a ? mark. Then you would have to (L)ook at the space to see what items are present.

public enum ItemType
{
    Empty,
    Wall,
    Enemy,
    Player,
    Candle,
    Knife,
    Etc
}
 
public abstract class Item
{
     ItemType Type;
      ... Other properties based on the item
}
 
class MapCell
{
    public Item Terrain;
    public List<Item> Items;
    public Item Person;
    public bool Hidden
}
 
public Dictionary<ItemType, DrawProperty> DrawDictionary;
 
public struct DrawProperty
{
    public char Character; //The ASCII character to represent
    public Color Color; //The ASCII color to draw. This would probably be overridden for terrain to draw based on if the space is currently visible or not.
}
 
MapCell[] LevelOne = new MapCell[1000];
int MapWidth = 50; 
//I'm a fan of making it a 1D array and using the modulus operator (%) to navigate the (x,y) coordinates. I think it is easier to store to disk this way. There are advantages to both approaches though...
Re: Game Jam #7 by Brett208Brett208, 05 May 2017 06:57

I finally made some time to brainstorm a bunch of ideas for the game for the collaboration. It follows fairly closely to Angband. This list is really meant as a starting place. If people want to see it go different directions, I am all for the input. RB expressed interest in working the Map Generation. If people are more for scripted gameplay, I would be fine with that as well. Scripting a lot of content is tough and time consuming, just like creating a quality random map generator. They both have pros and cons.

I think this is a lot more detail upfront with design decisions than other Game Jams we have done. So, it if isn't appreciated, we could just delete the post and be a little more free form…

Angband1.png

End Result Goal. See the bright white area that is visible to player and the darker gray that is explored but out of current view.

Map Drawing

  • Add floors and walls to map.
  • Generate static map for testing.
  • Create a Map Render Class
  • Create an interface for a MapDesigner.
    • Initially use a placeholder class that delivers the static test map.
    • Replace with an actual random map generator.
  • Trigger drawing a new map when a stair case is used.
    • Maybe press (<) to go up and (>) to go down. Doesn't really need to be separate chars though if the staircases are not both up and down.
  • Add light source to player's location.
    • Walls/floors within light source are brighter (maybe white)
    • Walls/floors outside light source are dimmer (maybe gray)
  • Add ability to add basic items in dungeon.
    • Money/Gems/Gold ($)
    • Food (f maybe?)
    • Light Source (~)
  • Add camera to map so map can be bigger than the screen size.
  • Add discovery to map. Characters outside of light source are unknown until they are explored.
  • Limit discovery so player does not see through walls.
    • Create an algorithm that determines what is not line of sight.
  • Add limited knowledge of items. Show items where last seen on map regardless of if they have been destroyed, picked up, etc when they are out of active view of the player.

Map Generation

  • Separate map into rooms that are reached by corridors.
    • Consider possibly autogenerating corridors that vary in width. Perhaps 1, 2, or 3 tiles wide.
  • Add Up Stairs (<) and Down Stairs (>) to map.
  • Add doors to map.
    • Make a percent chance door will exist at end of corridor or where 2 corridors meet.
  • Add special scripted rooms to map.
    • Save scripted rooms to file for future use.
    • Use either a text editor or design a custom editor for scripted rooms.
  • Add hidden doors to map.
  • Add (S)earch command. (Maybe set to find hidden 50% of the time until an attribute is added to character that affects search ability.)
  • Add hidden traps. Reveal through search command
    • Add a property where they only go off X% of the time when walked on undiscovered.
  • Add (D)isarm command. Percent chance disarming fails. If Fails percent chance character sets off trap.
  • Make map generator deposit items semi-randomly.

Inventory System

  • Add inventory screen to game.
    • Consider making inventory sit next to the map, so not a separate menu that appears. This makes sense on current monitors for desktop style play. An inventory screen that comes up would make more sense on a phone or maybe smaller tablet.
    • Make a placeholder for item weight.
    • Allow items that are the same to stack.
    • Add (G)et command to pickup items.
    • Add (D)rop command to drop items.
  • Add (W)ear / (W)eld command so player can don items from inventory.
    • Perhaps just start with welding a light source and maybe a weapon or something.
  • Add (T)ake off command so player can remove items.
  • Add screen to show what items are equipped to the player.

Character Stats

  • Add current health and max health to character. Maybe start with 100 for testing.
  • Make player regain health. Maybe 1 every other turn to start???
  • Add (R)est command for not using turns while not moving.
    • Make resting regain health faster. maybe one every turn while resting???
  • Make player get hungry over time.
    • Add a satiation stat to player. Maybe max 1000, lose 1 every turn.
    • Allow player to die if it reaches 0.
  • Add (E)at command. Increase satiation stat as eaten.

I think this list will see us through the Game Jam without being completed. If not, we could start adding in monsters, Pathfinding for monsters, experience, increasing danger and item value in dungeon, …

Okay, current plan is:

Current Time Zones:
Brett: UTC-10
RB: UTC-6
PiscesMike: UTC-4
TowTow10: UTC+10

Timeline:
2:30am UTC Friday - Intro to Mercurial, Bitbucket, and MonoGame. (TowTow seems knowledgeable on programming but has not used Mercurial, so this will be some time to make sure we are on the same page and able to collaborate/share code.)

PiscesMike: 3PM-7PM UTC Saturday
RB: 3PM-11PM UTC Saturday???
Brett: 8PM-5AM UTC Saturday
TowTow10: 9PM-5AM UTC Saturday

RB, I know that I dumped you in a time slot without asking, so please let me know what you really want. If you are available in the time block I listed, it would be great to allow overlap and get myself and TowTow10 bootstrapped into what you both have accomplished so far. But not knowing your schedule, I'm sort of going out on a limb.

Working on same code over two time periods
I see where RB is coming from with the code base being different. I will say that we have done about 4 collabs together, so I have a decent idea of the basic game structure you both use in MonoGame (I think anyways, I could be off here though…). Also, if the game wanders off where I want it to go, that is okay. I'm only one in four working on it, so I don't want everyone else to feel like it has to be exactly what I want. If RB overlaps some to answer questions, I think it will really smooth out okay anyways.

Also, I'm sorry to sort of leave everyone hanging. TowTow and I had a long private chat. I didn't know where TowTow stood on the different technology we talked a lot off the main chat window about it. It got pretty late my time and I didn't want to stay up and write this summary post in the forum for others to read about the changes. So, yeah I pretty much confused everyone by waiting to post this.

Working an overnight (US time) Game Jam
PiscesMike brought up the idea of doing something overnight US time instead of the current plan. If this gains some tracking on Thursday, I'm happy to accommodate best I can. We are getting close to starting though and need to solidify any time changes.

Re: Game Jam #7 by Brett208Brett208, 04 May 2017 06:47

Well I'm thoroughly confused about the plan now. I can understand splitting it up, though I worry somewhat that if we're working in the same codebase, me and PiscesMike will storm ahead and build something different than what Brett had in mind, who was the original idea proposer. I've seen many scenarios where people get into something after others have spent all day on it and just feel like it's not worth the trouble to try to jump in and learn somebody else's mess when you only have a single day to get something done.

Or are we doing two separate projects?

If you guys in the late boat are OK with it, I'm OK too. I'm just bringing up the concern because I've seen it be a problem many, many times. It seems like the limit is an hour or two of development before it becomes uninteresting to try to dive in. The only times it works is when what people are doing is very compartmentalized and the late people can just implement an AI that matches some interface or something of that nature. I don't know that I understand this project well enough to predict that that's going to be possible.

I'm not trying to rain on the parade, but I just want to make sure I understand what's happening, and that we all understand some of the consequences of our current planned approach.

Re: Game Jam #7 by rbwhitakerrbwhitaker, 03 May 2017 22:43

Just posting an update concerning me and Brett208's discussion in chat last night.

Looks like we have another candidate for the collab, and also things are looking like they need to be shifted a bit. Thanks to my half functioning brain, I failed to ask for a few extra hours off work. So, I'm looking at being available from 11AM-4PM EST. That corresponds to 4AM for Brett208 and TowTow who wants to join. After a bit of wrangling, we determined it's probably best to split into two teams, and span the collab between two teams. The current suggested plan is for Me and RBWhitaker to start out the game jam early in the day (my 11AM, and 9AM for RBWhitaker) and then Brett208 and TowTow will join when they can ~3PM my time or 12PM for RBWhitaker.

Just suggestions for the moment, and subject to change.

The other thing that was discussed was setting up an array to implement our world. I've suggested the following as a way to build an array of custom objects. There was some discussion and other suggestions, so I'm just throwing this out there as a reference to what I had thought. Feel free to post other ideas and thoughts as you have them!

public enum Visibility
        {
            Hidden,
            Active,
            Inactive
        }
 
        public enum ItemType
        {
            Empty,
            Wall,
            Enemy,
            Player,
            Candle,
            Knife,
            Etc
        }
 
        struct WorldItem
        {
            ItemType[] item;        // An array so we can stack as many object as needed in any spot
            Visibility visibility;
            //Color color       // In case we want to add color
            //Active            // For game object que management
        }
 
        WorldItem[,] LevelOne = new WorldItem[100,100];

This would allow us to track the basic objects as well as some needed properties. I was thinking it would be cool to implement a fog of war effect in three stages: Undiscovered, Discovered and highlighted(Bright white color), and Discovered but not highlighted(Grey color representing things that have been discovered but are not in the current radius of the players light).

Again, just suggestions that I'm posting so we have a record of whats been discussed. Have a great day!


"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

Re: Game Jam #7 by PiscesMikePiscesMike, 03 May 2017 20:49

Hey everyone, I'd like to nail down the timeline for the game jam. I was thinking 5PM UTC or 1PM Eastern Time. Currently I think it is myself, PiscesMike and a possible for RB Whitaker. Not too late to sign up either if interested.

Time wise, the current plan is to work on it for one full day. If people want we can commit to a formal 8 hours of work or just continue through the day and evening.

How does this work for everyone?

This would be 7AM my time, so shifting it later is easier for me than earlier. Although I'm not opposed to shifting it a little earlier if it works better for others (or I could join a little late if a lot earlier works better). I'm UTC-10 (10 hours behind Universal Time).

On Tuesday I plan on throwing up a list of tasks for the Game Jam. Mostly to get us thinking about the order of critical tasks so the game works. But also to get ideas flowing on what people want to work on and how they relate. No requirement to work from the list I generate.

-Brett

page 1123...next »