Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Ding! Games is a small independent studio run by two brothers working part-time. Our goal is to create games that we love to play.

Entries in this blog


Unreal Posting Trello Cards from a Running UE4 Game

This tutorial will give a step-by-step guide for creating Trello cards from inside a running Unreal Engine 4 project. While you can use this for just about anything you can think of, I personally use this as a way for my players to post bugs from inside the game. If you're not familiar with Trello, I highly suggest you check it out. It's a great tool for project management and organization. It should go without saying, but you're going to need an account on Trello in order to make any progress here. I also want to mention at this point that this will be a C++ tutorial. Without some form of additional plug-in or other engine modification, you can't make the needed HTTP Request calls. Also, setting this up will assuming you know how to add input mappings and have worked with Widgets a bit. Note: This was created UE4 4.17. This article was originally published Ding! Games. We're going to start simple, but I'll talk about a few ideas for adding in some variance toward the bottom. Part I: Trello We're going to start by going through some steps to authorize access to your Trello account and get the information we need in order to post new cards onto the board of your choice. In the end, we're looking to make an HTTP request to Trello that looks something like this (the italicized parts surrounded by {} are what you'll end up replacing with your own values). https://api.trello.com/1/cards?key={Your+key}&token={yourtoken}&name={New+card+name}&desc={New+card+description}&idLavels={Label}&idList={list} Step 1: Key The first thing to do is generate a key with your Trello account. This will let you start to get the rest of the required items. While logged into Trello, go to the following link: https://trello.com/app-key Step 2: Token The next step is to authorize write access. Copy the below address, but replace {Your+Key} with the key you got from Step 1 (make sure you take out the {} as well). https://trello.com/1/authorize?key={Your+Key}&scope=read%2Cwrite&name=My+Application&expiration=never&response_type=token Step 3: Board Id Now you need to get the id of the actual board you want your cards to get posted to. Use the following link (no modifications needed): https://trello.com/1/members/me/boards?fields=name Exactly how this looks will depend on which Web Browser you're using. For example, Chrome will just spit out all of the text without organizing it at all, while Firefox will sort and color the data for you. Either one is fine, just look for the long string of alpha-numeric characters right after the name of the board you're specifically looking for. This id isn't actually needed in the HTTP request line, but you need it to get the next two ids... Step 4: List Next up, the list within the board you want the cards to post to. As before copy the below, but replace the board id with the id you got from Step 3. https://api.trello.com/1/boards/{board+id}/lists Again, how it breaks it out will be determined by what Web Browser you're using. This is where using something like Firefox will make it a lot easier to pick out the exact one you're looking for. This time, the id (not the pos) you need is before the name of the list you want to post to. Also, make sure you don't inadvertently copy the board id again. Just one more... Step 5: Label Last, but not least, is the label you want put on the card itself when it gets posted. This should be getting familiar, replace the board id in the address with your own. https://api.trello.com/1/boards/{board+id}/labels As with step 4, this can be a bit messy if your browser doesn't break it out for you, but you should be getting the hang of it by name. Grab the id (first entry per set) for the color you want your bards to post as. Okay, hopefully you copied all those ids down somewhere, because you're going to need them for the next part, actually writing out the code. Part II: C++ Code Now that we've got all of the various ids that we need, it's time to dive into doing some code. Step 1: HTTP Module First up, we need to make a small edit to the build file, and include the HTTP module. public class Zeus : ModuleRules { public Zeus(ReadOnlyTargetRules Target) : base(Target) { PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "HTTP" }); PrivateDependencyModuleNames.AddRange(new string[] { }); } } Step 2: Header Definition Now, on to the actual implementation. I added my logic in the Game Mode, but you can actually put it just about anywhere you want. I'm also going to show a very simplistic setup, although I'll give some ideas on how to expand upon it at the bottom. #pragma once #include "ZeusFunctionLibrary.h" #include "StandardPlayerController.h" #include "Http.h" #include "GameFramework/GameMode.h" #include "ZeusGameMode.generated.h" UCLASS() class ZEUS_API AZeusGameMode : public AGameMode { GENERATED_BODY() public: AZeusGameMode(); /** Used to report a bug */ UFUNCTION(BlueprintCallable, Category = "Trello") void ReportBug(FString Name, FString Description); UFUNCTION(BlueprintImplementableEvent, Category = "Trello") void ReportBugComplete(bool bWasSuccessful); private: void OnReportBugComplete(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful); }; There are three functions defined in the above code: ReportBug: My goal is to have bugs reported from the game's GUI, so I wanted to be able to have the actual reporting of the bug called from blueprints. This function is passing the Name of the bug, and the full description (both entered by the player). You can modify this as you see fit. ReportBugComplete: This is implemented more for testing purposed. It's used to push the result of the bug submission back up to Blueprints to be handled. You can modify this as desired, or just remove it entirely. OnReportBugComplete: This is the function that gets automatically called after your HTTP request is processed. As such, it has to stay as is. Now to the best part, submitting the card! Step 3: Implementation Here's the code: #include "Zeus.h" #include "ZeusGameMode.h" const FString TrelloCards = "https://api.trello.com/1/cards?"; const FString Key = "1234567890abcdefghijklmnopqrstuv"; const FString Token = "123456789abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrst"; const FString Label = "123456789abcdefghijklmno"; const FString List = "123456789abcdefghijklmno"; AZeusGameMode::AZeusGameMode() { // Nothing extra needed in the constructor for this } void AZeusGameMode::ReportBug(FString Name, FString Description) { TSharedRef Request = FHttpModule::Get().CreateRequest(); Request->SetVerb("POST"); //Replace all the spaces with + Name = Name.Replace(TEXT(" "), TEXT("+")); Description = Description.Replace(TEXT(" "), TEXT("+")); //Construct the HTTP url FString URL = TrelloCards + "key=" + Key + "&token=" + Token + "&name=" + Name + "&desc=" + Description + "+(V:+" + UZeusFunctionLibrary::GetProjectVersion() + ")" + "&idList=" + List + "&idLabels=" + Label; // Set the built URL Request->SetURL(URL); // Bind OnReportBugComplete() to be called once the request is complete Request->OnProcessRequestComplete().BindUObject(this, &AZeusGameMode::OnReportBugComplete); // Process the request Request->ProcessRequest(); } void AZeusGameMode::OnReportBugComplete(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful) { // Calls up to a Blueprint implemented event ReportBugComplete(bWasSuccessful); } All of the logic takes place in the ReportBug function, essentially going through the following steps: Create the request and set it to POST (This is an HTTP protocol thing) Change all of the spaces to + (Another HTTP protocol thing) Build out the full string to be reported, using the model I posted way up top. Note that I have a function in there that adds on the current project version to the description. This is very handy for tracking bugs, as you really want to know what version someone is playing, without having to worry about them typing it in themselves somwhere. Set the built URL against the Request, bind the OnReportBugComplete() function and then process the request. That's it for the code level. This alone gives you a good bit of freedom for what to do, but I'll show you a simple implementation at the Blueprint level next. Phase 3: Blueprints Step 1: Widget First, lets build out our Widget that the player will actually use to input their bug: I was looking for functional when I threw this together, not pretty. It's an extremely simplistic Widget, with some texts boxes for the user to input a title and description of the bug, and then either Submit, or Cancel. The buttons have the following attached to their respective OnClick() events: Submit: Cancel: Step 2: Input Mapping Under project Settings->Input, we want to add an action mapping to start of this whole series of events: Step 3: Report Bug Event Last, but not least, we need to fill out the logic for when the user actually presses F12. I put this in the Blueprinted version of my Player Controller, but you can put this in anything that receives user input: A couple of things to note here is that I automatically take a screenshot and pause the game. Neither or required, but I find both to be handy. Conclusion And there you have it! While running, you should now be able to press F12, create a bug report and submit it to Trello, where it should appear almost instantly. Now, as I mentioned earlier, this is a rather straightforward approach that has the potential for expansion. For example, as it stands, the Board, List and Labels are currently hard coded values, meaning that you always post to the same place with the same label marking it. You could expand upon that by putting in a drop-down for the play to choose how critical of a bug they found, passing that as a variable down to the ReportBug() method (such as in the form of an enum), which you could then use to select which label gets attached. You could also let the player submit recommendations or feedback in addition to bug reports, which could result in the cards being posted to a different list, or completely different board. The variations are endless, but ultimately, anything that lets the player quickly provide some form of feedback without having to leave the game or do something else is ideal. Hopefully you don't have any trouble getting any of the above implemented, but if you do, please feel free to post your questions, and I'll see what I can do. Best of luck! Shawn Shawn is the Designer/Developer at Ding! Games. They are currently working on a game code-named Zeus, a RPG Action/Puzzle game. For more great articles or to get the latest news bout game development, visit them at their site.




Zeus: A Puzzling Action Adventure RPG

Zeus. The code name for the latest game I'm working on. It's going to be an adventure, puzzle, action RPG... and yes, I know that's a mouthful. The game is drawing a lot of inspiration from the old-school Quest for Glory series by Sierra. If you're not familiar with the series, imagine King's Quest, but with combat. If you're not familiar with that either, think of a point-and-click adventure game (like those made by Telltale games), but with less pointing and clicking and more top-down/third-person controls. Add to that role-playing game stats and combat and it starts to paint a picture of what we're making. If you still don't know what I'm talking about, then I've got a new game for you to try out! You take the role of a newly raised skeleton and after selecting a specialty (warrior, rogue or mage), you quickly get caught up in the politics of the land. You'll have to use all the skills at your disposal to overcome a number of challenges and prevail, likely (and hopefully!) with much hilarity in the process. Moving on. Although I took a good bit of time off from game development recently to finish my degree, I dove back in with a vengeance a little over a month ago, and I've made a lot of great progress. I've got a lot of the out-of-combat systems set up, such as inventory management, and intractable objects. I'm pretty happy with how the switching camera worked out: I also finished an initial prototype of the game's combat system. Although I had to work out a few AI bugs in the process: I didn't intend for this to be a horror game! Luckily, I got all the initial bugs worked out, and sent out the prototype to a few friends to try and break...and provide some feedback. For those interested more in the development side of things, I'm making the game in Unreal Engine 4, which is simply an amazing engine. Also of interest is that 100% of the character and environmental assets for the game are being purchased from the Unreal Marketplace. There's a lot of amazing content there (such as the Skeleton and Ratkin you can see in the image above). While this is limiting in some ways (nothing truly custom), there's a lot of great stuff in the marketplace that we can work with. I can honestly say that this is the most excited I've been about any of the projects we've worked on, including the games we've published, as well as the projects we've had to scrap. I'm looking forward to sharing more as we move forward. Shawn This article was originally published at Ding! Games. Shawn Greer is the lead designer and developer at Ding! Games. He's currently working on a project code-named Zeus, a puzzle RPG game for PC For more articles like this or to see more information, please visit their site.




Recruiting a Concept Artist for Zero Down: Part 1

This week's post is planned as a multi-part endeavor. My hope is that I have a follow up for you next week, but that will depend on how things pan out. As I discussed last week, our concept artist split ways with us. We're now looking to move forward with a different project (one perhaps just as ambitious, but in different ways). We're looking to make an RPG that takes a lot of its influence and pays tribute to a lot of the old school SNES games.

I talked the idea over with Brian, our 2D Production Artist, and he really likes the idea, being a huge fan of the genre and time period. However, while Brian is a fantastic 2D production artist, he is self admittedly not a great concept artist. It simply isn't his forte. This puts us in a bind. While we could "borrow" concept art from around the net, tailoring things to make it our own and letting Brian recreate things as he sees fit, eventually this would leave us without a unified visual style throughout the game.

This brings us to our 2 part problem.

1. We need a concept artist
2. We lack sufficient funding to hire/contract one through normal means

That is where this week's post comes in. I'm going to lay out our plan for trying to obtain a concept artist.

Let's start with some ground rules.

First, no blowing smoke. I know for a fact that a lot of people try to hire an artist by saying that working with them will be great exposure for their work, or some similar line. While there may be some margin of truth to this, that's a horrible selling point, and I know it. There will be no mention, discussion or suggestion that said artist should simply feel privileged to be working with us to get exposure. That's just lame.

Second, I can't promise money at a later date. While I feel that there is a lot of potential for this game, I can't promise any actual sales. I've seen people throw out lines such as "We're going to make hundreds of thousands on Kickstarter, and you will get your fair share". While it would be awesome if we made a ton of money, it's possible we won't make a cent.

Third, no vague terminology like "getting your fair share". I'll be straight up and honest, and offer a flat percentage of any revenue the game makes. No weird pricing schemes, no trying to cheat people out of any money (that we may or may not make). We'll even put it into a legal contract to ensure its binding. I'm looking for someone fun to work with, but I don't want anyone to feel like they may get screwed on the off chance we do make something successful.
Now on to the plan. What are we going to actually do to try and find this miraculous artist? Well we're going to take a multi-pronged approach and see if we can get anything.

Twitter: Twitter is great, and we're going to use it. In fact, Brian and I have already started pushing out some tweets. The trick here is to be relentless without being annoying. Two to three custom Tweets a day tailored to hit different hashtags is my initial thought. We'll vary when we send out the Tweets, trying to determine the best times to do so. If we don't get any results from this after a couple of days, we'll go back and reevaluate this approach to see if there's anything we can change.

Gamedev.net: This website is a very popular place for game developers (most notably indie developers) as well as other lurkers who are simply interested in various aspects of making games. For under $10, you can put up an ad that will last for thirty days. I'll be putting up an ad on the site, and we'll see if it garners any interest. We may get lucky here. After all, this is the exact same way we found Brian (or maybe it's better to say this is how he found us?).

Conceptart.org: A pretty cool site devoted completely to concept artists. They have a forum with a section for job offers. While a number of the job offers are for paid positions, they do allow offers for non-paid work (which is really what we're offering). I'll also be putting up an ad there, and we'll see if I can find any interest from that site.

Indieteamup.com: I'm not overly familiar with this site, but Brian recommended it, so I'll check it out. This one might be geared more for developers, but I'll take a look at it and post there too.

Dinggames.com: Come on now, I can't list everything else without at least plugging our own site. If you're reading this, and are interested in being a concept artist, or know someone who is, shoot me an email: ShawnGreer@dinggames.com

So that's the game plan. We're going to shotgun out across all of these sites and see what we get back. We'll keep track of what worked, what didn't and feedback we get. For anybody that does contact us back, we'll ask them how they heard about us, so we can track where we're hearing people back from. I'll provide a status update next week with all of this information.

Wish us luck!

Note: This was originally posted 1 Jun 2015 on www.dinggames.com. Also of note, the position has been filled. I'll write up the details in part 2.




Introducing Morpheus

Note: This is a repost from our website www.dinggames.com.
Original Post Date: 3/30/2015

Over the past few weeks I've dropped a few not-so-subtle hints about what our next project is going to be. However, I've just been saying that I'd talk about it more at a later time. Now, this isn't some grand reveal like you'd hear about at one of the big AAA studios. I'm not that egotistical (or at least I try not to show it). In fact, this is less of a big reveal, and more about me finally taking the time to write to you about it. So lets get to it!

Codename: Morpheus

We're sticking with our mythological gods as project code names in order to have some way to reference the game before it has a title. I'm big on not giving the game a title until some point in the middle of development, but it makes it easier to have some way to reference what we're working on with the team. As Morpheus is the Greek god of dreams, this works perfectly with our overarching story. Also, did anyone just think of Matrix and get a light bulb?

Now, I'm not going to go into all the details of the game, mostly because we're still working them all out, but here's the high level concept of the game. First and foremost, we're switching from Mobile to PC for this game. It was always my intent to only do one or two games on mobile before moving away from it, and I think we're ready for that. This is both a very excited and nerve wracking move, as it means we all have to step up our game. At the same time, it gives us a lot more freedom and flexibility that we didn't have on mobile.

Morpheus will be an RPG (or role-playing game for any laymen that happen to be reading this), with a strong emphasis on the story. We're looking to do a rather deep story, stretching my storytelling skills to the max. The main plot is about a young girl who is dealing with the loss of her father. The actual game itself will take place in a series of five dreams, each representing one of the five stages of grief. Within each dream, the young girl will be working to overcome that stage of grief and move on.

This basis has led us to some interesting design challenges that we've been looking at. First is the actual gameplay itself. Our primary focus has been for each of the five stages of grief (Denial, Anger, Bargaining, Depression, and Acceptance) to evoke those emotions in the player themselves. How do we present these emotional states and this story as a whole as an interactive story? By putting this within the base framework of an RPG, how do we utilize things like combat, experience and leveling, without breaking the player out of the story.

Well, I'd like to think we have some interesting ideas for how to tie all of this together. As I mentioned earlier, detailing out everything in this game is a bit beyond the scope of this blog post, I will give an idea of what we're looking to do. Here are three examples of some of the ways we're looking at trying to really tie the story into the mechanics.

First, we're looking at combining the players "health" and "mana" bars into a single bar, called emotional state. This both simplifies things, by giving the player a single resource to manage, but also adds a level of complication, as using certain abilities will cost the player emotional state.

We're also looking at tying character progression very closely to the story. As the player completes significant story points, they will be awarded with emotional points, tied to the dream they're currently in. These points will then be able to be spent to give the player additional passive and active abilities which are also tied to that dream.

Finally, we're looking at affecting combat itself within each dream. I'm not going to go into too much detail on this one, but we're thinking of making some small random fluctuations to combat that will differ depending upon which dream you're currently in. I know that's vague, but we're still reviewing these, so I don't want to give anything away yet here.

So that's just a taste of what our next project is going to be. I'm very excited about it, and really looking forward to getting some initial prototypes together to start testing things. Hopefully I have more to share on that in the near future.

Now, since this post has been all about things to come, I'm going to share a couple of other upcoming tidbits. First, we're completely looking to switch up how we're doing project management, version control, bug tracking etc. We're actually looking at doing a cloud server solution, setting up Perforce, etc. I plan to get that set up in the next couple weeks. Once I do, I plan to do a lengthy post here and the pros/cons, challenges, etc.

Second, and more exciting, I'm going to start live streaming in the near future. My plan is to set up a regular weekly time that I'll be streaming, with some odd random streams thrown in as I have time. I'm not sure exactly when that's going to start, but hopefully it will be within the next week or two.

That's all for this week. Take care and happy gaming!




One Step Forward, Two Steps Back

Note: This is a repost from our website: www.dinggames.com

This past week, Ding! Games has had a solid step forward, and two good steps back.

So the biggest news that I have since my last post is that we've brought two more people into Ding! Games. The first is Brian McIntosh. He's an awesome 2D Graphic artist and he's already started to produce some great looking art to replace the crap that I've got in there. Second, is Ellen Topitzer, who you may recall as the artist that did our logo. She's an awesome artist and is already hard at work doing concept art for the main character in the game (as well as some other things). The website has been updated, and you can see both of them in the "Meet the Team" section. They should both start blogging about their own journey in making this game as well, so be sure to look out for them and say hi.

That was our one step forward, now what is the two steps back? With new blood comes new ideas, and Brian threw us a curve ball by coming up with a really good one. I'd like to say that I'm simply an amazing game designer and that everything I come up with is gold. That is simply not the case. One day after joining the team, Brian sent the rest of us an email with some varied suggestions. Among them was a recommendation that we make the game a ground runner in addition to a swinging game, thus making the entry level to the game easier, but keeping the rewards higher for going to the heights and trying to swing. The idea had a ton of merit to it.

So this is where I give out some advice to the game designers out there. You have to know when to take input from someone else, even if that input causes your developer (who also happens to be me) to have to go back and redo a large part of what has already been done, especially if that suggestion will make your game better.

Now, does that mean you can always take input from everyone if it's good? No. Eventually you have to draw the line, otherwise you'll fall into the trap of always refining and polishing your game and you'll simply never finish it. However, in the earlier stages of development, making changes like this can prove the difference between a success and a flop (or at least I'd imaging that's true, since I don't actually have either under my belt).

This brings me my next piece of advice. Now this one I can say with certainty. Prototype your game and develop something that's actually playable as soon as possible. While your ideas may sound great on paper, the truth is, until you've done this a thousand times, you won't know if it's really good until you play it. That doesn't mean your prototypes have to be polished, functional or even look good (in fact, if they do, it means you're spending too much time on them). You just need to start getting something together with the core gameplay mechanics and let people play it, even if those people are the rest of your development team. If you're flying solo, then get some friends or family to play it. You'll eventually want a broader audience, but you simply need to get someone to play it as soon as possible.

We had a prototype before Brian joined us. It was after playing that prototype that Brian came back with his game changing suggestion. After we all agreed that it sounded good, I developed another prototype that included his ideas and sent it out to the team. Everyone agreed it was better, so now we're headed down that path. Success for all and score one for prototyping.

So what's next for Ares? While our artists continue making stuff so that the game looks cool, I'll be continuing to build the new prototype. Then our next big step is to have the game played by a group of playtesters. I'm not going to lie, I'm both excited and scared out of my mind. This will be the first time someone outside our immediate development team will play the game. I'll have my fingers crossed that they've got something good to say, otherwise it really will be back to the drawing board.





Welcome to the Business Side of Ding!

Note: This is a repost from our website: www.dinggames.com, from our business guy Mike.

I suppose I should start off with an introduction to me. I am Mike Greer, the man in the suit, fast talker, salesman, marketer, and conqueror of worlds. I was born in California and lived there until I was...actually I think that is too far back. Let's start with my business experience instead. I have worked in retail ranging from a cashier up to a store manager. I have also worked at a large corporation in the call center as a sales associate and moved up to an Inside District Manager of Florida. I received a Bachelor's from the University of Rhode Island for Business Marketing. What does this all mean you may ask? It means that I will be handling the business side of things for Ding! Games. It will be my job to help make sure our game gets proper exposure before as well as after the release and to help make it profitable. As much as I want to make games just to make games, I also want it to be profitable so that we at Ding! Games can make this a full time career.

What to expect from my blogs will be my journey in helping us gain exposure as well as my random business thoughts and practices. I have done a lot of research about what causes an Indie game to fail and the overwhelming results have been a lack of marketing and exposure. It makes me wonder how many amazing games are out there that no one knows about. I will warn everyone now that some of my posts might go off in to some random tangents, however I hope that anyone reading will learn something about us, about their own business, or simply be amused by my ridiculous nature.

Introduction done. Expectations set. So now we can get in to where we are at now. The website is up and you can see more on the trials and tribulations on that here. Now we have a sweet website and a sweet logo. (Side tangent incoming) Before I continue on I must give a shout out to the amazing artist that did our logo for us, Ellen Topitzer. I am very happy to announce that we have brought her on as a concept artist. Her artwork is inspiring in every way. Please check out her Facebook Page and her website (tangent over). Now that the website is setup we published our Twitter and Facebook pages which has been a ton of fun and quite a learning experience. The insights tab on the Facebook page allows you to see how many people your posts have reached as well as a likes tracker. Everything about the analytic side of a Facebook page has been very robust and I am looking forward to working with it more. If you haven't guessed it yet, social media is going to be our main marketing plan for the stage that we are in with Ares.

I have always been an active member of the social media community and now I get to use it for a greater purpose, making my dream become a reality. Video games have been a huge part of my life since I was but a we lad. Video games to me are an escape to another realm, a chance to hangout with my brother who lives across the country, or just a way to release from the stresses of life. They bring a smile to my face and for that amount of time no matter what else is happening in my life, I am happy. I want to make games that can bring happiness to other people the way games have brought happiness to me. I am finally starting to do this with Ding! Games and I could not be more ecstatic about it.

Moving on to the next business aspect that I am working on currently which is getting some money for start up purposes. My suggestion to anyone who is looking to start up any business is to do what we are doing and reach out to family and friends first. It will be easier to work with someone who already knows you and believes in you. Luckily, we do not have very high costs for starting the company. Most of what we need comes from the pro version of Unity as well as some other expenses Shawn needs on the programming side. Once we obtain the financial backing we need we will also be incorporating the business and becoming 100% official, aka recognized by the government as a business. That will be a very exciting day for me. I have always wanted to own a business and I could not possibly think of a better type of business to own. A quote that I have always thought highly of is, "Find something you love to do and then figure out a way to make money from it." Ding! Games is my step to living by this quote.

I think that is a good quote to finish the blog up with. Thanks for reading and I look forward to writing more posts in the future. The posts will be along the lines of how to grow and manage a social media following, marketing your company and game, as well as how to monetize your games.

You can keep up to date with our blog posts and development of Ares by liking us on Facebook and following us on Twitter.





Ding! Games - New Beginnings

This is a repost from www.dinggames.com. This one is a couple weeks old. I'm going to try and catch this new blog up to our only slightly less new blog on our website.

A celebration is in order! We finally got the website fully up and running and ready for public consumption. It's amazing how long this process actually took, how involved it was, and how much I didn't actually know going into it. However, before I go any further, I want to state right at the start, that Ellen Topitzer is simply amazing. Seriously, go check out her work! Mike is lucky enough to know her, and she developed the awesome logo that we're using. Her artistic skill is astounding. Go check her out at www.ellentopitzer.com and www.facebook.com/EllenTopitzerIllustration. Her dream is to make children's books, and I want my little girl to have her books. So if you're either in the industry, or know someone that is, you need to get her hired now!

Okay, that aside, I believe a bit of an introduction is in order. My name is Shawn Greer, and I'm the founder, lead game designer and lead programmer for Ding! Games. However, anyone who's observant and actually looks around this site will be quick to point out that I'm also the only game designer and programmer we have. But saying lead makes me feel more important. I started the company with two others. First is my brother Mike Greer, who is running the business side of things (and I'll let him tell you more about that himself when he posts an introduction) and my good friend, Josh Williams, who is our 3D artist (again, he can tell you more about that himself).

We're an indie game development startup, hoping to make our mark among the thousands of others out there developing games. All three of us are avid video game players, and we came together out of a strong passion to create our own games. At this point, we're pretty far into development of our first game, codenamed Ares (we needed something to call it while we're still coming up with a name). The game is a physics based endless runner game targeting mobile platforms. While our intent is to make a fun, polished game, one of our big objectives with this game is simply learning how to work together to make a game. While we all have some experience (of varying levels) in how we're each contributing to the game, none of us has ever actually made a game (that's partially a lie, I've done a lot of dabbling on the programming end, and even made a working version of Tetris - with extra features - in C++, but there were no menus or anything like that, so it only partially counts).

So what's the point of this website and blog, if we aren't a bunch of experts in our field here to dole out wisdom gained through years of toiling away in the game industry? Simply put, it's to chronicle our journey. All of us at Ding! Games will be writing blog posts on a regular basis, each throwing a shining light on our successes, failures, discoveries, embarrassments, and failures (I'm expecting a lot of those). If you're brand new to developing games, you can follow along and hopefully pick up the occasional useful tidbit (hopefully because we discover something awesome, but more likely because we share a blunder of something not to do, and you can learn from our mistakes). If you've been in the industry for a while, then maybe you find it a bit humorous and refreshing(?) to to see someone stumbling their way through the trenches that you paved the way for (and if so, feel free to offer up any suggestions or advice by responding to our various posts!).

Now, as I mentioned (wrote?) earlier, all of us here at Ding! will be blogging about our respective journeys on a regular basis. So we will be able to provide insight, or at least humor, about many different aspects of developing a game, from game design and programming (me), to modeling and animating (Josh), to the business stuff (Mike). Although, as you'll see in the remainder of this first post, because there's only three of us, there will be a lot of cross over and dabbling in other fields.

This brings me to this website. I am a programmer, yes, but I am not a web designer (which I'm sure is apparent). However, I was able to put together this website, which I think itsn't too shabby, due to a couple of amazing tools:
Bluehost: These guys are awesome, and I highly reccomend them to anyone looking to create a presence for themselves online. Not only do they provide some really great hosting solutions, their customer support is among the best I have ever dealt with. They are friendly, knowledgeable and resolve issues extremely fast. That's like the Holy Trinity of customer support! Check them out and use them.
Wordpress: I'm sure I'll be preaching to the choir on this one, but Wordpress rocks. It sets up an entire framework for putting together your webpage, so that you don't have to create everything from scratch. When we first looked into establishing a presence online, we looked (and spoke) with a few web developers. It was going to cost us hundreds, if not thousands of dollars to create a decent looking website. Wordpress enabled us to do it ourselves, almost for free (I'll get to that in a second). Could a professional web developer have made site a better? Of course! Yet as an indie game studio with zero income, not spending money on things is pretty nice. This allowed me (a complete nub when it comes to web development) to put together a rather decent, customized web page. Wordpress enables this by its use of themes, which come in thousands of flavors, both free and premium (that's where we dropped a few bucks, we really liked one of the premium themes, Avada). If you use Wordpress, awesome. If not, check it out.
So that's us. Ding! Games. Since I've gotten these preliminary introductions out of the way, expect to start hearing from us on a regular basis regard the game (called Ares for now) as we continue to make it. Also feel free to follow us on Twitter and like us on Facebook (my business guy tells me to say things like this, and he's pretty smart, so I listen). Feel free to toss us a hello, either in the comments below (there are working comments below, right?) or on the "contact us" page (which I'm about 99% positive is working now).

Thanks for listening to my opening ramble.




Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!