Game Jam #7

Game Jam #7 Start Time and Length

Brett208 01 May 2017 08:39

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

Last edited on 01 May 2017 08:39 by Brett208 Show more

Re: Game Jam #7

PiscesMike 03 May 2017 20:49

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

rbwhitaker 03 May 2017 22:43

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

Brett208 04 May 2017 06:47

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

Brett208 05 May 2017 06:57

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...